Continue in 2 seconds

The Vital BI Maintenance Process

  • July 01 2004, 1:00am EDT

One key element for having a positive return on investment on BI solutions is the maintenance - making sure the solution is optimally used once it is implemented. However, maintenance for BI solutions differs sharply from the maintenance process for operational systems such as ERP systems.

Most larger organizations today are aware of business intelligence (BI) systems and how they can help improve business performance; and many such systems have been implemented. However, the success rate for BI solutions is not much more impressive than that of other IT systems. Success rates of BI implementations are affected by:

  • Underlying operational systems and their processes, which are not adapted for these kinds of applications. The data extractions for the BI systems become difficult because the mostly normalized database structure in operational systems is good for updating data, but not for exporting data to other systems.
  • Poor data quality (that can often go unnoticed in operational systems). This poor data quality surfaces and leads to unpleasant surprises with BI solutions. This, in turn, will often seriously delay the BI implementation and render it difficult.
  • Political aspects. When implementing systems that will democratize the flow of information, the political aspects in an organization may be formidable. Some managers may have problems handling such an increased flow of information, while other business units may get the same information and be able to act upon it.

These factors, when they exist, will usually show themselves at a relatively early stage during the BI implementation. What will not show itself early is the necessary maintenance charge (i.e., the resources needed to keep the system alive and constantly adapted to the business users' needs). This maintenance charge is often severely underestimated by the project team responsible for implementing the BI system.
Maintaining a successful BI system is not the same thing as maintaining an operational system. Operational systems, such as ERP solutions, often handle defined business processes that explain and help the business (e.g., how to handle orders or product shipments). As a consequence, the maintenance for operational systems is often centered around improving or modifying already known and implemented process-based business activities.

BI systems, on the other hand, are providing business users with reports and analyses. These business activities are rarely predefined processes. Instead, the business users are relatively free to conduct reporting and analyses as they wish.

Because BI processes are usually not implemented within a BI system, the maintenance process for BI systems tends to be more vague and difficult to define. It is difficult to try to determine how the business users will work with a BI system if they are given the freedom to do their own reports and analyses. Also, the business users, if they have had little experience with BI, often do not know exactly what they want from a BI solution without having worked with it beforehand. The attitude is often, "We know what we want when we see it." Therefore, successful BI solutions should be developed iteratively.

As a consequence, it is difficult to estimate the workload that the maintenance will represent. If the maintenance is insufficient, the business users may not obtain the information they need. The BI system will then be used less, yielding less return on the investment made.

BI Maintenance Characteristics

The difference in the structure between operational systems and BI systems and the resulting differences in maintenance are often not fully understood by the organization implementing a BI solution. As a result, insufficient resources are often allocated for BI maintenance. The main differences between the BI and the operational systems that, in turn, will affect the maintenance process are listed in Figure 1.

Figure 1: Differences Between BI and Operational Systems

The differences mentioned in Figure 1 will have important repercussions on the maintenance process. Even if BI systems seldom have predefined processes explaining how to do reports and analyses, the maintenance can and should be defined in a process. This process handles education, support and further development.

The user education will develop over time in a way that does not correspond to the education for the usage of operational systems. As there are rarely any fixed ways of working with BI within an organization, new needs will lead to new applications that will necessitate further education, all of which will evolve over time. The user education will have to constantly change in order to explain the new solutions. However, this evolution is normal in most business situations. Most will have difficulties defining a non-process based way of working, and understanding of BI needs will improve only after having worked directly with such solutions. If this user evolution is not taken into account when implementing the system, the BI system will become less and less useful over time as the user needs will evolve further and further away from the initial solution that does not evolve accordingly.

Furthermore, the support and development will be different for BI solutions. Because most BI users will learn to really take advantage of BI systems as they continue to work with them, support and development must be relatively easy. Therefore, the flexibility of the BI system and the responsible team is a must if it shall be able to respond in a timely manner to the ever new and changing user demands.

The Right BI Maintenance Approach

The project management for the initial implementation of a BI system should be fixed in well-defined processes just as it is for any other IT project (including operational systems). There are differences on how to manage BI projects compared to other IT projects, but in both cases, the projects should be run in a structured manner.

The operational system project management most often has a macro plan similar to that shown in Figure 2. Hopefully, there actually is a well-defined business case before launching the project (even though a great number of projects seem to start with only a vague business case). Also, the future maintenance and support is not part of the project, but is considered a future process for which a system maintenance team will be responsible. Compared to BI systems, the maintenance part can often be relatively small once the system is put in place.

Figure 2: The Average IT Project Macro Planning

For the BI system implementation, the overall project management process recommended would approximate that shown in Figure 3. As shown in Figure 3, the BI project evolves into a process that turns some of the usual project phases into a well-defined repetitive process. Also, in order to optimize the BI investment and assure that the system is actually used, it should be measured according to metrics such as usage, cost savings, time savings and overall ROI. Based on this together with the business users' demands, the system is further modified in order to improve the measured results, measured again, further developed, etc. This project/process model takes into consideration that the user needs change over time and that their way of working or wanting to work with BI is often difficult to predict. The BI maintenance process aims at always optimizing the BI solution so that it will correspond to business needs and give a positive ROI.

Figure 3: The BI Project/Process Macro Planning

A typical example of business user involvement when implementing an operational system is found when a user is asked to sign and approve specific processes or reports from the system before implementation. This way of working is most often not adapted for implementing BI systems. For BI systems, it is more important that the business user approves the underlying data that will be used in the reports and analyses than the look of the resulting reports or analyses. In short, the business users' responsibility is more formal for operational systems, whereas the IT department is under more pressure to show flexibility when implementing BI systems. In a more practical sense, this also means that the business users' demands may often lead to changes in the database structure for the underlying data warehouse or data mart. The result may be completely new BI applications that may have little in common with any earlier applications.

One way to prepare the BI system team members for the future maintenance is to have a staged delivery approach when first implementing the system. This means that the phases between initiation and delivery will go relatively rapidly, delivering ongoing smaller solutions rather than one "complete" solution later on. Each solution is most likely to be further modified and improved once the business users start working with it. What this actually means is that IT and the business take into account before the implementation that BI solutions, like any other IT solutions, are rarely delivered the first time exactly as the business users want them. There are usually some misunderstandings in the communication between the different project members, notably between the business side and the IT side. Also, bugs in the functionality are common. It is only when the business users start working with the BI solution that they will fully realize how to take advantage of the new reporting and analysis possibilities. It should, therefore, be expected that each delivered solution will be further developed and improved.

The staged delivery approach will put less pressure on the business users when it comes to defining their needs, something that usually fits them well. Also, the staged delivery approach is in line with the BI maintenance process, as the IT team quickly understands how to do the maintenance (i.e., working in iterations). The team quickly realizes that maintenance is an important resource-intensive ongoing activity, which is nevertheless necessary in order to deliver optimal solutions. The drawback of this approach is that it puts higher demands on the project manager, as he or she must have a good knowledge of BI solutions. It also means that the IT team shall have to be flexible and implement a flexible BI architecture, rather unlike the architecture for most operational systems.

The IT organization may argue that more flexibility from their side means less stable systems. Every new software installation can potentially pose a problem for another program. Each new development might risk causing problems with other already existing functions and features when being tested. For an ad hoc query engine, new demands on network, database access and database performance may be necessary. All these aspects should be taken seriously, but it will become dangerous in the long term if the quest for stable systems will hinder further development of strategic solutions, which is what BI systems most often are.

In any case, there are few if any IT projects where there is no need for modifications. This should be taken into account from the start. For a BI application where the users can often "choose" to use it, modifications should be considered normal and healthy. They show that the users are actually taking advantage of the solution. That the first version of a BI system would correspond exactly to the business users' needs is unheard of. If there are no user demands, it most likely means that they are not using the system - not that the solution is perfect. Inadequate maintenance means that the users will be limited in their analyses and reporting, thereby limiting the positive results when measuring the solution.

Most literature on IT project management does not cover the follow-up once the system has been launched. In real life, all too many project members are only too happy to leave after the launch because they are simply too exhausted to want to go on. However, most BI systems will reach their optimal value only after further modifications and adaptations (together with corrections of problems that have gone undetected), some time after the system has gone live. This is where the real added value is developed. The real success of a BI system is likely to show itself only after the maintenance process is working correctly. This also means that what is often referred to as BI support is actually development rather than support in the classical operational systems sense.

Today, operational systems are most often aimed at supporting business processes that define how the business is run and also how the business users are to conduct their business. This means that the definition of these processes is a major part of implementing operational systems such as enterprise resource planning (ERP) systems. On the other hand, most BI activities have no defined processes for analyses or reports, as it is difficult to predefine how the business users will work with such activities. In many cases, predefinition is not even desirable, as it may limit the business users from using their imagination when working. Even though BI processes is an area that is presently evolving, it is still rare to find process-based BI solutions.

Because most BI systems are not process-based, they should be flexible in order to adapt themselves to the different and ever-changing business needs. BI systems cannot be forced upon users as can operational systems, because business users can often get by without BI in the short term. If the initial BI implementation has gone well, the quality of the ongoing maintenance will be the difference between a successful BI system that convinces the business users to continue using the BI solution - and thereby assures long-term ROI - and an unsuccessful one. There are no shortcuts to obtaining this success; and if there is no such thing as a free lunch, there are no free BI successes either. However, process-based BI maintenance that replaces some of the "classical" project-based BI approaches will help to create the success.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access