Design Thinking in SAP Implementation
CHAPTER 1
I have spent more than a decade in SAP consulting and during this time, I have been involved in at least a dozen implementation project in various capacity and based on this experience, I can say that successful implementation is more about meeting the client expectations rather than technical and business solutions. In some cases, they are one and same but adding to woes of SAP consultants, good solutions and client expectations are not always one and the same.
If you don’t agree with this or want to understand why there is a gap, you just need to look into a mirror. You see, we all are users and we use various services every day. Several consultants and experts are trying constantly to make those services better and yet we resist to change. Maybe not always but more often than we want to agree. It is easier to digest the change if it is gradual and small, but a sudden jump is hard. I am using smartphones since 2010 (started late I know) and I have always used android. I am waiting for android 8 update but if someone wants me to start using Apple's iOS, I will be reluctant. Hell… for me switching from Windows 7 to Windows 10 was also painful and I only did because I was compelled to do so.
It is a human behaviour to cling to the old and resist the new. In case of SAP implementations, it is usually the case. SAP is much more integrated and organized from a typical legacy software. A lot of industry users are not even technical people, for them, the software is just a tool to do their operation. And they want to complete their job fast. However, after SAP implementations, they had to work in an integrated fashion which means entering more data and maintaining a stricter structure. It helps the organization but it does not always help the user in their day to day job. When it does make their job easier then user loves it. They readily accept these changes. If the user acceptance is low then the solution – no matter how good and innovative it is, will be termed as a failure. Lower user acceptance leads to lower productivity which finally hits the quarterly result and then the big bosses get worried and they call the SAP consultant and tell them about the bad job they have done usually leading to further changes or reverting back to old legacy systems.
For 11 years, I have worked for a big MNC and painfully I have seen years of hard work getting rolled back or left unfinished because users do not approve the solution. In this case, usually the SAP vendor takes worst hit but everyone loses. SAP, the client and the vendor and the SAP consultant (here we come). If you indulge me, I will dare to say that this is the reason for 75% of implementation failures and I am saying this knowing well that SAP has limitations and the SAP vendors are not always hiring the best of the talents (even if they proclaim it in bold letters). I say this because most of the failures are attributed to two main issues:
Mismatch in client expectation and the actual solution.
SAP implemented solutions are sometimes not the latest solution available.
And both of this happens because of how a typical SAP project is implemented. The requirement is gathered from the users and generally, after that it takes more than a year for the SAP implementation to complete. In this time, the smaller legacy vendors have implemented many new features which users now automatically want and obviously the SAP consultant is not aware of. Second, the requirement gathering itself is flawed. SAP consultants ask the user to explain the requirement and freeze it. The flaw is asking the user. They have their normal jobs and suddenly someone asks them to explain their business process. Even if they try their best, something is lost in translation and this happens at every stage. After “gathering” the requirement, SAP consultants show them a demo how it may work in SAP and try to “freeze” the requirement by drafting requirement documents and taking a sign off. A typical waterfall model.
If you are an SAP consultant, you know how the requirements change on everyday basis and it is hard to develop a solution if we keep incorporating the constant changes. A requirement sign off acts as contract commitment and it pins the responsibilities of respective shareholders and it can be used by project managers to track the progress. So, it does have a lot of merits and so it persists. But, in the end, it is all about user acceptance. A contract may be fulfilled, and payment is done but if the project fails, as I said – everyone loses.
We need a better system.