Lessons Learned from S/4HANA Cloud Implementations
I was watching the classic film Back to the Future the other day and I began to ask myself the inevitable question that everyone asks when seeing that movie: “If I could travel back in time, where would I go and what would I do?”
Would I invest in Google?* Would I watch the signing of the Declaration of Independence? Would I convince myself to ask Becky to the Prom? These were all worthy choices. However, because this is specifically an SAP blog and because we are constantly trying to provide business value to our customers by learning from both our successes and challenges, I would humbly answer the question as follows: If I could go back in time, I would travel to the summer of 2016 when we began our SAP S/4HANA Cloud journey. I would then locate my 2016 self and provide “me” with the following bits of wisdom.
If the shoe fits, wear it; but if it doesn’t, don’t try to squeeze into it.
While the solution is continually evolving, Multi-Tenant S/4HANA Cloud is currently best leveraged when the customer’s business needs are effectively captured within existing or near term published road map Multi-Tenant S/4HANA Cloud functionality. When applied in this way, the software fits and implements quickly and efficiently.
When shoe-horned into non-existing Multi-Tenant S/4HANA Cloud functionality or nuanced industry specific needs (a.k.a. Oil and Gas production revenue accounting or Fashion garment sizing), the pains of required process workarounds or “Influence Requests” due to incongruent functionality threaten to overcome the benefits of the multi-tenant solution. Don’t forget that the Single Tenant Edition is an excellent and viable approach to pivot to when the business can’t fit into the Multi-Tenant Edition scope. Cinderella’s sisters were wrong to try and squeeze into that glass slipper.
What may seem simple at first, probably isn’t.
Data migration is not as simple as filling out the template spreadsheets. The spreadsheets often contain multiple tabs and the data in each row must be consistent across the tabs. Business users have a difficult time reviewing these spreadsheets to confirm data, and errors can be difficult to spot.
In addition, there is no data dictionary to define each data element (aka column header). As a result, and especially for companies moving from a non-SAP system to SAP S/4HANA Cloud, it is imperative to have migration template review sessions with the client data migration team and SAP functional experts prior to beginning any data migration efforts. With proper preparation, the process can be simplified significantly, but still won’t be simple.
Agile is not just a way to describe your yoga instructor.
Overly aggressive timelines, set by business users not familiar with the effort to implement an ERP, are dangerous but can be worked with. First, listen to the implementation experts and set business user expectations accordingly, not the other way around.
If there is disagreement, take a step back and start by evaluating an Agile approach to bring in scope successively over time, hitting business deadlines with minimum viable product until the entire solution is rolled out.
SAP Activate is built for this Agile methodology approach and it should be leveraged accordingly. Of course, if that approach still won’t meet business requirements, bring all the proper stakeholders together to align expectations with realistic deadlines, or consider stopping the project.
ERP implementation is a game the whole family can, and should, play.
Your integrator should not do the project for you or, worse, to you. If the business cannot commit subject matter experts to the project, the project should be put on hold. Further, the subject matter experts should be on-boarded completely during the prepare phase – going through online training to get exposure to the application and their specific scope items of interest, prior to the Fit to Standard sessions in the Explore phase.
Also, important to note is that ERP projects, whether simplified via S/4HANA Cloud or not, can become a game of attrition if allowed to. Engage a trained Organizational Change Manager to assist with keeping the implementation team energized while also readying the business to accept the inevitable changes.
John Hancock was on to something.
Getting signatures/sign-offs throughout the project is critical. Have business users formally sign off on all design/configuration decisions, user acceptance tests, and training completions; a signature tends to get proper attention to these critical steps.
While decisions made during a project won’t all warrant a formal, sign-off, they should be consistently documented and communicated.
Decisions, large or small, made in project team meetings or impromptu issue resolution meetings, tend to get lost and often re-discussed. While the same decision will likely be reached, with the only cost being the lost productivity of revisiting something that was already decided, it is possible that people won’t remember the circumstances of the decision and further issues could arise. Have the project manager keep a decision log, including the date of a decision and the team members present. The decision log should be a part of regular status meetings and reports. Overcommunicate.
What’s good for the goose isn’t always good for the gander.
SAP allows and, actually, encourages customers to submit “Influence Requests” to bring the true voice of the customer into product management decisions. And while this is an excellent practice, it is important to remember that a request is just that and does not ensure it will be accepted. Just because one business believes that a certain capability should be enabled in the Multi-Tenant Edition functionality, that does not mean that most businesses will need the same functionality.
SAP must balance each request with market need as well as technical capability. Of critical importance is that the project not be put on hold for these requests as they take time and, even if accepted, may be put on the roadmap for a release that comes after the scheduled deployment. Hope for the best and plan for the worst, ensuring that there is a back-up plan (such as process workarounds or side-by-side extensions) in case the influence request is denied.
S/4HANA Cloud is more than software – it is a new way of partnering with SAP.
The project must take into consideration the SAP Support Desk as project team – considering what time zone they are in, how they will staff over holidays, how to best communicate and more. SAP also supports projects and the ongoing lifecycle of the solution after go-live with Preferred Success; they are an integral part of the team during and after the implementation. This approach is a new paradigm to provision of ERP as a service and provides tremendous opportunities for leverage.
Lastly, I would remind myself that even though there is no such thing as an easy ERP implementation, S/4HANA Cloud Multi-Tenant Edition makes ERP implementations easier and provides countless additional benefits to the business once implemented. So, while I may or may not go back and ask Becky to prom, at least my S/4HANA Cloud implementations would all benefit from my recently gained wisdom.
*Investing in Google would be a VERY close second