Why consider an SAP S/4HANA Rapid Move approach when starting the transformation of your finance operations

Throughout my 20-year career, I have collaborated with clients across multiple industries on various projects to transform their finance functions leveraging SAP solutions. I started with R/3, followed with ECC 5 and ECC 6 (with the significant emergence of the new general ledger). In 2018, I moved onto my first of many SAP S/4HANA transformations featuring all the wonderful new capabilities one can read in online blogs.

SAP S/4HANA projects themselves have many different flavors, like the most known Greenfield, Brownfield, SAP Central Finance, SAP Public Cloud and what we at IBM/TruQua refer to as the “Rapid Move”. I have worked full lifecycles for all these types of S/4HANA transformations. However, it’s Rapid Move in particular that I would like to share a few lessons learned, and some key watch points based on my experience.

Before I share my views, here is a quick review of what a Rapid Move approach is and why organizations 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—which ends up costing more. On the other end, we have Brownfield where the transformation is 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) and upgrades it to S/4HANA.

Before the data loads and subsequent conversion, it allows for some transformation to occur in the form of configuration and/or code development. The data is then loaded into this new transformed empty shell (after it’s properly mapped) and the final conversion process is run. With the Rapid Move approach, organizations really have a valid alternative when adopting S/4HANA.

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

1. Align on project methodology

One can say that this tip is true for all projects, but it's especially important with a Rapid Move project as it has many unique characteristics that 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 organization’s maturity with this way of working. If a hybrid agile approach is not a standard working practice, the start of the project might be delayed while the organization aligns.
• The BPML (Business Process Master List) is an essential component that most organizations use. Furthermore, having a clean and governed BPML is an absolute need to manage the scope and execution of the project. In the end, it is not about introducing technology alone but standardizing, simplifying and automating (where possible) finance business processes. It’s essential to identify early on those processes that are going to be transformed and the ones that are going to be kept as they are (lift and 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 can 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).

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 that the organization 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 becomes. This statement is true for all aspects of the project but is especially important for data mapping and migration, which is typically in the critical path.
• Clearly split between transformation scope items (at BPML level 3) and lift and remediate.

4. Get your data right

• Cleansing some data should, in theory, have already begun many months before the project starts. 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 approach is one of the significant advantages of a Rapid Move project, as we are not forced to bring all data history and can instead choose only what is necessary for the business requirements (one year of data for yearly comparison is recommended). The cutover windows are normally limited so the less you bring the better.
• Be clear and continuously strive for simple mapping rules between ECC and S/4 for the transformed items (ledgers, chart of accounts, profit centers, cost centers, and so on). Take profit centers as an example: Mapping of 1:1 between source and target is good and so is mapping many to 1. However, if you want to split profit centers (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 might be needed in the source system if the organization 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 might 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 is 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 items 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 process needs 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 organization. Lack of or ineffective communication on plans, milestones, status and outcomes significantly impact the project.

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

Rapid Move is here to stay and there’s an increasing number of organizations 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 many Rapid Move transformations and are therefore uniquely positioned to advise and guide you each step of the way.

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