Category: ERP

Love amongst vendors is fickle

Informatica just announced a partnership with SAP. This illustrates just how difficult it can be for software vendors to develop lasting mutually beneficial relationships, since SAP had exactly such a relationship with Ascential (presumably this is now moot). Reportedly, Ascential got a lot less from this relationship than they had originally hoped, so it remains to be seen whether Informatica will do any better. Just to add to the haze, SAP has been stating recently that its Netweaver brand of technology will do ETL functions itself. So what is a customer to do: continue with Ascential, switch to Informatica, or wait for Netweaver to provide functionality?

I would suggest that the correct response is: “continue whatever you are doing”. If you were using Ascential, then it is perhaps less comforting that SAP no longer promotes this, but the technology clearly works the same both pre and post press release. If you were using Informatica anyway then nothing changes, while waiting for Netweaver to do ETL for you and so obviate the need for a separate tool is perhaps the only dubious choice. SAP’s record with products not at the heart of their application platform expertise is patchy at best. SAP first tried a BI product (actually more than one) in the mid 1990s, then replaced this set with LIS and other tools, then switched yet again to BW and Business Explorer. SAP’s MDM product did not exactly set the world alight. Despite heavy marketing through its vast installed base, it turns out that just 20 customers had deployed SAP MDM by mid 2005 (revealed at an SAP conference). 20 out of an installed base of 18,000 customers is about 0.1% penetration after two years of trying. SAP has since dropped this and bought A2I, and will rebuild a new MDM offering around that, which is another hard lesson to customers that buying from big vendors is by no means always “safe”.

So customers with ETL needs and no committed product yet should just evaluate Informatica and Ascential Datastage (now an IBM product) and let them slug it out. These two vendors emerged as the leaders in the ETL market, with previous pioneers like ETI Extract shrinking to near oblivion, and Sagent disappearing entirely. Only the eccentric and secretive company Ab Initio has retained a niche in high volume ETL, though since customers have to sign an NDA just to peek at the product it is hard to know much about their market progress.

IBM’s relationship with SAP also continues ambivalently. IBM makes a stack of money from services around SAP implementation, and gets some database revenue if the customer runs SAP on DB2, so in principle their relationship should be on solid footing. Yet SAP’s Netweaver announcement put this (including its XI technology) smack up against IBM Websphere in the middleware space, a core business for IBM, who have eschewed the business applications market. The path of true love is a rocky one.

SOA – Sounds-like Objects Again

Judith Hurwitz’s article today on SOA reminded me of at least two previous industry trends. I recall that analysts over a decade ago were predicting that “applets” were the way of the future. These mini-applications would allow customers to pick and choose a pricing routine from one vendor and a cost allocation routine from another and mix and match with impunity. This would allow a new range of innovative application vendors to bring solutions to market and let a thousand start-ups bloom. What did we get? SAP. For those who think it is different this time, let us all try and remember CORBA, which was another attempt to provide services that were application-neutral and would lead to a new set of standards-based applications. Seen too many of these recently?

The difficulty with such things is that the vision is always dragged down by the detail, and gaps in the offerings. In SOA, everything sounds good until you realise that there are no services for semantic reconciliation of data from these multiple sources, nor seemingly much in the way of a business inteligence layer. Worse, in order for people to actually build composite applications based on the SOA services, it will require all the current application vendors to meekly open up the guts of their products to allow composite apps to call them. Why exactly would they do this? Of course they will make defensive PR noises about being open, but the goal of application vendors is to sell as much of their own software as possible, not help someone else. Those with the largest entrenched installed base have the most to lose, so expect these vendors to start to offer their own “superior” form of web services, which will allow calls out from their own applications to “legacy” (i.e. anyone but them) applications, but don’t hold your breath for services going the other way. After all “legacy” is partly a matter of perspective, rather like freedom fighters and terrorists. If you are SAP then Peoplesoft is legacy, but of you are Oracle then it doesn’t look that way.

When looking at industry trends always ask yourself “who is going to make money here?”. Well, middleware vendors might, which is why IBM is so keen on the idea. As always, hardware vendors win from anything new and complex, and all that extra network traffic will benefit a further set of vendors. Of course the systems integrators will have a field day actually building those composite apps. So in summary, lots of camps will make money, so expect the hype to continue apace. Whether customers will see much real benefit is another matter.

Siebel aquisition may give Oracle indigestion

The applications industry saw further consolidation this week with Oracle’s purchase of Siebel . This is a logical step for Oracle, who need to bulk up in order to feed their struggle with SAP in the applications war, though after Peoplesoft (and hence JD Edwards), Siebel may yet cause some indigestion. It was well known on the industry that Siebel has struggled of late after its meteoric growth in the boom years. Clauia Imhoff amusingly refers to this acquisition as “donkeys can fly” on her blog. I don’t think that she intended that as praise. Siebel’s revenues shrank last year and there has been an exodus of management.

While the idea of customer relationship management is a noble one, Siebel was partly a victim of its own aggressive marketing hype, which promised much more than it delivered. Firstly, given the broad landscape of deployed applications in large companies, it was unrealistic to expect one application to “own” the customer. Worse, Siebel was long on marketing slides and short on well engineered code. A friend working at a bank who spent two years implementing Siebel described it as a “multi million dollar compiler”, since almost every function that they required was not in the core product, and required lengthy and expensive coding from Siebel consultants.

