Skip to Content
Author's profile photo Former Member

If the shoe does not fit, must we change the foot?

Gloria Steinem said that, and not me, and she probably didn’t have SAP projects in mind when she said that. However, the way some customers approach SAP projects, it does come pretty close to it.

Just before SAP became the most popular way of improving the fortune of corporate houses, the stage was already set nicely by stuff like Re-engineering and TQM. I remember standing in queue at a book shop near my home to get a copy of the Hammer and Champy classic on Re-engineering. And my dad used to give me TQM manuals that his friends sent him from Japan, and the Deming and Juran books. TQM and Re-engineering were both brilliant ideas – and I was firmly convinced, coming out of college, that corporate world is going to be a lot different from the one I watched my dad worked in. While things did change in corporate world, I have serious doubts whether TQM or Re-engineering really gave the kind of benefits it promised. Sure – there were shop floor improvements etc, and lean six sigma etc did create some good value. But I don’t think it revolutionized corporations as advertised.

There were several SAP projects that started in mid nineties as part of re-engineering efforts in the company. These were top-down strategic imperatives, exactly the kind that Hammer and Champy said would work wonders. SAP’s major pitch was – and is – that SAP already has best practices in-built . Several companies thought the fastest way to successful re-engineering was to adapt their business process as closely as possible to SAP’s standard processes.  The primary theme of SAP projects was to find the gaps between As-is and To-be (as in SAP) processes, and do necessary enhancements to get to the future state.

This seemed to be a logical path at the time – at least to foot soldiers like me. But I soon realized that this does not always work as planned. The trouble with top-down planning is that it needs strong leadership and commitment at all levels of the corporate chain of command to succeed. This is seldom true in practice though.

For starters – not every one who is affected gets a seat at the table to determine scope. For example, the COO who wanted SAP logistics probably did not know the day-to-day troubles that the packers and truck drivers solved on their own. So these problems were never part of the scope given to the people implementing SAP – and consequently, the problems would surface only at the end when it was kind of late to solve it.

Now about the business process part itself. Not all business processes are great the way they are implemented – and there is some scope for improvement. But that is not the same as saying SAP’s business process is the best for your company and that you should switch to these. If every one followed the same exact process, there is very little that would distinguish one company from another – and this is clearly not ideal. So, companies have to judiciously decide which processes can be treated as commodities and which have to be kept as competitive.  This is where the Gloria Steinem quote especially rhymes true.


For SAP gigs to succeed, employees should be considerably empowered. Management usually buys into that idea  readily at the beginning of the project – and gives them the power to decide. However, at the first failure point – things go back to how they always worked.  The most common reason is that employees who have a full time “day job” are asked to also do the project job. Now if they were to choose between fire fighting on day to day issues, and doing the project role – guess what they would choose. There is also the flip side of this. I have also seen employees being terribly afraid of re-engineering ideas for a variety of reasons – like job security, and disliking the idea of making them do more work for the same pay and benefits.

It is also critical to get the right relationship established with the consultants helping with the re-engineering and associated SAP implementation. Consultants bring the ideas that worked well from other projects – but only employees know how it would fit their company. If employees dismiss every idea brought to them, they won’t benefit from the wisdom that the consultants bring. If employees blindly follow consultants’ advice – you might build processes that don’t really fit your company. It is a delicate balance – and it needs a lot of commitment to be successful.

How much ever you like SAP, it is hard to keep chugging with no end in sight. Unless releases or waves of functionality are well planned and tightly executed, and employees rotated to something new periodically, it is hard to keep up the morale. It is also kind of hard when you have to move from one stressful project to another. So companies have to keep this in mind when they plan their projects. Companies who ignore this do so at their own peril. Encourage your inhouse SAP experts to be active on SCN, ASUG etc – and to attend and present at SAP events. Such networking will give a lot of benefits, that make it worth the investment.


One last thing before I sign off. Just because SAP came out with something new – do not jump head first into it . In the same breath, let me also say that do not shy away from something because it is new.  No I have not lost it – the point here is that customers should be prepared to do some due diligence. Try out for yourself the things that come out from SAP. Once you know what you can and cannot do with the new offering, you can deicde whether to invest in it. A lot of failed projects can be traced back to this lack of due diligence. Make full use of the SAP account representative – this person is your best access point to SAP. He/She should be able tp get you access to product managers and other experts with whom you can interact and get a better understanding of the value proposition, before you commit resources.

