As Cool as Possible

SAP Implementation Projects with a Longer Duration, at Less Cost, with Greater Long-Term Benefit

From ASAP (As Soon as Possible)…

Over the years, far too many SAP implementations have concluded with ONOs (“outcomes not optimal”) and a major contributor to client disappointment has been haste. In sum, the focus has been for clients to get to go-live as fast as possible, which is a very low bar of success for a very high measure of investment.

Further, ASAP-based implementations are still far too much about “software implementation” than about “business transformation”. Missing or wayward elements of most implementations include:

1. IT Predominance: Despite excessive rhetoric from SAP, its implementation partners, and the clients themselves about SAP being “about business”, IT tends to play the major role in most implementations.

2. Bullet-point Strategy: The lack of business process measurements in business cases.

3. Short-term Point of View: A complete negligence of post-implementation planning.

What we need are projects of a possibly longer duration, at less cost, with greater long-term benefit.

As detailed in my previous post http://sapsearchlight.blogspot.com/2012/03/racing-to-mediocrity-false-grail-of.html hasty implementations lead to disappointing results:

• Clients have not satisfactorily planned for post go-live and are not prepared to manage and evolve their emerging SAP plant.

• Project members and end users have received insufficient knowledge transfer and are not sufficiently competent.

• Because the endeavor was viewed as IT-centric, business process design was not carried out in an optimal and effective fashion and staff is still ill-prepared to participate in continuous business process improvement.

• It is also highly probable that the project suffered from a start-stop-restart syndrome which contributed to a “late and over budget” result.

A move to SAP is a dramatic step that will change the career path of nearly everyone involved. The ASAP methodology only addresses an implementation project. Clients adopting SAP are urged to more fully prepare themselves for an SAP future.

..to ACAP (As Cool as Possible)

The firms that we have found to be the most successful at leveraging their SAP investment into measurable business benefit are those that a) were steadfastly business centric and b) fully planned their post-implementation organization well in advance of go-live.

What follows is a front-end extension to the ASAP methodology that mimics these firms' best practices and will:

• cost less by adding the guidance of an intelligent, numbers-based business case that will reduce project “drift”;

• cost less by vastly reducing the power curve as well as the learning curve (see below)

• arm the business blueprint stakeholders with the requisite skills and background to reduce the duration of the blueprint phase while enhancing its effectiveness;

• fully avoid the start-stop-restart syndrome;

• fully avoid go-live shock by virtue of planning and forming a post-implementation “Center of Excellence” well before the go-live date.

The Learning Curve: Most clients are aware of the learning curve for implementation project staff and end users but ignore the learning curve for senior management and middle management. Thus, in early phases of an ASAP project (the runway) most attention is paid to the project team, especially those who will participate in configuration, data migration, and testing.

ACAP rectifies the omission of addressing the learning curve of senior and middle management.

The Power Curve: The number one killer of project budgets and timelines is an uncontrolled power curve. The power curve kicks in when your senior and middle management become aware of the effects of a shift to a horizontal (i.e. cross-departmental) business process organization. Hierarchies tend to flatten when made horizontal so if this realization only occurs at the outset of the Business Blueprint phase, the time lost in arguments having to do with authorities and responsibilities around processes will erode project costs, timelines, and management of nervous systems.

If, prior to launching Business Blueprint, there has been knowledgeable management commitment to a change to a more horizontal way of working and pre-project education has been provided, this curve is shortened.

Once you have begun to scale the learning curve, the power curve will begin as well. Where these curves cross may decide the fate of your project and will certainly affect project costs.

“As Cool As Possible” in Five Steps

Why ACAP (brief recap)?

1. To avoid the pitfalls of over-acceleration.

2. To prepare the client for the long-term of SAP.

3. To assure continuous and measurable business process improvement.

We begin with an understanding that the goal of a client is to improve its Profit & Loss and its Client Loyalty.
In order to achieve these goals, this is the value chain that is recommended:

This value chain begins with the end users who are actually the true “drivers” of business process fulfillment in that they actually touch the applications and complete the underlying process tasks.

