Many years ago, I was talking to some academics at a certain UK university, who were studying IT flexibility and change. They were looking for organizations in which to observe IT flexibility, and had received an invitation from a certain large organization. But they were told on the first visit that this organization had just taken a decision to implement SAP, and so they came away disappointed. Obviously there was no point in studying flexibility and change in this organization - because there wouldn't be any.
I thought this was staggeringly stupid, for two reasons. Firstly, the researchers were turning their back on an opportunity to learn something really useful about flexibility and change, by studying a situation where they believed (rightly or wrongly) it would be absent. Secondly, the researchers were not taking this decision on the basis of any previous scientific study of SAP, but on the basis of received opinion about SAP. How are we ever going to discover the truth about SAP, if independent researchers avoid looking at SAP.
A lot of what passes for knowledge in the software industry is unreliable hearsay and untested belief. That doesn't mean it's completely false: even superstition often contains a grain of truth, but half-truths shouldn't be swallowed uncritically.
Along with the supposed inflexibility of SAP, there are widespread beliefs about the elapsed time and cost of implementing SAP. These beliefs are very common among people who have had no hand-on experience with SAP.
Meanwhile the people who know most about SAP generally fall into two categories. Besides those who work for SAP itself, there are many people who work on SAP implementation - either within SAP customers, or within SAP partners and other IT service firms. To the extent that SAP implementation has become a nice little earner for a lot of people, there are undoubtedly people who have a strong commercial interest in talking up the customization requirements in any given situation. Any IT director who tries to implement a plain vanilla (and therefore cheaper) version of SAP has probably got to face a lot of well-argued opposition.
The inflexibility and expense of SAP is therefore not purely a technical fact, but a sociotechnical construction. Changing this will require not just technical change but change in governance.
Of course, this doesn't just apply to SAP. But it's SAP that draws the most criticism - and this includes vague criticism from people who don't really know what they're talking about, as well as more precise criticism from people who do.
So when I hear about the inflexibility of SAP, I find myself asking lots of questions. Precisely what is the nature of this inflexibility, and how am I supposed to reconcile this assertion with the evident commercial success that SAP has achieved? How are we supposed to evaluate any moves that SAP might make to improve flexibility.
On Thursday, SAP is expected to announce hosted CRM. Prior to the announcement, Phil Wainewright is looking for something dramatic that can compete with SalesForce.com and the other on-demand CRM vendors. He cites a recent MySAP roll-out that took 8 months, and compares this with a typical 30-day implementation lead-time for on-demand CRM. But how shall we judge if SAP's announcement is good enough to address the needs of this particular test case?
What can SAP say on Thursday (and more importantly, what can they deliver after Thursday) that will overcome not only the sceptical attitudes of many IT pundits, but also the established (and expensive) implementation practices that are apparently widespread in the SAP world?
Software as a service (SaaS) is not primarily a technical change, but a change in governance. So I shall be looking for some major innovation at this level.
Technorati Tags: SAP SaaS service-oriented
No comments:
Post a Comment