This article contains an explanation from elfware CEO Hamish Cameron of various Oracle Retail cutover strategies, previously an answer to a question in a Q&A. In particular, it focuses on the different features of a phased cutover versus a ‘Big Bang’ cutover, as well as offering methods to reduce project costs and ensure cutover success.

Hamish is concerned with understanding and communicating the transition risk landscape and agreeing a combination of cutover approach and mitigation activities which appropriately balance risk and cost for an organisation.

Q: "We are implementing Oracle Retail, replacing an in-house legacy application suite in which retail applications such as Merchandising, Inventory Management, Pricing, Allocations, Assortment planning etc are tightly coupled to core Master Data tables.

We are steering away from big bang, but can you advise on what approaches we could take?"

‍

Response

“The biggest two questions to consider when cutting over are: how agile is your current legacy and integration landscape and how big is the appetite for mitigation?

Typically I believe phasing a cutover actually adds more risk, as it requires significantly extra work and the costs escalate and/or the quality processes going in to each state then reduce.

Phasing an implementation reduces cutover risk but has other big impacts I'll refer to later.

In particular doing anything apart from Big Bang requires a significant amount of:

1. Transition planning - define the states, what is performed where in each and how will you transition from one to the next
2. Change and Training - you will need to prepare change activities for each state including preparing and executing training. This is not just for users but also application support and integration teams.
3. Testing - end to end testing is required for processes and integration in each state, including reporting visibility. That means UAT (User Acceptance Testing) as well as technical and integration testing 
4. Development - Mostly this should be legacy and integration plus interim reporting, but you'll typically be surprised by how many downstream systems are impacted that hadn't been considered. It really depends upon your organisation's ability and appetite for decoupling existing capabilities into multiple transition states.
5. Support - I've been going in reverse order, but after each state transition it is key to stabilise support for the state, and validations, reconciliations and operational reporting may well change between each state.  Data integrity issues may well also cause delays to the next transition.

So you need time, capability, organisational commitment, Oracle Retail and Legacy architectural expertise and budget to make it feasible to mitigate by phasing your implementation or your cutover.

Alternative 1: Phasing your Implementation 

If you have plenty of time then you can plan upfront and execute each state as a sequentially separate project over a timeframe - it becomes a significant Programme Executive undertaking to persuade business stakeholders why a long running project with a large price tag is unlikely to deliver benefits in a typical retail timespan.

Alternative 2: Phasing your Cutover

If you don't have plenty of time, then you will need to execute in parallel ... and that's where the fun really begins with people designing, building and testing for multiple states in parallel across multiple environments in order to be ready to execute the cutover sequentially.

With that said I've been involved with different approaches over the years, for example:

1. Decouple by System

This is the most advisable approach where possible.  It really comes down to ensuring all processes in each system are covered in the relevant transition state and that interface commissioning/decommissioning is well planned and executed.

2. Decouple by Division/Merchandise Group

Works where the divisions have largely separate legacy systems with low levels of overlap, so probably not feasible for you.  If you try this by splitting out from a single integrated application I suspect you will open a ‘Pandora’s box ’of modifications and testing.  Normally the issues will come in POS, sales transaction auditing and reporting, but depending upon your current legacy systems, it may also impact purchasing, invoice matching (and/or accounts payable), inventory, transfers/allocations, pricing/promotions, e-commerce, planning and finance ... you name it.

3. Decouple by Location e.g. Brand/Country

This really has similar characteristics to decoupling by Division/Merchandise Group, however usually purchasing, invoice matching, transfers and allocations are your key pain points.

4. Decouple by process area/functionality

e.g. Item and Master Data followed by pricing/promotions, purchasing etc in some order and then the transactional layer.  

This is the most common approach taken.  It absolutely works but I'd refer you back to points 1. to 5. above - it is very expensive and has fundamentally undermined projects at a number of retailers causing the implementations to be paused and not achieving objectives.

‍

Other mitigation approaches we have taken:

‍

5. Simulate transition to production and production runs a multitude of times

Automating all aspects of integration testing, validation, reconciliation and transition allows it to be tested within an inch of its life through transition and a month plus of realistic data a multitude of times.

‍

6. Parallel Run

Execute an automated parallel run where data is fed into RMS (Retail Merchandising System) via a combination of data migration scripts and the integration layer from legacy with isolated processes double keyed or enriched in the RMS (Retail Merchandising System).

This can be significant effort and can be fraught with complexities in the mappings and integrity between legacy and RMS, typically resulting in quarantining which requires legacy, mapping or RMS correction to release.  That can be an overhead and result in reconciliation difficulties due to timing etc.  So as the parallel run continues more data will typically get out of whack.

Conclusion

‍

The most appropriate implementation mitigation approach depends upon a number of factors, not all of which are covered in this brief overview.

Absent very good reasons for doing otherwise (such as disparate application and integration landscapes) generally I would recommend approach 5. Simulate transition to production and production runs a multitude of times as the automation tools are readily available to implement this strategy.

To offer a greater level of risk mitigation this can be done in combination with 6. Parallel Run, but it does require a greater appetite for such mitigation as it will take both additional time and budget.

‍

---

‍

Hopefully Hamish's discussion helps you to understand a little more about the transition options for an Oracle Retail Implementation. If you have further questions, feel free to contact him on LinkedIn or send him an email.

Oracle Retail Implementation and automation related IT services are elfware’s forte. Using our implementation experience in combination with the elfCafè platform and approaches, our team will optimise your implementation, application management and resolutions for your most complicated bottlenecks, as we have for similar organisations from all over the globe.

Click here to visit our main site, or here to contact us and discuss how we can assist with your Oracle Retail journey.

‍