What they are driving are the SAP enterprise applications which constitute the “engine” that gets your enterprise onto the super highway of major business processes (otherwise known as “what you do” in the marketplace.

You can measure your speed and direction by tracking key performance indicators relative to your business processes and thus calibrate for improvements in….ta da!…your profit and loss and client loyalty.

The ACAP extension is intended to properly address all facets of this value chain, not just those relative to the SAP enterprise applications “engine”.

It is also intended to assure that your enterprise can continually follow the value chain well after SAP go-live. It is therefore cyclical, not linear like the SAP roadmap.

SAP Executive Seminar

I have been providing SAP Executive Seminars since January of 1996 (and have no completed more than 70 in various modes). I have found that it helps immeasurably to provide participants with some reading material prior to the seminar. In addition to my own The SAP Blue Book, a Concise Business Guide to the World of SAP, I often recommend Reengineering the Corporation by Michael Hammer & James Champy.

The most desirable outcome is for senior management to fully appreciate that business process is the core subject of their endeavor, not IT. Such an appreciation will lead them to participate in the implementation project in a highly proactive fashion and with a higher bar than to finish on time and on budget.

Justification/Business Case Workshop

In the course of most of my SAP executive seminars and borne out in primary research is the fact that firms frequently fail to prepare a solid business case for their SAP investments. In such cases, I strongly recommend a two-day working session in which a high level business case can be generated and agreed as a foundation for moving forward.

Center of Excellence Workshop

Day 1 An introduction to the principles, functions, and uses of an SAP-driven Center of Excellence with a focus on the business & IT dynamic and measurable business benefit. Complete presentation of all four domains: enterprise, enablement, applications, and IT with explication of roles, communications, and sustainment.

Day 2: Draft Center of Excellence Organization: a high level positioning of the Center of Excellence within your firm’s over-all organization followed by a domain by domain outline of a potential new organization. As a key aspect of this positioning, we will seek to established core, foundational principles to be adopted moving forward. The final step will be to create a high level plan for the transition from your existing organization to the new Center of Excellence with a focus on organizational readiness and on individual job descriptions and individual transition requirements.

The organization and transition plans must normally be approved by the Steering Committee.

Business Process Excellence Workshop

This workshop will prepare your designated Business Process Owners and Business Process Experts for the Business Blueprint phase of an implementation as well as subsequent continuous business process improvements. Using the high level business case as a starting point, we identify the business processes that will be addressed, break down the components of each process, and pinpoint the key performance indicators that need to be improved. We also explore best practices for business process modeling, management, and governance.

In addition to assuring that the business blueprint team is fully prepared for the project, we also issue a delivery in the form of an initial value-based business case that will be the centerpiece of the project charter.

Organizational Readiness Assessment

The majority of SAP implementation projects begin shortly after firms license with SAP. In most cases, this is premature. While many project individuals may be prepared, the full organization usually is not.

Over the past ten years I have frequently administered a self-assessment by which 25 to 40 of a client’s business and IT leaders take an anonymous survey in which they agree or disagree as to whether or not best practices are being followed. Setting up the survey takes a few hours and respondents usually take fifteen minutes to complete the survey.

The value of the assessment is the highly credible set of diagnostics which, in their ensemble, demystify an organization’s true level of readiness for an implementation project.

Less formal means of assessing your readiness may suffice but you should avoid moving too swiftly to assure that you will avoid the start-stop-restart syndrome that will bust your budget as well as your nervous system.

Below is the readiness model that is recommended.

Each member of the assessment team is provided a link to a survey that takes fifteen minutes to complete as they need only to reflect their level of agreement or disagreement that the firm adheres to a given best readiness practice. Responses remain anonymous to assure high credibility.

Here is an example of readiness results (from Level 3: Goals & Measures):

Beyond addressing each of the levels or areas of readiness, we provide a forward map of activities intended to address the most critical shortfalls and thus improve readiness to start the engagement.

Conclusion

The time required for ACAP is a slight fraction of the time required for ASAP and the outcome is that a client will be focused on the right subjects with an effective business and IT dynamic.

The half-day allotted to the engagement readiness assessment assumes a half-day briefing and forward planning exercise based upon results of the assessment.

While following ACAP will add some cost to the over-all endeavor, the return on this investment will be:

• An acceleration of the subsequent SAP learning curve and a shortened business process power curve
• A better defined business and IT dynamic
• A defined organizational destination (the Center of Excellence) rather than a goal of simply “going live”
• Avoidance of the “start-stop-restart” syndrome
• The assurance of a business-centric endeavor.

All as cool as possible.

Racing to Mediocrity: The False Grail of an Accelerated SAP “Go Live”

For too long, SAP and its implementation partners have offered “speedy” methods for implementation. These methods nearly always do more harm than good and should be given serious re-consideration.

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 are 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.

The State of SAP 2012: New Research for a New Age

From 1995 through 2000, I worked in SAP systems integration, helping clients to implement R/3. In 1998, I published The SAP Blue Book, A Concise Business Guide to the World of SAP. One concern I had back then was that there was no primary research at all about the best practices for implementation.

Since that time, I have been gathering primary research about implementation best practices and, even more important, about post-implementation practices and strategies. As a result, over the years, I have led fourteen major research projects and participated in dozens of others. Among the most striking lessons learned across studies relative to SAP (in no particular order):

You Get How You Pay For: Fixed-fee implementation projects are the least successful; value-based fee projects are the most successful (if you can measure).

Tell Me If You’ve Heard This One Before: The large systems integrators tend to perform fairly well in the Fortune 500 market and very poorly in all other markets.

Latch-Key Kids: In a study on end user training and supports, 76% of firms polled claimed that their end users were struggling or failing when it came to SAP competency. When compared to firms that claimed they were doing well, we found that the successful firms overwhelmingly provided more continuous training than the struggling firms.

I Said I Wanted Chicken but Now I Want Steak and Later I Will Be Happy to Have a Hot Dog: The client group mindset changes radically between the time they choose a systems integrator and the time they start a project. Then nearly everything changes again after go-live. (Moral: it is good to have an articulated long-term vision before starting down the SAP path).

My Last Confession Was during Business Blueprint (The Privacy of the Confessional): In public settings, clients blame SAP or their systems integrator for project issues. When provided an anonymous platform, they place far greater blame on themselves.

A Day at the Dentist: Measurement of business performance is deemed (incorrectly) as painful as root canal. (Fewer than 20% have tangible measures during implementations).

Unfortunately, some of the essential data is now old and therefore no longer fully credible. Further, there are a number of new subjects (Centers of Excellence, Shadow IT, and Maintaining SAP Super User Networks) where little or no primary research is available.

In order to answer myriad questions about the state of SAP 2012, we have launched a survey with hopes of having final data and analysis in time for SAPPHIRE.

Survey link:  http://www.surveymonkey.com/s/N9JWXBZ

Survey completion should be about 15 minutesIn return for your contribution, we will provide you with a study based on the survey results -- “The State of SAP 2012: SAP Installed Base Survey Results” -- and/or any of the following white papers:

• We Do It Themselves - Outsourcing SAP Support Services
• Your Users Are Stumbling and Your Business Is Suffering, How cutting SAP Training could make bad times worse
• SAP as the Engine to Measurable Business Benefit

 White papers will be delivered via e-mail, in pdf format, within seven days of your survey completion.

  

In the survey, we ask for your e-mail address. This address will not be used for any purpose at any time other than for returning requested material to you.

Survey completion should be about 15 minutes as the questions are fairly straightforward and responses are mostly “multiple choice” or “check all that apply”.

Example:

Survey Sections include:

Intro Demographics of Respondents

1 Current State

• SAP maturity
• Strengths & weaknesses
• Center of Excellence status

2 Current Organization

•  Business process organization/success rates
• Super user/end user status
• Organizational change management

 3 Forward Planning

• HANA
• Business Intelligence
• Mobility

4 Center of Expertise status

5 Working Preferences

• Service preferences
• Information sources
• Preferred Events
• Preferred Workshops

The first and most important benefit to having this information is to see where you fit across the SAP installed base market. You will gain an understanding of what issues are being faced by others as well as what they are doing to evolve.

The data has extra credibility in that is derived from your peers. Feel free to contact me if you have any questions:

Survey link: http://www.surveymonkey.com/s/N9JWXBZ


michael.doane@cgi.com         michael@michaeldoane.com

It's Cloud's Illusions I Recall: 2012 SAP Client Trends

As is customary this time of year, we have had a plethora of “lists” either of nostalgia (looking back at 2011) or with anticipation (looking ahead to 2012). Prominent on these lists for SAP are: HANA, mobility, Bob J, and Solution Manager (the four horsemen of the Sapocalypse). I fully expect SAP to keep the horns blowing hard for these subjects, though I would truly welcome something new that isn’t techy-wonkish.


In that light, I continue to believe that neither The Cloud nor SaaS are particularly relevant to SAP clients in the installed base with revenues > $500M. No client of major size is going to use cloud in more than a lab environment as they will be loath to consign the heart of their IP to a cloud environment. And although SaaS solutions continue to evolve, they do not lend themselves to continuous business process improvement (to say the least).

The trends that I list here (in no particular order) are clearly not part of the mainstream with analysts whose eyes are turned to the technology but should be trends that clients themselves will follow.

Shadow IT is on the Rise: While I do not have any primary research in this regard, I have noted a serious increase in the frequency of IT systems and solutions used outside of official IT and without official approval. The vast majority of shadow IT is business intelligence (with a concentration upon executive dashboards). This rise is probably due to a) IT leadership not tuned to business needs and/or b) corporate dictates to IT to reduce costs, leaving IT unable to serve business.

