Day 3 / Session 9

BI: Facts & Fallacies

There are a lot of myths about BI. Some of them are dispelled here

Sanjay Mehta

Sanjay Mehta, CEO, MAIA Intelligence gave a perspective of BI entitled ‘If you don’t “get it” you don’t get it!’

Starting with a slide depicting a variation upon the folk tale about the blind men and the elephant, Mehta said, “If I retold this story today to teach a lesson about BI, I might call it “Three blind analysts and a data warehouse.” Conventional BI tools make it unnecessarily difficult to explore data from multiple perspectives, so analysts tend to pursue only a limited set of predetermined questions.

A BI solution, on the other hand, makes it so easy to shift from one perspective to another while exploring and analyzing data that we, as analysts, are encouraged to pursue every question that arises during the process.

The primary activity of data analysis is comparison. Individual facts mean nothing in isolation. Facts become meaningful when we compare them to one another. To say that quarter-to-date revenue is $1,383,593 means little until you put it into context through one of more comparisons, such as by considering it in relation to the revenue target of 1.5 million dollars or to the amount of quarter-to-date revenue that was earned by this date last year.

Newly appointed managers often ask how they can improve the return on investment (ROI) on their companies’ BI investments. Generally, what they mean is that the implementation isn’t showing any ROI because no one is using it. Often, the data warehouse was developed without any business involvement. The IT organization is likely to have done this for what appeared to be the best of reasons: it assumed that the data warehouse could assemble crucial data. The IT organization hoped that, one day, the value of the data warehouse would become obvious and “prove itself” — which hasn’t happened yet.

The cure is to avoid building a data warehouse or BI application independent of business requirements. The composition of the team that works on the initiative should reflect a clear linkage of business and technology.

IT organizations frequently complain that business managers ask them to provide BI applications with ad hoc query capabilities, but refuse to use them after they are implemented. Also, we are often told, “The only application the managers are happy with is Excel spreadsheets.” Many companies are locked into an “Excel culture” because they are comfortable with its simplicity and because it enables them to “work on the numbers.” Such tweaking enables managers to hide the truth and even commit fraud. Generally, however, tweaking occurs from the benign motive of seeking to offer some insight into the data that isn’t revealed by the system. Managers addicted to Excel don’t realize that they are thwarting the adoption of their BI application and creating potential information liabilities.

Use compliance regulations, as an opportunity to educate business users about the risks posed by the widespread use of spreadsheets, proliferating data silos and unclear ownership of performance data.

The more a company insists that it does not have any problem with the quality of its data, the bigger its problems usually are. Data quality should be a continuous worry, rather than an issue addressed by a single, limited project.

The misinterpretation of a material event begins with the data that’s offered, rather than with the interpretation. The IT department is only partly responsible for data quality. Make the business departments identify or confirm the subject areas of interest that may offer data they need to analyze.

Establish a data quality “firewall” — a process or set of automated controls designed to recognize data quality issues in incoming data and block low-quality date from entering your data warehouse. Implement a process at the back end for auditing and verifying the data. This includes reconciling the warehouse data back to source systems.

If you have an ERP, CRM or other enterprise application strategy, and a strong BI and DW infrastructure, don’t assume that you should disassemble your enterprise DW or replace your BI tools and applications. You can benefit from a “blended” strategy.

Departmental managers and IT staff should work together to stamp out redundant BI tools. Stop the proliferation of new tools by enforcing standardization for tools before they are deployed. For established tools, develop consolidation plans and initiatives to address problems created by multiple BI project and application silos.

Define a review/feedback process for ensuring that the BI strategy, investments and skills stay aligned with an overall vision and architecture, as well as business needs. Consult Gartner’s BI methodology and life cycle model, which identifies nine significant steps in the life of a BI deployment. This model is based on the best practices established by organizations that have successfully implemented BI and is divided into two distinct, but intersecting cycles: construction and consumption. Use the BICC to manage these cycles in the life of BI deployments

If BI initiatives are not working well, managers may believe that they can fix the problem by hiring an outsourcer that they expect will do a better job at a lower cost. Some companies have decided to outsource their operational applications (for example, their ERP systems). This has made it tempting to outsource the associated data warehouse applications to reduce the cost of BI initiatives—particularly those that are perceived as challenging.

Remember the “golden rule” of outsourcing: Outsource only those things that are not a core competency or core business. Business strategy formulation and feedback on its results must be a core competency. Consider insourcing these services.

Judging from the inquiries we receive, the buzzwords “dashboards,” “scorecards,” cockpits” and “corporate monitors” are at the height of the Hype Cycle. Often, the budget allotted is small, and managers don’t want to fund expensive BI tools or data warehouse initiatives.

If you have already implemented a solid data warehouse infrastructure, then a performance dashboard or complex scorecard is easier to create because the environment for aggregating data already is in place.

Ensure that management uses a strategy map in conjunction with its scorecard or dashboard. If you are not buying into a framework to make sure your set of metrics is coherent, then don’t expect any value other than anecdotal performance indicators. A strategy map is a cause-and-effect diagram between the objectives — or performance indicators at a more-detailed level — in a scorecard. If such mapping isn’t completed, the scorecard offers little more than a collection of unrelated metrics.

Every company has a different culture and every IT organization faces different challenges.