While planning and drafting the roadmap for your ERP consolidation program, i.e. an SAP Template Rollout approach, you generally have two opposite options:
Either (a) you parallelize your individual rollout projects as good as you can (see figure 1). This approach means you have the same start date and the same Go Live date for a certain number (greater than one) of your total set of rollout sites.
Or (b) you execute each one after another one completed (see figure 2).
Of course, there is a third option: you execute your projects overlapping (i.e. a new one starts before another one was finished).
There are specific advantages and disadvantages.
The parallelized approach makes the program faster, it shortens the time schedule. This is the biggest benefit. But there are significant costs to be considered: This approach demands a lot more staff, not only the consultants by the service provider, but more important the business process owners and key users. There are few companies able to staff several projects for the same moment of time!
But the biggest disadvantage of the sequenced approach (option b) in a one single client single instance system is the huge risk of transport management conflicts. During Go Live support in rollout x you have already created some transport requests in your quality assurance or integration system for the rollout x+1. These were company code independent ones. Now, you are forced by an urgent Change Request of the productive site (rollout x), to make a customization and a corresponding transport request. It can so easily drive a serious transport management conflict and you must transport customizing settings of rollout x+1, which were never tested! A huge risk for your productive plants! And, this risk is valid for both, the one-after-another and the overlapping approach.
Of course, this risk is always there. But you can imagine that it is much higher in the time directly after any Go Live date. This is presented in figure 3.
Therefore my suggestion is: Execute your rollout projects in parallel, if you can. We made really good experiences with this approach in a lot of company groups, e.g. in the Automotive, Consumer Goods and Chemicals industry. But there are some pitfalls to be avoided!
Pitfalls to be avoided:
- Do not under-estimate the demand for resources in the parallelized approach. What ever the company representatives are promising: there are never enough process owners and key users available. And, they have to travel a lot from site to site. No time for holidays in between.
- Do not under-estimate the time you need for data migration. In a one single instance single client system with a parallelized approach you must consider the upload for a big number of data migrations possibly in a short cutover time frame. Take care during planning the project schedule!
- Have an eye on knowledge transfer. Going on-after-another you generally have the chance to rollout with just one team. But in the parallelized approach you have to train the rollout teams working concurrently, and you have to consider the time and budget for this knowledge transfer in your project plan!
- SAP Managed Tags:
1 Comment
