Intelligent Enterprise

Data warehouse teams often postpone thinking about the ongoing operations of their new data warehouses and business intelligence systems until they're nearly in production. It's too late to start designing your operating procedures when deployment deadlines are looming and users are clamoring for data and reports. The train has already left the station. You'll be making stuff up as you go along, inevitably making mistakes.

Think about two sets of considerations with respect to the ongoing operations of your production DW/BI systems. The first set revolves around users: What information do they need to use the system successfully? And after the initial launch, how will the system improve and evolve to meet their needs? Second and equally important are the planning considerations for technical systems management: the procedures to ensure the system operates trouble-free—or at least crisis-free.

Front-Room Operations

When a new DW/BI system is deployed, business users focus on the front room: the interface they see and use every day. In fact, user communities sometimes refer to the data warehouse by the BI tool vendor's name or the "reporting portal." Little do they realize that building and deploying reports is only a fraction—typically less than 10 percent—of the effort required to create a data warehouse and BI system. But people focus on what they can see. If the reporting portal is ugly, uninformative or slow, the entire data warehouse system looks bad.

When launching the BI environment, you'll publish an initial set of reports, charts and analyses that meet the requirements identified through business user interviews at the beginning of your project (see the previous column," Alan Alda's Interviewing Tips for Uncovering Business Requirements,"May 2005). Let's assume these deliverables are meaningful, attractive, parameterized as appropriate and allow drill down where useful. You must train the business users on the system you've built: not just where to click, but also how the analyses should be used and why. Here are some typical user questions you must be prepared to answer:

• How do I access the BI system?
• How do I request broader system access?
• How do I find the report I need?
• When was the data in the system last refreshed?
• Will I be notified if there are any?
• Where can I get help?
• How do I customize a report?
• How do I build a completely new report?
• How do I add my report to the system so others in the organization can use it?
• How do I customize my dashboard portal view?
• How do I build a more complex analysis?

You might be able to build such an intuitive reporting environment that the answers to some of these questions are obvious, but you're fooling yourself if you think you can avoid documenting the system and providing rollout training.

You must establish (and maintain) a Web site with fresh information about how to use the system, data currency and where to get help. If your reporting tool has a Web-based launch page, think about customizing that page to add this important information. Otherwise, train users to go to your page first and link from there to the reports and/or tool page.

You must also develop plans for training after the system is in production. New hires will need training and a surprisingly large percentage of the initial users will benefit from more instruction. Perhaps you'll need to offer new types of training, for super-power users or very occasional users. Online instruction materials are useful, but there are significant benefits to getting business users in a room where you can talk to them—and they can talk to each other—face to face.

Your front-room rollout and operations plan should include a plan for the help desk. If your organization has a centralized IT help desk, use the same infrastructure for first-tier support. Even though connectivity is a lot simpler than it was a decade ago, the majority of user issues are still about how to connect. A centralized help desk can help on this front, but plan for a large percentage of questions to get escalated to specialists—probably someone on the data warehouse team.

Many query and reporting tools let business users customize their system views, often by creating "My Reports" folders on the portal. This functionality is great, but you should develop policies and procedures for personal reports warranting higher visibility. It often makes sense for central BI team members to put reports through quality assurance and tweak them before publishing to a broad audience. It's not only a matter of ensuring that new or revised reports are accurate; you must also ensure that they perform well and that modifications won't adversely affect existing users.