In my final reading/proofing of The SAP Green Book, Thrive After Go-Live (www.michaeldoane.com), I noted that I seldom went more than ten pages without ranting about how clients short-sheet their end users at every turn, well before coming to an entire chapter on the subject (The Care and Nurturing of SAP End Users). I considered toning it down but ending up leaving it all in. In brief, my complaint is that clients want to do anything but train their users (buying more software is usually the preference) whereas their ROI is going right out the back door because of general user incompetence.
In the course of writing The SAP Green Book, I talked with a number of consultants, analysts, and clients, including a CIO whom I greatly admire and whose firm has thrived for ten years with SAP applications. Here is a near-verbatim snippet of one of our conversations.
Me: So how are things going, Bruce? Still thriving after go-live?
Bruce: Clear sailing.
Me: How about your end user competency? Everyone up to speed?
Bruce: Oh, for sure.
Me: What if I interviewed one or two of them?
Bruce: Uh, hold it. You got me there. I don’t really have any idea.
Bruce’s company went live in 1999. In the intervening ten years, there has been no formal user refresher training.
From The SAP Green Book
In 1990, a good friend of mine helped an Australian company go live with SAP R/2. Eight years later, he was called back to the client for new work on SAP R/3. In the course of his project, he spent time with many of the people he had worked with before and in the course of a pub conversation he learned that despite a move from R/2 to R/3 and two subsequent upgrades, the users had received zero refresher training throughout the eight years. The effect, they said, was that through time they felt more and more intimidated (‘hemmed in”) by the applications software and were using less functionality than in previous years. This intimidation only increased with each new change in functionality.
This situation is wide-spread. Therefore it is encouraging to read about success at Xerox, where end user training was the key to a successful roll-out:
The key difference with this roll-out...is that Xerox accepted user training as a prerequisite for going live and made sure that end-users had enough time to complete their courses. "This meant 80% of end-users had to complete the basic training programme before going live," says Farrow.
Xerox used 1,400 training simulations taken from the company's final SAP implementation, rather than interim versions of the software. This meant there were no surprises and relatively few problems when it went live. "Well-trained people will always be able to do their job more efficiently," she says.
In the past, Xerox has squeezed training budgets and timelines in favour of system development and design. This is because unlike the technical aspects of system roll-outs, the benefits of training are difficult to quantify, says Farrow. "Training always got the short end of the stick and we had to fight to get it on the critical path of the project."
Full article = http://bit.ly/81oWKo
Keeping users up to speed should be a no-brainer but few firms are as enlightened as Xerox. Hopefully, I will see more such examples and in a subsequent reprint of The SAP Green Book, I will feel compelled to nag a tad less.
SAP Searchlight Michael Doane
Monday, December 7, 2009
Thursday, December 3, 2009
SAP Maintenance Rate Hike: The Listening Tour
Heartening news:
Dec 1, 2009 DUESSELDORF (Dow Jones)--German business software maker SAP AG (SAP) Tuesday said it had postponed a decision to charge customers higher maintenance fees for its enterprise support until next year.
This announcement, coupled with the fact that over the past six months, SAP has wisely backed off its announcement of a maintenance fee hike from 17% to 22%, is heartening and in stark contrast to a Bill McDermott’s quote that characterized the initial announcement.
"The real criticism you can make is, 'Gee, Bill, why did it take you guys so long to increase the cost of customer support, because you were five points below the industry benchmark of 22% all that time, and giving up shareholder value?' " McDermott says. "That's a fair criticism I'll accept with open arms."
Contrast this to Tuesday’s SAP declaration: "With this (delay), SAP once again demonstrates that it takes the concerns of its customers seriously and also recognizes the ongoing pressures bearing down on IT budgets in the current economic environment," the company said.
Last March, my somewhat delayed response to the rate hike was a blog post SAP: Stop Chopping Off the Tallest Heads to Make Everyone Equal http://snipurl.com/tjgu2 in which I called for tiered pricing based upon relative support burdens.
In a recent, detailed article http://snipurl.com/tjgsi, Bob Evans of Information Week pores over the statements, retractions, suggestions, and organizational pause going on in the upper echelons of SAP. The article is titled Will SAP Move to Tiered Maintenance Fees? But unfortunately there is little discussion of this. All the same, this article as well as recent others by Mr. Evans on the subject are well worth reading.
In parallel, we are told that SUGEN had completed its KPI labors and that Gartner will soon commence an audit (though what form this audit will take is not clear to me).
While I still am not hearing anything suggesting tiered pricing for SAP maintenance, the delay in raising maintenance costs is a heartening signal that SAP is listening to its installed base and may find a rational way out of what appeared to be cause for massive client revolt.
Dec 1, 2009 DUESSELDORF (Dow Jones)--German business software maker SAP AG (SAP) Tuesday said it had postponed a decision to charge customers higher maintenance fees for its enterprise support until next year.
This announcement, coupled with the fact that over the past six months, SAP has wisely backed off its announcement of a maintenance fee hike from 17% to 22%, is heartening and in stark contrast to a Bill McDermott’s quote that characterized the initial announcement.
"The real criticism you can make is, 'Gee, Bill, why did it take you guys so long to increase the cost of customer support, because you were five points below the industry benchmark of 22% all that time, and giving up shareholder value?' " McDermott says. "That's a fair criticism I'll accept with open arms."
Contrast this to Tuesday’s SAP declaration: "With this (delay), SAP once again demonstrates that it takes the concerns of its customers seriously and also recognizes the ongoing pressures bearing down on IT budgets in the current economic environment," the company said.
Last March, my somewhat delayed response to the rate hike was a blog post SAP: Stop Chopping Off the Tallest Heads to Make Everyone Equal http://snipurl.com/tjgu2 in which I called for tiered pricing based upon relative support burdens.
In a recent, detailed article http://snipurl.com/tjgsi, Bob Evans of Information Week pores over the statements, retractions, suggestions, and organizational pause going on in the upper echelons of SAP. The article is titled Will SAP Move to Tiered Maintenance Fees? But unfortunately there is little discussion of this. All the same, this article as well as recent others by Mr. Evans on the subject are well worth reading.
In parallel, we are told that SUGEN had completed its KPI labors and that Gartner will soon commence an audit (though what form this audit will take is not clear to me).
While I still am not hearing anything suggesting tiered pricing for SAP maintenance, the delay in raising maintenance costs is a heartening signal that SAP is listening to its installed base and may find a rational way out of what appeared to be cause for massive client revolt.
Tuesday, December 1, 2009
From Heidelberg to Hell: How SAP Fails to Support Clients in the North American Small and Midsized Enterprise (SME) Market
There is currently a lot of positive buzz about the next iteration of SAP’s Business ByDesign, an Saas offering (or, not really: http://blogs.zdnet.com/Howlett/?p=999) targeted at small clients like those of Salesforce.com, Workday, and others.
While the initial version of BBD resulted in a general market shrug, my impression is that SAP will, in time, come up with a creditable offering. They usually make good on R&D promises, though they often take a very long time to do so (APO, CRM, nearly every element of NetWeaver). Once the software is robust, one might assume, BBD will make its way successfully into the marketplace because “it works”.
I have my doubts. SAP, as an organization, has very little understanding of small or medium enterprises and has a spotty record of supporting firms in these markets. This isn’t only my observation. It is SAP history.
1. SAP believes that the smaller the firm the less complex the operations
In 1995, I began working in the world of SAP and my first impression was that it was intended for very large organizations. This impression was driven by a high volume of press about mega-projects such as Hershey, Georgia Pacific, Proctor and Gamble, et al.
I soon got wind of a “Heidelberg Project” (AKA SAP-Lite) that was apparently underway and was intended to service small and mid-sized firms. We never saw evidence of a successful conclusion to this project and over the next seven or eight years SAP continued to trot out SME solutions that had two common elements: 1) the offering was a chopped-down version of R/3 and 2) abject failure in the marketplace.
The thinking at the strategic levels of SAP has persistently been hamstrung by the belief that the smaller a client organization the simpler it is to run. Anyone who has ever implemented SAP software in firms of $50M to $300M knows that truth runs in the other direction. Volume does not necessarily result in complexity. Flatter organizations (those with fewer layers of management) are not necessarily simpler.
While very large clients have a division or department for everything under the sun, SME staff is most often populated by “hyphenates”, staff with multiple roles. Someone in sales also heads up marketing. A factory foreman also supervises distribution. SME’s often have no one for a given function for which a VLE will have dozens to hundreds (quality control, research, …).
Note to SAP: What I am addressing here is software deployment and operation and should not be confused with the level of difficulty of software implementation, which we all know is vastly more complex for VLEs.
The problem of scaled down software has at least been rectified as the All-in-One (A1) offering includes all the features and functionality of basic SAP enterprise software since in essence, All-in-One is simply a marketing term. It is the same software licensed by Fortune 100 firms.
What has not been rectified is SAP’s view of how clients in the SME should be enticed, how implementations should occur, and how installed base clients should be supported.
2. SAP SME staff usually knows less about the market space than does its alliance partners
SAP not only has roadmaps for its clients but also for its alliance partners in the services arena. Second tier and boutique SAP systems integration firms are regularly pressured to follow the official SAP roadmap (or playbook) for software sales and implementations. Often these playbooks emanate from Walldorf and while some of the practices included therein may work well anywhere, others more clearly address the German market than the North American market.
Messaging and marketing to this market have vastly improved in recent years and SAP provides a number of websites (e.g. PartnerEdge) with a vast store of tools, templates, case studies, and the like.
However, many of the practices are flat out wrong for the SME market. Value Engineering is too heavy for most small clients in both conception and practice. Others are flat out wrong, like a template implementation plan pawned off on systems integrators with vertical solutions that gives the impression that any implementation will be done in nine weeks at a cost of $500,000. Besides the one price fits all idiocy, what’s really cool in this template is that various module consultants are planned for two days a week. If projects are done at the client site, doesn’t this strike SAP as travel-heavy?
Further, alliance partners are required to invest in semi-constant teleconferences, site conferences, and the like in order to get training (according to these same playbooks) and to demonstrate their adherence to SAP SME standards.
3. SAP SME account management is chaotic.
Even more frustrating for alliance partners in this market is that the SAP SME cast and crew are reorganized at least every six months, resulting in helter-skelter musical chairs that requires brand new relationship networks and an enormous cost in time.
I recently spent a few years working with an SAP SME systems integration firm. In the first year, I worked with 23 different SAP people (sales, partner support, marketing, etc.). By the end of that year, fifteen of these people were either transferred or fired and the other eight held new positions. The second year was no less chaotic. I have stopped taking business cards from SAP people in the SME.
4. The answer to every knotty problem is more software.
The common dream in Walldorf is that clients can simply buy the software and that no services would ever be required. That is why, from Solution Manager to Fast Start, SAP continues to provide “solutions” in the form of software. Hey, that’s their business, right? Wrong.
Software is not an answer to a business question. It is a variable in an algorithm that can lead to an answer. SAP claims to provide business solutions but without a proper perspective regarding the services needed what you get is a pier and not a bridge.
5. SAP competes with its alliance partners.
In 2000, there were more than 200 SAP systems integration practices in North America with a healthy eco-system of majors (IBM, Accenture, Deloitte, CapGemini, Bearing Point, CSC), second tier, and boutiques. At the time, SAP Consulting had around 5,000 consultants worldwide. It has since grown to more than 25,000 while the number of other SAP systems integration practices has dwindled to the level of mere dozens and only IBM, Accenture, and (to a lesser degree) Deloitte remain major SAP players (CSC is mostly in the DoD and public sector).
While SAP claims that it does not compete with its alliance partners, SAP Consulting is, de facto, on any short list and, despite the highest hourly rates in the universe, it wins a healthy share of clients.
There is a brief chapter in The New SAP Blue Book called “Yes, You Can: SAP for Small & Medium Sized Enterprises” in which I counter many of the myths about SAP for this market. It is a sunny-side up point of view that I am determined to update in the next printing. Given the chronic lack of commitment or intelligence emanating from SAP for the SME, the chapter may have to be retitled “Yes, You Can (But You Might Not)”.
While the initial version of BBD resulted in a general market shrug, my impression is that SAP will, in time, come up with a creditable offering. They usually make good on R&D promises, though they often take a very long time to do so (APO, CRM, nearly every element of NetWeaver). Once the software is robust, one might assume, BBD will make its way successfully into the marketplace because “it works”.
I have my doubts. SAP, as an organization, has very little understanding of small or medium enterprises and has a spotty record of supporting firms in these markets. This isn’t only my observation. It is SAP history.
1. SAP believes that the smaller the firm the less complex the operations
In 1995, I began working in the world of SAP and my first impression was that it was intended for very large organizations. This impression was driven by a high volume of press about mega-projects such as Hershey, Georgia Pacific, Proctor and Gamble, et al.
I soon got wind of a “Heidelberg Project” (AKA SAP-Lite) that was apparently underway and was intended to service small and mid-sized firms. We never saw evidence of a successful conclusion to this project and over the next seven or eight years SAP continued to trot out SME solutions that had two common elements: 1) the offering was a chopped-down version of R/3 and 2) abject failure in the marketplace.
The thinking at the strategic levels of SAP has persistently been hamstrung by the belief that the smaller a client organization the simpler it is to run. Anyone who has ever implemented SAP software in firms of $50M to $300M knows that truth runs in the other direction. Volume does not necessarily result in complexity. Flatter organizations (those with fewer layers of management) are not necessarily simpler.
While very large clients have a division or department for everything under the sun, SME staff is most often populated by “hyphenates”, staff with multiple roles. Someone in sales also heads up marketing. A factory foreman also supervises distribution. SME’s often have no one for a given function for which a VLE will have dozens to hundreds (quality control, research, …).
Note to SAP: What I am addressing here is software deployment and operation and should not be confused with the level of difficulty of software implementation, which we all know is vastly more complex for VLEs.
The problem of scaled down software has at least been rectified as the All-in-One (A1) offering includes all the features and functionality of basic SAP enterprise software since in essence, All-in-One is simply a marketing term. It is the same software licensed by Fortune 100 firms.
What has not been rectified is SAP’s view of how clients in the SME should be enticed, how implementations should occur, and how installed base clients should be supported.
2. SAP SME staff usually knows less about the market space than does its alliance partners
SAP not only has roadmaps for its clients but also for its alliance partners in the services arena. Second tier and boutique SAP systems integration firms are regularly pressured to follow the official SAP roadmap (or playbook) for software sales and implementations. Often these playbooks emanate from Walldorf and while some of the practices included therein may work well anywhere, others more clearly address the German market than the North American market.
Messaging and marketing to this market have vastly improved in recent years and SAP provides a number of websites (e.g. PartnerEdge) with a vast store of tools, templates, case studies, and the like.
However, many of the practices are flat out wrong for the SME market. Value Engineering is too heavy for most small clients in both conception and practice. Others are flat out wrong, like a template implementation plan pawned off on systems integrators with vertical solutions that gives the impression that any implementation will be done in nine weeks at a cost of $500,000. Besides the one price fits all idiocy, what’s really cool in this template is that various module consultants are planned for two days a week. If projects are done at the client site, doesn’t this strike SAP as travel-heavy?
Further, alliance partners are required to invest in semi-constant teleconferences, site conferences, and the like in order to get training (according to these same playbooks) and to demonstrate their adherence to SAP SME standards.
3. SAP SME account management is chaotic.
Even more frustrating for alliance partners in this market is that the SAP SME cast and crew are reorganized at least every six months, resulting in helter-skelter musical chairs that requires brand new relationship networks and an enormous cost in time.
I recently spent a few years working with an SAP SME systems integration firm. In the first year, I worked with 23 different SAP people (sales, partner support, marketing, etc.). By the end of that year, fifteen of these people were either transferred or fired and the other eight held new positions. The second year was no less chaotic. I have stopped taking business cards from SAP people in the SME.
4. The answer to every knotty problem is more software.
The common dream in Walldorf is that clients can simply buy the software and that no services would ever be required. That is why, from Solution Manager to Fast Start, SAP continues to provide “solutions” in the form of software. Hey, that’s their business, right? Wrong.
Software is not an answer to a business question. It is a variable in an algorithm that can lead to an answer. SAP claims to provide business solutions but without a proper perspective regarding the services needed what you get is a pier and not a bridge.
5. SAP competes with its alliance partners.
In 2000, there were more than 200 SAP systems integration practices in North America with a healthy eco-system of majors (IBM, Accenture, Deloitte, CapGemini, Bearing Point, CSC), second tier, and boutiques. At the time, SAP Consulting had around 5,000 consultants worldwide. It has since grown to more than 25,000 while the number of other SAP systems integration practices has dwindled to the level of mere dozens and only IBM, Accenture, and (to a lesser degree) Deloitte remain major SAP players (CSC is mostly in the DoD and public sector).
While SAP claims that it does not compete with its alliance partners, SAP Consulting is, de facto, on any short list and, despite the highest hourly rates in the universe, it wins a healthy share of clients.
There is a brief chapter in The New SAP Blue Book called “Yes, You Can: SAP for Small & Medium Sized Enterprises” in which I counter many of the myths about SAP for this market. It is a sunny-side up point of view that I am determined to update in the next printing. Given the chronic lack of commitment or intelligence emanating from SAP for the SME, the chapter may have to be retitled “Yes, You Can (But You Might Not)”.
Subscribe to:
Posts (Atom)