How to Understand The Misdirection on SAP Change Management
Executive Summary
- SAP uses change management to pivot away from the customization required for their system.
- SAP does this to keep customers from learning.
Video Introduction: SAP Change Management
Text Introduction (Skip if You Watched the Video)
SAP frequently uses change management to control perceptions on projects, including the fact that they constantly sell their software to customers with a poor match for their application. SAP proposes that all of the world’s best practices are contained within its applications, and any deviation from their applications is a deviation from best practices. Proposing change management is a critical part of SAP’s strategy for recovering from the fact that SAP sales promised that nearly all of the customer’s requirements would be met “out of the box.”You will learn how SAP uses the concept or accusation of the resistance to change as a cover for lack of functionality to meet customer requirements.
Our References for This Article
If you want to see our references for this article and other related Brightwork articles, see this link.
Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.
SAP and Customization
SAP has had a long-standing policy of getting customers to change their business processes to match SAP’s functionality. SAP exaggerates how much their software does and presents a false construct called best practices, which states, somewhat absurdly, that all best practices reside within SAP’s software. This absurdity is covered in the article The Basis for SAP’s Best Practice Claims.
After an SAP sales cycle completes, it is always found that SAP cannot do as much as it was proposed that it could do to meet the business requirements. In most cases, the consulting company’s requirements have been rigged, supporting the software selection to select SAP no matter the requirements. As users begin to push back on changing their business processes, SAP, along with the consulting company, will trot out the argument that the company is merely being resistant to change.
Change Management + Little Customization + Best Practices + Process Rearrangement to Whatever SAP’s Functionality Does
SAP is interested in fitting whatever their customer’s business process is into their software. SAP consulting companies want to maximize their billing hours, so they are pro customization, while SAP is anti-customization.
But overall, SAP has developed a very effective strategy where they use these various concepts to cut off a customer’s options and brand anyone who disagrees with SAP as fundamentally a problem. The options of a customer narrow even more after the software is implemented. At that point, a series of new restrictions are put into place.
The Challenge of IT Change Management
In the article by ASUG, which provided false information regarding a S/4HANA implementation for S/4HANA, some germane statements are made regarding how change management is most often explained and blended with other topics to control the behavior of SAP implementations.
“The key challenge in any “vanilla” implementation is acclimating people to an environment where they are adapting their work processes to a system, rather than adapting a system to their work processes. That means a change management strategy is as important as a technology strategy.”
This has been the boilerplate statement of SAP and SAP consulting companies for decades. It is challenging to find SAP implementations that don’t have moderate to extreme customization. And it is not like these previous projects did not have change management as a concept. Secondly, the issue of entirely relying on change management does not solve the problem.
There are often processes that do not make sense to change to SAP’s way of doing things. These may be key business requirements for the company that they can’t change. For example, ECC has always been weak in process industry manufacturing.
When Change Management is an Excuse for Bad Software
Change management is a frequent topic of conversation. It has become common to say this or that it is a matter of change management. The term is often used as a cover for a bad system. It has become routine for companies to choose software from SAP or Oracle without ever showing the software to planners, implementing it poorly with the help of a large consulting company, and forcing bad systems on the user community. This can be considered the IBM Systems Implementation Approach after this approach fails to get the users to use a system that provides the bad output. The individuals responsible for either the selection or the implementation like to use the term change management. Change management covers everything. It provides the political cover necessary to justify why the company cannot get value from the new system.
Good Products Enable Usage by Themselves
Not all products require change management. iPods did not. After they had been introduced, people found them very easier to use and improved over what came before them. No one has ever had to develop a workaround for an iPod because they are expertly designed and do everything the user wants. This is not to say that systems do not require training. I am a firm believer in investing in implementations, and more complex solutions need more socialization, as I describe in this post. This is not the same thing as change management as an excuse for bad software. I never use the term that way. I will say, “look, the software is weak,” not when a weakness is pointed out that “oh, that is change management.”
Use the Bad Things I Gave You
It is amazing how often I have discussions with people on systems that extremely difficult to use and very poor in functionality, and I am told that the users need more training on the system. Inevitably the next statement relates to the users “not getting it.” This gets back to an essential point, which is the following:
Did the users ever have a chance to use the system your selected before you bought it?
Almost always, the answer is no. I have an enormous observation to provide to people trying to get users to adopt any system. Let them try the different systems and provide their input into which one they like best. First off, this significantly improves the likelihood of software being selected, which the users will use.
Secondly, it puts the decision-makers in a better position because they can now say the users were part of the decision. After seeing this time after the time, the evidence is clear; users can select better systems than executives on selection committees or consulting companies that typically have financial ties to the software companies they choose.
How to Rig an RFP to Maximize Billing Hours
The RFP is a common feature of software selections. In this article, we will provide the truth about software RFPs.
The Truth About the Software RFP
When managed by consulting companies, the software RFP is critical to serving as justification for the software selection to select the software from the vendor that the consulting company has resources ready to bill for. We spend time talking about what software is right for the customer’s needs. However, why do we do that when Deloitte and Accenture, and so on have already decided on the software they want to implement?? That is why they and other consulting companies use the same RFP template. It’s based upon, you know, “best practices.”
The Peculiar Match of the Software RFP to Oracle or SAP
Isn’t it odd how often the RFPs match up so perfectly with either Oracle or SAP? And how those consulting companies primarily have consulting resources trained in those products? Did that software that Deloitte or Accenture or IBM or Infosys etc…turn out to be a bad fit for your company? Well, first, it was not selected for you. It was selected for the financial needs of the consulting company. But don’t worry. If you pay them enough money, they can make even the worst fitting application below average with enough custom coding.
The Greatest Software RFP of All Time
One of my favorite RFPs ever was put together by IBM Global Services. It compared an analytics application against a coding environment. The selection document’s logic was that you could create the same thing in the coding environment as the application. And you might have guessed at this point, but IBM Global Services had resources for the coding environment, but not for the application. So if the client chose the application, IBM GS would lose out on consulting hours.
I pointed out that this comparison made no sense and that you can’t compare a finished application to a coding environment. But the IBM consultants told me to think outside of the box. Telling someone to think outside of the box appears to be a reflexive statement used to defeat consistency questions. In the rock paper scissors of arguments, it is undefeated.
IBM Will Look Out for IBM
I will always remember a quote from an IBM Sr Manager on the project when I brought up some misrepresentation explained by the IBM partner. He said,
“IBM is going to look out of IBM.”
So remember that. If you bring in IBM, IBM is going to look out for IBM. They may pretend to be client-focused, but they do not feel any responsibility to the account. As a client, you might be paying them, but they are there for themselves. If they can deceive you, if they can backward engineer the RFP to maximize their billing hours, they will do it.
Adopting ECC Functionality for Process Industry?
Companies cannot simply adopt ECC’s functionality for process industry manufacturing because they don’t make any sense. Doing so would be a force fit that would leave the company unable to function properly. SAP is often confused, thinking that everything the company does must be sacrificed at the altar of how SAP works. However, there is a different idea, which the software should support what the company wants to do.
“The only way you can crack that nut is by not only having change champions within the organization but by also simplifying the solution as much as possible,” says Sharma. “People will accept change only when they know that their job is going to be easier.”
Here Sharma is commingling two issues into “change management.” One is the issue of simplification and change resistance, and the other is the company’s requirements.
Process Industry Example
In the example of the process industry, it is not a question of simplification of the process. The issue is that process industry companies perform manufacturing in a way that SAP does not effectively model. Any process industry manufacturing company that uses vanilla ECC or vanilla S/4HANA will lose money if they don’t customize ECC or S/4HANA or use other applications to perform some of the functions and then integrate back to ECC or S/4HANA. This example does not have anything to do with people resisting change to resist change. SAP and their consulting partners enjoy placing any resistance to SAP into the category of “resisting change,” but this is inaccurate.
Resisting change due to being set in one’s ways can occur, but it is not the majority of SAP resistance generally. The main reason for resisting SAP is that SAP cannot meet certain business requirements.
Conclusion
Change management is a euphemism used by SAP and SAP consulting companies to make customers feel bad because SAP’s applications can cover far less of the functionality than was expected during the sales process. I have personally been in multiple scenarios where SAP misleads the customer as to what certain functionality could do, and I have never seen SAP own up to this with a customer. Instead, SAP will blame some “miscommunication” that may have occurred.
In this way, the terms that SAP uses, such as “change management,” serve as propaganda that allows SAP to remove itself from criticism. The problem, according to SAP, is never that they mislead the customer as to what requirements could be covered by SAP functionality.
Secondly, SAP consulting companies support this perspective of SAP change management philosophy because they normally rig the requirements so that SAP will win the software selection. This is why companies cannot trust consulting companies to create RFPs for them. The RFPs will invariably lead to buying maximum services from the consulting company through the selected software. The removal of the software RFP would be damaging to the consulting companies. It would probably lead to better decisions and better outcomes, but as is often explained to me, it would be negative for the implementation “ecosystem.” An ecosystem is a vibrant community of consulting companies and value-added resellers that backward engineer software RFPs, overstaff projects and manage from the combination of the two most critical items in consulting — the billable rate and the margin hour.
Therefore, they provide the same false messaging as SAP regarding SAP change management. From this, the customer often believes they are receiving objective advice.