Providing User Support

The design and development of your DW/BI system has focused on building a system thats easy to use, intuitive, and performs well. Youve built BI applications, be they canned reports , a dashboard portal, a closed loop data mining application, or a combination of all. Youve trained the users on the data and applications. Whats left to do?

A lot. The business user community will grow and change. Some users will learn the new tools immediately. Others will require some hand-holding and retraining . Even if your system is perfect and the business users catch on immediately, youll need to bring new employees up-to-speed . On an ongoing basis, its not unusual to have the same number of people involved with supporting the business users as initially developed the system.

The user- facing part of the DW/BI team engages in the following activities:

BI portal maintenance and enhancement
BI application specification and development
BI Help Desk support and training, discussed in Chapter 14

Weve seen the user-facing side of the DW/BI team range in size from dozens of people for large companies with a centralized DW/BI system, to a single person. The smallest organizations often have a single-person shop, but its really hard for that person to handle the back-room maintenance while communicating effectively with the business users. Ongoing, its hard to see how you can get by with fewer than two people: one for the back room, and one for the front room.

Maintaining the BI Portal

Even the smallest DW/BI team should maintain an intranet site where users get information about the system. Weve talked about this portal already in Chapters 8 and 9, where we discussed how the portal should be organized to find reports; in Chapter 13 where we described the metadata that should be published on the portal; and in Chapter 14 where we talked about documentation and training materials.

Here we briefly present an additional set of information that should go on the portal, having to do with operations and maintenance:

System status: what is the most recent day of data in each business process dimensional model
Schedules of planned outages
Honest and complete status of any unplanned outages
Clear warnings to users about problems in the system, like data quality issues. Include an honest and complete assessment of when the problems will be fixed.
The systems current operational status, including:
- How many queries have been answered in the last hour
- How many reports generated
- Current number of active users
- On-demand report of active queries, how long theyve been running, and whos running them

Proof points about the systems capacity, to foster user confidence in the system:
- How long the last data load took
- How big the largest data load was, and how long it took
- Maximum count of simultaneous users

The DW/BI team must commit to open and complete disclosure to the user community about any problems.

Every 12 to 18 months, you should review the entire DW/BI system. Evaluate whats working well for the users, and what should change. Remember, change is inevitable, and is a sign of a healthy system. As part of this periodic evaluation, consider refreshing the look, layout, and content of the BI portal.

Extending the BI Applications

The initial reports and BI applications for a new business process dimensional model will soon be modified and augmented. Users dont always know what reports and analyses they want until you show them something fairly close. Then theyll tell you what they dont wantthe report you just createdand, lets hope, give you clearer information about what they now think they need.

The cycle repeats as business imperatives change.

Data mining applications, and other kinds of closed loop systems, are seldom implemented in the first phase of a DW/BI system. First, the basic data is brought online. Then, business users and DW/BI team members build ad hoc models and analyses. This analytic work usually has tremendous value to the business, for example by improving Marketings understanding of customers, or providing mechanisms for reducing costs. The next step, beyond improving understanding, is to systematize the knowledge gained from ad hoc analysis by building a closed loop system. In our experience, ad hoc analyses are usually valuable enough to provide a positive ROI on the DW/BI investment, and many implementations stop there. Those DW/BI teams that go on to build data mining applications and other kinds of closed loop systems usually reap greatly increased ROI.

The process of developing a closed loop BI system requires close partnership between the business people, who can effectively develop the business rules and analytic models, and the DW/BI team, who will write the system specifications and formalize the models. The majority of the application development effort requires a fairly standard development skill set, which is often met by the same developers who work on the operational systems. The developer needs a relatively small amount of specialized knowledgefor example of the Analysis Services object modelsin order to implement the calls into the databases or data mining model.