One of SAP’s strategic imperatives for the near future is to raise the company’s operating margin. Speaking at SAP’s annual meeting, Co-CEO Henning Kagermann was sanguine that the margin could reach 35%.
This goal explains some of SAP’s actions in the recent past — such as the raising of (high-margin) maintenance fees — but could it also predict something of the future? Take professional services, for example, which furnish high margins indeed for consultants, system integrators, and the like. If SAP is out for higher operating margins, won’t the quest eventually compel SAP to expend more effort on these high-margin activities.
For now, the answer is no. Just last month, Ed Harbach, the CEO of BearingPoint had the following to say during his company’s Q1 2008 earnings call: “I have not seen any of our major partners take on more work themselves and…try to squeeze the integrators out. We have good relationships with them. They have good relationships with many other people.” This was in response to the question, posed by Edward Caso of Wachovia, that “I know you’re very involved in implementing packages for SAP and others. Have any of those software vendors increased the amount of services or integration work that they’re doing themselves at the expense of the service providers?”
Surely one of SAP’s long-term strengths has been the company’s unflagging commitment to its ecosystem. But something has to give. If SAP indeed wants higher margins, it may at some point have to put the squeeze on service providers within its own ecosystem.
This could, in fact, be a boon to the marketplace. There’s little that challenges a services provider (especially a systems integrator) more than an SAP project. If SAP itself rode point on more such projects, there would probably be fewer failures.
Demir Barlas, Site Editor
At the recently concluded Sapphire Berlin, SAP co-CEOs Henning Kagermann and Léo Apotheker argued that IT-enabled “strategic agility” was the path to competitive differentiation in the current business environment. Kagermann, for example, stated that “true business network collaboration can only be conducted on a services-based IT infrastructure that is flexible and efficient enough to allow companies to adapt their business processes to business needs.”
What’s interesting about this rhetoric is that it is at odds with SAP’s character. Enterprise applications, whether from SAP or other providers, are not agile. They can’t be changed by the customer, since the code is proprietary, and vendors do not tend to make major revisions to the product. If you’re lucky, you get six-month upgrade cycles driven in part by the feedback of your industry peers; if you happen to be in an industry or segment not particularly valued by the vendor, you won’t even be that lucky.
This isn’t a knock against traditional software providers. In fact, perhaps the strength of much of SAP’s product is that, like the businesses it serves, isn’t agile. There are only so many ways to process purchase orders, tie systems together, and orchestrate process flows; there are only so many ways an enterprise can conduct business; and SAP is more vested in finding the canonical way of doing things instead of giving you fifty options. If you want system-wide agility, you need to be able to code changes yourself, and this requires both open source and a very well-trained in-house IT team.
Agility is one of the most abused words in IT and management today, for a number of reasons. Firstly, agility isn’t necessarily good. Becoming competent and staying that way is probably a better guarantee of business success than flitting from model to model in search of success. Secondly, agility may not even be possible. Branding tends to lock you in. Starbucks can’t sell cheap coffee and still be Starbucks, even if selling cheap coffee is the right model. Finally, agility may not require much of a boost from IT. IBM’s 1990s decision to get more heavily into services, one of the few genuine examples of agility over the past two decades, didn’t need IT to succeed.
Demir Barlas, Site Editor
Wal-Mart, which agreed to buy SAP ERP Financials last year, officially began its rollout yesterday. It’s a massive, multi-phase project that sees Wal-Mart ditching its long history of developing IT systems in-house in favor of working with packaged software vendors (including SAP arch-rival Oracle).
Already, however, there are some red flags around this project, not from a functionality or project expertise perspective — SAP ERP Financials works, and Wal-Mart can afford the finest systems integration — but from a strategic perspective. Consider that Wal-Mart CIO Tom Schoewe has stated that “As you continue to see us grow, enter new countries, [SAP is] something that can accommodate that better than our home-grown solution.”
Growth? Entering new countries? Wal-Mart registered a 3.5% same-store sales decline in April, its worst performance in this metric in nearly three decades, and has been beaten out of South Korea and Germany, where the local retailers easily kept pace with Wal-Mart’s basement pricing strategies and continued to retain local customers, many of whom were no doubt culturally alienated by the faux-friendly in-store Wal-Mart experience. This winter, many of the people who faithfully shop Wal-Mart may have to spend their money on natural gas and gasoline instead, and there’s no indication that the world’s shoppers — outside England — are enthusiastically lining up to shop at Wal-Mart.
Wal-Mart is a vast company, and is a larger economic entity than some countries, but growth isn’t perpetual, and success in foreign markets is fickle. The company would be better served adjusting to these economic realities rather than planning to expand still further. It’s not as if there aren’t other priorities. How about squeezing more margin out of higher-margin goods? How about finally delivering on that RFID promise? How about building a brand friendlier to social issues like the living wage? But no, Wal-Mart anticipates business as usual, and has brought SAP along for the ride.
Certainly, Wal-Mart, like so many other retailers, needs to develop new IT capacities in order to keep up with larger supplier ecosystems, more complex logistics, and pickier customers; but to peg the SAP investment to corporate goals that don’t have much of a chance of succeeding seems like an invitation to project failure of some kind.
Demir Barlas, Site Editor
SAP signed a megadeal with the U.K.’s Birmingham City Council (BCC) in 2006 designed to save the sum of $2 billion over 10 years. However, SAP’s BCC deal is currently a project in trouble, joining the cities of Portland and Burnaby as recent SAP public sector projects that are going wrong. Today, Brendan Arnold, BCC’s Director of Finance and the executive in charge of the SAP project (known as Voyager) stepped down from his post, capping two years of complexity and acrimony at BCC.
The crux of the problem is that BCC, which processes hundreds of thousands of invoices a year, wanted to move those financial processes to SAP but encountered difficulty along the way. Earlier this year, as many as 30,000 BCC invoices had not been paid by the system, recollecting the SAP-LAUSD situation in which LAUSD employees were not paid for months. Capita, the consultants involved with the deal, have pocked twice the amount they were originally supposed to get, and left a terrible impression with BCC employees who refer to them as “Crapita” on The Stirrer, a Web forum utilized by the BCC community. Capita, which offered both training and support for the project, allowed some urgent support requests to go unanswered and unlogged, creating further problems for frustrated BCC employees who are the frontline users of Voyager.
As if this weren’t bad enough, John Hemming, a local politician associated with the project, decided that the employees were to blame and called them “whingers” on The Stirrer. Hemming and senior leaders of Voyager believe that BCC staff resisted being trained and are unaware of the full value of the system, which does in fact successfully process far more invoices than it neglected earlier in 2008. For their part, employees blame management for being optimistic, unprepared, and in denial — three characteristics that are guaranteed to tank any major SAP project.
Perhaps the most damning view of the entire project comes from Stirrer contributor ATVLand, who has this to say [some sentences re-ordered]:
“The SAP system was developed for widget makers and the like – hard outputs. But that’s just it – we discovered that our service area, over coming months, will be monitored on ‘outputs’ tied in to Voyager; these outputs will determine how much money my team gets, and also whether or not our personal performance will then allow for regrades…Many of the things the Council do are not measurable – SAP tries to make them so. A colleague worked for a London Borough where they tried to introduce SAP, he said that the staff became slaves to the system, constantly inputting data to it – and not getting on with delivering the service. The Council runs on a lot of goodwill (despite many people out there thinking we’re all wasters) – more and more of out time is spent trying to get around the levels of bureaucracy and indecisive/pedantic/thick Cabinet Members – people of Birmingham will suffer if the staff are forced into yet more layers of bureaucracy. I’m told placing an order for something has to go through several layers of people now too – is that really more efficient? The removal of petty cash means that we can’t provide coffee for clients, we subsidise BCC from our own pockets for bus fares and odd items of statonary/office equipment etc now have to be bought at considerably higher prices through the SAP system (rather than popping to poundland and claiming back) – is that really better for the Council?”
There are many important points here, perhaps the chief of which is that the nature of service, especially public service, cannot (or should not) be reduced to “hard outputs” in all cases. Indeed, that’s the major difference between public and private service, and it could be one of the reasons that so many SAP projects in the public sector are falling short.
Demir Barlas, Site Editor
The IT industry is abuzz with talk of Workday’s recent Software as a Service (SaaS) deals at Chiquita and Flextronics. While I’m glad that Workday is having its day in the sun — after all, I have Workday founder Dave Duffield to thank for Cornell’s Duffield Hall, where I passed many pleasant hours — I’m uneasy about these deals for a number of reasons.
The market has gotten hold of the idea that Chiquita bought 25,000 subscriptions, and Flextronics bought 200,000. This notion has spread through the IT media and brought Workday accolades for signing the biggest SaaS deals in history. Workday itself doesn’t manifestly make these claims (in Chiquita’s case, Workday merely said that it was implementing human capital management applications “across the organization”), but hasn’t done anything to clarify the situation either. Claiming that Workday will be used “for” 200,000 employees, as many news organizations have done, is a dereliction of journalistic responsibility, because that “for” can be fudged to mean that Human Capital Management (HCM) addresses the needs of 200,000 employees. However, what the market is more interested in is the number of actual end users.
I’ve always thought that HCM is at least as important as Customer Relationship Management (CRM), but I’m frankly skeptical that all the employees in an organization would use it. Sure, if HCM underlies a self-service HR intranet, it could extend to everyone at a company. Everyone would be issued a user name and password to enter the system. But is this part of what Chiquita and Flextronics have bought? It’s impossible to learn much about either of these deals, because the companies aren’t talking. That’s strange in itself, because CIOs who have converted to SaaS tend to make very enthusiastic interviewees — like converts who are eager to spread the SaaS word.
For me, Flextronics’ and Chiquita’s silence clouds Workday’s recent success. I want to know what Workday sold to Flextronics and Chiquita, and how many workers will have subscriptions to the solution. I want to know not because I’m a skeptic, but because I’m a reporter at heart and want to know whether these deals are actually the biggest SaaS deals of our time, so that I can compare them fairly to SAP deals and Salesforce.com deals. I also want to know whether HCM has gone beyond the self-service portal in these instances, and for this purpose I’d like both companies (and Workday) to be more clear. I thought obfuscation was an old on-site software provider trick; it is really is a brand new SaaS day, it would be nice to see more open practices.
Demir Barlas, Site Editor
A recent book entitled Rightshore!: Successfully Industrialize SAP Projects Offshore by Capgemini consultants Anja Handel, Wolfgang Messner, and Frank Thun can serve as a helpful read for soon-to-be SAP end users deciding how to calibrate an implementation strategy.
Given that system integrators can execute an SAP implementation from anywhere in the world, SAP end users will be called upon to decide how they want their partners to deliver service. Rightshore! offers a helpful discussion of the various options in this regard, and their respective benefits. For example, the book explains that there are five basic implementation delivery models:
- External Offshore: External execution by offshore partners.
- External Distributed Delivery: External execution by nearshore partners, who subcontract work out to offshore partners.
- External Nearshore: External execution by nearshore partners.
- Internal Centralized: Internal execution by a single party.
- Internal Decentralized: Internal execution by several parties.
The fastest-growing model is external offshore, which went from being involved in 1% of IT delivery projects in 2006 to an estimated 5% by 2010. Rightshore! points out that external offshore promises 15-20% savings over internal delivery. This is why many systems integrators, Capgemini included, have hired tens of thousands of Indian workers; the resulting wage arbitrage allows integrators to deliver cheaper implementations to customers via the distributed delivery model.
Of course, this raises an interesting question — why not bypass nearshore partners and go directly to an Indian integrator, such as Wipro? This didn’t get talked about much at this year’s Sapphire, but could be a big issue by next year. Given that almost all of the major SAP failures over the past year involved nearshore partners, there’s no knee-jerk reason to dismiss offshore partners for any SAP project.
Rightshore! makes the argument that a blended approach to delivery models is the key to a successful IT project implementation, but naturally this owes something to the fact that Capgemini owns the trademark to the world ‘rightshore’ and has a vested interest in promoting this model. However, moving past the marketing fluff, rightshoring is a concept that should be taken seriously in the SAP context. An SAP project is complex enough to benefit from the ability to farm out certain kinds of tedious technical work offshore while retaining certain functions, such as training, from near-shore providers. Vendors understand the soundness of this approach as well, and Indian systems integrators have long invested in dedicated U.S. and European resources in order to be able to tell the ‘rightshoring’ story to customers.
For some enterprises, buying SAP is a relatively easy decision, but implementing SAP raises many anxieties. To begin with, there are the horror stories of implementations gone wrong, resulting in millions of dollars of cost-overruns and long delays to go-live; consider the LAUSD fiasco, Waste Management’s $100 million lawsuit against SAP, and problems in Burnaby and Portland. But even in the best of cases, SAP implementation is a major challenge. ‘Rightshoring’ your implementation is one way to mitigate the inevitable risks.
Demir Barlas, Site Editor
There is a growing number of failed SAP public sector deployments, ranging in scope from the Los Angeles Unified School District (LAUSD) megadeal to the smaller Burnaby, B.C. project. Now the city of Portland, Oregon can be added to that list. A city analyst has revealed to the media that Portland’s SAP project, budgeted at $31 million in 2006 for a 2007 go-live date, is now estimated to be nearly $50 million and won’t be complete until 2009. Portland has fired its systems integrator, Ariston Technologies and Consulting, and is working directly with SAP services to get the system up and running.
It isn’t clear who’s to blame for the cost overrun and project delay, but Portland and Ariston will no doubt implicate each other in time. The soundness of the underlying SAP software itself has not been questioned by either party.
One of the interesting features of Portland’s SAP implementation is the claim, made in a budget document back in 2004, that:
“Users are aware of the many recent developments in ERP software that they feel would better serve their needs. Staff specifically cited on-line real time queries as a high priority as well as the ability to drill down or summarize data. Most said that the staff time spent compiling financial information from various sources in different formats outweighs the cost of a new system.”
While it’s impossible to argue over the merits of the business case without access to all the numbers, it seems highly unlikely that improved data reporting capabilities justify a $50 million expense (to say nothing of maintenance costs for years to come). Of course, there’s also the benefit of getting rid of Portland’s old legacy systems, but how expensive can these be? In the case of Washoe County, Nevada, another SAP ERP customer working with Ariston, 23 interfaces costing between $15,000 and $20,000 each were ditched after implementing SAP. Call it a half million in savings.
Granted, enterprise applications investments are not always about immediate hard cost savings. For many companies, the investment is strategic: for example, it enables them to remain competitive, keep pace with the data demands of their ecosystem, or achieve long-term efficiencies in front and/or back office processes. But the public sector is not the private sector. Portland isn’t in competition with other city governments, and its main job is to provide basic services that governments have successfully provided for thousands of years before the advent of software. It’s very easy to understand why blue-chip private companies such as Coca-Cola or Bank of America would go with SAP and related applications investments, because the investment allows them to do things they couldn’t even contemplate before (such as smart picking in Coca-Cola warehouses). It’s no so easy to understand why city governments are eagerly disbursing tens of millions of dollars for software for enterprise software.
There’s a reason it’s called enterprise software.
Demir Barlas, Site Editor
There’s a major shortage of SAP skills in the marketplace, thanks to the inevitable lag time between SAP’s aggressive debut of new products and IT workers’ ability to master the associated skills.
That’s the message from Foote Partners’ upcoming report on IT skills and compensation. The report is massive, encompassing hundreds of skills, cities, and vendors, but its relevance to the SAP world is focused on the following takeaways:
Hot SAP Skills: SAP MDM, SAP ERP, NetWeaver BI (formerly SAP BW) and SAP HCM are seeing double-digit growth in compensation over the past several months.
Fading SAP Skills: ABAP, Basis, Payroll, SAP SD.
This isn’t meant to service as an index of importance. In other words, the “fading” skills aren’t less vital or widespread; they’re just not seeing compensation growth at the same pace as the hot skills. Similarly, the hot skills are not necessarily the high-volume skills; if you’re an SAP HCM expert, you can command an increasing premium, but you might have fewer opportunities to apply those skills. There are many such factors involved in maximizing your marketability. However, based on Foote Partners’ insights, it’s a safe bet to say that techies with experience in any of the “hot” categories should be talking to recruiters immediately.
In terms of the “fading” categories, it’s worth wondering whether, in time, these could be yesterday’s skills.
Demir Barlas, Site Editor
There are no authorized SAP training partners.
That seems like an odd claim to make given the large number of companies claiming to provide authorized SAP training–Genovate, for example, and dozens of other companies based in South and East Asia. But the fact of the matter is that SAP itself does not officially recognize, let alone authorize, any of these companies as training partners. The partner category closest to this function is “education,” which SAP defines more as the ramping up of existing SAP end users than as the generic training of aspiring SAP developers. Becoming an authorized SAP education partner is difficult; only one company in the U.S., RWD Technologies, is qualified in this category. Naturally, SAP training is provided on an ad hoc, on demand basis by consultants and integrators, but this service is also much closer to SAP’s category of “education” than to the current marketplace understanding of “training,” which is most frequently used in the aspiring SAP developer context.
Yet, somehow, companies such as Genovate continue to claim that they are authorized SAP training partners. Genovate isn’t even mentioned on SAP.com, but on the SAP Developer Network, SDN, the company is regularly described as being an “authorized” SAP training partner.
Either SAP countenances Genovate’s claims in some indirect way or SAP doesn’t bother to address the messaging issues raised by these de facto members of the ecosystem. Either way, it’s a disservice to the marketplace. Walldorf’s mighty legal machine should forbid companies from claiming to be authorized SAP training partners, because such claims do not accord to SAP’s own partner taxonomy or to SAP’s rigid standards for partner authorization. In fact, such claims exist largely to separate vast numbers of gullible Indian technology graduates from their hard-earned money by building the impression that SAP itself confers legitimacy on “training” companies.
The big news in the SAP world this week is the severe shortage of skills; along with Foote Partners, we’ll be exploring this subject in an upcoming podcast and articles. As far as SAP customers are concerned, the existence of shady training companies is contributing to the influx of inexperienced (and, in some cases, fraudulent) SAP techies into the marketplace. When SAP skills get diluted, projects fail.
So it’s really in everyone’s interest for SAP to hit hard at the so-called “authorized” training partners, particularly those in India. The point isn’t to stop these companies from operating, it’s to remove the impression that they have SAP’s mark of approval. At that point, let the marketplace decide their fate.
Demir Barlas, Site Editor
The show floor was electric this year at Sapphire 2008 in Orlando. With over 15,000 attendees, the vendors had their work cut out for them. I saw booths that featured magicians, Guitar Hero, and a 2008 Porsche. A handful took the sex appeal approach. With all these distractions, people were wandering around aimlessly everywhere. Upon noticing the clear behavioral differences I got the urge to ask these people what their original goal was en route to Sapphire.
Mike – UK based oil company
Mike said that he was doing board research on SAP for his “own personal learning experience.” He described his experience at Sapphire thus far as a net cast over everything SAP. His company is not currently using SAP as an ERP solution, but he seemed to think that they will in the future.
Deon – Australasian forest products company
Deon was focused on upgrading SAP, since his company had not upgraded in quite some time. He seemed almost angry in asking,”How does SAP justify the cost of an SAP upgrade?” and “Can it be quicker, with less disruption to the business?” Deon also said his company was very interested in Duet and that Outlook integration is very important.
Nancy – North American computer technology and consulting corporation
Nancy was at Sapphire to gather info about HCM and to “learn more about Cognos.”
Lynn – North American agricultural biotechnology corporation
A “secret agent” for her rapidly growing company — no time to spare! Lynn is researching new capabilities to be unlocked within SAP in order to leverage it properly. She was completely on task, admitting that she has “several meetings with SAP to understand, from a strategy and execution standpoint, where we can go from here.”
Does Sapphire help the average corporation? You tell me… what did you set out to accomplish at Sapphire this year? If you didn’t make it this year, what would you do in a sea of vendors and unlimited enthusiasm?
I’ll be going around next year, so be sure to look for me… I’m sure looking for you.