Abstract: Careful planning and preparation, a step-by-step migration with clear priorities, continuous monitoring, and employee training and involvement are essential for a successful implementation of S/4HANA.
As I explained in the introduction to BLOG 26, the “Red Thread” posts form a summary of the 25 previously published BLOG posts by project phase:
- project preparation -> concluded with the Project Kick-Off Meeting (see BLOG 26).
- scoping & prototyping -> completed with the end-to-end (e2e) process integration test (without RICEF and without connected sub-systems) (see BLOG 28)
- realization -> completed with the end-to-end (e2e) acceptance test (incl. RICEF and connected subsystems) (see BLOG 29)
- implementation -> completed with the go-live and the complete handover of the system to the business owners respectively the operational support organization (current article: BLOG 30)
This article is about “Implementation”.
Phase 4: Implementation of S/4HANA
After the system has been approved procedurally and functionally by the process owners or business owners in the realization phase, it can now be finally implemented. In my experience, this involves three important areas of activity in particular:
- training of the end users
- finalization and implementation of the go-live plan
- planning and organizing support for the production ramp-up
Training of end users
If you have followed my recommendation in the article on creating user documentation (see BLOG 25), you are well equipped to train the end users, because they can largely train themselves independently from the CBTs (Computer Based Trainings) that can be created with manageable effort on the basis of the user documentation. This simplifies training planning in particular, as no separate resources such as rooms and trainers need to be planned and the scheduling of training sessions can be omitted. All that needs to be done is to keep track of whether employees have completed and trained in the CBTs that are newly relevant to them. You can track this in a separate LMS (Learning Management System) or use the functions normally available for this in the authoring tool.
If you then also follow my recommendation for the migration (see BLOG 22), it will also be easy for you to provide the users with a training environment that is filled with the real master data and at least part of the transaction data to be initially transferred. My recommendation is to work with several clients here – a master, in which the data is built up once and which is periodically copied to one or more clients (e.g. one in even weeks and a second in odd weeks), in which the users can then train. I would not recommend using the test client itself for training, as this leads to otherwise avoidable additional complexities.
For employees working in shifts in production who have to make entries in the new system, e.g. in a PDC system, manned training stations in production have proven to be useful, where they can be trained before or after the end of the shift.
Finalization and implementation of the go-live plan
When creating go-live plans, I have always been guided by the following principles and have done very well with them – even in very complex environments:
– All steps that are technically and organizationally relevant are included in the plan. In particular, also activities such as the clearing of warehouses and the periods of parallel maintenance of master data. Responsibilities (responsible executor and accountable manager) are stored as well as the complete dependencies of the individual tasks among each other. In this context, I have had very good experiences with the use of MS-Project as a management tool for the go-live. In order to make the planning available to everyone and for updates, I have had good experience with Excel exports. With the right approach you can export a MS-Project plan well 1:1 to Excel. An example template, which you can use to understand what I mean, can be found in my Digistore24: https://sapxp.ch/asap-ms-project-plans-digistore24/ in the SAMPLE_Projektplan_Aktuell.mpp or xlsx from the project planning package. A dedicated go-live manager is responsible for the creation, ongoing updates to the go-live plan, and escalation of delayed activities. If the go-live goes across multiple sites, it is highly recommended to nominate a dedicated go-live manager for each site in addition to the overall responsible go-live manager.
– All steps for data migration, including all post-processing, are already completed in an evolutionary manner during the complete test migration runs, including data source, function to be used in the migration tool, and all pre- and post-processing. This is one of the reasons why it is so important to follow my recommendation for migration (see BLOG 22).
Finally, everything should be documented in such a way that the migration can be continued without any loss of time, even if a key member of the migration team is unavailable. The migration team lead or manager is responsible for maintaining and updating all migration-related tasks in the plan.
– As part of the go-live, NO physical inventory of stock is taken, in particular stock is not “counted” into the new system by physical inventory – this can only go wrong (even though it seems to be a widely held belief that this is a “good” practice). The book inventories are always documented, with all mutations automatically transferred to the new system. Only in this way can an audit-proof migration be carried out without unnecessary risks. If it is deemed necessary to perform a physical inventory, this can be done either in the legacy system before any go-live activities begin or in the target system after the go-live has been fully completed. Stocks that cannot be migrated 1:1 from old to new (e.g., due to WM, because new batch or serial numbers are introduced, or also because material numbers are split or merged) that cannot be easily posted directly to the new storage location/storage bin can be posted to a separate migration storage location (in the same valuation area) and from there posted automatically or manually to the final new storage bin/storage location after the transfer. This ensures that the reconciliation of the accounting stock accounts between the source and target systems, which is necessary for the release of the stock postings, is not unnecessarily delayed.
– Place a great deal of emphasis on the detailed conversion of the connected third-party systems (interfaces) from the old to the new system, as well as the associated data statuses and their resolution!
– The go-live and cut-over plan ends when the first activities in all essential functions have been successfully executed in the target system. These are in particular:
o The migration of the inventories and the successful reconciliation of the inventory accounts (this is THE go-live criterion, because from then on, postings will be made in the new system).
o The first MRP run
o The first payment run for vendors
o The processing of the last bank statements from the previous period and the transfer of the open items of the debtors that depend on them
o The transfer of all stocks to the migration storage locations (see above)
o The complete processing of the postings still to be closed in the legacy system (or in parallel)
o The migration of the main account closing balances from the legacy system
o The first month-end closing
– Although it is sufficient to plan the entire go-live on a day-by-day basis, the “hot” cut-over phase, during which inventory postings are generally not possible, should be planned on an hour-by-hour basis. I also strongly recommend planning to do a test run as a dress rehearsal at least for this “hot” cut-over phase!
Planning and organizing support for the production ramp-up.
Determine support needs early on, especially on site for the hot cut-over phase as well as for the production ramp-up. If you are going live at multiple sites at the same time and working multiple shifts, it can be very quick to be surprised by the number of resources needed when they do detailed planning. For each site, shift and function that needs support, plan the names of the respective supporters and also take into account that there needs to be another level on the backend to resolve the reported incidents that cannot be solved right on the spot. In particular, consider the language aspects as well: If a majority of the on-site supporters permanently need a translator next to them, this is not only resource draining, but also ineffective. I have had good experience with planning the go-live support early enough so that the additionally required (local) consultants can also support the integration and acceptance test on site and thus also familiarize themselves with the specifics of the processes and the site in their functions at the same time for mutual benefit. If you are going to have an external AMS service provider support your new system in the future, you should also involve them early on as a resource for the backend. I am even of the opinion that the latter should handle the incidents that were recorded after the accepted acceptance test and are not directly attributable to the migration and the cut-over, in order to have the handling of the productive tickets in hand from the very beginning.
The situation is similar with the incident management system, which should be identified, developed and used in good time. In many cases, incidents are managed in some system during the project, e.g. MS-Excel OP lists, and the final incident management system intended for later productive use is NOT used; the reasons for this seem to be manifold. In my opinion, however, this is a fatal mistake, because then …
- the users, key users and my internal support organization are integrated into the processes of the currently productive incident management system according to defined rules and are familiar with them and their operation.
- I (unnecessarily) increase the complexity immensely if I also have to plan and implement the changeover to another or even the introduction of a new ticket system during the go-live.
- the project resources supporting the production ramp-up do not have to deal with incident management in parallel in two different systems over a longer period of time.
- if I use the same ticket system, I automatically carry forward unresolved tickets to production (whether I then evaluate or prioritize them differently there can be decided at any time).
So please don’t make this mistake and use your ticket system intended for later productive operation to manage all incidents that occur, at the latest in the acceptance test (better already in the integration tests) as well as in the user trainings.
Please also remember to schedule time slots for escalation meetings with the process owners, the steering committee and the management at high frequency (initially on a daily basis) for the hot cutover phase and for the first few weeks of production startup. If everything goes super smoothly and you have a “boring go-live” because you have consistently implemented my recommendations from this BLOG, you can cancel superfluous meetings.
EPILOG
This post concludes the cycle of BLOG posts with my experience-based recommendations for a S/4HANA implementation based on best practice processes from my perspective. I am aware that in many posts of the BLOG I have simply given experience-based recommendations or even made corresponding assertions. This may seem unserious or arrogant to some (I would feel the same way) – but it is not meant that way at all. I am happy to explain the background of each recommendation and each assertion to you and to justify them. If you are interested in this or if you have any questions about individual procedures or tools, please feel free to contact me!
Please also forgive me if I have overlooked or deliberately not addressed certain aspects. Since the goal was to share my experiences with you, I have of course only written about them and what is important from my point of view.
And of course I’m happy about any other kind of feedback, like this one, which reached me via LinkedIn on 09/09/2022:
“Your blog … has really brought me further. Thank you very much! I am an expert in process management and many of my customers are in the process of converting to SAP HANA. I’m trying to bring both views of processes together and that’s how I landed on your blog. Let’s enjoy networking and getting to know each other. I also have a blog and am therefore even more pleased to have met a competent companion. Best regards S.”
IN ANY CASE, I WISH YOU A SUCCESSFUL COURSE OF YOUR S/4HANA IMPLEMENTATION AND THAT IT RESULTS IN A “BORING GO LIVE”!
AND IF YOU HAVE USED THE TOOLS FROM MY DIGISTORE24, YOU SHOULD HAVE SUCCEEDED EFFECTIVELY AND COST-EFFICIENTLY!
… And if it was so, do not forget to celebrate this duly with the project team. The money for it you have already saved in the project!