Customer approaches to a packaged DSS system by 0N4nG1Kh

VIEWS: 8 PAGES: 4

									                                       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 adaptation
    started 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
                                                    Customer Approaches to Packaged DSS
                                           High




                                                         "Explorers"                   Copiers




                              Level of resource
                                 constraints



                                                        Innovators                     Perfectors




                                            Low
                                                  Low                                               High
                                                                       Risk aversion
    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

                                                                                                           1
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.


                                                                                                       2
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.




                                                                                                        3
Figure 2: Where is the time spent?




Dr. Bjarne Berg a Professor of Computing Sciences at Lenoir-Rhyne College. 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 bergb@lrc.edu


--------------------------------------------------------------------------------------------------------------------------------




                                                                                                                         4

								
To top