In the first article of this column ( http://www.dmreview.com/master.cfm?NavID=68&EdID=5182) appearing on DMReview.com on May 12, 2002, I made the case that to move beyond the delivery model of data warehousing (DW) and business intelligence (BI) to a business sustaining model, we need to focus more on actionable use of information. The DW needs to affect the business, not make business life easier. First, the DW/BI team needs to create business functional requirements. The typical list of functional requirements for an analytical environment usually contains:

  • Move data monthly,
  • Clean up customer name and address, and
  • Provide access to integrated data.

Unfortunately, none of these are business requirements. In a mature field like DW, solid reduction in costs, cycle times and increases in revenue have to be guaranteed. BI efforts must be explicitly aligned to business opportunities. Data movement requirements, cleansing, query and ETL tool acquisition must take a back seat. Business functional requirements should resemble these ideas:

  • Create new up-sell marketing programs,
  • Identify and pursue cross-sell opportunities, and
  • Share prescription data to identify drug interactions.

Specifying requirements and engineering solutions requires delving into business processes and change management. It means there is a whisper of business process reengineering (BPR) or knowledge management(KM) in moving beyond the data warehouse. This column will adapt some concepts from BPR and KM and apply them to extending DW value.

Techniques for Advancing the DW

There are three basic categories of techniques. Some should seem familiar; others may be different.

Alignment Techniques

These identify business requirements and align the business with the existing and potential BI projects. Examples of these techniques are:

  1. Determining business drivers for the DW – A DW that moves beyond itself looks for sustaining justification. This means understanding the explicit business drivers, goals and objectives the DW could support. Again, "better access to data" is not a valid business reason. An understanding of measurable business targets should be used to create an atmosphere of direct connectivity to the business.
  2. Develop conceptual models to create baseline analytical and functional requirements. Two types of models are crucial for developing an apolitical set of parameters for an actionable data warehouse.
    • Measurement model – while not a model in a diagram sense, nevertheless a measurement model contains a conceptual list measurements and metrics that can be applied (or are applied, such as balanced scorecards) to prove to the business that goals and objectives are being fulfilled. In addition, this model directly supplies the technical architects with the baseline functional requirements. They can be algorithms, counts or simple signals an event has occurred. An example of a measure is distribution cost as percent of sale, loss ratio, yield, etc.
    • A high level or conceptual data model – This type of data model defines core subject areas, entities (super-type level) primary keys and attributes required to fulfill the measurement model. Many times this can be extracted from an existing model. Combining this information with the quantitative knowledge derived from the measures creates a solid baseline of requirements that can reviewed by business users.
  3. Develop "know if" scenarios – Create process flows of how the business will, or could, use the DW information. The key here is that the team cannot accept the business telling them " we know what to do, just get us the data." An example would be a process describing how customer Scores will be calculated and presented at various touchpoints. The result of this process will be the business recognizing and committing to new ways of using information Benefits of this technique are twofold. Obviously, it forces business users to think differently than just "getting data" and more toward business change. Secondly, the technique lays down a base line of process knowledge and human capital required to full exploit the DW.
Apolitical means that you will be able to derive the future DW environment you truly need vs. a fight over theoretical constructs such as atomic data warehouse, star schema and federated data marts - all great approaches within perfect scenarios. However, none of these constructs singularly support advanced BI or long-term actionable use of information (i..e, no religious wars).

Value Chain Analysis Techniques

These techniques develop models that depict where and when the business will use information to increase value or achieve goals.

  1. Determine high-value processes that utilize information for corporate benefit – these are identified from the "know if" scenarios.
  2. Create models of the high-level business flow of information, by SUBJECT AREA, as it will flow through the organization.
  3. Analyze INTEROPERABILITY between all processes in this high-level flow. You are looking for latency issues, volume bottlenecks or areas where data controls will be critical.

Quantitative Design Techniques

These techniques determine agnostic frameworks for BI. That is, they identify what types of access layers and data movement is required for your particular data analysis and usage requirements. The agnostic label again emphasizes that a sustainable, actionable DW does not pursue a single vision of schema or operation (star schema, atomic, etc.) but creates a framework that can adapt to business needs over time.

  1. Merge the analysis of measures and interoperability to determine a framework. (Framework here means the nature and sequence that the combination of granular data stores, summarized stores, operational stores etc. are implemented.) Cross- analyze measure and ISC latencies volumes etc. to shortlist required technology and meta data.
  2. Use clustering techniques to determine applications that are aligned with business drivers. An example is to do an affinity analysis between measure attributes and objectives, or attributes and measures.
  3. Correlate the framework requirements to the applications to identify a series of iterations to implement new BI applications. Use the measures to identify ROI opportunities and build the business case.

Once you get on a roll, the extended DW will support development of new business process models. These will reflect potential opportunities to use new information. After the frameworks have been defined and projects are designated, then a change management plan for business processes can be developed and implemented. After all, these techniques have most likely pointed out that there is an opportunity to do business better once the information is produced by the DW. The potential organizational changes require a comprehensive plan that systematically assesses and addresses the cultural impacts of sharing information.
Unfortunately, many DW shops do not believe that analysis and discipline can result in discovering a business case for reengineering. They will miss their opportunity to advance to a more beneficial second or third generation DW/BI. CIOs will have to argue successfully for more mature approaches to information handling.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access