A BI-driven approach can be very effective in implementing business transformation programs within an enterprise framework. In this respect, the value proposition associated with BI reaches far beyond the capability to pull together and analyze data. In fact, this paradigm is a key enabling process that can drive the resolution of fundamental enterprise design challenges.
This article focuses on the design approach of enterprise-level BI solutions - specifically, the place of BI in the business transformation activity within an enterprise environment. It documents the experience gained in the design and implementation of an enterprise BI solution that was initiated within the Materials e-procurement program at Intel Corporation in the period of 2002 to 2004 and captures key learnings that surfaced during the course of the project in an attempt to establish a methodology that can be used both by program managers and enterprise architects designing enterprise business transformation programs.
BI and the Enterprise
Although the primary connotation of BI solutions lies within the realm of advanced analytics, the main enterprise challenges to industry today concern basic visibility of operational data. Most organizations are struggling just to see what happened, let alone what is happening (closer to real-time visibility). Along with the need for a comprehensive enterprise picture, they want high data quality.
The creation of the enterprise model is a major challenge; success stories are not common. A BI-focused approach can help build an enterprise model that drives the realization of the "single version of the truth" concept. Intel's experience with GPR supports this assumption.
Global Procurement Reporting
GPR was born out of the need to see spends specifically in the indirect procurement area. Direct spends (defined as spends that represent materials used for manufacturing the product) were traditionally highly visible procurement activities. The realization that indirect spends comprised nearly 60 percent of total procurement spending - $5 billion to $6 billion - highlighted the need for a solution enabling detailed analysis of this area. A program named e-Procurement was created to deal with the business transformation required to enable indirect procurement re-engineering. GPR started as the reporting leg of the solution, but it gradually grew in significance to become the transformation engine in the creation of a comprehensive BI infrastructure.
GPR enabled the transition from a regional model - in many cases, a primitive one where commodity managers asked suppliers to provide spends information - to a globally centralized model that supports comprehensive spends visibility.
Through a release strategy that spanned more than two years, GPR today covers 97 percent of corporate spends. About 1,000 users are running 2,000 reports per week. The solution enables sourcing (aggregated) and operational (line-level detailed) analysis.
Design Approach
The notion of optimization on a global level, within a relatively unclear area (indirect spends) meant that the problem was defined at the enterprise level. Both the application and technology layers of the solution support the realization of the enterprise model - an online transactional processing (OLTP) layer, an enterprise data warehouse (EDW) as the container decision support system/reporting layer of the enterprise data model, and a relational online analytical processing (ROLAP)-based technology as the reporting solution.
The first step was to create a conceptual data model providing visibility to data in order to support the program value dials. The creation of this model, shown in Figure 1, and its representation within the e-Procurement program team was a key milestone.
Figure 1: Conceptual model connects commodity, supplier and contract.
A small team of business experts with application-design experience created a dimensional model based on this conceptual model. Their goal was to identify the key dimensions - most with a hierarchical structure - that would be able to answer most business questions (see Figure 2).
Figure 2: GPR Dimensional Model (Sample)
Data quality assessments were made on the critical master data elements, and key definitions were created for concepts such as Invoiced, Commits and Paid. These metadata definition discussions were extremely tedious but necessary.
The team gathered report requirements only after all of the above was completed. Initially, they defined requirements at a high level, mapped against the dimensional model within a fit/gap assessment. The goal was to identify whether any dimensions were missed. In the detailed design phase, the required attributes were identified, and the logical data model was completed, enabling the actual solution development to start.
Observations
A subject area is defined by the fact that it deals with core business processes. These processes are linked to core master data elements, and these elements are core to the subject area. Business transformation programs that operate on a subject area level therefore provide a natural mechanism of dealing with master data re-engineering. A well-formed synchronized plan can build out the enterprise master data required to run the entire supply chain.
Subject area design, utilizing multidimensional OLAP technology, focuses on identifying the dimensional structure on which the entire subject area is built. The identification of the hierarchies within those dimensions creates a foundation for nearly unlimited reporting scenarios to cover an open-ended number of business questions that may arise in the future.
The other critical attribute of a subject area design is that enterprise data models residing in the EDW should be created once and used by all potential applications. Instead of recreating them repeatedly, a subject area design approach will create a "single version of the truth" model that can be reused.
