Lessons From a Business Intelligence Software Breakdown

Wednesday May 26th 2010 by Larry Marion

A pre-built business intelligence software solution turned into a user nightmare for one firm, providing valuables lessons for users of off-the-shelf BI applications.

In more than 15 years of interviewing senior executives about their business intelligence software implementations, I can’t recall hearing about a more badly mangled environment than the tale I am about to tell. And I can’t recall meeting a more candid IT executive than Dawn Conant, director of business intelligence at Beckman Coulter, life sciences instrument maker.

Conant publicly disclosed the company’s trip into a BI rabbit hole, and subsequent escape, at the April 2010 Business Intelligence Summit organized by research firm Gartner.

Beckman has $3.3 billion in annual revenues and 12,400 employees, but beginning in 2001 it created a business intelligence software monster appropriate for a company 10 times its size. Astoundingly, business units created more than 900 Business Objects universes (essentially data marts).

Worse yet, approximately two thirds of them were running directly against a single global Oracle ERP instance or other online transaction processing system. There was no data warehouse to protect the production environment from the analytical sandbox, so performance was awful.

User departments were running amok amid the data marts – more than 1,500 decentralized report writers had created more than 4,500 different canned reports. But only 1,200 reports were unique, Conant noted.

You can predict that there wasn’t a single version of truth. Instead, there were hundreds of expensive versions of guesses. The frustration and confusion went right to the top – the board of directors had called in its own audit team because it couldn’t validate the company’s financial reports.

Conant’s summary of the situation by 2007: “It was complete chaos.”

Beckman’s CEO and CFO called a halt to the madness in late 2007, just as the IT department was trying to clean up the mess. The top execs had heard from Oracle about the prebuilt analytics approach that the software vendor offered and they bought into the vision.

It would save money and streamline the IT organization to use the Oracle Business Intelligence Enterprise Edition, accessing a data warehouse pulling data from the Oracle ERP system.

For the past several years Conant and her team have been implementing a large number of Oracle prebuilt analytics applications to support the following business functions:

• Customer and Product Profitability
• Inventory Management
• Order Management and Order Fulfillment
• Service (custom build)
• Supply Chain
• Finance
• Human Resources
• Quality Assurance (custom build)

All of them went live in early May, with approximately 300 reports. By the end of the year the number of reports is expected to rise to roughly 600.

Conant and a team of 120 people (divided equally among IT, business, and consultants) implemented a powerful business intelligence software environment complete with validated and authenticated data, providing important insights about product profitability by region, customer, or other metric.

In the process her team replaced a fragile and expensive infrastructure with one that was more stable and cost efficient. And she learned a lot of lessons about pre-built analytics apps:

• The rule of thumb frequently provided by the vendors of prebuilt apps is that you should be able to use at least 80% of what is in the box and only have to customize 20% or less. It will come as no surprise that her first piece of advice is to not bank on that level of usability. Instead, carefully match up the code you get versus the functionality you need. “Significant analysis of the code,” is required before you make a commitment, she noted at the event.

• This need for analysis is especially true for the extract, transform and load (ETL) portion of a data warehouse and analytics infrastructure. As Conant points out, ETL is roughly 80% of the implementation challenge and cost, so if the out-of-the-box analytics provides at least 50% of your data sourcing code, it is probably worth it.

• Make sure your business users, and especially your experienced report writers, are part of the code analysis team. The IT department won’t know where all the source data problems are, so you better have people on the assessment team who know the black holes.

• Modifying those prebuilt apps is not a job for neophytes—only let experienced implementers touch that code.

• Building your environment also takes experience to avoid serious mistakes, not the least of which is horrible performance problems. “We didn’t know what we had purchased,” Conant acknowledged to explain the challenges users initially experienced with the performance of many of the reports.

• Report development centralization was implemented to ensure appropriate levels of control. Rather than 1,500 distributed report writers, no more than 100 people will be given writer access to the system. And they will be extensively trained. Validated reports conforming to SOX and other compliance mandates become standard operating procedure, not a wish list item.

• Everyone knows managing data quality is tough, but typically the task is underestimated. Validating and testing data was “extremely hard,” she adds.

• I’ve been hearing IT executives lament about the inadequate amount of change management they included in their implementation plans since they implemented ERP systems to avoid the Y2K scare 10 years ago. Conant says there is still a substantial change management task ahead at Beckman. Taking custom developed reports away from the users that developed them and replacing them with flexible, pre-built reports that are centrally developed is on her plate for this year.

As others have noted, selling the best practices of the pre-built apps is one way of persuading managers to accept the new way of life. Top executives will support this effort because it gives them the opportunity to implement strategy and execution throughout the enterprise.

Other experts offer other cautions about pre-built business intelligence analytics:

• Pre-built apps makes sense for support functions, notes Christian Kirschniak, Global SAP Solutions Leader, Business Intelligence Solutions, HP. Enterprises need to differentiate their core capabilities and shouldn’t consider a generic approach for those processes. HR or IT is not a core competency, so pre-built analytics makes sense in those areas, he added.

• “If analytical packaged apps don’t start with a basic architecture for exploring data, [nor a] a preconceived mix of fixed tables and schema with a presumed approach to reporting, then you’ll run into expensive customizations,” warns Dyke Hensen, Senior Vice President, Product Strategy of PivotLink.

And Dyke should know, his 20-plus years in the Business Intelligence software business includes stints at pre-built analytics firms such as SPSS, Hyperion and Arbor.

The bottom line on pre built analytics: They deliver less than you hope but are usually better than starting from scratch.

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved