One recurring theme in the world of large enterprise ERP is that of ERP system consolidation. Many global corporations have seen proliferation of their SAP or other ERP instances over time. Sometimes this is due to a legacy of decentralisation; often it may be a result of growth through acquisition.
In most cases, these organisations are seeking to rationalise and reduce the number of ERP systems they deploy, usually with joint objectives of cost savings and increased efficiency through the extension of common global business processes.
This leads us to a commonly quoted but often misunderstood scenario - the "roll-out" of a "global" SAP "template".
I have worked extensively with Clients in such programmes. This work has extended from the initial steps of defining a common global process model, to planning the roll-out programme, designing and building the SAP template, and executing the regional or global roll-out, across multiple countries and / or business units.
I have often been asked for advice on the "best practice" approach for executing the global template roll-out. This can be a big subject, but one good place to start is to make sure that everyone understands what is meant by these three simple words: global - template - roll-out. It is surprisingly common for different participants to have quite different perceptions of what these words mean, and this can cause serious misalignment of expectations as the programme progresses. Let's consider them here:
What is a Global Template Roll-Out?
Global - this usually implies the adoption of a common, shared model, covering not only the system itself but also the design of the business processes. This in turn means that someone, somewhere in the organisation, must start by designing this model. Such people are usually referred to as global or regional business process owners, and are often notoriously difficult to find, even in the best run organisations.
The use of the word global also implies that a strong, centralised driving force is behind the roll-out programme - one that is powerful enough to support the programme team in addressing the inevitable local resistance that is forthcoming during any such global initiative. So any ambitious "global" programme must be supported by a strong governance mechanism.
Template - when applied in an SAP context this word can mean many different things to different people. The starting point for the template should be the common process model, and it is important to clarify the expectations, rule and constraints that apply to the template.
One common misconception is that the term "template" is applied only to the SAP system itself. To be effective, the template must be defined more widely than this. The scope of the template includes the design standards, common master data definitions, the supporting (and re-usable) testing and training material, the governance processes, the roll-out methodology, and more. The template should be the complete package, not just the system.
Roll-out - the objective here is to benefit from the economies of scale and the reusability of the template package. Each new roll-out should not be allowed to become a new adventure and a re-invention of the wheel (this can arise by default if there is a lack of continuity in the roll-out teams and / or implementation partners).
The template should enforce the required standards and consistency, but allow some modest flexibility for local process differentiation due, for example, to country-specific legislation. But the roll-out is principally designed to spread the benefits of the common, consistent solution, and maintaining a focus on this is paramount.
During the roll-out, the integrity of the template must be protected by a strong governance approach and by (you guessed it) the business process owners, whose influence should be sought whenever the template design is significantly challenged. It certainly will be.
SAP Templates - Where do you start?
It is clear that the meaning "global template roll-out" will be interpreted differently by different participants, unless these terms are clearly defined in the context of your own programme. And no such roll-out can proceed on the technical merits of the solution alone. It's a major business programme, which requires strong, visible and sustained governance - not only to design and build the template, but also to protect and enhance it as it weathers the stormy challenges of roll-out.
So where do you start when you need an SAP template for a common solution roll-out? For most large enterprises there are usually two options - start with a new system, based on an agreed global core design, or start from an existing design, based on an established, locally designed system. Each option has its own pros and cons, as illustrated below.
Options for your SAP Template Foundation
I have often found it useful to describe SAP ERP systems in terms of some sort of shape (hexagonal is my current favourite). But in this context I will use a simple analogy by comparing these two template design approaches to a beachball and a snowball respectively.
Start with a new global design
In an ideal world you might start such a programme by getting key business leaders and process owners from around the globe in a room together, to start to build a common business process model, based on their collective experience and best practices. Involving the representatives of the future roll-out target businesses from the start is also a strong way to support buy-in.
I have worked with Clients in such "green-field" scenarios and this approach provides a solid foundation. Then the new global SAP template can be designed, built and piloted successfully in one business unit or market before being rolled-out to others, with a strong common core design and governance mechanism in support. It requires a significant investment up front, but - if done well - should provide a strong common template which supports the business consistency objectives and is sustainable.
The beachball analogy simply illustrates the fact that the core design is fixed up front - the basic shape of the template (beachball) is known and remains consistent. The initial template design phase takes sufficient recognition of global requirements that the core design either includes these directly, or at least leaves appropriate space for them to be added later.
The beachball will inflate as the system grows in size through multiple roll-outs, but the integrity of the basic shape (template design) is maintained - it will still be spherical, just bigger. And the care taken with the initial design also should ensure that the structure is strong enough so that the ball won't burst under the inflationary pressure of roll-out - it can bend and bulge a bit here and there if needed.
Start with an existing local design
In reality many organisations may not have luxury of starting this way with a blank canvas. They are where they are, and have to make the best of it. Frequently this scenario starts with identification of an existing system, and an aspiration to use it as a starting point for the SAP template.
If you already have several SAP instances, the question of how to choose which one should form the best template foundation can be an interesting one, but we'll leave that question for another blog.
It is not unusual for an existing active SAP implementation project in some part of the business to be suddenly commandeered by the "centre" and informed that from now on it will be positioned as the new global template. Although clearly the initial core design in this case may be local rather than global, the assumption is often made that additional processes and requirements of other countries or business units can simply be added to extend the scope of the template as the roll-out proceeds.
This can be a dangerous assumption, as it can often be the case that a locally designed template cannot fit a previously unanticipated global agenda very well. But even if the organisation structures and process design within the system can be made to fit in template terms, it can be much harder to instigate the necessary governance mechanisms when starting from a localised solution.
It becomes more difficult to counteract the "not invented here" syndrome, which may be quite justifiable because the roll-out target business did not have input to the original design. And senior management may have a tendency to assume that because it worked for one business, it can be made to work quite easily in another, without the overhead of needing business process owners and a maintainable common business process model.
In this approach the template is more like a snowball. It starts off small and grows significantly in size as it rolls out, and more processes and content are added by each implementation. But with reduced governance the risk is that these may be unique and customised rather than standardised, and our snowball starts lose structure as it (in design terms) gathers unwanted bits of sticks and dirt along the way.
If the slope (ie the roll-out challenge) is too bumpy, our snowball may get diverted from its originally intended course. And of course if the temperature gets too hot, then our template will start to melt...
If your business is a target for an impending global roll-out of a SAP template designed elsewhere, without your input, then one of your first actions should be to ask to see the template documentation which supports it. You would be surprised how often the template seems to have very little supporting documentation - even as simple as a basic business-oriented overview presentation.
If the roll-out programme cannot easily provide you, as a roll-out target, with a clear picture of the template and its shape, then it's not a template. It's a disaster, waiting to happen.
Know which shape you are
Is your SAP global template a beachball or a snowball? As usual, there is no simple right or wrong answer. You may be somewhere in between.
The beachball is the more strategic choice and is preferable if you can afford it, because of the global buy-in and powerful governance that can be engineered in up front. This gives the best foundation for template sustainability and ongoing programme success.
The snowball is a more tactical approach, and can be quicker and cheaper, at least in the short term. It is a popular choice when there is a compelling business need, such as an urgent need to integrate a recent acquisition. But the chances of sustaining a successful, long-term, common process and system template roll-out using this approach are slim.
This is because the same business pressures that led to the snowball approach being adopted in the first place also mitigate against investment in the necessary resources and governance which are required to sustain it.
The most important thing is to at least make sure that all those involved know the shape of the ball (the template) - and of the ballpark (the roll-out programme objective and approach). That way the right expectations can be set up front and shared, so that the benefits of the SAP global template roll-out can be maximised.
And, if your global roll-out succeeded with some other shape, I'd be interested to know...