System iNetwork

November 25, 2008

Fatal Flaws in BI Implementations

Failed BI efforts generally revolve around people and processes rather than technology, Gartner reports. The IT research and advisory firm pinpoints nine "fatal flaws" that stop companies from achieving strategic BI results. Bill Langston, director of marketing and channel development for New Generation Software, shares insights on each of these pitfalls. Chime in if you have reactions, too, or see additional weak spots to consider.

Flaw #1: Believing that "If you build it, they will come"

Langston: It’s tempting to think keeping users out of the software evaluation and tools selection will speed the project along. But when you look back a year or two after implementation, the companies with the highest ROI are almost always the ones where both technical and business people were involved from the beginning. People tend not to trust new software they are to use if they haven’t had any input in its selection. Users have strong opinions about the look, feel, and function of BI tools just as software developers have strong opinions about the languages and development environments they use. Another huge benefit to getting other managers involved at the beginning of the project is that if these managers see the project benefiting them, they may be willing to pay for all or at least some of the effort from their budget, rather than the IT budget. In fact, the willingness of at least one other manager to help fund and embrace the project is a powerful indicator of whether the solution has a chance of being adopted by users outside the IT department.

Flaw #2: Managers "dancing with the numbers"

Langston: Excel is a terrific tool for analysts, and it’s unrealistic to think companies are going to stop using it as a BI tool. But, Excel is not a data mart. The data underlying your Excel worksheets should not originate in Excel. It needs to come from a secure data source that’s updated according to an agreed-upon set of rules. A middle ground that addresses the need to provide Excel users with access to sensitive data, while maintaining control over its accessibility, is to store the underlying data your Excel users need in XML format inside your corporate security environment and use Excel’s XML import feature to link it to worksheets. On the IBM i, you can use the Integrated File System (IFS) to hold the XML files in secured folders. This also provides a way to ensure that the data in an Excel sheet is based on actual corporate data, not individual user’s manual input.

Flaw #3: Data quality problem? What data quality problem?

Langston: Most companies don’t realize how bad their data is until they start providing managers and analysts with reports. Part of the problem is due to the lack of standards for data entry, and part of the problem results from a lack of agreed-upon definitions and methods for deriving values when using data elements for BI. The easiest way to improve the quality of the data entered by users is to give them reports based on the data they entered and assign them a task that requires them to try to use this data in some fashion. People who never thought about the ramifications of how they enter data usually raise their standards if they can see how the data is used downstream.

Flaw #4: Evaluate other BI platforms? Why bother?

Langston: Many of the BI offerings from the major ERP vendors were developed independently and then brought together as a result of a merger or acquisition. They may not offer more than a veneer of integration, and future release enhancements may be driven by the needs of the ERP sales team, rather than by the broader needs of existing customers. They may also be optimized for the platform where the ERP vendor feels it has the most growth potential. Often, for IBM i customers, that means a BI solution that’s Windows or UNIX centric, rather than one designed for DB2 and the i.

Flaw #5: It's perfect as it is. Don't ever change...

Langston: NGS often tells companies that if their BI project is successful, it will become equally as important to their business as their accounting or other “mission-critical” business software. That sometimes comes as a surprise to managers who think of it as having a beginning and ending date. If you aren’t getting lots of requests for new information or different ways of viewing information, your users aren’t depending on the system. The BI tools you select need to be very flexible and come from a vendor who has shown the ability to deliver new releases with new function on a regular basis.

Flaw #6: Let's just outsource the whole darn BI thing

Langston: We rarely encounter this attitude. In our experience, most companies want to retain control of the project and their data. Reporting and analysis is very personal. No two people want to look at things exactly the same way so it’s very difficult for an outsider to set up a useful BI environment.

Flaw #7: Just give me a dashboard. Now!

Langston: Dashboards are exciting because they are colorful, graphical, and fun to design. But, we find in many small to mid-size companies, managers are more comfortable looking at all the underlying detail about the business rather than a graphical summary. Unless your managers or analysts can communicate how they would benefit from dashboards, you should be cautious about investing significantly in a dashboard development solution. A dashboard won’t make people better managers if they aren’t inclined to use it or if they can’t identify the business objectives it should measure.

Flaw #8: X + Y = Z, doesn't it?

Langston: “One version of the truth” may be an almost impossible goal for a large enterprise, but you can come close if you spend time upfront defining business terms so everyone agrees on what they mean. This is another reason why you need both technical and business users engaged in the BI project from the outset. The IT staff in most IBM i shops is pretty knowledgeable about the database and the way the business application software operates, but they can’t know all the ways managers want to use the data. Getting things defined and using consistent methods for calculating critical values is something the IT staff members can do very well if they have the support and input of company management.

Flaw #9: BI strategy? No thanks, we'll just follow our noses

Langston: In school, did you ever try to write a term paper without first writing an outline? Tackling a BI project without a strategy or operational plan is basically the same thing. Fortunately, it doesn’t need to be that long or complicated if you’re in a small shop. Like some of the other points above, the process of trying to document your strategy should force you to get various people engaged in the project from the outset. Writing down what you intend to do will also help you when the project objectives inevitably change, and you need to adjust your timeline. Without the written document, it can be difficult for people to remember just how much the project has changed from the original plan, and they may not accept the timeline changes.

Jim Maughan of Cyberscience Corporation adds another glitch that can hinder BI success:
"The biggest 'flaw' I see is when the customer or the BI vendor attempts to make the first deployment of BI too large for the business need. After customers see what is possible with BI, they will most likely change (expand) their requirements. If the BI project is larger than one month, it needs to be redesigned. The BI project plan and tools need to be flexible because change is inevitable. BI projects should not be limited to just data in the BI data repository. Systems that can 'drill down' to the production application and data base are a must for BI system users."

What are your BI thoughts?

--Vicki Hamende, application development and database editor

Posted by vhamende at November 25, 2008 2:04 PM