The savvy manager's guide to business intelligence: Making the business case for BI

The following on building a business case for BI is an excerpt from Business intelligence: The savvy manager's guide

The business case for business intelligence

Consider this scenario: You have been tasked with building a data mart for the purpose of analyzing a customer value portfolio based on all customer interactions, ranging from telephone inquiries to purchases, returns, customer service calls, payment history, etc. On the one hand, you must determine what organizations are going to be supplying data, how and when the data sets are to be supplied, and how the data is to be organized and modified for integration into the data mart. In addition, you must be able to manage the quick integration of new data sets when it is determined that they are to be included in the data mart. Alternatively, you must be able to manage the provision of information services to the business analysts, each of which may be logically or physically situated in a different location.

It would be difficult, if not impossible, to build this system without having a clear understanding of where the data is coming from, how it needs to be manipulated before it enters a data warehouse, what data is to be propagated along the data mart, and what kinds of applications are using that data. More importantly, after the system is built it is critical to have a blueprint of the way that information flows into and out of the system to provide a tracking mechanism to back up any conclusions that are drawn through data analysis. To get a handle on how to manage this environment, it would be useful to have a high-level model of the processes associated with populating and using this data mart.

The Information Factory
Most systems can be viewed as a sequence of processing stages fed by directed information channels in a manner that conjures up the image of an Industrial Age factory. In fact, there are many practitioners who have taken to describing information systems in terms of an information factory (most notably Bill Inmon, Claudia Imhoff, and Ryan Sousa in The Corporate Information Factory). Although this view may actually constrain our perspective of the use and value of information, it is a useful paradigm for how a business process can be modeled.

The Value of Modeling Information Flow
At this point you may be wondering: "This is a book on business intelligence. Why should I care about nonanalytical processing?" The answer is that business intelligence (BI) is not limited to a company's interaction with customers, but instead includes knowledge accumulated from any collection of data consumers, such as internal (i.e., within the organization) and external (i.e., cross-company) business applications. As an example, consider a supply-chain interaction between your company and a collection of product suppliers. There is embedded business knowledge that can be derived from examining all details of those interactions, including measuring vendor sensitivity to your requests, response time, methods of delivery, compliance with contractual agreements, and conformance to just-in-time delivery issues. To extract this intelligence we must understand how we have implemented our business applications and determine what data we need to collect and where that information needs to be collected. The information flow model will assist in this determination.

Design versus Implementation
Traditionally, implementers are trained in algorithm design to break down each application into a collection of discrete processing stages that can be essentially implemented in isolation. When all the stages are finished, they are combined to form the complete application. But this process of discretizing the construction of applications leads to an assembly line model of information processing in the way that data and partial results are forwarded from one processing stage to another. These processes take data (e.g., a transaction stream or extracted records from multiple data sets) asinput and provide some product as output. That can be a physical product (such as invoices to be sent out to customers), a side effect (such as the settlement of a sequence of transactions), or an information product (such as a BI report).

To remedy the eventual effects of this development process, an important part of the methodology of designing and implementing a business application is modeling the business process as a way of guiding the algorithmic implementation. In fact, building this model is the first step in the process of exploiting information. This business process modeling incorporates descriptions of the business objects that interact within the system as well as the interactions between users and those business objects. The same concept holds true for analytical and intelligence applications, where the eventual product is described in terms of analytical use and benefit.

Benefits of the Business Process Model
There are some major benefits for building this model. One is that understanding an information flow provides logical documentation for the business process. Another is that it exposes potential for adding value through the kinds of analytical processing we discuss in later chapters. A third benefit of this business modeling process is in communicating user requirements to the implementation team. When a formal framework is used to describe a process, not only does it ease the translation of user needs into system requirements, but it also provides the manager with a high-level view of how control migrates throughout the system and how information flows through the system, both of which in turn help guide the dissection of the problem into implementable components.

More generally, an information flow, as embodied as part of a business process model, provides the following benefits.

• Development road map: Identifying how information is used and diffused helps direct the development of interfacing between the discretized execution components as well as tracking development against the original requirements.
• Operational road map: When the application is in production, the model provides a description of how any analytical data sets are populated as well as a launch point for isolating problems in operation. It can also be used to track and isolate data quality problems, map workflow and control back to information use, and expose opportunities for optimization.
• Management control: This model provides a way to see how information propagates across the organization, to identify gaps in information use (or reuse), and to expose the processes involved in information integration.
• Calculation of return on investment (ROI): This allows the manager to track the use of information, the amount of value-adding processing required, and the amount of error prevention and correction required to add value and to relate the eventual business value back to the costs associated with generating that business value.

• Read the rest of this excerpt on Making the business case for business intelligence.
• Read more excerpts from data management books in the Chapter Download Library.