There are many myths surrounding an ERP implementation, regardless of which ERP system is involved. The myths and misconceptions that I encounter during the implementation of SAP S/4HANA are seamlessly linked to those from ECC times.
For example, many companies assume that this is a pure IT project that only marginally affects the business departments. Or that a deep and detailed planning automatically guarantees the success of the project. Just as persistent is the belief that the use of best practices is generally a saviour. What is truth, what is myth, what is really important for the success of the project?
Who is responsible for the S/4HANA Migration?
The implementation of SAP S/4HANA is always a major financial effort. Regardless of whether it is a new implementation via greenfield approach, a migration via conversion or a hybrid approach. Therefore, you need a sponsor for the project, preferably from top management. Often the sponsor gives the unfortunate IT manager the task of calculating a business case for the project.
BUT: In over 30 years of SAP consulting, I have never seen a serious business case for an ERP implementation that resulted solely from IT savings (e.g. system consolidation, standardisation)!
Reasons for implementing a modern ERP system
Experience has shown that effective leverage is primarily achieved through measures that affect the business departments.
- Simplification of processes (“do we really need this?”)
- Harmonisation of processes (“one business problem -> one process -> one ERP function”)
- Optimisation of processes (process innovations, automation)
- Quality improvements in master data (improved maintenance processes, avoidance of redundancies)
Groups of people involved in the S/4HANA implementation: business, IT and top management
The business is therefore not only needed in the project for writing the functional specification. It makes sense for IT to work with the business side to identify the company’s “pain points” before the actual S/4HANA project and to derive the goals for the project from this. This then also results in the “why?” of the project, a very important input for later project communication.
To ensure that the goals do not become mere lip service, which no one can or wants to remember in the later conception workshops, it is advisable to agree on clear rules of the game, for which a commitment from top management is essential. Such a rule could be, for example: “A local deviation from globally defined processes is only permissible in the case of mandatory local legal regulations.
In this context, the importance of process owners and key users in the company organisation cannot be emphasised enough. An ERP project needs clear contacts from the business and, above all, decision-makers who define a worldwide end-to-end process.
How detailed should the project planning be?
Who doesn’t know them: project plans in Excel or MS Project that contain thousands of tasks and in which human resources are planned to the week or even to the day? After all, the business needs to know that Mr/Mrs X will be needed for two hours and 15 minutes on Wednesday afternoon in three months’ time (a detailed agenda should be sent out eight weeks in advance).
Such detailed project plans do not survive the first contact with reality, and the project manager or the project management office are permanently busy with rescheduling.
The same applies to very long-term plans: In our fast-moving world, you cannot simply assume that a S/4HANA implementation project will be the top priority in the company over a period of three or more years. In reality, crises, strategy projects, mergers & acquisitions and so on always come in between, competing with your ERP project for attention and scarce resources.
Therefore, say goodbye to the idea of creating very detailed and long-term project plans. More important are
- the definition of a target picture (system and process landscape) that you want to achieve with the ERP project.
- a rough roadmap with important milestones. However, also be prepared for the fact that this roadmap will be subject to change.
- a detailed project plan for specific sub-projects and a maximum timeframe of 12-18 months.
- agreement with the business side
- on project quotas for the most important resources (e.g. 50% for a process owner)
- on fixed project days. The detailed planning of the content of the workshops should be done 1-2 weeks in advance.
How do you create the requirements functional specification for the S/4HANA project?
All requirements for the processes and procedures to be implemented are collected in the functional specification. However, the creation is seldom as simple as expected.
The "waterfall method" from as-is analysis to target concept to functional specification
In the ideal “waterfall methods” world, project life is quite simple: After an as-is analysis and a target concept, a functional specification is created and accepted. Its requirements are never changed afterwards and the IT can implement them in software, which can then be tested on the basis of the functional specification. If, exceptionally, there is a change, it is a change request that has to be meticulously justified and planned in case of approval.
So much for the theory. In practice, this only works reasonably well if the new ERP system takes over the processes of the old system almost unchanged.
However, since the implementation of S/4HANA also includes process optimisation, the business side is finding it increasingly difficult to write “watertight” specifications. This is due, among other things, to the increasing workload in the business departments, which have to manage the project work in addition to their daily business. This chronic lack of time has a negative effect on the detail and quality of the requirements and is the root of many change requests.
Often there are also communication problems between the business and the IT, which simply cannot find a common “language”. On the one hand, it should be possible to describe requirements in such a way that the business can establish a relationship to day-to-day business. On the other hand, the requirements must be so formally clear that they can be implemented in the ERP system. Ambiguity and misunderstandings turn the functional specification into a “moving target” for the IT with corresponding effects on the project schedule and budget. Fact is: the later the need for change is recognised (in the worst case, only during user training), the more serious the effects will be.
"Agile" approach as an alternative?
In face of this problem, can’t we just bury the waterfall approach and go “agile” instead? Unfortunately, agile project methods such as Scrum are often misunderstood by the business to mean that you don’t have to formulate any requirements at all or that you can change them at any time. Unfortunately, this is not the case. In addition, with agile project methods you have to accept that one of the following project dimensions must be variable:
- The scope (“we work with a fixed timeline and a fixed budget and see what comes out”).
- or the timeline/budget (“the functionality is given, but we can’t say in advance how long it will take and what it will cost”).
This will usually not be acceptable for projects as substantial as an S/4HANA implementation.
My recommendations therefore focus on improving the quality of the requirements and identifying any need for change as early as possible:
- Every additional hour that the business invests in the target concept pays off twice in the implementation phase.
- Use process visualisations to find a common language between the business and the IT. Swimlane diagrams from the Business Process Modelling Notation (BPMN) have proven themselves in practice. Do not make a science out of process modelling but choose a level of detail that is practical (maximum 10-12 functions per process, maximum 3 process hierarchy levels).
- Do not wait until the end of the implementation phase before confronting the business in a user test with the implementation of their requirements in the ERP software for the first time. Schedule regular presentations of prototypes and mock-ups (rapid prototyping), get feedback from the business at an early stage and provide buffers for changes in the project plan from the outset.
Benefits and limits of best practice and cloud
There are best practices (industry reference processes) for S/4HANA both from SAP and from some consulting firms. The S/4HANA Public Cloud also works with standard processes. Best practices and cloud solutions are advertised as significantly shortening the project times for an implementation. In particular, a target concept phase is largely eliminated; a short fit-gap analysis seems sufficient.
But are predefined standard processes suitable for your company? To answer this question, you should first classify your company’s processes in terms of their suitability for best practice. The method based on Gartner has proven itself:
The processes referred to as “bread-and-butter” do not give the company a competitive advantage; they often result from regulatory (example: advance VAT return) or administrative (example: ordering office supplies) requirements. For such processes, it indeed makes sense to use best practice processes within an ERP system or the standardised functions of a cloud solution (for example, for travel expense reporting). So you adapt your way of working to the system.
For competition-critical processes (e.g. quotation or service processes), on the other hand, best practices make little sense, because when using best practice processes you are by definition just as good (or bad) as your competition. Here it is worthwhile to adapt the system to your individual processes (be it by configuring the ERP system, by using add-ons/programme extensions or by connecting specialised third-party systems). Please note that different processes are critical for competition in different companies (depending on the industry and the company’s individual know-how and strengths).
So-called “game changer” processes have the potential to change the “rules of the game” in the industry or to create new business models (for example in the “Internet of Things” or “Machine Learning” environment). No “off-the-shelf” processes come into question for this. In addition, such processes will initially be implemented as prototypes outside of the naturally somewhat “sluggish” ERP systems in order to learn quickly from trial and error.
Is the S/4HANA implementation project finished with the go-live?
If you plan your project only until go-live and the project organisation disbands immediately afterwards, this will have consequences:
- The acceptance of the new system by the users will be poor because there is only regular IT support for the problems that naturally occur at the beginning. Bear in mind that especially the “smartphone generation” has little use for user manuals.
- If users assume that the project will no longer exist after go-live, they will try to push all conceivable requirements and special processes into the conception phase according to the motto “It’s now or never!”
Therefore, plan a hypercare phase with increased user support from the familiar project organisation right from the start of the S/4HANA implementation. It is better to save on user training and user manuals and invest in the training of key users and on-the-job training.
After the go-live, you should conduct lessons learned workshops with the business side, the results of which will be included in a Release 1.1 of the ERP software. Plan these lessons learned workshops from the outset. This will take the pressure off the project to have every exotic process mapped in the S/4HANA system by go-live.