home icon

Why Do BI Implementations Fail?

Posted by Zubin Limbuvala

Having spent the large chunk of my working life with SAP's products, I encounter people and organisations who have been left a bit disillusioned by the effectiveness of the business intelligence (BI) suite of products from SAP. In my experience of working as a consumer or a consultant, I have encountered my share of partially ineffective solutions. While I believe in the products and services I have delivered, it does amaze me that despite the best intentions and amount of money spent, there are times when I hear customers disillusioned by BI and question if it was ever meant to deliver that they wanted. This blog represents some of my thoughts and reflection on what are the odds stacked against SAP BI.

SAP's BI product suite is not vastly different from any other vendor. It has most (if not all) of the capabilities which most organisations need for effective BI. SAP BW has one of the best ETLs for SAP source systems, a very good modelling layer, a functional query writer in BEx - I know there are a few detractors here, but the capabilities it offered (and the newer visualisation tools are quite sharp) were quite adequate for a large section of users for the past 10 or so years.

I feel the answer to my question lies in the first word itself "SAP" which has become synonymous with its extremely popular ERP offering. Most organisations who have implemented ERP successfully or through painful iterations of not so successful implementations will expound about the "key to success" being project management rigour, the need to keep the solution "vanilla" and a tight control on scope. In other words, all the things that a BI project should not be. In far too many projects, I've seen organisations implement BI as another module of ERP. Get a set of requirements, set them in stone, write up lengthy project documents, ask the business users to sign them off, deliver them after 6-9 months, by which time either the requirements or the business users have long moved on or ahead. In some respects, the end users often feel disillusioned by the promise of IT delivering BI and resort to doing it themselves with their own tools or a helpful IT savvy colleague (read spreadsheets or new age click and analyse tools)

The other issue with SAP BI is that it is often delivered alongside the ERP program, often shoehorned to tag along the timelines or at best have the luxury of a short lag (maybe a month at best). This has two drawbacks - firstly to build BI on a shifting source system where the data scenarios are largely unknown, user behaviour is unknown and actual scenarios are far from mature. In short, build BI on shifting sands with the expectation to deliver it right the first time. The other issue is user involvement. In most implementations, the time which a business user can devote to an IT project is limited and precious. In most cases, BI gets shunted down the pecking order and the design is often left to the IT consultant who is told to create it as per their experience. After all they have experience of creating BI reports for other organisations, why should our needs be any different?

Hence, when SAP BI is delivered at the end of a project / program, it is often seen as lacking relevance, slow to change, not having met expectations (which were not documented in the first place) and struggles with adoption. The cure for this is often seen as another wave of fixes, often attached to subsequent ERP upgrades / enhancements where the same mistakes are often repeated.

The story becomes no different when the business requires changes to be made to the reports. The BI change is taken through the same set of rigid controls and processes which are designed for ERP systems. The result is the same - even small BI changes (sometimes as small as adding an extra column such as a formula) take days to deliver. I've also seen that the same organisation would happily adopt a shorter change cycle for another BI application in its landscape but not if the first three characters in its name start with SAP.

While I believe there is a place and time for the waterfall methodology in BI, it is generally successful in building the underlying data layers, source system connections and creating the strong foundation off which a business centric BI can be developed. Anything to be built off top of this layer should be flexible and adaptable to business needs. After all BI is a quite different!

About Author

Zubin Limbuvala- Head, Global SAP Analytics, Wipro, Ltd.

Zubin heads Wipro's Global SAP Analytics team. He is a senior Analytics leader with over 22 years of experience in SAP ERP and BI integration, management consulting and strategic decision making. He has worked across several domains such as Retail, Automotive, Oil & Gas and HLS, helping his clients getting the best from their investment in Analytics to bring valuable insights about their business.

Read all blogs

Comments (1)

Sagar - February 7th, 2017

Absolute Good read!! Seconding on the thoughts of Agile Methodology, Design Research with the complete involvement with the end-users(reading between lines) and thinking beyond the technical boundaries.

Post Comments