The dwindling of the SAP consulting eco-system gives clients less choice than ever: Twelve years ago, there were 300 North American SAP practices. The large practices, often referred to as ‘the usual suspects’ included Price Waterhouse, Coopers & Lybrand, Anderson Consulting (later Accenture), CSC, Deloitte, KPMG (later BearingPoint) , Ernst & Young, IBM, and SAP Consulting. That’s nine firms. Today, we are down to SAP Consulting, IBM, Accenture, Deloitte, Capgemini, and CSC. That’s six firms. And the count of North American SAP practices is less than 100 with almost no second tier. This is the result of aggressive provider consolidation, vastly increased global delivery, and mass growth of SAP Consulting and the IBM and Accenture SAP practices.

Centers of Expertise will continue to give way to Centers of Excellence. Centers of Expertise are intended to get the most out of SAP software. Lots of clients have them. Centers of Excellence are intended to drive continuous measurable business improvements. Few clients have them. So what’s the trend? 2010 and 2011 saw a rise in client maturity regarding the distinction between the two CoE meanings and substance. A rise, I said, not a tsunami. The vast majority of firms with SAP will still be looking in the wrong direction (towards technology) to improve their maturity.

Marc Benioff, CEO of SalesForcedotcom (that’s right, they are still mis-named and still use dotcom in the moniker) will continue to embarrass himself with loudmouth declarations about his firm toppling SAP, Oracle, et al. He’s been doing so for about five years now and should be getting hoarse even as the vision of “toppling” grows ever distant. Waves of analysts, however, will buy in to this delusion.

