Let's get in touch.
Norbert Kytka, Headquarters Plattling
Contact
Christopher Stangl, tell me why I need a rollout strategy? Is it not possible to just roll out SAP systems without a 'strategy’?
I would not advise anyone to try and proceed without first defining an SAP rollout strategy. The majority of our customers are international companies with multiple locations. You need to decide which locations you’re going to handle first, and which will come later. It doesn’t matter whether you’re carrying out an initial installation or upgrading your systems, you always need to make this decision. The big question is: What’s the best way to plan the rollout sequence? People often think of beginning with headquarters, but in fact that’s not always the best starting point, even for a first installation. We need criteria to help us define the right sequence and approach the rollout efficiently, economically and with the lowest possible risk.
What criteria can I use to define my procedures for the rollout and when developing my SAP rollout strategy?
There are ‘hard’ and ‘soft’ factors. The hard factors you can assign weights to and evaluate in a matrix. We start from an analysis of the current situation. What does the system landscape look like? Is it a hybrid landscape resulting from gradual acquisitions and changes over time? Or perhaps we want to roll out at a company with five locations and three different ERP systems?
After that, we assess various criteria. For example, we might consider whether the system landscape includes legacy systems which will soon no longer be maintained, or where the one employee who knows how to maintain them is looking at retirement.
Other criteria are determined from legal requirements, especially nowadays, in a constantly changing world. We need to keep a constant eye on events like Brexit or new regulations in our own legislation, since our ERP and finance systems must always follow the regulations. That means we need to be aware when our international locations might be affected by changes that would involve a lot of manual effort or a high investment to implement in the legacy systems, or even if they would not be implementable at all.
There are many criteria like this that need to be taken into account for an SAP rollout strategy. Another example is compliance: will the existing systems still comply with regulations in the future, or can you already see that it will be impossible to implement new regulations? For example, it might be clear already that it is just not technically possible to implement the permissions concept needed to handle future data protection regulations.
Do you also take business factors into account in this analysis? If so, in what way?
Yes, we do look at business factors when developing the rollout strategy. For example: Are there new requirements from the market? What do our client companies expect? Are there areas where they can only achieve what they want with a major investment in their existing system?
We have some suppliers among our customers. What’s happening in the sector at the moment is: Lots of automotive suppliers are trying to get orders from Tesla. These suppliers need to remodel their systems to handle e-mobility, and that means adding new processes and methods in various places. If you were formulating an SAP rollout strategy at this point, it would make sense to prioritize the relevant plants for the rollout, to ensure that the new business area was being launched on the strongest possible foundation.
Other good candidates for early rollout are sites that have been established recently or are expected to grow rapidly for some particular reason. If your site is going to double or triple in size in the very near future, it makes sense to support this growth with a new system, and not struggle to crowbar everything into Excel spreadsheets or obsolete systems. This only makes it harder and more complex to transition later on, and transitioning after major growth is riskier.
The same applies if you are planning major upgrades or expansions to the technology at a site, perhaps as part of Industry 4.0 initiatives.
What role does risk management have to play when developing a rollout strategy? After all, SAP systems are generally business-critical systems.
Risk considerations have a major role. Of course, we need to understand exactly what the repercussions might be if the rollout is held up. We determine how many sites are affected if, say, work is held up at an assembly site that is supplying three other sites with goods. This might not have such major consequences as a delay in the rollout at a pre-production location that is part of the same company and supplies ten production sites with modules.
What about the soft factors – what is their role in developing the rollout strategy? For example, the employees’ attitude to change at the various sites? After all, introducing SAP systems is always a major change.
These soft factors have a highly important role. There are many dimensions to a rollout, from technical changes and new processes to organizational changes. It’s only possible to manage everything if the people involved are enthusiastic about change. I’m always looking to find people who are enthusiastic about being involved in change, to act as the “beacons” and encourage the process with success reports.
OK, I have an overview of the criteria involved in developing the SAP rollout strategy. What comes next?
The customer knows their organization much better than we, the external consultants, do. We discuss the criteria with the customer and work with them to develop a weighting scheme. Depending on the company’s organization – centralized or decentralized – we may also work on this weighting with the local site representatives. We then use this weighting scheme as a basis for defining the rollout plan.
What timescale should I estimate for developing the rollout strategy?
We plan around three to six months for this process. This is a timescale with plenty of time to develop and discuss different scenarios. It is almost unheard-of to actually implement the first scenario we look at, we are talking about an iterative process. An SAP rollout strategy is often the start of a collaboration that will continue long-term. It has a stable foundation but should not be seen as a rigid framework.
The organization needs an outlook, or perspective; the sites need to know when they will join the move towards the future. However, change is generally the order of the day in a flourishing business. We have customers whose rollouts we have been supporting for a decade. The SAP rollout strategy evolves along with the businesses themselves over time: acquisitions, mergers, new sites, etc.
Based on your experience, what “do’s” and “don’ts” can you suggest for developing a rollout strategy?
The “do’s”: We need a clear picture of the personnel structure in the organization: where are the young trailblazers looking for change? Who are the ones who would like to, cling to the old ways for a couple more years before retiring? This kind of ‘soft’ knowledge is extremely helpful.
We also need an accurate understanding of how the customer’s business operates. Where are the predetermined breaking points? Which departments are essential to keep things from grinding to a halt? Where are the bottlenecks that could result in downtime?
What about the “don’ts”?
The biggest “don’t” for an SAP rollout strategy is trying to do too much. For example, I wouldn't try and crowbar new SAP systems into every location in the country in one go, if I have three quite different organizational units there. I’d rather schedule in a couple of extra rollouts.
