Before the Project Sponsor becomes comfortable with the data warehousing effort, quite a number of his or her questions and concerns will have to be addressed. This chapter attempts to provide answers to questions frequently asked by Project Sponsors.
It is naïve to expect an immediate change to the decision-making processes in an organization when a data warehouse first goes into production. End users will initially be occupied more with learning how to use the data warehouse than with changing the way they obtain information and make decisions. It is also likely that the first set of predefined reports and queries supported by the data warehouse will differ little from existing reports.
Decision-makers will experience varying levels of initial difficulty with the use of the data warehouse; proper usage assumes a level of desktop computing skills, data knowledge, and business knowledge.
Desktop computing skills. Not all business users are familiar and comfortable with the desktop computers, and it is unrealistic to expect all the business users in an organization to make direct, personal use of the front-end warehouse tools. On the other hand, there are power users within the organization who enjoy using computers, love spreadsheets, and will quickly push the tools to the limit with their queries and reporting requirements.
Data knowledge. It is critical that business users be familiar with the contents of the data warehouse before they make use of it. In many cases, this requirement entails extensive communication on two levels. First, the scope of the warehouse must be clearly communicated to properly manage user expectations about the type of information they can retrieve, particularly in the earlier rollouts of the warehouse. Second, business users who will have direct access to the data warehouse must be trained on the use of the selected front-end tools and on the meaning of the warehouse contents.
Business knowledge. Warehouse users must have a good understanding of the nature of their business and of the types of business issues that they need to address. The answers that the warehouse will provide are only as good as the questions that are directed to it.
As end users gain confidence both in their own skills and in the veracity of the warehouse contents, data warehouse usage and overall support of the warehousing initiative will increase. Users will begin to "outgrow" the canned reports and will move to a more ad hoc, analytical style when using the data warehouse.
As the data scope of the warehouse increases and additional standard reports are produced from the warehouse data, decision-makers will start feeling overwhelmed by the number of standard reports that they receive. Decision-makers will gradually want to lessen their dependence on the regular reports and instead will want to start relying on exception reporting or highlighting, and alert systems.
Exception reporting or highlighting. Instead of scanning regular reports one line item at a time, decision-makers will want to receive exception reports that enumerate only the items that meet their definition of "exceptions." For example, instead of receiving sales reports per region for all regions within the company, a sales executive may instead prefer to receive sales reports for areas where actual sales figures are either 10 percent more or less than the budgeted figures.
Alert systems. Alert systems also follow the same principle, that of highlighting or bringing to the fore areas or items that require managerial attention and action. However, instead of reports, decision-makers will receive notification of exceptions through other means, for example, an e-mail message.
As the warehouse gains acceptance, decision-making styles will evolve from the current practice of waiting for regular reports from IT or MIS to using the data warehouse to understand the current status of operations and, further, to using the data warehouse as the basis for strategic decision-making. At the most sophisticated level of usage, a data warehouse will allow senior management to understand and drive the business changes needed by the enterprise.
A successful enterprise-wide data warehouse effort will improve financial, marketing and operational processes through the simple availability of integrated data views. Previously unavailable perspectives of the enterprise will increase understanding of cross-functional operations. The integration of enterprise data results in standardized terms across organizational units (e.g., a uniform definition of customer and profit). A common set of metrics for measuring performance will emerge from the data warehousing effort. Communication among these different groups will also improve.
Consolidated financial reports, profitability analysis, and risk monitoring improve the financial processes of an enterprise, particularly in financial service institutions, such as banks. The very process of consolidation requires the use of a common vocabulary and increased understanding of operations across different groups in the organization.
While financial processes will improve because of the newly available information, it is important to note that the warehouse can provide information based only on available data. For example, one of the most popular banking applications for data warehousing is profitability analysis. Unfortunately, enterprises may encounter a rude shock when it becomes apparent that revenues and costs are not tracked at the same level of detail within the organization. Banks frequently track their expenses at the level of branches or organization units but wish to compute profitability on a per customer basis. With profit figures at the customer level and costs at the branch level, there is no direct way to compute profit. As a result, enterprises may resort to formulas that allow them to compute or derive cost and revenue figures at the same level for comparison purposes.
Data warehousing supports marketing organizations by providing a comprehensive view of each customer and his many relationships with the enterprise. Over the years, marketing efforts have shifted in focus. Customers are no longer viewed as individual accounts but instead are viewed as individuals with multiple accounts. This change in perspective provides the enterprise with cross-selling opportunities.
The notion of customers as individuals also makes possible the segmentation and profiling of customers to improve target-marketing efforts. The availability of historical data makes it possible to identify trends in customer behavior, hopefully with positive results in revenue.
By providing enterprise management with decisional information, data warehouses have the potential of greatly affecting the operations of an enterprise by highlighting both problems and opportunities that heretofore went undetected.
Strategic or tactical decisions based on warehouse data will naturally affect the operations of the enterprise. It is in this area that the greatest return on investment and, therefore, greatest improvement can be found.
As we mentioned in Chapter 2, return on investment (ROI) from data warehousing projects varies from organization to organization and is quite difficult to quantify prior to a warehousing initiative.
However, we can identify a common list of problems encountered by enterprises as a result of unintegrated customer data and lack of historical data. A properly deployed data warehouse can solve the problems, as discussed below.
Divisions or departments have the same customers but do not share information with each other.
As a result, cross-selling opportunities are missed, and improved customer understanding is lost. Customers are annoyed by requests for the same information by different units within the same enterprise.
Solving this problem results in the following benefits: better customer management decisions can be made; customers are treated as individuals; new business opportunities can be explored.
Data in different operational systems provide different information on the same subject. The inconsistent use of terms results in different business rules for the same item.
Thus, facts and figures are inconsistently interpreted, and different versions of the "truth" exist within the enterprise. Decision-makers have to rely on conflicting data and may lose credibility with customers, suppliers, or partners.
Solving this problem results in the following benefits: a consistent view of enterprise operations becomes available; better, informed decisions can be made.
Critical reports take too long to produce. Data gathering is ad hoc, inconsistent, and manually performed. There are no formal rules to govern the creation of these reports.
As a result, business decisions based on these reports may be bad decisions. Business analysts within the organization spend more time collecting data instead of analyzing data. Competitors with more sophisticated means of producing similar reports have a considerable advantage.
Solving this problem results in the following benefits: the report creation process is dramatically streamlined, and the time required to produce the same reports is significantly reduced. More time can be spent on analyzing the data, and decision-makers do not have to work with "old" data.
Managerial reports are not dynamic and often do not support the ability to drill down for further detail.
As a result, when a report highlights interesting or alarming figures, the decision-maker is unable to zoom in and get more detail.
When this problem is solved, decision-makers can obtain more detail as needed. Analysis for trends and causal relationships are possible.
Customer, product, and financial histories are not stored in operational systems. Conversely, attempts to store historical data in operational systems result in unwieldy data structures.
As a result, decision-makers are unable to analyze trends over time. The enterprise is unable to anticipate events and behave proactively or aggressively. Customer demands come as a surprise, and the enterprise must scramble to react.
Decision-makers can increase or strengthen relationships with current customers. Marketing campaigns can be predictive in nature, based on historical data.
Aside from solving the problems above, other reasons commonly used to justify a data warehouse initiative are the following:
Support of enterprise strategy. The data warehouse is a key supporting factor in the successful execution of one or more parts of the enterprise's strategy, including enhanced revenue or cost control initiatives.
Enterprise emphasis on customer and product profitability. Increase the focus and efficiency of the enterprise by gaining a better understanding of its customers and products.
Perceived need outside the IT group. Data warehousing is sought and supported by business users who demand integrated data for decision-making. A true business need, not technological experimentation, drives the initiative.
Integrated data. The enterprise lacks a repository of integrated and historical data that are required for decision-making.
Cost of current efforts. The current cost of producing standard, regular managerial reports is typically hidden within an organization. A study of these costs can yield unexpected results that help justify the data warehouse initiative.
The competition is doing it. Just because competitors are going into data warehousing does not mean an enterprise should plunge headlong into it. However, knowing that the competition is applying data warehousing technology should make any manager stop and see whether data warehousing is something that his own organization needs.
The costs associated with developing and implementing a data warehouse typically fall into the categories described below.
Warehousing hardware can easily account for up to 50 percent of the costs in a data warehouse pilot project. A separate machine or server is often recommended for data warehousing so as not to burden operational IT environments. The operational and decisional environments may be connected via the enterprise's network, especially if automated tools have been scheduled to extract data from operational systems or if replication technology is used to create copies of operational data.
Enterprises heavily dependent on mainframes for their operational systems can look to powerful client/server platforms for their data warehouse solutions.
Hardware costs are generally higher at the start of the data warehousing initiative due to the purchase of new hardware. However, data warehouses grow quickly, and subsequent extensions to the warehouse may quickly require hardware upgrades.
A good way to cut down on the early hardware costs is to invest in server technology that is highly scalable. As the warehouse grows both in volume and in scope, subsequent investments in hardware can be made as needed.
Software refers to all the tools required to create, set up, configure, populate, manage, use, and maintain the data warehouse. The data warehousing tools currently available from a variety of vendors are staggering in their features and price range (Chapter 11 provides an overview of these tools).
Each enterprise will be best served by a combination of tools, the choice of which is determined or influenced not only by the features of the software but also by the current computing environment of the operational systems, as well as the intended computing environment of the warehouse.
Software costs can easily account for a quarter to a third of the overall data warehousing cost in a pilot project.
Services from consultants or system integrators are often required to manage and integrate the disparate components of the data warehouse. The use of system integrators, in particular, is appealing to enterprises that prefer to use the "best of breed" of hardware and software products and have no wish to assume the responsibility for integrating the various components.
The use of consultants is also popular, particularly with early warehousing implementations, when the enterprise is just learning about data warehousing technologies and techniques.
Service-related costs can account for roughly 30 percent to 35 percent of the overall cost of a pilot project but may drop as the enterprise decreases its dependence on external resources.
Internal staff costs refer to costs incurred as a result of assigning enterprise staff to the warehousing project. The staff could otherwise have been assigned to other activities.
The heaviest demands are on the time of the IT staff who have the task of planning, designing, building, populating, and managing the warehouse. The participation of end users, typically analysts and managers, is also crucial to a successful warehousing effort.
The Project Sponsor, the CIO, and the Project Manager will also be heavily involved because of the nature of their roles in the warehousing initiative.
The external costs of a typical data warehouse pilot project of three to six months can range anywhere from US$0.8M to US$2M, depending on the combination of hardware, software, and services required.
Table 3-1 provides an indicative breakdown of the external costs of a warehousing pilot project where new hardware is purchased.
Table 3-1. Typical External Cost Breakdown for a Data Warehouse Pilot (Amounts expressed in US$)
| Item | Min | Min.as % of Total | Max | Max.as % of Total |
|---|---|---|---|---|
| Hardware | 400,000 | 49.26 | 1,000,000 | 51.81 |
| Software | 132,000 | 16.26 | 330,000 | 17.10 |
| Services | 280,000 | 34.48 | 600,000 | 31.09 |
| Totals | 812,000 | 1,930,000 |
Note that the costs listed above do not yet consider any infrastructure improvements or upgrades (e.g., network cabling or upgrades) that may be required to properly integrate the warehousing environment into the rest of the enterprise IT architecture.
The typical risks encountered on data warehousing projects fall into the following categories:
Organizational. These risks relate either to the project team structure and composition or to the culture of the enterprise.
Technological. These risks relate to the planning, selection, and use of warehousing technologies. Technological risks also arise from the existing computing environment, as well as the manner by which warehousing technologies are integrated into the existing enterprise IT architecture.
Project management. These risks are true of most technology projects but are particularly dangerous in data warehousing because of the scale and scope of warehousing projects.
Data warehouse design. Data warehousing requires a new set of design techniques that differ significantly from the well-accepted practices in OLTP system development.
The project sponsor must be a business executive, not an IT executive. Considering its scope and scale, the warehousing initiative should be business driven; otherwise, the organization will view the entire effort as a technology experiment.
A strong Project Sponsor is required to address and resolve organizational issues before these have a chance to derail the project (e.g., lack of user participation, disagreements regarding definition of data, political disputes). The Project Sponsor must be someone who will be a user of the warehouse, someone who can publicly assume responsibility for the warehousing initiative, and someone with sufficient clout.
This role cannot be delegated to a committee. Unfortunately, many an organization will choose to establish a data warehouse steering committee to take on the collective responsibility of this role. If such a committee is established, the head of the committee may by default become the Project Sponsor.
The end-user community provides the data warehouse implementation team with the detailed business requirements. Unlike OLTP business requirements, which tend to be exact and transaction based, data warehousing requirements are moving targets and are subject to constant change.
Despite this, the intended warehouse end users should be interviewed to provide an understanding of the types of queries and reports (query profiles) they require. By talking to the different users, the warehousing team also gains a better understanding of the IT literacy of the users (user profiles) they will be serving and will better understand the types of data access and retrieval tools that each user will be more likely to use. The end-user community also provides the team with the security requirements (access profiles) of the warehouse.
These business requirements are critical inputs to the design of the data warehouse.
Because of the costs, data warehousing almost always requires a go-signal from senior management, often obtained after a long, protracted ROI presentation.
In their bid to obtain senior management support, warehousing supporters must be careful not to overstate the benefits of the data warehouse, particularly during requests for budgets and business case presentations. Raising senior management expectations beyond manageable levels is one sure way to court extremely embarrassing and highly visible disasters.
Aside from managing senior management expectations, the warehousing team must, in the same manner, manage the expectations of their end users.
Warehouse analysts must bear in mind that the expectations of end users are immediately raised when their requirements are first discussed. The warehousing team must constantly manage these expectations by emphasizing the phased nature of data warehouse implementation projects and by clearly identifying the intended scope of each data warehouse rollout.
End users should also be reminded that the reports they will get from the warehouse are heavily dependent on the availability and quality of the data in the enterprise's operational systems.
Attempts to produce integrated views of enterprise data are likely to raise political issues. For example, different units have been known to wrestle for "ownership" of the warehouse, especially in organizations where access to information is associated with political power. In other enterprises, the various units want to have as little to do with warehousing as possible, for fear of having warehousing costs allocated to their units.
Understandably, the unique combination of culture and politics within each enterprise will exert its own positive and negative influences on the warehousing effort.
A number of tasks in data warehousing require coordination with multiple parties, not only within the enterprise, but with external suppliers and service providers as well. A number of factors increase the logistical overhead in data warehousing, among them:
Formality. Highly formal organizations generally have higher logistical overhead because of the need to comply with pre-established methods for getting things done.
Organizational hierarchies. Elaborate chains of command likewise may cause delays or may require greater coordination efforts to achieve a given result.
Geographical dispersion. Logistical delays also arise from geographical distribution, as in the case of multibranch banks, nationwide operations or international corporations. Multiple, stand-alone applications with no centralized data store have the same effect. Moving data from one location to another without the benefit of a network or a transparent connection is difficult and will add to logistical overhead.
Inappropriate Use of Warehousing Technology. A data warehouse is an inappropriate solution for enterprises that need operational integration on a real-time, online basis. An ODS is the ideal solution to needs of that nature.
Multiple unrelated data marts are likewise not the appropriate architecture for meeting enterprise decisional information needs. All data warehouse and data mart projects should remain under a single architectural framework.
Poor Data Quality of Operational Systems. When the data quality of the operational systems is suspect, the team will, by necessity, devote much of their time and effort to data scrubbing and data quality checking. Poor data quality also adds to the difficulties of extracting, transforming, and loading data into the warehouse.
The importance of data quality cannot be overstated. Warehouse end users will not make use of the warehouse if the information they retrieve is wrong or of dubious quality. The perception of lack of data quality, whether such a perception is true or not, is all that is required to derail a data warehousing initiative.
Inappropriate End-User Tools. . The wide range of end-user tools provides data warehouse users with different levels of functionality and requires different levels of IT sophistication from the user community.
Providing senior management users with the inappropriate tools is one of the quickest ways to kill enthusiasm for the data warehouse effort. Likewise, power users will quickly become disenchanted with simple data access and retrieval tools.
Overdependence on Tools to Solve Data Warehousing Problems. The data warehouse solution should not be built around tools or sets of tools. Most of the warehousing tools (e.g., extraction, transformation, migration, data quality, and metadata tools) are far from mature at this point.
Unfortunately, enterprises are frequently on the receiving end of sales pitches that promise to solve all the various problems (data quality/ extraction/replication/loading) that plague warehousing efforts through the selection of the right tool or, even, hardware platform.
What enterprises soon realize in their first warehousing project is that much of the effort in a warehousing project still cannot be automated.
Manual Data Capture and Conversion Requirements. The extraction process is highly dependent on the extent to which data are available in the appropriate electronic format. In cases where the required data simply do not exist in any of the operational systems, a warehousing team may find itself resorting to the strongly discouraged practice of using data capture screens to obtain data through manual encoding operations. Unfortunately, a data warehouse quite simply cannot be filled up through manual data encoding!
Conversion transforms electronically stored data to the appropriate format or granularity. Underestimating the requirements to obtain and transform data into the correct format may lead to slipped schedules and unmanaged expectations regarding the data that will be available in the warehouse.
The mantra for data warehousing should be: start small and build incrementally. Organizations that prefer the big-bang approach quickly find themselves on the path to certain failure. Monolithic projects are unwieldy and difficult to manage, especially when the warehousing team is new to the technology and techniques.
In contrast, the phased, iterative approach has consistently proven itself to be effective, not only in data warehousing but also in most information technology initiatives. Each phase has a manageable scope, requires a smaller team, and lends itself well to a coaching and learning environment. The lessons learned by the team on each phase are a form of direct feedback into subsequent phases.
Estimates in data warehousing projects often fail to devote sufficient time to the extraction, integration, and transformation tasks. Unfortunately, it is not unusual for this area of the project to consume anywhere between 60 percent to 80 percent of a team's time and effort. Figure 3-1 illustrates the distribution of efforts.
The project team should therefore work on stabilizing the back-end of the warehouse as quickly as possible. The front-end tools are useless if the warehouse itself is not yet ready for use.
Time estimates in data warehousing projects often fail to consider delays due to logistics. Keep an eye on the lead time for hardware delivery, especially if the machine is yet to be imported into the city or country. Quickly determine the acquisition time for middleware or warehousing tools. Watch out for logistical overhead (as discussed on page 62-63).
Allocate sufficient time for team orientation and training prior to and during the course of the project to ensure that everyone remains aligned. Devote sufficient time and effort to creating and promoting effective communication within the team.
The data warehousing effort should be focused entirely on delivering the essential minimal characteristics (EMCs) of each phase of the implementation. It is easy for the team to be distracted by requests for nonessential or low-priority features (i.e., nice-to-have data or functionality). These should be ruthlessly deferred to a later phase; otherwise, valuable project time and effort will be frittered away on nonessential features, to the detriment of the warehouse scope or schedule.
A data warehouse needs to be strongly supported and nurtured (also known as "care and feeding") for at least a year after its initial launch. End users will need continuous training and support, especially if new users are gradually granted access to the warehouse. Collect warehouse usage and query statistics to get an idea of warehouse acceptance and to obtain inputs for database optimization and tuning. Plan subsequent phases or rollouts of the warehouse, taking into account the lessons learned from the first rollout. Allocate, acquire, or train the appropriate resources for support activities.
Using OLTP Database Design Strategies for the Data Warehouse. Enterprises that venture into data warehousing for the first time may make the mistake of applying OLTP database design techniques to their data warehouse. Unfortunately, data warehousing requires design strategies that are very different from the design strategies for transactional, operation systems.
For example, OLTP databases are fully normalized and are designed to consistently store operational data, one transaction at a time. In direct contrast, a data warehouse requires database designs that even business users find directly usable. Dimensional or star schemas with highly denormalized dimension tables on relational technology require different design techniques and different indexing strategies. Data warehousing may also require the use of hypercubes or multidimensional database technology for certain functions and users.
Choosing the Wrong Level of Granularity. The warehouse contains both atomic (extremely detailed) and summarized (high-level) data. To get the most value out of the system, the most detailed data required by users should be loaded into the data warehouse. The degree to which users can slice and dice through the data warehouse is entirely dependent on the granularity of the facts. Too high a grain makes detailed reports or queries impossible to produce. Too low a grain unnecessarily increases the space requirements (and the cost) of the data warehouse.
Not Defining Strategies to Key Database Design Issues. The suitability of the warehouse design significantly impacts the size, performance, integrity, future scalability, and adaptability of the warehouse. Outline (or high-level) warehouse designs may overlook the demands of slowly changing dimensions, large dimensions, and key generation requirements, among others.
The above risks are best addressed through the people and mechanisms described below.
The Right Project Sponsor and Project Manager. Having the appropriate leaders setting the tone, scope, and direction of a data warehousing initiative can spell the difference between failure and success.
Appropriate architecture. The enterprise must verify that a data warehouse is the appropriate solution to its needs. If the need is for operational integration, then an Operational Data Store is more appropriate.
Phased approach. The entire data warehousing effort must be phased so that the warehouse can be iteratively extended in a cost-justified and prioritized manner. A number of prioritized areas should be delivered first; subsequent areas are implemented in incremental steps. Work on nonurgent components is deferred.
Cyclical refinement. Obtain feedback from users as each rollout or phase is completed, and as users make use of the data warehouse and the front-end tools. Any feedback should serve as inputs to subsequent rollouts. With each new rollout, users are expected to specify additional requirements and gain a better understanding of the types of queries that are now available to them.
Evolutionary life cycle. Each phase of the project should be conducted in a manner that promotes evolution, adaptability, and scalability. An overall data warehouse architecture should be defined when a high-level understanding of user needs has been obtained and the phased implementation path has been studied.
Completeness of data warehouse design. The data warehouse design must address slowly changing dimensions, aggregation, key generalization, heterogeneous facts and dimensions, and minidimensions. These dimensional modeling concerns are addressed in Chapter 12.
Although there are no hard-and-fast rules for determining when your organization is ready to launch a data warehouse initiative, the following positive signs are good clues.
A successful data warehouse implementation will have a significant impact on the enterprise's decision-making processes, which in turn will have significant impact on the operations of the enterprise. The performance measures and reward mechanisms are likely to change, and they bring about corresponding changes to the processes and the culture of the organization.
Individuals who have an interest in preserving the status quo are likely to resist the data warehousing initiative, once it becomes apparent that such technologies enable organizational change.
A data warehouse is likely to get strong support from both the IT and user community if there is a strong and unsatisfied demand for integrated decisional data (as opposed to integrated operational data). It will be foolish to try using data warehousing technologies to meet operational information needs.
IT professionals will benefit from a long-term, architected solution to users' information needs, and users will benefit from having information at their fingertips.
An IT department, division, or unit that continuously fights fires on unstable operational systems will quickly deprioritize the data warehousing effort. Organizations will almost always defer the warehousing effort in favor of operational concerns—after all, the enterprise has survived without a data warehouse for years; another few months will not hurt.
When the operational systems are up in production and are fairly stable, there are internal data sources for the warehouse and a data warehouse initiative will be given higher priority.
Although significant portions of the data warehouse effort can be outsourced to external parties, there are key roles that must be fulfilled by the enterprise's internal staff. The demands on the time of end users and IT staff for a data warehouse project are as heavy as (or perhaps are heavier than) the demands of an operational system development project.
Once the data warehouse is up, sufficient resources are also required to support its users and its continued evolution.
Data warehousing results come in different forms and can, therefore, be measured in one or more of the following ways.
New Reports/Queries Support. Results are seen clearly in the new reports and queries that are now readily available but would have been difficult to obtain without the data warehouse.
The extent to which these reports and queries actually contribute to more informed decisions and the translation of these informed decisions to bottom-line benefits may not be as easy to trace, however.
Turnaround Time. Results are also evident in the less time it now takes to obtain information on the subjects covered by the warehouse. Senior managers can also get the information they need directly, thus improving the security and confidentiality of such information.
Turnaround time for decision-making is dramatically reduced. In the past, decision-makers in meetings either had to make an uninformed decision or table a discussion item because they lacked information. The ability of the data warehouse to quickly provide needed information speeds up the decision-making process.
Timely Alerts and Exception Reporting. The data warehouse proves its worth each time it sounds an alert or highlights an exception in enterprise operations. Early detection makes it possible to avert or correct potentially major problems and allows decision-makers to exploit business situations with small or immediate windows of opportunity.
Number of Active Users. The number of active users provides a concrete measure for the usage and acceptance of the warehouse.
Frequency of Use. The number of times a user actually logs on to the data warehouse within a given time period (e.g., weekly) shows how often the warehouse is used by any given users. Frequent usage is a strong indication of warehouse acceptance and usability. An increase in usage indicates that users are asking questions more frequently. Tracking the time of day when the data warehouse is frequently used will also indicate peak usage hours.
Session Times. The length of time a user spends each time he logs on to the data warehouse shows how much the data warehouse contributes to his job.
Query Profiles. The number and types of queries users make provide an idea of how sophisticated the users have become. As the queries become more sophisticated, users will most likely request additional functionality or increased data scope.
This metric also provides the warehouse database administrator (DBA) with valuable insight as to the types of stored aggregates or summaries that can further optimize query performance. It also indicates which tables in the warehouse are frequently accessed. Conversely, it also allows the warehouse DBA to identify tables that are hardly used and therefore are candidates for purging.
Change Requests. An analysis of users' change requests can provide insight into how well users are applying the data warehouse technology. Unlike most IT projects, a high number of data warehouse change requests is a good sign; it implies that users are discovering more and more how warehousing can contribute to their jobs.
Business Changes. The immediate results of data warehousing are fairly easy to quantify. However, true warehousing ROI comes from business changes and decisions that have been made possible by information obtained from the warehouse. These, unfortunately, are not as easy to quantify and measure.
The importance of the Project Sponsor in a data warehousing initiative cannot be overstated. The project sponsor is the highest-level business representative of the warehousing team and therefore must be a visionary, respected, and decisive leader.
At the end of the day, the Project Sponsor is responsible for the success of the data warehousing initiative within the enterprise.