Another friend working at a giant corporation reckoned that their Siebel rollout cost more than their SAP rollout, and that was not meant as a compliment to SAP. Large companies (though not of course system integrators) had become disillusioned with these massive systems integration projects, while Salesforce.com showed just how much was possible in a relatively simple, hosted environment. When the giant deals dried up after the internet bubble collapsed, Siebel was ill suited to adapt to the more difficult sales climate, and a host of executive changes at the top were just the tip of the iceberg, with an exodus in the last year or so of mid-level staff. However, just as breeding two elephants rarely produces a gazelle, the disappearance of Siebel into Oracle’s maw does not solve the issue of customer integration in large companies. The definition of “customer” is still spread amongst every application that needs to reference it, which includes sales force systems but also billing systems, marketing systems and support systems. In time there will be one less definition around as Siebel is absorbed, but this barely scratches the surface of the problem of reducing the complexity of dealing with multiple definitions of master data such as “customer”, as there will still be dozens of sources of this data around. As discussed elsewhere , this requires tools that are not built on the assumption that they are the one and only source of the truth.

On SAP and Zombies

On SAP and Zombies

I worked for many years in Exxon and Shell and noticed something curious about large (are there any other kind?) SAP implementations: something odd happens to the people on them. Previously reasonable people would start to view the world entirely through the eyes of SAP, as though by using the software they had joined some secret society or cult. Despite any evidence to the contrary, it was as if these people had their critical faculties removed when discussing SAP applications – which could do no wrong even when there were clear problems or issues. If, for example, you mentioned some issue with the software or project, a glazed look would come into their eyes as of they were extras in “Invasion of the Body Snatchers” http://www.imdb.com/title/tt0049366/combined

I noticed this for the first time after being involved in an SAP roll-out at Exxon in the late 1980s, one of the first large-scale SAP projects outside of Germany. The project was justified because Esso UK (where I worked) had very old transaction systems that needed replacing with something, and a previous attempt to implement software from Walker had been a fiasco. The business case rested on getting rid of all the accounts clerks who raised invoices and processed orders, the idea being that the rest of us employees would do this instead using SAP. So if you wanted anything from stationery to a new part for petrol station, you would use the system instead of involving people from finance. Unfortunately SAP at the time was still partly in German, and had a quite complex user interface that involved remembering various esoteric codes to do anything like post an invoice, so although we were all sent on training, things did not go well. After a period of denial, it emerged that Esso’s suppliers were not being paid to such an extent that there were issues about the company’s credit rating, and so all the old finance clerks (and more) were re-hired to sort out the mess. To save face, they were distributed around the business lines in order to not make it look like there were now more admin and finance staff than there were before the system. This was the first instance of denial around SAP that I observed – the project was “too big to fail”.

A little later I moved to Shell UK and was invited to a presentation by a gentleman from Shell Centre who will remain nameless; let’s call him Roger. We were to hear about Shell’s new IT strategy. Flanked by consultants from PWC, Roger proceeded to explain that Shell was going to implement SAP. The bulk of the presentation was done by PWC, and was light on details e.g. the only business case seemed to be “er, other big companies are doing it”. When I mentioned that the Esso UK implementation had not delivered its promised benefits there was another zombie-like experience, with Roger saying that he had been on exotic trips to all sorts of companies in warm locations in order to research the area, and there would be no problem. I asked “Have you ever seen an SAP screen” to which the reply “I don’t need to” was not the comforting response I had hoped for.. If you were about to spend a large but unspecified amount of money on a system and you were in charge of the recommendation, would it not have been prudent to have cast a quick glance at what was being bought? Apparently not. Fortunately the consultants from PWC, who at the time got 11% of their worldwide revenue from SAP implementations and so were utterly objective advisors, saw no problem at all either.

The space-out stares continued when we were selecting a finance, time-writing and billing system for Shell Services International, the internal IT arm of Shell at the time (1998). Despite that fact that SAP was designed for manufacturing companies and not services companies, and despite the fact that none of the consultancy firms implementing SAP used it for their internal tracking, SSI management selected SAP for this purpose. What was required was very simple and could have been done in a dozen commercial packages, or indeed probably an Excel spreadsheet on steroids, but SAP it was. The cost of this, for an organisation with under USD 1 billion in total revenue (and loss making at that) was estimated at USD 50 million i.e. 5% of total revenues, which should have set off some alarm bells (most big companies spend less than 2% of their revenue on IT, never mind one project). Not a bit of it, and the project duly clanked into life. What did it cost? Not a popular question, and eventually someone admitted that it had cost USD 70 million “up to the time they stopped counting”. Did anyone get into trouble over this? Far from it. Were the customers happy with their new billing systems? I can assure you they were not.

So what is it that causes such odd behaviour? I can only speculate that once a project reaches a certain size then it indeed cannot be seen to fail – too many senior people had their name on the decision to implement, and so problems dare not be acknowledged. The people on the project, comforted by the sheer scale of the thing going on around them and concentrating on delivery, have trouble seeing the wood for the trees. The scary thing was the inability to even raise issues for fear of being labelled “not a team player”. I’m not sure if this is something that occurs on any very large IT project, as I doubt there is anything peculiar about SAP that induces such lack of objectivity. However it is an odd experience, seeing those around you who you formerly trusted seemingly oblivious to all issues and suddenly incapable of critical reasoning. I felt like Kevin McCarthy’s character Miles Bennel in the “Invasion of the Body Snatchers” movie at the end, running around shouting: “you’re next, you’re next!”