Paths to the SAP Roadmap

In my experience, the uncertainty stems from the fact that many of the programs and instructions are too technically oriented. They are too strongly oriented to the product or the application. The problem is: In this way, they hardly provide answers to the questions of those who decide on a project of this size.

Many IT managers or CIOs are thus faced with a challenge: They first have to convince their board or management that a changeover is necessary. But the decision-makers are not usually concerned with technical issues.

Green, Brown or Blue? The differences between the paths and tools are usually not known at management level. And the differences cannot be communicated in a meaningful way or are of particular interest. In addition, from a technical point of view, all "colors" are always possible anyway.

It is crucial that a roadmap program provides suitable answers. This is expressly not just about technical feasibility. In my experience, six aspects play a central role. Anyone setting out on the road to S/4 should take them into account.

Strategy

At the beginning of every consideration and analysis is the question of a company's strategic goals - and how these goals can be achieved with the help of IT. At this point, it is crucial to formulate measurable goals.

So it's not about buzzwords like "digitization" or "cloud readiness". Instead, it is about concrete goals such as "increasing production output by x percent by using optimized scenarios for detailed planning". The more precisely the goals are formulated, the better.

In addition to fixing the goals, it is indispensable to also name the strengths of a company. One such strength could be: the "possibility of changing a customer order up to x days before shipment or handover". Being clear about one's strengths and recording them serves to maintain competitive advantages.

To find out and formulate the measurable goals and strengths, short interviews "at eye level" are suitable. They must be conducted professionally. These interviews can be conducted by consultants who are experienced in dealing with top executives.

Target Landscape

Every company lives and develops its own processes. These processes must first be understood. Existing documentation is usually sufficient for this purpose. Additional information is provided by an evaluation of the processes and functions currently in use. Short briefings by employees also help. They often know the specifics of the company best.

The consultants match this knowledge with the previously developed goals. In this way, they can design a target system architecture. In my view, two aspects are particularly important here: First, the target landscape should not be developed with SAP in mind alone.

On the other hand, the actual availability under S/4 must be checked - for example, for components that are only available in so-called compatibility mode. As part of these analyses, the experts should install and run the SAP Readiness Check. They can then study and evaluate the results of the check.

In addition, a rough comparison of the target landscape with SAP best practice processes is recommended. In this way, it is possible to find out how high the proportion of the SAP standard is in the planned IT landscape.

A live comparison with the company's process experts in an S/4 sandbox system would also be perfect. In this way, for example, the question of how strategic and operational requirements can be mapped can be clarified.

Changeover scenario and options

Basically, there is always more than one path that leads to the goal. Anyone who wants to identify the right path for their company must take a variety of criteria into account.

These include system-related or organizational influencing factors. However, the criteria also include the costs, the complexity of the implementation or the company's willingness to take risks. Criteria catalogs and checklists are suitable for analysis and evaluation.

Often the options are reduced to just three scenarios - namely New Implementation (Greenfield), System Conversion (Brownfield) or a Selective Migration (Bluefield).

In my experience, however, this is not very helpful. The reason is that the "colors" only reflect distinctions in technical system setup and data migration - and that only from SAP ECC 6.0 to S/4.

The following case: Switching from ECC to S/4 is primarily an IT project. The source and target system architectures are also congruent or nearly identical. In such a case, technically oriented methods such as Brownfield or Bluefield are the most suitable - and Greenfield is probably out of the question.

In another company, however, the need for modern or standardized processes is enormous. Here, the decision would probably be more in favor of Greenfield - and Brownfield and Bluefield rather ruled out.

The timing of the decision also plays a role. The later the decision is made to switch to S/4, the greater the differences between the source and target architectures.

This is mainly due to the technical progress under S/4. In such a case, Greenfield would also be more likely to be considered - and Brownfield and Bluefield would be rather unsuitable. In the case of dynamically growing companies, it can also make sense to set concrete interim targets. If the company reaches such a goal, it already realizes measurable added value - regardless of when the journey to the goal is continued.

Effort and costs

The costs and expenses should be calculated at an early stage - and as fully and transparently as possible. This applies in any case if it is not an agile, process-based startup. The main focus should be on the cost-driving factors.

These factors include the costs for the internal effort of the company's own IT, licensing costs or also the operating costs for the systems during the project term. Sometimes several variants of a target system architecture come into question. Often there are also several options for the changeover. In such cases, it is advisable to prepare option-specific calculations.

Minimization of risks

Every S/4 implementation also entails risks. This applies, for example, to the associated costs and changes. The risks can vary - for example, in relation to the size of a company or the extent to which it already uses SAP. All risks must be identified and named.

It is important to take into account the concerns of top management - for example, with regard to operational risks, investment protection or the future viability of the target architecture deployed.

If the concerns are not heard, the necessary decisions may not be made or may only be made under strict conditions. A convincing changeover concept therefore takes management's concerns into account. Even more: The risks must be shown to be manageable through appropriate measures.

Companies should work with appropriate risk checklists. These lists can be supplemented individually. For larger projects, it may also prove useful to establish risk management as a permanent part of the project organization.

Project organization

The professional organization of an S/4 project is essential for the success of the project. The intended roles and responsibilities in the project must be clearly described. As a suggestion, they should be filled with possible people from the respective company. Impending bottlenecks in capacities often become apparent at this point.

This also applies to the delimitation of competencies and the composition of committees. Depending on the project type and scope, the roles or the content of the tasks will vary. However, companies should always ensure that business and IT representatives are represented by their experts.

For larger projects, it is advisable to think about special roles. These include, for example, change management, risk management or vendor contract management.

Particularly for new implementations with a strong focus on SAP best practice processes and digitization standards, it is advisable to include another committee in the project organization. This committee should review and validate the requirements outside of the SAP best practice standard.

To avoid dependence on external consulting firms, companies can build up knowledge carriers with expertise on S/4 internally. In doing so, training with regard to the new should take priority over the operational running of the existing SAP systems.

Sometimes capacity bottlenecks also occur. In such cases, professional providers can be called in as "backfill" to temporarily take over application management services. They ensure that the company's own organization can operate and support the newly installed system professionally and independently.