SAP: Master or Puppet?

I must warn you before you start reading the text below that it mostly relates to “core” SAP systems, such as SAP ECC, BW etc. It may not be relevant to new-wave technologies like HANA, Ariba, Fiori, mobile… you will understand why.

In my life, I have taken part in multiple SAP projects. These were greenfield full lifecycle implementations, roll-outs, extensions of existing functionality, reviews, or just one-off problem solving consultancies.

I have seen how SAP is implemented in different companies, and what the approach to SAP implementation is. Of course, it varies, but more often than not, it can be categorized into 2 types.

SAP is a Master

If a company tries to follow SAP’s standard business model, then it can be considered as “SAP is a Master” model. In this case, the company understands that SAP has accumulated best practices from all over the world in its 40 years history. In short, this model can be explained in a phrase “If the business process does not work properly in SAP, then the process is wrong and must be changed”. Of course, if the company follows this approach, then SAP implementation mostly means change management for the business. Lots of business processes have to be reviewed, analysed, streamlined and reorganized. It is a painful process, often a REALLY painful process. But as a result, SAP technical implementation becomes easy, almost like a walk in the park. The number of bespoke developments in the system is low, and the number of “tricks” and manual intervention in the process is low.

SAP is a Puppet

If a company considers itself as unique, then most often company management tries to use SAP as a tool to achieve other (not always business-related) goals. Subsequently, lots of existing business processes in the company migrate to SAP “as is”, without analysis and review. The approach is to use “SAP as a puppet” in users’ hands.

The most common explanation of why this happens is “our business processes are unique and they are our competitive advantage”. As a result, SAP implementation becomes a rodeo where consultants need to tame the users’ requirements and literally put a square peg into a round hole sometimes. The technical SAP implementation becomes a nightmare. It means lots of customer-specific developments, lots of manual steps in the process, lots of headaches.

Business users think that once they state their requirements as “it must be like this”, their part of implementation ends. It is not so. This approach backfires. Business users need to test and re-test the developments, explain requirements again and again to different team members. That is chaos.

Who is responsible?

You would be surprised, but sometimes either consultants themselves, or salespersons of consulting companies, are responsible for the chaos they create at customer side. Why?

Consultants may have not enough knowledge of existing SAP functionality or soft skills to convince the customer their best move is to follow the SAP standard logic.

Salespeople may have pressure from company managers to sell more ABAP developers to the customer, as they have a bench. Of course, nobody will ever confirm this.

How to fight this?

Even though you as consultant may not be responsible for the sales process, you may control what is happening on the project when you arrive there.

Let’s assume you have knowledge of company business and SAP functionality. You see that users press for the bespoke solution where a business process change may make SAP standard solution usable. How can you explain the users that they are wrong? Ask them to explain the reason. Very likely the answer is “because I need to send this report/spreadsheet/document to another person”, or “I am not responsible for another part of the process, there is a separate person to do this”, or “it was done like this since the Romans era, hence it is the only correct way”.

Do not be lazy; try to track the path and the use of report/spreadsheet all the way to the final point. Check what value the second person in the process adds. And then tell users (and their managers!) a story…

Once upon a time, there was a group of scientists. They took a box and put a dozen of rats there. Then they took a piece of cheese on a rope and started to lower it. As soon as rats started jumping for the cheese, all the rats were showered with cold water. Eventually, rats were trained that they should not touch the cheese until it reaches the bottom of the box.

Then, one rat was replaced with a new one, who was never showered before. Scientists started to lower the cheese, but… the new rat did not jump! One by one, all the trained rats were replaced with new ones, and none of new ones ever felt the cold shower. Nevertheless, no single rat jumped when scientists lowered the cheese. Why?

Because it was the rule out there!

It means that “it was done like this since Romans era” is not a proper explanation of the reasons. If there is a better way to achieve the business goals with SAP, it should be employed. Or users should find the real reasons (cold shower) to do things differently. SAP implementation is not for the end users’ convenience, but for the management decisions. The better the process – the better and cleaner the reporting to management gets – the better management decisions are.

What is the approach to SAP implementation in your company?