Thursday, October 11, 2007

SAP & Business Objects

Everyone will have heard by now about the massive buyout of Business Objects by SAP. At just under US$7 billion, this is almost twice as much as Oracle paid for Hyperion several months ago (ok, 7 billion US is not that much anymore, but 4.7 billion euro is a nice stash of cash). While the deal is still awaiting approval by shareholders and regulators, it's probable it will go ahead.


The most obvious observation to be made about the deal is that it's a reaction to the Oracle/Hyperion deal, which it no doubt is, in part. There is another angle, though, touched on by Joshua Greenbaum over at Enterprise Anti-matter. One of the points he makes is that the ERP market is starting to stagnate as a result of market saturation. This is certainly the case in the market here in Australia: a conversation I had with a contact in a large BI/Data Warehousing company highlighted the fact that a lot of former ERP consultants are applying for jobs in business intelligence. If the industry research companies are to be believed, BI is still experiencing growth and is apparently on every CIO's 'radar' for the next year (I am so sick of military metaphors for business...).


Joshua also mentions the different perspectives that ERP and BI companies have on what it is that they do, with ERP obviously focussed on transactions, while BI is tools-oriented. This is certainly true, but I think that it goes further than that.


Transaction-oriented systems like ERP or any OLTP system, have inherently different design requirements from systems designed to support decision-making. Transaction systems need to process lots of small packets of data very quickly, are designed for efficient data entry and storage, and are mainly used by people with relatively little organisational authority. They are also, comparatively, easy to design. The workflows and processes supported by these systems (or in the case of ERP, imposed by these systems) are well understood and possible to document in minute detail.


Decision support tools, though, are designed to answer questions and facilitate a decision-making process. Making decisions is a fundamentally different kind of activity to keeping track of business events. The need for a decision-support tool necessarily means that the users (ie. decision-makers) are functioning in an environment characterised by uncertainty. They may have an idea of the kinds of questions they need to answer, but they can't be absolutely sure that this list is complete (and practice shows that it never is). Indeed, in answering those questions, a whole range of new questions invariably arises. In short, the use of a decision-support tool is fundamentally a learning process:


  1. The users don't know exactly what they need
  2. They don't necessarily need what they want
  3. Use of the system itself changes their understanding of what they need
  4. The system therefore needs to change to help answer new questions (and back to 3 again..)

Learning is an evolutionary process, which means the development and use of decision-support tools also needs to be evolutionary. The difference between ERP and BI is not just a tools-based perspective, it's a need for a fundamentally different mindset on the development and use of the system. When you throw users with a massive amount of organisational clout (senior executives) and cognitive factors associated with decision-making into the mix, the practice of BI and ERP are worlds apart.


Unfortunately, a lot of IT folk don't understand this difference, and we see time and again the use of old-fashioned engineering approaches to BI projects. Such approaches may work fine for transactional systems, like ERP, but doom many BI projects to failure. SAP's own BI module, SAP/BW is widely loathed as a decision-support tool, in large part because it was developed by people with a transactional-mind set. I'm aware of one very large BI project that is currently underway (not using Business Objects or SAP/BW) that exhibits exactly this engineering approach: 18 months into the project, not a single user-facing aspect of the system has been delivered to anyone, with all the work going to the back-end infrastructure. Without something for the users to react against, the learning process can't kick-off, and the requirements (against which all this infrastructure is being designed) cannot possibly be properly understood. Down the track, either one of two things will happen (unless something changes): either the requirements will change and the system will have to be redesigned; or requirements will change, the system won't be updated, and no-one will use it because it doesn't answer their questions. The only way around this is to deliver some quick wins in the form of one or more pilot projects that focus on easy, yet strategically important business areas - get the system in front of some user eyeballs, and the requirements elicitation process will be driven by their feedback.


In any case, to bring this back to SAP and Business Objects, the move makes a lot of sense for SAP. They pick up expertise on developing systems for decision support, not just recording transactions. Hopefully, they recognise this, and the move is not just motivated by a reaction to Oracle and Hyperion, or to tap into a growth market. The fact that SAP are saying that Business Objects will continue to operate as a separate business suggests they want to keep the skill base around, and hopefully it will translate into some skills transfer in the direction of SAP.

4 comments:

Bruce Fowler said...

Given the available research and the growing body of knowledge that exists in this area, how is it that such fundamental failures in project management and approach continue to occur?

How much of this acquisition is strategic positioning by Business Objects in response to the diminishing market share to competing products?

Rob Meredith said...

Hi Bruce,

Great to hear from you again. Hope all is well.

It really is like a collective amnesia. It's partly due to the training many of our IT professionals get at University - very few have specialised programs in decision support or business intelligence. The same goes for a lot of our academics too! It's also partly due to the poor message put out there by vendors (technology is the solution!).

It's also partly the expected approach to IT project governance: boards, executive sponsors, etc., all expect a certain pattern to a development project - specific deliverables with specific milestones. It's very difficult to launch into an evolutionary development process which is something of an unknown journey. The developers don't know exactly where they're going (because the client doesn't either), and that makes businesses very nervous.

Rob Meredith said...

I'm sure a fair bit of the decision to purchase, on the part of SAP, was driven by the saturation of the ERP market and the ongoing growth in BI. I'm also sure a fair bit of it was driven by Oracle doing exactly the same thing.

Cheers,

Rob.

Paul Hawking said...

Hi Rob
I am sorry there a couple of incorrect assumptions. firtsly the SAP market in Australia and the world is far from saturated. This is reinforced in Australia by the recent new customers so far in 2008; CBA, Olex, Reject Shop, Corporate Express, HarrisScarfe, BBQ;s Galore, Ballance, Westnet, Rays Outdoors.

Secondly by industry and SAP estimates there are a 30,000 to 50,000 skill shortage worldwide. this is certainly not an indication of a non growing market.

In terms of SAP BI and BOBJ; they are build on completely different architectures. BOBJ does not have a data warehouse layer and therefore has to extract data everytime a report is run. The MD admitted to me the otherday thet the product was never designed to be an enterprise wide BI tool due to the impact on performance of having to load large volumes of data. secondly the lack of a data warehouse layer makes it difficult to compre historiacl data especially if data is changed in the source systems.

30% of BOBJ customers use SAP. There is no doubt that BOBJ presntation layer tools are far better than SAP's. So these customers used BOBJ tools on top of their SAP platform. The new BOBJ/SAP BI roadmap reinforces this concept with a lot of empahsis on the incorporation of SAP master data quality tools.

The main problem with SAP BI implementations they developed at a business unit level and thus no enetreprise wide strategy which many companies are now addressing. This was not as big an issue for BOBJ customers because as mentioned previously it was never intended to be entreprise wide.

The reason SAP is keeping much BOBJ as a separate entity is that 70% of the customers do not use SAP. This means a different mechanism for dealing with many of these customers especially the smaller ones. SAP uses a similioar approach with their SME customers by using partners and resellers and the realtionship managers.