For example, a company's data might include the date a customer receives products and the date the customer needed those products, but the KPI of real interest is on-time delivery. How do you determine the on-time delivery percentage for each customer and for a region as a whole? Can you compare a particular customer's on-time delivery average with the average for all customers in his or her industry? Another example of a crucial KPI is customer retention. Your data might contain the dates of your organization's first and last contact with a customer, but users care about whether they've retained the customer. Make sure you give them what they really want.
In one real-world case, the president of a small insurance company complained that he couldn't get a specific 500-page report from the warehouse. After asking a few questions, I discovered that the president was flipping through the report and looking for customers who had significantly cut back on their insurance coverage, as reflected by a drop in premiums. What the president really needed was a metric of the percentage change in premiums from one time period to another. Unfortunately, the builders of that data warehouse had never asked what the data was for. They just cubed up the existing payment information the president requested—without first discovering what the president really needed—and moved on to the next project.
One of the best ways to identify the KPIs that will deliver the most value to the company is to determine what factors the organization uses to calculate bonuses for upper management. Often, a manager's bonus depends on the manager achieving goals that are important to the company's business. So, for example, if a manager's incentive pay is based on increasing sales and maintaining a specific level of customer retention, you'd better build cubes that make it simple for that manager to instantly identify and use those numbers.
Limited or Poor Access to Data
Related to the problem of delivering the right data is the problem of delivering the data to the right people. You can build a warehouse that contains all the necessary KPIs and is easy to use—but still fails miserably. There are various schools of thought on making data-warehousing information available. Many companies expect nothing more from a data warehouse than the ability to produce the same static reports that they create from relational databases. Although this approach is possible, it misses the point of building a warehouse and merely creates a very expensive data repository. To get the maximum benefit from a data warehouse, users typically want to be able to explore, mine, or otherwise analyze data and answer business questions. You need to use appropriate client tools to provide the appropriate level of analytical capabilities to various users, even when those users are geographically dispersed.
Enlist users to help you select a client tool to access the warehouse. Analysis Services has great tools for building and maintaining warehouses, but it has no real tools for client access. Microsoft does offer Microsoft Excel and Data Analyzer for this purpose and more recently has added a powerful new tool with the release of SQL Server 2000 Reporting Services. For most users, who simply need canned reports with basic drilldown capability, Reporting Services gives a good mix of static reports and some limited analytic functionality. You can expand certain items in a report, in effect drilling down to see more detail. And you can filter on certain items. So, for example, you can choose to see data for all products or just certain product lines.
Providing access to reports with some drilldown capability is sufficient for many users. However, as you move higher in the organization, people have less time to play around with data. Some client tools use a scorecard- or dashboard-style UI. A scorecard or dashboard is a screen that shows KPIs in an easy-to-grasp format. If you think about your car's dashboard, you know what this interface can look like. With one quick glance, you can see your speed, engine RPMs, oil temperature, and fuel level. Many client tools let you build a KPI scorecard. The point is to give users a quick visual overview of the most important KPIs. If any of the KPIs isn't measuring as expected, users can drill into the information and discover the cause of the problems.
The users who must delve into the data in greatest detail are analysts. A scorecard isn't meaningless for analysts because it provides a good overview of the data, but analysts typically spend most of their time immersed in more detailed data for complex analyses. To give analysts the details they need, you might consider a powerful, full-featured client application such as Business Objects Crystal Reports, Cognos PowerPlay, or ProClarity Analytics Platform. (For an overview of third-party SQL Server products, see Michael Otey's Windows & .NET Magazine article "Pump Up SQL Server 2000" at http://www.sqlmag.com, InstantDoc ID 42408. The article is free if you register on the site.) Make sure you involve your organization's analysts in the client-tool selection process, but don't rely solely on analysts to help you build a warehousing solution. If you do, you'll likely end up with a design that's too complex for the average user to navigate. Finally, remember that having real end users test the tools you select is crucial to the eventual acceptance and use of the warehouse.
Poor Data Quality
As I said earlier, one essential step to a successful data warehouse is to create a single version of the truth. Users must be able to rely on the validity of the data in the warehouse. If the data is suspect, the warehouse project is destined to fail because users will refuse to use it.
Companies have various strategies for validating data. In some companies, the strategy is to simply ignore dirty data and leave it in the warehouse. In other companies, there is a data "owner," often the business champion or someone in the champion's group, who is ultimately responsible for the data's accuracy. For example, if the CFO is the data owner, someone in the finance department validates all warehouse updates against the accounting system and gives a green light only if everything checks out. Storing several years of history in the warehouse also helps with user acceptance. When users can see that the historical data is in line with their expectations, they're more likely to have confidence that the current data is correct as well.
Don't think that you have to wait until the warehouse is complete before you verify the data. Look at all data coming from various source systems, identify data problems, and fix them at the source when possible. If you can't fix data problems at the source, try to fix those problems during the extraction, transformation, and loading (ETL) process. For example, data-collection screens that let users type a city name into a free-form text field will ultimately lead to errors, such as spelling the city of Ann Arbor as Ann Arbour, Anne Arbor, or AnnArbor. Standardizing such data-entry details makes the warehousing process easier and also provides better data throughout the organization. As you identify incorrect or incomplete data, you can work to fix it while you're designing and building the ETL process.
Inadequate Funding
Another essential factor in the success of data warehouses is proper budgeting for projects. Even with a quick-hit data-mart project, funding estimates tend to be low—often much too low. Initial budgets frequently leave out funding for unforeseen expenses. For example, data-cleanup efforts are notoriously tricky and difficult to predict. Often, organizations don't know about bad data until the data is extracted and ready to load into the warehouse.
When one hospital I worked with loaded its first cube, the pharmacists discovered entries that showed dispensed medications without the name of a prescribing physician. The hospital claimed that the source systems wouldn't allow the entry of a prescription without a prescribing physician. However, the pharmacists checked the data, and sure enough, a bug in the entry system was allowing a small group of users to enter prescription information without the physician's name. Solving this unforeseen problem cost the project time and money but ultimately led to solving other data-related problems.
Don't forget to budget for all parts of the project, including training, software licenses, and hardware. A data mart costs less than a full-blown data warehouse, but the first mart you create might cost more than subsequent marts because of the learning curve. Be sure that your first project is properly funded, or you might run out of money before the mart can deliver any business value.
Less Risky Business
Data-warehousing projects are typically risky propositions. Like any large IT project, their success or failure hinges on several interrelated factors. Data warehouses are rarely, if ever, fully successful when IT drives them alone, so get a business champion on board. You need to reach into the business to understand the KPIs and how to best deliver that information to the users. And remember that users need tools that are easy to use and support varying levels of analytic capabilities. Data warehouses need not fail if you work to avoid the most common mistakes, and your organization can begin to reap the benefits of being able to make informed decisions faster.
End of Article
Prev. page
1
2
[3]
next page -->
