That got your attention didn't it? Reading through Michael Doane's polemic Racing to Mediocrity: The False Grail of an Accelerated SAP “Go Live”, it is an easy conclusion. For example:
Veterans of SAP implementations will unanimously agree that the single most damaging facet that turns projects into death marches is the clients’ a) failure to agree to adopt the best practices as reflected in preconfigured solutions and/or, worse, b) failure to agree internally on the details of a rational business blueprint.
In fairness, Doane sprays his critique to everyone involved in failure, with the core theme that 'speed kills.' He is sharply critical of earlier attempts to accelerate SAP implementations:
The mantra back then was clearly “stuff it in” and services firms were actually marketing to the speed with which they could deck out a client with SAP. We were hearing about eight month implementations, six month implementations, and, finally, three month implementations. I fully expected to read a headline such as "Roadrunner Corporation Completes SAP Implementation during Long Lunch Break!"
He doesn't see the recently released Rapid Deployment Solutions (RDS) as being much better:
The key to acceleration is to skip the traditional business-blueprint and configuration phases and cut to the chase by complete adoption of pre-configured business processes. Since those two phases traditionally take 50%-60% (or more) of a total ASAP cost and duration, their elimination is presumed to result in a massive time and cost savings.
The core fault of this methodology is that its only aim is to get a client live as fast as possible. It includes zero post-implementation planning. By eliminating business blueprint, it fails to bring business and IT together to learn business process engineering and business process management.
Contrast this with Michael Krigsman's glowing endorsement of RDS:
Enterprise customers are weary of open-ended, hourly consulting arrangements. These deals often favor the vendor, taking advantage of the human tendency to slide toward complacency and the status quo. In other words, open-ended contracts frequently lead to bigger and bigger projects, scope creep, and a host of other ills.
Packaged, productized, and standardized services are here to stay in the enterprise software market, including in ERP. Forward-thinking services organizations are already moving in this direction, and dinosaurs who ignore the obvious will be left behind.
He would say that because in the same article, Krigsman says:
In the late-nineties, SAP introduced AcceleratedSAP (ASAP), which consolidated a standard implementation process and set of tools for ERP deployments. (I was deeply involved in creating the ASAP tools and even wrote the first installer myself.)
As far as I can tell, RDS represents the latest iteration of a continuum that started with ASAP so it is easy to understand why Krigsman supports this position. If he doesn't then in Doane's analysis, he is tacitly admitting that ASAP, in which he was deeply involved, is fundamentally flawed. It's equally easy to see why Doane would give it a hard time. He believes that you cannot short cut certain aspects of SAP implementation, rollout and deployment. He has the evidence to explain why.
I'm not a fan of binary arguments but what we have here are two polar opposites. Curiously, both Doane and Krigsman point fingers at all parties. So is this more a matter of emphasis sharply stated? I have problems with both analyses.
Doane's analysis while thorough and fact driven does not state what to me is glaringly obvious. Why, after all the years of failure hasn't someone, somewhere tipped up during the decision making process and set out how this stuff falls down so that there can be no doubt what is involved AND the consequences of failure. I'll get to this at the end.
Senior people I know at both Deloitte and IBM have told me they are committed to customer success. Snicker if you want but they are only too aware of the problems. Both tell me that customer expectations are never well aligned to what can be achieved as originally envisaged but claim they do their level best to make sure clients understand what is realistic during the blueprint phase. I have no reason to disbelieve their intent but we have to remember that they are employed by firms that are driven by the concept of the billable hour and not outcomes. That has to change. It is Vinnie Mirchandani's lament that after so many years and thousands of implementations, we still don't have a good way of bringing projects in on time and at reasonable cost.
If IBM was truly innovative it would be automating and commoditizing much of that labor – its own and that of the rest of the market.
What I find disconcerting is that even at the top IBM confuses its nice margins from milking old software and old data centers and old partners like SAP as “innovation”.
More prosaically this exchange between myself and Vijay Vijasankar, associate partner IBM last evening illustrates both the cynicism and playful snark that abounds around SAP projects:
@vijavijasankarv: Landed in PHX to see note from one of my delivery project execs that she is going live successfully . Back to back successful projects yay!!
Do you see how in this example go live remains the primary goal? Doane would likely say: 'Let's take a peek in another year.'
Krigsman's analysis rests upon the notion of the Devil's Triangle. I have major problems with this proscriptive approach because as described, everyone is to blame but it is almost impossible to ascribe responsibility. Another problem is that the Devil's Triangle concept is cast as an eternal truth. This also leads to a general theory of relativity situation where it is possible to portray any failure as representative of aspects of the Devil's Triangle. Sometimes it convinces, at other times it doesn't. I don't doubt that aspects of the analysis hold true but my experience suggests that there is always a root cause that can be identified which in turn leads to some of the symptoms Krigsman observes in hindsight.
My view is that on balance Doane is more convincing but there are aspects of Krigsman's view that can be usefully incorporated into an overall assessment. His discussions around management blame are often instructive but fall short on demonstrable remedy. Where I believe both fall down is in the recognition that failure can almost always be traced to:
- Over eager salespeople minimising risks around complex solutions.
- Over eager buyers wanting to buy into the brand. I've seen entire customer panels talking about SAP Business ByDesign making this mistake.
- Customers not having enough information during the decision taking process. There is a lack of truly independent voices prepared to vigorously speak to reality. Way too many who know the reality are afraid of upsetting their paymasters.
- A lack of willingness by customers to acknowledge that they didn't do all they could have to mitigate risk. There are exceptions to this acknowledgment - check SAP Me Sideways.
All of this happens before anyone signs a contract and before the real pain sets in.
Readers will no doubt pick holes in this assessment but what I am attempting to get to is root cause, not symptoms of outcomes. More important, is there an alternative? Although details are short in supply, I like Heather Clancy's report of Force.com usage at Kimberley Clark, an SAP customer. She notes:
Earlier last week, I chatted with another big company — consumer products giant Kimberly-Clark (the maker of Huggies and Kleenex brand among others) — about its decision to use Force.com to transform its existing enterprise software deployment, which happens to be built upon SAP software. This example is really interesting because it represents what I believe will be a more common future: one in which businesses use various social software and analytics applications to pull more value out of their legacy software.
Her key takeaways:
- The integration was easy to prototype for business-side buy-in
- It was quick
- It didn’t take a lot of new infrastructure
- The team didn’t have to rely on oodles of outside consultants
- Future changes are easy to make
SAPfans will argue: 'But wait a minute, you are comparing apples and oranges.' Am I? Think about it for a moment. Clancy's piece talks about flexibility as key. SIs will tell you that you can bend SAP any shape you want. That's flexible isn't it? Well yes, as long as you are prepared to wait for code to come out and then discover that change is very, very difficult. I always remember AMR analyst Bruce Richardson (now with Saleforce.com) saying way back when: "After you've installed SAP you've built a layer of concrete you hope you'll never have to dig up." I also know there are limitations with the Force.com platform but that's a separate discussion.
And let's assume you can sustain the apples and oranges argument. Doesn't that still leave open the question as to why SAP implementations are a hard road? What is it about Force.com in this context that represents a significant mind shift for Kimberley Clark?
From the looks of things, implementing SAP is not going to get much easier any time soon. There are no major releases planned, simply enhancement packs through 2020. If you buy into RDS AND are prepared to accept its severe limitations in terms of process design then maybe that will be your road to Valhalla. But until buyers truly understand what's going on before they sign those contracts then people like Doane and Krigsman will have plenty to say - even if they disagree.
There is another possible reality. Vishal Sikka, executive board member SAP has said many times that HANA offers an opportunity to rethink business processes. The business driving elements such as decentralisation and the explosion of interrest in mobile are in play. Cloud vendors are showing us important elements of the technology with which to get the job done. Despite what detractors might say, HANA really does have disruptive potential.
If SAP is able to figure out how to bring all these principles together then maybe, just maybe, the RDS solutions of (say) 2015-17 will finally prove Krigsman right and blow up Doane's key arguments. As always - watch this space.