The definition of a business process expert will continue to be refined. To date, the definers have come from the ranks of IT (read=techie) analysts and more technical-minded consultants. If you go to the BPX Community pages at SDN, you get the impression that business process expertise is about “tools” and “modeling” and, oh my, SAP NetWeaver Process Orchestration. Just as construction is not defined by hammers and nails, we need to remember that business process expertise is supposed to be the nexus between business and IT. The blur. BizIT. Fellow definition refiners are welcome here.

Super user networks will be more common and more effective. 2010 heralded the beginning of the end of the dreadful neglect of SAP end users as we continue to find ways to prove the cost of such neglect and thus gain client mindshare around the issues.

The Long Green Road to CGI

Learning from Clients What Most Vendors Still Won’t (Can’t?) Do

Back in 2001, I left the field of SAP consulting to become an industry analyst at META Group. My coverage area was consulting firms and over the next six years I advised dozens of them in regard to competitive analysis, marketing & messaging, delivery methods, market positioning, and effective sales techniques. What I enjoyed most about this work was the freedom to complete research in order to move past anecdotes and direct experience. What I liked least about this work was, frankly, a lot of the vendor contact. An uncomfortably high number of the consulting leaders that I came across were combinations of self-righteous, arrogant, deaf, paranoid, and dishonest. Too often I was told “We are our clients’ trusted advisors”, a specious claim for which there was never any evidence. Multiple partners from one of the largest firms tended to say “Our clients love us”, to which my immediate answer was always “You’re not talking to all of your clients.” Sales pitches invariably included a reference to how “our people are different”, to which I would ask “How different? Can they go sleepless? Do they have three hands?” The single most annoying aspect of vendor contact was hearing how a firm was “the industry leader in [fill in the blank]” when in nearly every case there was no reference to how such leadership was ascertained or awarded. As Christopher Hitchens puts it (albeit in a different context) “What can be asserted without proof can be dismissed without proof.”

All this time, I very definitely kept my hand in the world of SAP. Until 2001, all efforts by SAP and its implementation partners were focused upon rapid implementations. However, I had a large number of META Group clients who already had SAP. Many of them had read my SAP Blue Book, A Concise Business Guide to the World of SAP and tended to say that it was useful while they were implementing but now that they were live, they needed other advice. Did I have another book about best practices after go-live?

While I was willing to write one, there was one significant impediment: with a rigid focus on implementations, neither SAP nor its partners had much to say in regard to best practices or thought leadership regarding the deployment of an SAP installation.

My META Group clients were all asking fairly similar questions:

• How do we best organize to keep business and IT alignment?
• How do we maintain end user competency?
• How do we gain measurable business benefit?
• Who out there is thriving with their SAP platform?
• What should we be outsourcing and how do we decide?

Seeking out answers, my first step was to talk to SAP. At the time, they were promoting a program around “SAP Competency Centers” that addressed only the SAP applications and associated middleware and did not address organizational or value driving aspects whatsoever. No help there.

My second step was to contact the SAP and Oracle practice leaders of Accenture, IBM, Deloitte, KPMG (later Bearing Point) and SAP Consulting to pose the question: Can you help clients build an SAP center of excellence?

Unsurprisingly, every one affirmed an ability to do so. Here is how every conversation went:

