Best Practice #1- Defining the Global Template

Most global SAP-programs are based on a template and deployment approach. The approach as such is hard to question, but there are a few potential pitfalls.
Far too many SAP programs talk about the Global template as the Holy Grail. From the view of the steering committee meeting, with the CEO, all sounds good. However, many of the programs have not defined what the global template must contain in detail. Some refer the content of the global template to the business processes, some to the documents to be produced, and others refer to it as entirely something else. If such a fundamental component is not defined in most SAP programs, how can you then be sure that you have delivered according to expectations?

A dependable Global template should contain, describe, and address truly the Global Business Processes. An attempt to portray a local practice as a Global Business Process and include it in the Global Template would not be beneficial to the project, in fact quite the opposite. Instead, select the truly Global Business Processes and make sure they are discussed and understood by SMEs in all regions / functions, and avoid creating a “corporate” template.

When designing the Global template, it would definitely be worth looking at unifying tools and systems to achieve a more homogeneous environment (though it may not always be possible) supported by (global) software and (global) hardware platforms. Even though sometimes it may mean more effort and (or) cost upfront, this will result in far more stable and sustainable solutions in the long run.
SAP announced earlier this year at SAPPHIRE that ASAP (Accelerated SAP) is to be replaced by the new SAP Activate. It is a combination of SAP Best Practices, guided configuration, and methodology optimized for S/4HANA. There are ready-to-run business processes optimized for S/4HANA, the configuration is guided directly in the system and the methodology builds on an agile way of working.

Best Practice #2 – Do not underestimate the power of Blueprint milestone

The traditional ASAP approach was based on a classical waterfall model representing a very structured implementation method, going through analysis phase, blueprint, build, test and go live. SAP announced that Activate is the new methodology where Agile is the prevalent method. I would strongly caution using Agile unless your team understands the cruciality of a solid and comprehensive Blueprint phase.

The Importance of Business Blueprint is very often underestimated by projects. It may be seen as a continuation of the project preparation phase where teams are still in process of being mobilized and at the same time as mere preparations to build or realization phase. This is one of the misconceptions that can cost the project dearly in later phases.
It is crucial to make sure the importance of a Business Blueprint is understood throughout the entire organization, and that the organization is committing the time / effort required; most importantly, committing the most knowledgeable resources it has. I cannot stress enough how important it is to have the best available resources on both sides – System Integrator and Client – especially during Business Blueprint.

Last but not least, and I understand that it’s not something a lot of projects would entertain (due to variety of reasons – cost, time etc.), but concluding Business Blueprint with prototype (or PoC as it’s commonly referred to these days) is of most importance or as well as complex Business Processes; having SMEs and decision makers witness “real deal”, would go a long way in understanding the solution and to ensure a successful implementation.

Best Practice #3 – Concentrate on end-end processes and avoid sub- processes

One of the main benefits with an ERP-system is the integrations cross sub-processes within the main process and from logistics to HR and Finance and towards basic master data. Another truth is also that system integrations normally are one of the most complex and problematic areas. I fully understand that there are often good reasons to have separate systems tightly integrated, but consider if possible utilizing the strengths in an integrated ERP-system where these integrations are ready out of the box. By trying to replace a business process step in an integrated scenario issues can be created in the process chain and cause severe design problems and costly re-engineering.

Experience tells us that sticking with standard ERP (SAP) functionality / business processes is a definite winner. Take a good hard look at your business process and try to answer, why you have been running it the way you have and more importantly, why can't aren't you running it as best practice may suggest; remember hundreds or even thousands of companies similar to yours are using this functionality. You are probably not going to be able to avoid customization altogether but keeping it to an absolute minimum is a good idea.

Best Practice #4 - Make sure the basic foundation is defined and decided on very early and based on a solid analysis and understanding of business requirements

Your SAP-system is built with a number of different IT and business components that need to be defined and decided based on the future business requirements. It is obvious that the hardware platform is one of these components that needs to be defined, but the business processes and the ability to analyze the KPI’s across countries in a harmonized way is dependent on how the enterprise structure is defined. Before you have defined and agreed upon the fundamentals around instances, clients, operating concerns and controlling areas, the business processes and the analytics should not have been defined yet.
Unfortunately, I have seen projects where decisions regarding these areas have been taken without proper analysis or the magnitude of getting these things right has not been understood by the decisions makers.

As a result, many enterprises have systems unable to support the needs of the future business. The consequences are very often an expensive re-engineering and redeployment project, where the system more or less needs to be rebuilt from scratch. This has become even more important in today’s hybrid environment where cloud decision becomes part of the matrix.

Best Practice #5 – Select your pilot site carefully and make sure your first site is a success

Global template should be a live pilot using a real site and not a theoretical one. By using an approach of a live template for the selected pilot site you avoid tests based on fabricated data, and academic and fiction processes. Therefore, one of the most important decisions to make early on is the pilot site for the project.

This approach still needs global alignment on certain design areas, securing the key global stakeholders and being aware that too much time spent on consensus kills the momentum. The go-live of the pilot is, of course, critical and the success will become a sales tool that lays the foundation for other divisions and the team that has been a part of the success will be the game changer towards the new culture and the new way of doing business.