Over the last decade, SAP has offered a packaged enterprise data warehouse (BW) and BI solutions for your ERP system. Today, many customers are looking at ways to implement these and newer tools. Unfortunately, frequently the customer's approach to packaged analytical products has been driven by a mix of deep skepticism and cautionary optimism. This article looks at what drives the SAP BI implementation approaches and how to avoid some of the most common mistakes. -By Dr. Berg
A Very Short History of "Packaged" BI
Today most ERP vendors provide at least a packaged data warehouse product and the largest vendors provide more advanced integrated Analytics (i.e. BPC, IP, EI, etc.) as well. At the time when these products came to market, many of the early ERP adapters had already developed their own reporting tools and the vendor's packed products were frequently met with hostility from IT organizations that were defending their custom developed reporting tools.
The business owners had a more mixed view of the situation. First, there were significant costs of ownership associated with the custom BI systems. Secondly, when the ERP transaction systems were upgraded, the BI systems needed substantial and costly changes as well. In addition, the custom reporting systems were inflexible to changes, and often had a high degree of latency between when the transaction occurred in the ERP system and when it was available for reporting.
As a result, the business owners looked to SAP and complained over the lack of reporting features in their products. SAP naturally began to point to their new packages solutions a
nd the first wave of adaptation started in earnest about 8-10 years ago. Now that the packaged BI tools have reached a larger audience, the focused is on how to implement them.
Caught in the middle of inflated business expectation and some hostility from IT departments, the approaches to the BI products have varied greatly:
Figure 1: Customer Approaches to Packaged DSS
Every project will make some modification to the vendor delivered standard content, but the innovators treat the delivered content only as a "reference" (to be improved on). Innovators have a low degree of risk aversions and have the perception that they are not constrained by resources (this may not be the reality). As a result, innovators approach the packaged management tools with a "fearless urge" to improve on the delivered solution. An organization of innovators is a fun place to work if you are in IT. However, for business people it can be quite frustrating
As a species, innovators are often found in specialized data warehouse groups, as well as in organization that are relying too much on external consultants who are trying to please everyone. The Innovators often create a system that is so customized that only a handful of people can support it, and is so fragile that an army of developers have to "baby sit" it to make sure everything works. The best way to avoid this is to include a few experienced people on the project that can inject some reality to the cost of ownership of customizing the standard solution.
From an app
roach standpoint the innovators can only be managed if they required to justify each change to the delivered content in a formal change control process.
Perfectors are an interesting group. Unlike the innovators, they are highly risk adverse. However, the perfectors share the innovators perception of few resource constraints. As a result, they are engaged in an almost endless testing of the packaged tool. System and integration tests will often have two and three cycles each, and findings are documented in detail. Separate test groups are actually quite common in the realm of the perfectors.
This is not a bad approach to the implementation, had it not been for the follow-up complaints that the implementation "took forever," "was costly" and "took a lot of resources." The perfectors' approach is also good when the risks to the implementation have to be minimized (i.e., large number of users). However, a perfector approach can also prevent the tool from being fully utilized, as management gets tired of paying for endless expensive projects.
Explorers are the software vendor's worst nightmare. They have little resources and have low risk aversions. As a result, the explorers engage in endless prototypes, proof of concepts and strategies, but seldom actually implement the tool. They are also frequent visitors at tradeshows, training classes and user community groups where they explore what could be done if they only had the resources to do it. It worth noting that the Explorer approach frequently ends up costing more money than any other alternative.
However, the Explorer approach can be valuable if a few individuals are given a short timeframe to evaluate the product. The approach can be particularly appropriate when the project size is very large, or when the impact of failure is very adverse (i.e. reports accessed by external customers). But, unless there are cle
ar scope agreements on the duration and resources to be used, the Explorer's are frequently engaged in an exercise of "analysis-paralysis" that can be very costly to the enterprise.
The "copiers" are a customer who wants a solution and not a project. They adopt the new packaged management tools as-is (copies it) and does not intend to spend a high degree of resources on the implementation. The copiers are also risk adverse and unlikely to be among the early adapters of the packaged DSS products.
Copiers are often found in companies with relative small IT departments with limited resources. The copy approach is normally conducted by a few individuals with limited directions from others (if too many people is involved, the copier approach will not work, as they are likely to ask for changes to the standard solution). Sometimes if the implementation group is highly skilled, the approach is successful. However, the lack of commitment of resources and limited business interaction is far more likely to lead to implementation failure and dashed hopes.
To avoid this, the copiers have two fundamental choices. First, they can select a small user group and an area where the packaged solution is relatively mature (often in finance). This will allow them to get experience with the tool before making larger commitments. It also allows the copiers to avoid risk by limiting the promises to the user community. The other alternative is to reduce scope to a limited area of low complexity and gradually employ the solution to a few users.
The largest risk with the copiers is that their tendency to "over-sell" the packaged solutions and underestimate the effort of employing it. In addition, they often start with very complex subject areas such as tax reporting, activity based cost reporting and material management analysis, where the tool's standard solution may have more limited benefits to specific industries.
As a result, many customers who adapt a copier approach fails.
The Direction of Implementing Packaged BI Solutions
As Figure 2 illustrates, each approach has its own "comfort phase" where they like to spend the most of the project time and resources.
All of the approaches discussed have a place in implementing a packaged BI solution. The explorers reduces the risks, the copiers reduces the implementation time, the perfectors makes sure the system works as advertised, and the Innovators can add many new and important features to the system. However one of these behaviors is dominates the project, significant risks may emerge.
The first step to avoid the dominance pitfall is to recognize the behavior and consciously select one approach or another based on the project need. The next step is to steer the project team from one behavior to another as the project progresses from the analysis phase to the design, construction and testing and implementation phases.
Regardless what approach you select, each has its benefits and risks. The correct approach will be guided by each company's strategy and risk aversion. But it should not be a function of lack of information and driven by whoever is available to join the project at any given time.
To be successful, careful consideration should be made as to the resource commitment to the project as well as how much risk the organization is willing to live with.
Thanks, Dr. Berg