Your Path To The Right SAP S/4 Hana Roadmap

In my experience, this uncertainty stems from the fact that most S/4 Hana programs and recommendations are too technically oriented. They often focus too much on the product or application. Consequently, none of them can answer questions from the people deciding on a project of this magnitude and importance.

IT decisionmakers and CIOs are therefore facing a unique challenge: They have to convince their CEO and management of the necessity of migrating to a new software generation, even though most of their higher-ups are unwilling or unable to concern themselves with the technological aspects.

Green, Brown, or Blue? The differences between the three implementation methods and corresponding tools are not often known to management. And for most top decision-makers, the differences cannot be meaningfully conveyed or are of particular interest to them; not to mention that technologically speaking, either one of the three methods would theoretically be feasible.

It is crucial for a roadmap concept to offer suitable answers to any questions, not just ones about technological feasibility. In my experience, six aspects play a central role in finding a roadmap. Everyone wanting to migrate to S/4 Hana should consider them.

Strategy

At the beginning of any plan or analysis, companies have to ask themselves: What are our strategic goals, and how can IT help us accomplish them? It’s imperative that companies define measurable goals. They should steer clear of buzzwords like digitalization or cloud readiness and instead focus on clear goals, like increasing output by x percent by optimizing detail planning. The clearer the goal the better.

Defining goals is only the first step, however. Companies also have to ask themselves what their strengths are. An example could be the possibility of changing an order x days before shipment or delivery. To be aware of one’s own strengths serves to gain or keep competitive advantages.

To define measurable goals or find strengths, professional short interviews are suitable. They can be conducted by consultants who are used to working with top managers.

System landscape

Over time, every company develops their own processes. These processes have to be understood before they can be optimized. Existing documentation is supplemented by an evaluation and analysis of currently used processes and functionalities. Short briefings by employees can help as well, as they are often aware of intricacies and peculiarities otherwise unnoticed.

Consultants compare this newly gleaned knowledge with the previously defined goals. Based on their insights, they can start designing a new system landscape. In my opinion, two aspects are crucial here.

On the one hand, the new system landscape should be designed to not only accommodate SAP solutions but other systems as well. On the other hand, the actual feasibility with S/4 Hana has to be evaluated, for example concerning components only available in compatibility mode. During this analysis, consultants should install and run SAP Readiness Check. Afterwards, they can study and analyze its results as well.

Furthermore, companies should also compare their new system landscapes with SAP best-practice processes. This way, they can determine how many SAP standard tools and solutions they plan to use in their future IT landscape.

A live comparison with a company’s process experts in an S/4 Hana sandbox system would be perfect. This way, companies would get a clearer picture of how strategic and operative requirements would be implemented in the new software generation.

S/4 Hana migration scenarios and options

As a general rule, there is always more than one way to reach your goal. If you want to identify the right way for your company, you have to consider various criteria, including technological and organizational factors. However, you also have to take costs, complexity of the project, and risk tolerance of your company into consideration. For analyzing and evaluating these factors, a criteria catalogue or checklist are recommendable.

More often than not, options for companies are reduced to three scenarios: new implementation (greenfield), system conversion (brownfield), or selective migration (bluefield). In my experience, this isn’t very helpful, however. These ‘colors’ really only signal differences in technological system setups and data migration – and they only apply to migrations from SAP ECC 6.0 to S/4.

Let’s imagine the following scenario: Switching from ECC to S/4 is primarily an IT project. Existing and future system architecture are almost identical. In this case, more technologically focused approaches, like brownfield and bluefield, make the most sense – and greenfield can be omitted entirely. In a different scenario, where the company in question requires modern and standardized processes, decisionmakers might favor greenfield and cross out brownfield or bluefield.

Another important factor that many companies neglect to consider is the timing – when the decision to migrate to S/4 is made. The longer companies wait to switch to the new software generation, the bigger the differences between existing and new system architecture will become. This is mostly due to the extensive technological progress in S/4. In this case, decisionmakers should go with greenfield, as brownfield and bluefield are not suitable.

For dynamically growing companies, it can prove useful to define clear interim goals. If the company meets such an interim goal, it benefits from measurable added value – regardless of when it continues the journey to its overall goal of S/4.

Complexity and expenses

Involved expenses and costs should be calculated transparently and in their entirety early on – at least if your company has opted for something other than agile, process-by-process implementation. The focus should be on cost-increasing factors, such as costs of efforts by internal IT staff, licensing costs or operational costs of systems for the project duration.

It can also happen that more than one version of a new system landscape or more than one implementation method are feasible. In these cases, I recommend preparing calculations for all the possibilities to keep options open and make comparisons easier.

Minimizing risk

Every S/4 Hana implementation carries a certain risk, for example pertaining to associated costs and changes. The risks can differ on a case-by-case basis, as they are largely dependent on e.g. a company’s size or how many as well as which SAP systems it already uses. Every risk has to be recognized and evaluated.

It is crucial to also consider concerns of top managers, like operative risks, investment protection or sustainability of future system landscapes. If these concerns are neglected or omitted entirely, it can lead to strict limitations during the project – if a decision is made at all under these circumstances. A convincing migration concept therefore also takes the likely concerns of management into account. Furthermore, IT decisionmakers need to effectively prove that risks are manageable by proposing countermeasures.

Companies should compile and work with risk checklists. These lists can be adapted to a company’s specific requirements. Regarding bigger projects, it can prove useful to establish risk management as a permanent part of project organization.

SAP project organization

Professional project organization is essential for a successful S/4 Hana project. Roles and responsibilities during the project have to be clearly defined. They should – as a suggestion – be filled with possible persons from the respective company. This often shows where capacity bottlenecks threaten to happen. This is also true for competencies and committees.

Depending on project size, scale and type, roles and tasks may vary. Companies should always ensure that both business and IT interests are represented by respective experts. In bigger projects, it is recommendable to consider establishing roles with special tasks like change management, risk management or vendor contract management.

Especially regarding new implementations with a strong focus on SAP best-practice processes and digitalization standards, establishing a special committee in project organization can prove useful. This committee would be responsible for analyzing, evaluating and validating requirements outside the SAP best-practice standard.

To avoid dependency on external consultancies, companies can invest in building internal S/4 Hana know-how. Information and education about the new software generation should take priority over knowledge of the operation of existing SAP systems.

Sometimes, companies might experience capacity bottlenecks. In these cases, professional providers can take over application management services as backfill. This way, companies ensure that their internal staff can manage, operate and support the newly installed system professionally and independently.