The undeniable and perpetually observed fact is that the money clients ?saved? with their accelerated implementation is lost multiple times over after go-live due to the corners that were cut and the failure to plan for the long haul.
How Speed Became the Key Issue in SAP Implementations
Prior to 1997, methodologies deployed by the various systems integrators were not adequately tailored to the unique requirements of ERP. Most were based upon pre-ERP ?Design Build Run? methods that had a heavy reliance upon the As-Is and To-Be phases. In the As-Is phase, a firm?s current business processes were inventoried, charted, and scripted. In the To-Be phase, a firm?s future business processes were designed, charted, and scripted. Ideally, these steps went as follows:
As-Is described the status quo of business processes
To-Be described the direct transfer of the as-is process into a to-be process that eliminates the weak points and achieves the intended benefit.
The key weakness of these methodologies lay in the slavish attention to the As-Is phase in which lower-level business processes were pointlessly charted and scripted at an exorbitant cost to clients and with little or no benefit for the To-Be phase. Many thought of this as the ?consulting partner?s retirement fund phase? and this aspect was one of the key drivers to highly-publicized cost over-runs in the mid 1990?s.
The result was that the buying public began to claim that it took an eternity and cost a fortune to implement SAP and these claims were repeated in the press, thus giving SAP a black eye.
In the spring of 1997, SAP responded with ?Accelerated SAP? or ?ASAP?, a methodology which in name and content stressed speed through a more direct approach, the use of conference room pilots, the deployment of templates, and greater leverage of best practices (i.e. the re-use of business processes that had demonstrably done the job). In short order, nearly all of SAP?s implementation partners adopted ASAP as their core methodology and many augmented it with improved value drivers, organizational change management, and executive considerations. The problem is that nearly all of these methodologies were branded as rapid. Deloitte?s ?Fast Track? and BearingPoint?s ?Rapid Return on Investment? (also labeled R2i) are a few examples. (Even Oracle Consulting?s methodology was called ?Fast Forward?.)
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!"
At the time, it was easy to understand a need to cut down on pointless project steps and to add a sense of urgency to implementations. The misfortune is that the speed message drowned out more important considerations and gave clients the impression that implementations would be simpler and less complex than they actually are. In years since, we have all matured in terms of understanding SAP and what it takes to properly implement it. Unfortunately, we have not yet carried our lessons of maturity over to the methodologies.
The net effect over the past fifteen years is that clients are still led to believe that the faster an implementation is accomplished, the better. Nothing could be further from the truth.
In SAP Implementation Projects, Speed Kills
This mania for speedy implementations, often fueled by client sticker shock coupled with account reps who underplay the importance and complexity of an implementation project, has too often led to an ?SAP wedding syndrome? by which clients race to the altar of go-live while utterly neglecting to prepare themselves for the twenty to thirty-year deployment marriage that will follow. The result is that clients poorly positioned to?effectively maintain or improve their SAP plant after go-live as their organizations are very similar to what they had before acquiring SAP.
So. SAP is in. Now what?
A thirty year life expectancy is a difficult concept for clients to wrap their heads around. Prior to SAP, they will have replaced individual applications (financials, sales & purchase order processing, production planning, et al) every three to four years. Above and beyond upgrades and application extensions, one key driver of a very long SAP shelf life is quite simply sunk cost.
I advise any client contemplating a fully accelerated SAP implementation to take heed of research I did some years ago to understand the consequences of speed:
These are long-term repercussions of implementation mistakes of which A, B, and D are directly related to haste and E is a result of poor client preparation for business process design.
The lack of quantifiable measurement means that a client?s SAP installation is simply a process-mover and not a strategic tool.
Breaking up the business stakeholders and the IT support team condemns a client to the same business/IT discordance that existed before the SAP implementation.
A lack of knowledge transfer, coupled with a short-changing of end user training, means that instead of expertly driving a Lamborghini to an attractive destination, end users are engaged in a demolition derby with a ?63 Chevy Bel Air that its internal IT team cannot repair.
For more on this, see http://www.michaeldoane.com/uploads/SAP_Training_Budget_Cuts.pdf
Another damaging consequence of a rushed implementation is that ill-prepared clients rush through project preparation and then go through a start-stop-restart convulsion wherein they finally realize during business blueprint that they don?t know quite what they are doing. They take a break to reflect, get further educated, and re-calibrate their relationship with their SI before getting back to the project, having lost time and money due to unwise project acceleration. This tends to result in the process of "I Said I Wanted Chicken (when we first acquired SAP) but Then I Wanted Steak (when we understood how powerful the software can be) & Later I Will Be Happy to Have a Hot Dog (as we now understand how complex it can be)."
. . . . .
While we have seen some improvements in implementation projects since 1997, we are still seeing far too many failures (or, to put a graceful spin on things ?outcomes that are not optimal?).
Through the years we have alternately blamed these failures on client intransigence and/or ignorance, systems integrator incompetency and/or greed, poor scope control, overwhelming technical complexities, lack of leadership, and lack of senior management commitment. And across the board, we tend to (rightfully) blame poor planning.
SAP doubled down on shortening implementation duration starting in September 2010 with Rapid Deployment Solutions (RDS). This varies only somewhat from previous attempts to provide clients with ?deployment-ready? SAP configurations by which clients need only to adapt their way of working in order to go-live. 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. In its ensemble, it does little to nothing to re-craft the client?s IT organization along business-centric lines. Sixteen weeks is far too short a period to provide effective change management to business stakeholders and end users. And there is not an ounce of business measurement included in the process. Only a client that is totally committed to full adoption of pre-existing business processes has any chance of success and such clients are few and far between.
The Illusion of ?SAP Vanilla?
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.
More great chunks of time are lost when trying to successfully configure to a blueprint that is highly customized to cater to client whim or confusion.
For point ?a?, I reference Marin County and Waste Management (and a lot of other clients who did not necessarily sue their systems integrators).
For point ?b? I reference more clients than I care to quantify.
To avoid OTANOs (?outcomes that are not optimal?), we must avoid a chaotic business blueprint experience.
While I have little faith in the Rapid Deployment Solution as a model for success, I do believe that a nuanced version of ?best practices adoption? can be valuable.
With the experience of thousands upon thousands of implementation projects behind them, consultants can point to business processes that have proven to be the most effective and clients should give every consideration to adopting such processes rather than merely applying their own. As I have said to many clients ?If you believe that your process is that much better than best practices have revealed to us, you are either very very good or you are suffering from organizational hubris.?
Considering adoption on a process by process basis is a great practice. Mass acceptance of best practices coupled with a wholesale deletion of the business blueprint phases is a terrible practice.
The pivot toward a chaotic business blueprint experience often occurs during the software licensing in which reality gets fudged in a variety of ways:
1. The client purchasing agents do not have a full understanding of what it means to ?adapt to SAP best practices? and, further, are seldom the same business stakeholders who will have to do so.
2. Most clients are unaware of the distinction between configuration and programming and thus are unable to grasp how subsequent customization may undermine the ?vanilla? offering.
3. Account reps are rewarded for license sales, not for subsequent client satisfaction or timely implementations.
4. As previously mentioned, adopting clients are seldom fully aware of the long-term nature of an SAP acquisition and so under-estimate the repercussions of blanket decisions made regarding business process.
5. A client?s ability to effectively participate in a business blueprint activity is rarely evaluated during the sales process.
The client group that negotiates an SAP software license is seldom comprised of the people who will subsequently run the implementation project, most especially in regard to the business blueprint phase. It is the latter who inherit a blanket decision to adopt SAP best practice processes. For these people, now stuck with ?Vanilla SAP?, no seat belt is sufficient to cushion the whiplashes to follow:
The systems integrator presents a ?best practice? business process to a client group.
Client: That?s not how we do that.
SI: But you can adapt to this process, right?
Client: No. It?s missing the steps we need. (We?re unique.)
SI: You said you would adopt best practices.
Client: The best practice is the one we are already following. (I built it myself.)
SI: But the statement of work says?
Client: I don?t care what it says. This is not how we do that. (Now I am growing angry.)
Repeat the above conversation across fifty to a hundred processes. Speak louder each time.
While I agree that clients need to strongly consider adoption of best practices as reflected in preconfigured solutions, I also know that in many cases they will resist doing so with good reasons (they simply cannot work in a proscribed fashion) or bad (they insist on doing things their way).
In this light, the fault quite often lies with clients who go into an SAP implementation insisting upon the delusion that their business processes are already top drawer and all that needs to happen is for them to be ?SAP-ized?. Such clients tend to underestimate not only the need for a rigorous business blueprint phase but also the organizational change management burden, the latter neglect based upon the premise that little will be changed since the processes will remain the same.
Once the project begins, it is revealed that a) existing business processes are ill-defined, insufficient, and not agreed across client constituencies and thus b) massive change to these processes will result in dramatic organizational change management. And of course, there is insufficient time and budget for either process re-design or organizational change management. Oops.
A Higher Bar than ?Go-Live?
Far too often clients view ?going live? simply as launching applications that support business processes without undue bugs or help desk calls and which provide at least a minimal level of reporting in an infrastructural environment that is somewhat reliable.
This is hardly what the business sponsors had in mind when they laid out millions of acquisition and implementation dollars. With implementation short-cuts and a ?faster, faster, faster!? attitude, the resulting ?live? may require ?life support?. Further, most clients find that well after go-live, they have a period of ?shake-out? that can last one, two, or three years in which they struggle to stabilize their applications in the high wake of the implementation investment.
The result of this lengthy ?shake-out? is that clients have completed the implementation and stabilized their SAP applications but they are no longer positioned to pursue a fresh ?to be? vision. They are, in short, doing a great job of standing still.. . . . .
Within a year after go-live, most clients ruminate as to ?what was the rush?? They regret their inability to measure. They rue short-changing end user training. They find they are daily paying for over-customization of business processes and the disaffection of business stakeholders. They begin to see how an extra month or two or three would have added great benefit to the over-all result. Over a longer period of time, as these same clients understand the long-term nature of their SAP, the fevered insanity of an accelerated implementation becomes apparent.
Getting to go-live as fast as possible is a very low bar of success for a very high measure of investment.
?. . . . .
In my next post, ?As Cool as Possible, a Call for Implementation Projects with a Longer Duration, at Less Cost, with Greater Long-Term Benefit?, I will provide the outline for an ASAP extension that will assure that implementations are business-centric, will avoid the start-stop-restart syndrome, and conclude with clients fully positioned for a successful transition into a continuous-business-improvement environment.
Source: http://sapsearchlight.blogspot.com/2012/03/racing-to-mediocrity-false-grail-of.html
espn magazine espn magazine anywhere but here wall street protesters att new york yankees pittsburgh penguins
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.