The Bottom-Up MisnomerOur data-warehousing approach is sometimes referred to as bottom-up, but it's far from itby Margy Ross & Ralph Kimball Continued from Page 1 An Orderly ConclusionAlthough teams and their management generally appreciate the need to gather business requirements, they often fail to appreciate the importance of agreeing on priorities. One way to help clarify priorities is to create an "opportunity matrix," as shown in Table 2. The rows — as in the bus matrix — list the core processes of the business. But in the opportunity matrix, the columns represent departments or workgroups rather than common dimensions. Each x in the table indicates which groups are interested in the metrics associated with the business process/event rows. In this manner, the opportunity matrix captures shared data needs and interests across the organization. Keep in mind, however, that focusing on the most frequently requested business process and its metrics doesn't necessarily translate into the top organizational priority. Once all the requirements have been gathered, a presentation and prioritization session is held with senior management from various departments and workgroups. The session begins with a playback of the requirements findings — typically a major eye-opener for senior management. These managers may have been funding (or trying to fund) their own department-focused analytic data fiefdoms. They're often unaware of the common information needs across departments in addition to the redundant resources and organizational waste associated with existing departmental solutions. We then paint the long-term picture of integrated analytic data across the enterprise. Rather than presenting a complex diagram with numerous boxes representing various data stores, we share the enterprise bus matrix (Table 1) with management. It's a wonderful communication tool to ensure a common vision and understanding without getting mired in technical details. Each business process row of the matrix represents a project within the overall data warehouse program. As such, we subtly focus the senior managers on manageable (and, we hope, meaningful) project scope boundaries. In an upcoming column, we'll discuss matrix rows that consolidate data from multiple processes; however, we don't suggest beginning with these more complex, consolidated processes. Meanwhile, the dimension columns of the matrix provide the common links between the business processes' KPIs and success metrics. Senior managers need to understand the importance of common conformed dimensions for consistent business rules, labels, and data. They should also appreciate that regardless of which data warehouse project (matrix row) is selected, resources are required to construct core dimension tables that subsequent iterations of the data warehouse will use. Once we achieve a common understanding of the current status and desired goals, we then help prioritize the projects. Using the quadrant in Figure 1, we ask business management to evaluate each project based on business value, impact, or importance to the organization. Meanwhile, IT representatives have assessed the feasibility of delivering the business process data. In short, for each row of the matrix, business drives the relative vertical placement, while IT drives the relative horizontal placement on the quadrant. This often highly interactive exercise concludes with projects in each of the four quadrants. Those in the upper-right, sweet spot quadrant in Figure 1 will be tackled individually as part of the initial phases of the data warehouse program. The metrics associated with the projects in the upper-left quadrant are highly important to the business, so IT resources not assigned to the data warehouse should address the feasibility concerns — most likely data issues, such as inadequate or nonexistent data collection systems. Projects in the lower right comfort zone don't warrant immediate attention because they're irrelevant to the business. Finally, those in the avoid zone should fall to the very bottom of the list. Achieve an Enterprise RoadmapWe've been involved in dozens of requirements projects that have culminated in this capstone event. Facilitating these sessions is extremely gratifying because the benefits to both the business and data warehouse project team are so significant. By the conclusion of the meeting, there's cross-organizational understanding of the present state of the data, a vision for the ultimate long-term enterprise plan, and an agreed-upon roadmap for addressing the gap that's been prioritized by both the business and IT. What more could you ask for? Now that we've explored our recommended activities and techniques for embarking on a dimensional data-warehousing program with iterative projects, you can see why the bottom-up label is a misnomer. We strongly encourage an enterprise orientation, not just from a data perspective but, more important, from a business point-of-view. Business management buy-in and consensus at this formative stage is critical to the long-term acceptance of the enterprise data warehouse environment. Margy Ross [margy@ralphkimball.com] is president of the Kimball Group and instructor with Kimball University. She cowrote The Data Warehouse Lifecycle Toolkit (Wiley, 1998) and The Data Warehouse Toolkit, 2nd Edition (Wiley, 2002). Ralph Kimball, founder of the Kimball Group, teaches dimensional data warehouse design through Kimball University and critically reviews large data warehouse projects. You can reach him through his Web site, www.ralphkimball.com. RESOURCESRelated Article at IntelligentEnterprise.com: "The Matrix," Dec. 7, 1999
|
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
| ||||||||||||||||||||||||||||||||
