In continuation with the blog that I posted last week, I will introduce the next SAP project best practices gathered from my own experiences acting as project manager and in other advisory roles in larger SAP programs over the last 20 years.
Best Practice #6 – Try to cover end to end processes and avoid processes that are cut in between
One of the main benefits with an ERP-system is the integrations cross sub processes within a 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 sometimes good reasons to have separate systems tightly integrated, but consider if possible utilizing the strengths in an integrated ERP-system where these integration are ready out of the box. By trying to replace a business process step in an integrated scenario can make violence in the process chain and cause severe design issues and costly reengineering.
Best Practice #7 – Make sure the basic foundation is defined and decided very early and based on a solid analysis
The SAP-system is built up by a number of different IT and business components that need to be defined and decided based on the future business and IT 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 cross 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 to mention a few the business processes and the analytics should not even start to be defined. Unfortunately there have been projects where decisions regarding these areas have been taken without proper analysis or the magnitude of getting these things right not has been understood by the decisions makers. As a result, many enterprises have systems unable to support the needs of the future business. The consequence is very often an expensive reengineering and redeployment, where the system more or less needs to be rebuilt from scratch. This has become even more important in today’s hybrid environment with parts of the processes or data on-premise and parts in the cloud.
Best Practice #8 – Use a step-by-step agile approach with firm milestones
The traditional ASAP approach was based on a classical waterfall model representing a very structured implementation method, stepping through requirements capture, analysis, design, coding/configuration, and testing in a strict, pre-planned sequence. The issue with this approach was that it was often based on long Business blueprint and Realization phases where no or very limited interaction with the business stakeholders took place. This caused an obvious risk that the solution was misunderstood, that the stakeholder not were engaged and that the solution at the end not was according to expectations.
The new ASAP and also the new SAP Activate builds on an agile way of working. Use it! Break down the project scope into small increments and deliver them in time boxed iterations. This will not only create a better understanding and a better commitment it will also push the project members to focus on the milestone in 1-2 weeks than on a milestone 2-3 months away. Compare this to the mantra in sports of focusing on the next game.
Best Practice #9 – Select your pilot site carefully and make sure your first site is a success
To my experience the Global template shall be a live pilot and not a theoretical one. By using an approach of a live template for the selected pilot site you avoid tests based on fictitious data, academic discussions what should be included for the specific processes and master data etc. Therefore is one of the most important decisions to be taken very early in a large scale SAP implementation, the one related to the pilot site (plant, legal unit, country, unit etc).
Of course, this approach still needs global alignment on certain design areas, anchoring with key global stakeholders etc but be aware that too much focus on consensus costs, kills time and have the risk of losing momentum and focus. The go live of the pilot is of course critical and the success will become a sales tool that lay the foundation for other sites and the team that have been part of the success will be the bearer of the new culture to implement systems and the new way of working.
Best Practice #10 – Define what the Global template is and what it’s not
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.
Define what the global template is and what it’s not. Far too many SAP programs talks about the Global template as the Holy Grail and from a “cloudless” view in the steering committee meeting with the CEO it sounds good. But, far too many programs have not defined what the global template is supposed to 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 something else. If such a fundamental component not has been defined, how can you then be sure that you have delivered according to expectations? I will not get into the details of what a SAP Global template shall contain in detail in this article, but stay tuned I’ll come back on this topic!
SAP announced earlier this year at SAPPHIRE that ASAP 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. If Activate delivers what it promises then it’s definitely a step in the direction to close the gap between reality and Martin Cobb’s paradox!