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?"
“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:
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.
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.
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:
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.
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.
This really has similar characteristics to decoupling by Division/Merchandise Group, however usually purchasing, invoice matching, transfers and allocations are your key pain points.
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.
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.
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.
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.