Me: Can you help clients build an SAP (or Oracle) center of excellence?

Practice Leader: Sure can.

Me: Good news. Might I see your methodology?

Practice Leader: Uh, we don’t have one of those. We, uh, compile a team each time.

Me: Fair enough. Who are your references?

Practice Leader: Well, we, uh, don’t have any of those. But, hey, Michael, let me introduce you to Steve.

Steve: Hi, Michael. I head up our firm’s applications outsourcing group.

These oft-repeated scenarios only inspired me to write an article entitled “Option A or Option A: Funneling Clients to Application Outsourcing. “

Taking it one step further, I undertook a study of the various implementation methodologies of leading systems integrators which revealed that post-implementation planning was almost entirely neglected. Every ounce of effort and concentration was upon a rush to the go-live wedding at the expense of the post go-live marriage. In essence, systems integrators (with much collaboration from SAP, which, let’s face it, actually named their implementation methodology ASAP) were helping clients set the stage for poor deployment.

I then went to what George W. Bush would later refer to as “the interwebs” (and which Senator Stevens of Alaska once helpfully explained is “a series of tubes”). There was a surfeit of information about upgrades and a mountain of listings about outsourcing (‘your mess for less!”). But there was nothing in the “tubes” about centers of excellence, SAP best practices for deployment, or even how to achieve and maintain business and IT alignment.

That took me to the end of 2001 and my bottom line was that all the consulting firms and SAP itself were rushing clients through lousy implementation projects, few of which included any post-implementation planning, and then abandoning those clients after go-live with a message of “You’ll figure it out (but when you don’t you can outsource to us.)”

From that point until recently, I relied upon a growing network of individuals to research best post-implementation practices since SAP Consulting and its partners were of scant use.

The first individual who contributed was Sharon Moody, who in late 2001 had recently retired from Delta but who very generously shared her research with me. With this jumpstart, I published a white paper about centers of excellence for SAP and was amazed at the outpouring of interest. At this point, I was given a major boost by Jack Childs who role at SAP in those days was that of babysitter to the top North American accounts. Between my position at META Group and Jack’s client contacts, I was able to make a number of client connections that revealed many best practices.

I presumed at the time that others would join in on this research. Outside of various members of SAP itself, none have other than fitfully and in passing. I have been joined by Michael Connor, founder and CEO of Meridian Consulting (www.meridian-us.com) and have found occasional material from AMR Research (now absorbed into Gartner), Forrester, and a few of the systems integration firms.

However, the best sources of learning best practices have been clients. For a stretch, I had the pleasure of working with a group consisting of Wrigley, S.C. Johnson and, to some degree, Kimberley Clark in which best practices were shared, debated, and refined. I had a wonderful week in 2005 Paris working with L’Oréal which had a very advanced global center of excellence. Through the years, I actively googled in search of articles or blog posts regarding post-implementation strategies and found very very little and while I came across a number of consultants with experience in the post-implementation market but found none of them worked in that market full time.

