Why Consider an SAP S/4HANA Rapid Move Approach when Starting the Transformation of your Finance Operations

Before I share my views, here is a quick review of what a Rapid Move approach is and why organisations are increasingly looking at it as a real option to adopt S/4HANA.

Picture Greenfield on one end of the spectrum, allowing full flexibility for transformation but taking longer to implement (and therefore costing more). On the other end we have Brownfield where the transformation is very limited which is why some call it a technical upgrade. Somewhere in the middle, we have the Rapid Move. I say somewhere because a Rapid Move project can sit very close to Brownfield or be more ambitious in the transformation and move closer to Greenfield. Essentially, a Rapid Move project copies the production environment into a new system without data (the empty shell), upgrades it to S/4HANA and, before the data loads and subsequent conversion, allows for some transformation to occur in the form of configuration and/or code development. The data is subsequently loaded into this new transformed empty shell (after it’s properly mapped) and the final conversion process is executed. With the Rapid Move approach, organisations really have a valid alternative when adopting S/4HANA.

Figure 1:  The spectrum of approaches to adopting SAP S/4HANA

Here are nine tips on what organisations should consider when leveraging the Rapid Move approach:

1. Align on project methodology

One can say that the above is true for all projects, but this is especially important with a Rapid Move project as it traditionally has many unique characteristics which require attention in methodology.

• Hybrid agile is proposed as the default methodology to be used in these types of projects. However, an assessment is necessary based on the organisation’s maturity with this way of working. If a hybrid agile approach is not a standard working practice, the start of the project could be delayed while the organization aligns.
• Is there a BPML (Business Process Master List) in use? Most organisations will have one, but a clean and governed BPML is an absolute must to manage the scope and execution of the project. In the end, this is not about introducing technology alone but standardizing, simplifying, and automating (where possible) finance business processes. It’s essential to identify very early on those processes that are going to be transformed and the ones that are going to be kept as they are (lift & remediate).
• Factor in contingency planning as no matter how many scans are done in the source system or how much understanding of the simplification list impacts, there are always unknowns that may arise based on the level of customization done.

2. Get the landscape and systems right

• Copy DEV from PRD. Don’t be creative in this regard.
• Have a clear strategy and governance to retrofit PRD transports back into S/4 DEV.
• Have a sensible transport approach supported by a best-in-class tool, like Rev-Trac, ActiveControl or SmartChange (no Excel spreadsheets please!!).

3. Decide on your key transformation items and don’t be too ambitious

• Choose the items that must be transformed straight away (to enable future capabilities) over the ones that can be adopted later.
• Make sure the organisation is ready for that change and is willing to advocate for it if needed.
• Remember that the bigger the transformation the more complex the project will become. This is true for all aspects of the project but particularly important for data mapping and migration which is always in the critical path.
• Clearly split between transformation scope items (at BPML level 3) and lift & remediate.

4. Get your data right

• Some data cleansing should, in theory, already have started many months before the project kicks off. If not, start it as soon as possible with a dedicated team.
• Take the opportunity to exclude unneeded organizational data like obsolete company codes, sales orgs, and purchase orgs. In the same way, be bold and don’t bring all the data history. This is one of the big advantages of a Rapid Move project, as we are not forced to bring all data history and can instead choose only what is absolutely necessary for the business requirements (one year of data for yearly comparison is recommended). Remember that the cutover windows are normally very limited so the less you bring the better.
• Be clear and always strive for simple mapping rules between ECC and S/4 for the transformed items (ledgers, chart of accounts, profit centres, cost centres, etc.). Take profit centres as an example: Mapping of 1:1 between source and target is ok and so is mapping many to 1. However, if you want to split profit centres (1 to many), how effectively can you define the rules and how are you going to reconcile the data after?
• Don’t forget to work material ledger into the plan with the appropriate resources. Experience has taught me that some changes may be needed in the source system if the organisation is already using material ledger (partially or fully).

5. Custom code remediation is an essential part of your agile sprints. However, service implementers that specialize in this task may not remediate custom code completely. Consider having a backup of functional consultants and developers to take care of the rest. Having existing documentation for each custom code will obviously be a plus but my experience tells me that this documentation sometimes is out of date or simply doesn’t exist.

6. Start planning integration testing early on, giving extra focus on the transformed scope items or those that simply run differently in S/4HANA (identified by the simplification list).

7. Start building a runbook for migration from the first (sandbox) conversion and update it as you go through the project and the remaining (many) conversions. This will need to run like clockwork as you approach cutover and go live.

8. Be excessively clear on communication internally to project team members as well as externally to the wider organisation. Lack of or ineffective communication on plans, milestones, status, and outcomes will significantly impact the project.

9. A Rapid Move project won’t take an organisation to the transformed end state but is rather the foundation where further transformation can and should occur. Remember that these projects have a “big-bang” go live so de-risking business operations must be a priority.

Conclusion

Rapid Move is here to stay and there’s an increasing number of organisations planning to follow this approach as they initiate their transformation journey. It can be the right mix of flexibility and control, accelerating time to value and minimizing business risk. At IBM/TruQua, we have delivered a large number of Rapid Move transformations and are therefore uniquely positioned to advise and guide you each step of the way.

Hope the above is useful and do reach out if you have any comments, concerns, or need help.

About the Author

Francisco da Cunha has over 20-years of experience helping global organisations reimagine and transform their finance functions leveraging SAP and SAP partner ecosystem solutions. Francisco focuses on making sure these organisations have the right systems solutions and business processes based on market’s leading practices, always taking into consideration the most recent technology innovations and trends.