Customer Approaches to Packaged DSS
- Why so Different?
As companies such as SAP, PeopleSoft, Oracle and others have started to offer packaged data warehouse solutions for their ERP systems, many customers have looked at ways to implement them. Their approach to implementing the packaged analytical products has often been driven by a mix of deep skepticism and cautionary optimism. This article looks at what drives the implementation approaches and how to avoid some of the most common mistakes.
Background
While Oracle launched their packaged data warehouse offering in the early 1990s, PeopleSoft and SAP came to market with their products in the late 1990s. Today, most ERP vendors provide at least a packaged data warehouse product and the largest vendors also provide integrated Analytics (iAnalytics) as well.
However, since these products were very late to market, the early ERP customers had already developed their own reporting and management tools. Therefore, the new packed DSS products were often met with hostility from IT organizations that were perfectly happy with their custom systems.
The business owners had a more mixed view of the situation. First there were significant costs of ownership associated with the custom systems. Secondly, when the transaction system was upgraded, the reporting system would need substantial changes to their extract programs. In addition, the custom data warehouses were often inflexible to changes, and normally 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 turned to the ERP vendors and complained over the lack of reporting features in their products. The vendors naturally pointed to the new packages solutions and the first wave of adaptationstarted in earnest. Now the question became how to implement the new tools (many of them were quite immature). Caught in the middle of inflated business expectation and some hostility from IT departments, the approaches to the DSS products varied greatly.
Figure 1: Customer Approaches to Packaged DSS
Copiers
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 mid-size companies, or companies with relative small IT departments with limited resources. The copier approach is also often conducted by a few individuals with limited input and 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). If the implementation group is highly skilled and has the right knowledge of the business, the approach is sometimes successful. However, the lack of commitment of resources and limited business interaction is 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 the area of basic finance). This will allow them to build expertise in implementing the tool before making large commitments. It also allows the copiers to avoid risk by limiting the scope of the user community and the promises to the business organization. The other alternative is to reduce scope to a very limited area of low complexity (i.e. A/P reporting) and gradually employ the solution to a few users.
The largest risk with the copiers is that they often inflate the promises of 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. As a result, many customers who adapt a copier approach fails.
Innovators
Every project will make some modification to the standard content, but the innovators treat the delivered content as only 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 specie, 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 approach standpoint the innovators can only be managed if they have to justify each change to the delivered content in a change control process.
Perfectors
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 2 and 3 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
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 that 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 clear 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 Direction of Implementing Packaged DSS
All of the approaches discussed have a place in implementing a packaged DSS 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 risk 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. As, the graph below illustrates, each approach has its own “comfort phase” where they like to spend the most of the project time and resources.
Figure 2: Where is the time spent?
Dr. Bjarne Berg a Professor of Computing Sciences at Lenoir-RhyneCollege. He has managed many large scale Fortune-500 data warehouse implementations and is also a frequent speaker at conferences and a subject matter expert in Business Intelligence. He can be reached at
------
1