In the spring of 2009 I began writing The SAP Green Book, Thrive After Go Live. First I gathered and expanded various articles and white papers that I had written over the years and contacted various contributors industry analysts Jon Reed (of JonERP, the independent Joshua Greenbaum, and Dane Anderson, a vice president at Gartner in charge of research of managed services. I also contacted a number of clients and consulted and the book was actively “edited” by these contributors as it was being written. I also had one more round of asking systems integrators if they could help clients build centers of excellence. This time, no one bothered to fake me out. One even said, “Michael, why would we teach our clients how to fish?”

Thus, it was not until October of 2009 that I had enough material to publish The SAP Green Book, Thrive After Go Live (a second, expanded and revised edition was issued this year. In February of 2012, the book will be re-issued by SAP Press).

Bridge Building

In early 2010, I had the good fortune of meeting Paul Kurchina, for many years the face of ASUG and today a leading light in the SAP Insider community. Through Paul, I met Gabe Rodriguez and Brian Dahill who lead the Center of Excellence special interest group at ASUG (and organize the highly popular pre-SAPPHIRE conference each year). Brian and Gabe honored me with the request that I keynote the upcoming event where I had the great pleasure of discovering huge client interest in business-centric centers of excellence. As had been the case for nine years to that point, the most frequent question I got was “Who can help us with this?” When I asked who they had tried, the answers were “Accenture but we kicked them out.” “IBM but we kicked them out.” “SAP but we kicked them out.”

When I asked why, I was told, invariably: “They had no methodology and they were too concentrated on IT and application maintenance. We want something business centric.”

Sound familiar?

Both Brian Dahill and I began asking clients: “Isn’t the key question ‘how do I build a center of excellence’?” The answer then was a resounding “Yes!”

Brian Dahill has been consulting in a center of excellence environment for the past eight years and neither of us had ever seen more than a PowerPoint on the subject of building one. I had few client engagements through the summer of 2010 and so I took the opportunity to build the first one, which I have dubbed “The Bridge Method, A methodology for creating a sustainable Center of Excellence that will drive & govern continuous and measurable business benefit”.

I was able to come up with this methodology based upon the assistance I had been providing to clients since late 2001. Brian was very helpful in reviewing my work and adding his input based upon his work in the field. It was also helpful that, during this same period, I linked up with SAP Education to lead three webinars on the subject of end users and enablement. To my great joy, the campaign was very successful and the contacts that I made (most notably Kerry Brown of SAP Enablement and Julie Stokes, the SAP Training Strategist at Fluor Corporation and leader of ASUG’s Documentation and Training Special Interest Group) have been instrumental in fine-tuning the Enablement Domain requirements for a Center of Excellence. (A case study “Drivers at Work Building an Effective and Sustainable Super User Network at Fluor Corporation” will be posted later this year).

The key tenet behind the center of excellence (and thus the critical path of The Bridge Method) is the re-ordering of the business and IT dynamic. For fifty years, we have been seeking “business & IT alignment” and I find that even this elusive goal is misbegotten since it suggests that business and IT should work in a partnership. In fact, IT should be entirely at the service of business. For this reason, the IT agenda –when it comes to applications- is almost entirely driven by business process owners. (For more detail on the strategy behind this, read my April 2011 post “IT, Your Fifteen Years are Up”.)

In August of 2010, just as I was finishing the first version of The Bridge Method, Paul Kurchina was asked by Nathalie Mercier of CGI who he would recommend as a speaker for a client event. Paul gave her my name and thus began my relationship with CGI, first in advising them in regard to their marketing and messaging, then in leading a client seminar, and finally in partnering with them in regard to Centers of Excellence.

From September of 2010 to date, I have not heard from anyone at CGI about how they are their clients’ “trusted advisor”, nor did anyone boast that their clients love them. No one tried to “sell” me on their field excellence or show off with three letter acronyms. Whereas most of their contemporaries avoided helping clients to build a Center of Excellence, the people I have worked with at CGI are continually asking a) how I can help them to help their clients get more value from their services and b) what do they need to learn to work with clients in this regard.

I was as a subcontractor in a few of their proposals and in February, I crossed “the aisle” and offered my services on a full-time basis. Shortly thereafter, I was awarded a sub-contract project with CGI to help a major Canadian bank design and plan its business process-centric Center of Excellence. This intense 400 hour project (which is the object of an upcoming case study) provided me a twelve-week period during which I was able to a) prove out, expand, and revise The Bridge Method and b) hang with my potential new colleagues at great length.

September 12, 2011 was my first day as a CGI employee. My title is executive consultant and my charge is to a) continue with my thought leadership in regard to centers of excellence and all that they embrace, b) expand CGI capabilities in this regard, c) continually inform CGI clients and prospects regarding best practices and how to and d) practice my arts in the field. Since mid-September, I have provided open "Thrive after Go-Live workshops in Toronto and Calgary" and have worked with five different clients in various aspects related to the Center of Excellence.

Throughout its history, CGI has been especially focused on managed services rather than systems integration. This concentration and experience provide the ideal context and support for all aspects of a business-centric center of excellence.

More and more of my CGI colleagues, including our Business Engineering group, are working with me to provide clients with the means to get more measurable business benefit from their SAP/ERP investments by organizing themselves in a business-centric fashion.

My joining CGI is by no means the end of my publishing and blogging. On the contrary, surrounded by an enlightened group of consultants and with more access to client contact, I expect to have more to contribute than ever before and welcome your continuing commentary and input.

About CGI

CGI, celebrating thirty-five years since its founding, is headquartered in Montreal. The acronym is derived from Conseil en Gestion Informatique which translates quite simply into “IT consulting”. Now that CGI is an international player ($4.2B, 46% Canada, 47% U.S. 7% Europe), the updated meaning of the acronym is a still precise Consulting for Government and Industry.

It's Good to Be Back

I know I’ve been lax about posting these past months. The key reason is that I took on a twelve week, Monday to Friday project helping a client in Montreal architect and plan an elaborate Center of Excellence (in partnership with CGI). I had not taken on a full-time twelve week project in twenty-five years and found the experience thrilling and overwhelming; thrilling because it was ultimately very successful and I learned volumes more about Centers of Excellence (more to follow); overwhelming because I necessary had night and weekend work to keep up with other clients and interests.


