- SAP uses change management to pivot away from the customization required for their system. They do this to keep customers from learning.
- SAP provides a false construct regarding change management which is directly connected to customization, best practices, process rearrangement to whatever SAP’s functionality does.
Introduction to SAP Change Management
SAP frequently uses the topic of change management to control perceptions on projects. In this article, 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.
SAP and Customization
SAP has had a long-standing policy of trying to get 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 requirements have been rigged by the consulting company supporting the software selection to select SAP no matter the requirements. As users begin to push back on having to change their business processes, SAP, along with the consulting company will trot out the argument that the company is simply 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 in fact, 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 to brand anyone who does not agree 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 commingled 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 extremely difficult 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 upon change management does not solve the issue.
There are often processes that it does 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.
Adopting ECC Functionality for Process Industry?
Companies cannot simply adopt ECC’s functionality for process industry manufacturing because they simply don’t make any sense for the company. Doing so would be a force fit, that would leave the company unable to function properly. SAP is often confused, thinking that everything that 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 requirements of the company.
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 either 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 simply 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 the resistance to SAP generally. The main reason for resisting SAP is that SAP cannot meet certain business requirements.
Change management is a euphemism that is used by SAP and SAP consulting companies to make customers feel bad for the fact that 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 mislead 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 terms of propaganda which allow 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. Which 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 software that is selected.
Therefore, they provide the same false messaging as SAP regarding SAP change management. From this, the customer often believes they are receiving objective advice.
Financial Bias Disclosure
Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.
Search Our Other SAP Content
Enterprise Software Risk Book
Rethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects
Better Managing Software Risk
The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.
Finding What Works and What Doesn’t
In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.
Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model