Overview of Global SAP Template Rollout Programs

Most big multinational companies that implement SAP, try to move towards a single SAP system across countries and business divisions, as part of their Business and IT strategy. Companies create a common global SAP template which covers most of the business needs and do delta changes due to country specific legal or statutory requirements as template is rolled out. This blog is about various aspects of a global SAP template rollout program in brief.

 

 

Why do companies end up having multiple ERP system? It can be for various reasons including

1. Individual geographies or divisions working as separate companies without any overall IT strategy
2. Different business processed followed in different countries
3. Different power centers within company
4. Familiarity with locally procured ERP systems when company was small
5. Mergers & Acquisitions
6. ERP systems implemented locally due to budget, timeline constraints
7. ERP systems in local language
8. To keep control of ERP system with local team and have flexibility for quick changes.

 

 

Why do companies go for single ERP system? Some of the most common reasons are

1. Business decision to streamline processes globally 
2. Increased visibility across enterprise
3. Smarter analytics and quick decision making
4. Deal with lesser number of IT systems and interfaces
5. Reduce dependency on multiple IT vendors
6. Manage IT support centrally; build common resource pool
7. Employees can be transferred easily across countries or divisions.

 

 

Implementing Global SAP Template is a long time commitment of budget, resources and cannot be successful unless it is sponsored at highest level. Most companies spend lot of time and energy in choosing a reliable IT partner. However equally important is managing the change within the organization. Unless all stakeholders are brought on board and convinced, implementing a successful Global SAP template is an impossible task. You may spend millions on buying and implementing ERP system but will not get the benefits if people do not accept the change.

To give an idea of how big SAP template rollouts can be, consider the following  – (i) these are usually spread over 2-5 years timeline and (ii) total budget over the years can be anything from 10 MUSD upwards. Since these programs are executed over a long duration, they are likely to be affected by changes in company and business environment.

Global SAP template programs are typically executed over phases or waves. In each wave SAP is implemented in one or more entities. The first wave is usually the longest and challenging one since business and project team tries to define the global process by taking requirements from all entities. Each subsequent wave will normally have shorter duration and lesser delta functionality. The entities are bundled in each wave depending on various factors like (i) similar business process (ii) geographical proximity (iii) language (iv) total number of users etc. Also factors like local economic condition, any pending acquisition or merger, other ongoing projects etc are considering while deciding to include any entity in a wave.

In first wave, business requirements for Global SAP template are gathered after conducting series of blueprint workshops involving all entities. These workshops can be held at central location or in individual entities or both. However there should be few workshops where representatives from all entries are present in same room to agree on common processes.  Creating proof of concept in SAP is a good idea as it helps business teams to get first glimpse of SAP and also relate to things discussed much better. The project methodologies should also be defined in the blueprint phase.

After the global processes in SAP template are arrived at, the message should go out strong and clear that delta changes will only be accepted only if backed by strong legal or statutory reasons or severe impact on customer service etc. Typically 40-70% of the global template may be implemented in the first wave and delta functionalities added in subsequent rollouts.

Learning from previous waves should be incorporated in all subsequent waves and tweak project methodologies as necessary. Services of business team from previous rollout should be taken in blueprint and go-live phase of subsequent rollouts as they can be positive catalysts in earning trust of business team for new rollouts.

The importance of maintaining the sanctity of global template and master data cannot be overstressed in any global rollout. The long term success of a global template program often depends on this. Project should define stringent template governance mechanisms and put in place dedicated teams for this purpose . There should be defined mechanism to resolve any issues arising out of mismatch between global template and local requirements.

 

 

Success of any implementation and post go-live issues depend a lot on accurate requirement gathering and testing. Some of the best practices worth following are given below.

 

 

Requirement Gathering

1. Involve senior people with decision making power in workshops on requirement gathering; both business and project teams need to agree of variety of issues in such workshops. 
2. Document all business requirements and get signed off  from all stakeholders
3. Document all test scenarios and get signed off  from all stakeholders
4. Create SAP demo of critical scenarios and show in workshops
5. Clearly define and explain the change requirement process involved for any new requirement post blueprint phase

 

Testing

1. Freeze all configuration changes except those dependent of custom object creation before start of informal testing phase in development client itself. This ensures stable system for testing and does not bring surprises in later testing. Any config changes at a later phase should have proper justfication.
2. Ensure availability of correct master data from informal test client itself. We don’t need full set of data but at least sufficient to do proper testing.
3. Go for end-to-end testing of interfaces from informal test client itself so that all issues can be detected early.
4. In unit testing, integration testing and user acceptance testing use real life business data for testing i.e. don’t test with fictitious master data, condition record or quantities.
5. Test with real life volume e.g. if interface is supposed to transmit 1000 lines in one idoc, test with 1000 lines and not with 10 lines
6. Do lot of challenge scenarios and try to break the system. You cannot never imagine 100% what all may go wrong when new users try out the system