Now that the project is ended, I am getting back up and out, beginning with a workshop this coming Tuesday in Calgary. The workshop title is taken from the subtitle of my book The SAP Green Book, Thrive After Go-Live and has been brilliantly organized by Paul Kurchina as the pilot to what we expect will be many more such workshops (we have Toronto and Ottawa somewhat in the works but I also have plans for Montreal, Atlanta, and Chicago down the line). Workshop content includes SAP Marital Counseling (addressing implementation failures), revitalizing the end user eco-system, value measurement, how to build a Center of Excellence, enlightened sourcing, and much more.

I did attend Sapphire for the nth time and got to hang with the ever-present Jon Reed (http://snipurl.com/27hp3f) while speaking on Centers of Excellence and how to build and sustain super user networks (with Julie Stokes of ASUG and Kerry Brown of SAP).

I plan on writing through the remainder of the summer. First up will be a pair of case studies. The first will cover a joint effort between me and Julies Stokes the head of training for Fluor Corporation by which we have rebuilt an SAP super user network. Julie and I presented at SAPPHIRE and actually attracted more than 170 people to our talk (credit Julie; she cuts a lot of ASUG ice). My second case study will cover the project that I just completed.

While I have been silent regarding this blog, there has been no silence whatsoever in regard to my posting “IT, Your 15 Years Are Up” from last April. http://snipurl.com/27om3t Beyond the case studies, I plan on pushing the notions embedded in this posting quite a bit further.

At any rate, hello again to all. It’s good to be back.

Biztel, MyTel, and the Silver Bullet with a Woman’s Name

Why Everyone Should Care about SAP’s Newest Technologies

Over the past three years, just as SAP appeared destined to become The Boring Old Man of the applications solutions industry, it has introduced three elements that have breathed life, youth, and new interest into its eco-system: Biztel (Business Objects/business intelligence), MyTel (mobile applications) and a silver bullet with a woman’s name that speeds up the whole process. While all three of these elements represent a fine champagne for technology-minded industry analysts, I am not a technologist and yet am enamored all the same. Taking the elements one by one…

BizTel


The leaps-and-bounds evolution of business intelligence in the SAP installed base since their Business Objects acquisition has recently made me remember a pair of opposing anecdotes about executive reporting.

Anecdote 1: Constant Craving


Some years ago, I had a client who was obsessed with getting all the intelligence imaginable. At one point, frustrated with his insistence upon obtaining levels of business intelligence that his software could not provide, I told him he would have to be patient “but give me a few years and we’ll install telepathic communications.” He was taken aback and I think, for at least a few seconds, he utterly believed me. And was charmed.

Anecdote 2: The Fig Leaf

Many years earlier, when I was a CIO, our Chief Commerce Officer defined a core sales report that he had to have delivered to his desk every morning. “Without that information, I can’t do my job.” For a few weeks, I delivered the report myself and laid it perfectly on the corner of his desk. One day I forgot but did not receive a call. The next I purposefully did not deliver it. Another day, and another. After about nine working days, I found myself in the CCO’s office listening to him describe other reporting requirements. As he did so, his gaze wandered to the corner of his desk. “And I didn’t get my core report today.”

“It’s been nine days,” I told him, “that you haven’t been able to do your job.”

If I had to choose between these two men as to which I would prefer as a client, it would be the one who believed, if only for a few seconds, that in time he would have telepathic processing. I believe he would know what to do with it while my former CCO colleague would not.

At one end of the spectrum is the executive who craves intelligence for all the right reasons; at the other end of the spectrum is the executive who uses a lack of information as a fig leaf. I’ve been at this for thirty-six years and am highly aware that the Cravers have too seldom been satisfied.

With Business Objects, however, we are seeing what is around the once elusive corner.

For those who are wondering just what has changed in the SAP market, I offer these simple observations:

SAP’s Business Warehouse was vastly inferior to Business Objects, not only in its “biztel” capabilities but also in terms of the “lead-up” utilities by which clients can enable business intelligence (data selection, cleansing, and organization or “cubing”).

By virtue of the fact that SAP had actually made a major acquisition, its senior management was hugely focused on justifying the investment and thus went all out to evangelize Business Objects and to incorporate the technology into mainstream SAP. (Note: until recent years, SAP was not an acquirer. Instead, they created various partnering lines, most of which have proven to be highly successful.)

Business intelligence is a slam dunk complement to SAP business process enablement.

Business disappointment in IT efficacy has led to a wave of business intelligence consulting contracted directly by business clients bypassing their own IT. Another example of constant craving.

In sum, I am observing for the first time a turn towards client numeracy (“a 20% rise in near-term pipeline will probably overcome our 12% drop in last month’s sales) as opposed to client literacy (“our sales results suck”). This twist in the marketplace is helping to reposition SAP as a business solutions asset rather than simply another applications platform.

MyTel


INTERIOR – Executive Suite Atop a Skyscraper - Noon

A Senior Vice President of Strategic Planning sits behind a huge desk and addresses the Admin Assistant who has clearly been summoned.

SVP (to his admin assistant): Bring me the updated sales report.

Admin Assistant: You already have it.

SVP: No, I don’t.

Admin Assistant: Yes, you do.

SVP (looking around his office): I don’t see it anywhere.

Admin Assistant: On your iPhone.

SVP (slapping his forehead): Ah, quite right.

The SVP punches the face his iPhone. CLOSE UP on iPhone to reveal a three-dimensional pie-chart of day sales by geographic region.

As skeptical as I can often be, I admit to the belief that the deployment of mobile applications resulting in the remote delivery of intelligence to a hand-held personal device is an ultimate step in information and business technology. Consider this: that quarter century ago, instead of putting a printer paper listing onto my Chief Commerce Officer’s desk each morning, I can now spend that time seeking new graphics expressions of business intelligence for him (like switching regional sales from a three dimensional dynamic pie chart to a “what if” enabled sliding bar).

Beyond the fact that mobile applications can be delivered to various personal display devices is the socio-psychological barrier that has been broken. Consider the evolution of business reporting over the past forty years:

• Printouts (black ink on green & white sprocketed paper)
• Printouts (black ink on white paper without sprockets)
• Black and white (or green on black) cathode ray tube display (numbers and figures only)
• Four color cathode ray tube display including basic graphics (bar charts, pie charts, et al)
• Laptop screen 3-D color graphic dashboards

While I am using the term MyTel for what is actually “SAP Anywhere”, I am told that the use of tablets is driving mobility even more than phones due to increased “real estate”. Prior to tablets and smart phones, none of the report delivery methods ever became the object of envy. (“Hey, Ricky! Check out this great printout!”) However, both smart phones and tablets are in and of themselves hot subjects across all business spectra. Thus, the addition of “cool” technology like business intelligence can inspire envy and thus slip credibly under the heading of “viral”. When intelligence goes viral, evolution follows.

The Silver Bullet with a Woman’s Name

Viral does not stand in line. Viral does not take a message. If what you seek does not appear on your screen within seconds, you may well start seeking something else. Thus, SAP has added the silver bullet named HANA to assure that when you flip to your tablet to check out sales activity, you have only to tap a few times and results will arrive, in shapes and in colors, within seconds. Understanding the depth and density of data required to compose those shapes and colors will give you a great appreciation of la belle dame known as HANA.

HANA is an in-memory computing engine that is vastly accelerated. While accelerated computing speed can benefit many aspects of an SAP installation, I am here interested in what it can do for business intelligence.

SAP claims that it has implemented a real-world scenario on SAP HANA that demonstrates the ability to perform arbitrarily complex queries on over 450 billion records in a matter of seconds.

They Said It Was Their Strategy. They All Say That. But This Time I Believe Them. And I Refuse to Blush.


It is difficult to impress hardened industry analysts and most of us have been all over these developments for months now with questions that begin with “If that’s true…” and “If it really works…” In addition to my own queries, I have followed those of another half dozen analysts with more technology background than I possess. My angle is business oriented and I am sometimes at odds with those analysts. Not this time. As a result of my continuing assessments since last year’s SAPPHIRE, my resistance has finally melted and I can now buy into the vision without feeling like a vendor troll.

Back when SAP acquired Business Objects, were they aware of how attractive mobile applications would become if they were delivering business intelligence? Apparently yes. Did this awareness lead to a recognition that for business intelligence to work satisfactorily they might need an in-memory accelerator? Again, it appears that the answer is yes.

Thus, this suite of new elements appears to be the fruit of execution launched by strategy that was inspired by a vision. Such a trifecta has not happened for SAP since the announcement of three-tier client server technology in late 1992. And we all know what happened shortly thereafter.

...

Regular readers of this blog will, I'm sure, be surprised to read a posting like this one, but hey, there's more.
Join me and experts from the SAP Consulting organization for a webcast series covering these topics, “Make the Most of Your SAP Solutions: A Roadmap for Enabling SAP Innovations”, click here for more information and to register for the three webcasts .
http://fm.sap.com/images/WhiteRhino/innovations_series_0511/HTML_pages/lp.html?SOURCEID=Blog ).

We kick off 5-31-11 with a webcast focused on BI, address HANA and In-memory computing on 6-14-11, and close out the series with a look at mobile SAP solutions on 6-28-11.