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.