In the next instalment, I will try to explain my thoughts on SAP’s own role in the success and failure of projects.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Mark Finnern
      Mark Finnern
      Hi Vijay,
      Like your list of things to keep in mind for a successful SAP Implementation.
      Companies have to judiciously decide which processes can be treated as commodities and which have to be kept as competitive.
      I would even go a step further and once the differentiation is done. Reach out to the community and collaborate on how to streamlining the commodity processes even further.
      SCN Wiki, enterprise services process, ... as starting points for that collaboration.
      Just a thought, Mark.
      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Hi Mark

      That is a very valid point.

      The value of community cannot be emphasised enough in today's world. This is true not only in commodity processes - even in the edge processes, community probably is better poised to give better feedback than inhouse team alone. Product companies have demonstrated that amply - Apple, IBM, Microsoft, SAP etc - and I think it is time projects follow this trend too. Currently projects make use of SCN by way of "how do I do this?" type technical forum questions for the most part. I think this will change and evolve considerably going forward.


      Author's profile photo Pravin Bhute
      Pravin Bhute

      Greetings for bringing up this critical subject in your blog.

      I would like to bring the "Best Practices" question to table in addition to what you mentioned.

      These are my personal thoughts which I have experienced in various projects. Some of customers continue asking consultants or Partners implmenting the projects on Best Practices. Though it makes sense to be aware of best practices, it is not necessary what worked for someone will work for you too. One should not get blinded with Best Practices or start modeling themselves as others did. Instead it should be analyzed how those Best Practices apply to your business and how are they going to help you. Your ultimate goal is to bring value to your very own business processes and make sure your KPIs are met.


      Author's profile photo Former Member
      Former Member
      Blog Post Author
      I completely agree, Pravin. A lot of judgment is needed when we deal with best practices. Best practices i general are specific to an industry. So, it does help implementors to get a quick idea of how things work in the industry. However, during blueprinting - it is vital that this gets tailored to the given client's situation.

      The equivalent of best practices in BI world is Business Content. Several projects try to instal Business Content and think that will solve their reporting issues. It has hardly ever worked, but some how this habit does not die

      Author's profile photo Jon Reed
      Jon Reed

      I'm enjoying this series because you are giving it some real thought and not just running out blame for the usual suspects.

      There are many ways you can slice and dice this. But when you take me back to the 90s, in my opinion there were way more serious project meltdowns then, as opposed to today. Partially it was just a different economic time, where budget constraints were rarely what they are today, and there was a lot more of an infatuation with technology for its own sake which led to over-the-top, careless, "waterfall" projects that led to huge overspends.

      The two things in the 90s that in my opinion really hurt projects were, one, the lack of a good supply of deep, experienced consultants who were project tested. The second was a tendency to excessively over customize when standard SAP didn't include the process the company wanted to follow. These days, I see a lot more restraint on all sides when it comes to customization of source code. Yes, it does still happen, but there is more of a hard look at whether the process to be customized is truly a competitive key for the business. Put under the microscope like that, and with a focus on instance consolidation and using the cloud to supplement on premise, I am seeing more sensible decisions as a whole.

      This is not to say that there aren't troubled projects out there, there are, which brings us back to the human side of all this. To me, the SAP customer has a lot of opportunity to educate themselves and use resources like user groups and SCN to avoid making mistakes that have documented "better approaches." At the same time, I think SAP can do a better job of meeting customers halfway on certain resource-intensive undertakings - Solution Manager being one of my current examples of this. And the SIs have a role to play as well, but since you intentionally wanted to look at customers in this blog I better not get you off topic. 🙂

      Author's profile photo Former Member
      Former Member
      Hi Vijay,
      I totally agree with your observations. Even I too passed through the same process while working for a manufacturing firm in 1990, where any new change was suggested for implementation, stiff resistance used to come from the end user and the management also used to half heartedly accept my suggestion. We also used to belive in TQM and SIX-SIGMA and used to talk a lot on it like how it will benefit us, but at the end implementation was a issue and we were told the solutions will not work for us.
      Currently I am working as a SAP Consultant and now also I see the same thing happening even after 20 years, our suggestions are accepted but user does not highlight his real problem being faced by him in his day-to day activities. He believes that SAP is the solution to all problems.

      I believe even after another 10 to 15 years we will be discussing the same.
      Vengal Rao.