Lessons From a Business Intelligence Software Breakdown

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.


You Can't Detect What You Can't See: Illuminating the Entire Kill Chain

On-Demand Webinar

(Page 1 of 2)

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.

Page 1 of 2

1 2
Next Page

Tags: business intelligence, BI software, business intelligence software, BI, business analytics

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.



IT Management Daily
Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that datamation.com may send you Datamation offers via email, phone and text message, as well as email offers about other products and services that Datamation believes may be of interest to you. Datamation will process your information in accordance with the Quinstreet Privacy Policy.