ERP Risk Mitigation. An Overview. May Ramco Systems Corporation

(1)

ERP Risk Mitigation

An Overview

May 2005

Ramco Systems Corporation 3150 Brunswick Pike, Suite 100

Lawrenceville, NJ 08648 Tel: 609.620.4800 Fax: 609.620.4860 http://www.ramco.com

(2)

INTRODUCTION

Implementing standard ERP products and other standard Enterprise Applications is risky. Industry statistics show that more than

60% of ERP implementations fail1.

The most common reason that companies walk away from multimillion-dollar ERP projects is that the purchased software product does not support one or more of their important business processes. At that point, they have two options:

1. Change their business processes to fit the software, which will mean deep changes in “long-established ways of doing business” that often provide competitive advantage in their markets. Additionally, roles and responsibilities in the organization need to be re-looked to fit the software architecture and

functionality. [OR]

2. Modify the software to fit the process. This will delay the project, introduce defects into the system and make software upgrades extremely difficult. Customizations will need re-coding to work with the new version.

SOME FACTS

The average ERP implementation takes 23 months to complete and results in a negative

ROI of $1.5 million2.

33% of implementations took “somewhat

longer” than expected and 26% took

significantly more time to complete.3

35% of implementation costs were

“higher” than expected and 20% were

“significantly higher” than expected.3

Many IT executives are dissatisfied with their IT solutions and solution providers.

30% of the IT executives polled felt “trapped” by their IT choice (indicating

that they did not feel in control). 4

23% had little intention of continuing their

relationship with their enterprise

application vendor4

A $5 billion drug distributor went bankrupt and blamed this setback on a failed ERP implementation.

1

Richard Ligus Global Logistics & Supply Chain Strategies article In February 2004 2 A Meta Group Report

3 A Financial Executives Institute Report

(4)

Other high profile failures of ERP implementation include:

Leading US car rental provider’s abandonment of its ERP project ($50-58 million).5

Failed ERP project ($112 million) at a top US provider of confectionery products resulting

in shipping delays and deliveries of incomplete orders.5

A multi-billion dollar paper product distributor that wrote off $168 million.5

An international pharmaceutical conglomerate that spent 7 years and over a half a billion

dollars trying to implement an ERP system.5

UK based furniture chain issued a profits warning after the botched rollout of an ERP that

led to customer orders being sent out incomplete; the problem cost $55 million to correct.6

The cost of a failed implementation is higher today than before. Supply chains are tight and companies carry minimal inventory. For instance, surplus buffers to offset any system failure are non-existent. In such tight supply chains, any implementation failure can be catastrophic.

WHAT RISKS CAUSE SUCH FAILURES?

ERP systems fail because they do not fit business needs (fitment risk) and the consequent

efforts to configure or customize the product affect the project schedule and costs (project

risk).

FITMENT RISK

5

A ZDNet article November 10, 2004

6 Andy McCue in Silicon.com, September 2004

The critical priority is therefore to mitigate risk when selecting and implementing an enterprise application.

(5)

Fitment issues may arise during Selection, Implementation or Post Implementation.

Fitment Issues during Selection

Typically, enterprise application selection involves listing the required features, preparing feature-function matrices and shopping for systems that comply with these features. The vendor with the highest level of fitment is preferred.

However, this may not always ensure selection of the right solution, as the selection process may have flaws such as:

a. Unique & critical processes could get overlooked

Feature-function matrices may be an inadequate yardstick. The vendor may have a ‘good features rating’, but may not satisfy certain unique processes that differentiate the organization. These critical processes should become "critical requirements" during a software selection process. If the software vendor fails to meet these requirements, they

become "fatal flaws”7 that will adversely affect the implementation.

The selection process at a distribution-oriented company revealed that drop shipment was a major issue. The primary focus of drop shipment in this enterprise was the financial transaction resulting from the material shipment process and the rebates from volume purchases to be realized by the distributor from the supplier. During the selection, the company failed to consider the impact on the financial systems and only reviewed the actual transactions supporting the transfer of materials.

Although material flow was important, the fatal flaw was the processing of rebates tied to the financial transaction. The selection team did not realize this until the later phases of the implementation. By missing a fatal flaw, the enterprise had to create custom code to handle the financial transaction and the rebate cycle.

This ultimately more than doubled the initial cost of the application license. In addition, each time the company needed to upgrade the ERP application, they would incur costs associated with this custom code. The company estimated that this requirement adds another 25 percent

to the cost of each upgrade.7

7

Yvonne Genovese and Brian Zrimsek, April 2004, Gartner

Companies that invest in expensive ERP systems run the risk that the selected application may not meet targeted business objectives due to lack of fitment of the application with unique business needs, resulting in a failed implementation.

(6)

b. Vendor responses are subject to interpretation

First of all, it is challenging to accurately describe solution needs in a feature/function RFP listing. The problem gets compounded when requirements and desired features are interpreted differently by vendors.

A “yes” response from vendor ‘A’ to a feature/function requirement has built in bias and interpretation towards the capabilities of that vendor’s product. Likewise a “yes” response from vendor ‘B’ has similar bias to its product. Yet, the two products may exhibit completely different behaviors (screen sequence, work flow, data entry, etc.) as to how they execute those functions. The true “functional fit” (or lack thereof) is only realized when the software product is being implemented.

Further, overzealous vendor sales persons may sometimes try to present a level of Fitment that is higher than reality!

c. Focus on features could ignore broken processes

The vendor may not satisfy all activities along an “end to end” business process chain, despite demonstrating a high degree of fitment to features. This will prevent the company from completing the business process with the selected enterprise application and force customization or bolt-ons to third party applications, again increasing implementation risk.

d. Products force lock-in to the set features

Products are not readily amenable to change. Organizations therefore get ‘locked-in’ to the chosen solution and vendor, and are forced to live with the reduced fitment – unless they opt to customize the application, a difficult choice under most circumstances.

Fitment Issues during Implementation

Organizations may therefore select a solution with less than adequate fitment to business needs. However the issue does not end with selection as fitment may continue to fall during the implementation process due to requirements growth:

a. Requirements are a “moving target”

Enterprise Application implementations run anywhere from a few months to a few years.

However, user requirements change by around 2% every month8. This creates a situation

where the fitment may have deteriorated by the time the solution is implemented and goes into production.

8 Capers Jones

(7)

b. New requirements are discovered at “go live”

Further, due to the use of an incomplete or inaccurate selection yardstick in feature/function matrices, users may discover solution requirements at the “go live” point that were not originally identified.

A fabric manufacturer wound up making extensive, unexpected (and expensive) modifications to its ERP package because the company discovered that the system could not handle the fact that the company priced the same bolt of cloth in two different ways: one price for

domestic consumption, another, four times higher, for export.9

c. Process Templates reduce fit

Another factor that reduces fitment is the use of process templates for speedy implementation. Although templates may speed up taking a solution into production quickly, they promote over-generalization and consequent fitment risk.

So even if the solution seemed like a good fit at the time of selection, the actual fitment on completion of implementation may be much lower. The solution would therefore be perceived as unsatisfactory by business users, leading to a partially or fully failed implementation.

Fitment Issues post Implementation

Technology investments are normally written off over a period of five to seven years. Organizations therefore seek to buy solutions that can support their business needs over this period. However, predicting fitment over the long term can turn out to be a risky endeavor. Fitment issues increase over time as:

a. Change is a constant

Once the solution is implemented and running, business process changes may occur due to changes in strategies or business models, new markets expansion, increase in competition, new staff coming aboard with different ideas, regulatory change (for instance Sarbanes Oxley) and so on. All these lead to further erosion in solution fitment to business needs.

(8)

b. Modifying solutions to manage change is challenging

Organizations may then need to modify the ERP system to react to change and restore fitment. However ERP systems are notoriously difficult to change once the initial design is complete as most systems are parameters-driven. Once parameters are set, it is not possible to change them anymore without far-reaching and unforeseen consequences for the implemented processes in the various modules. A related consequence of this inflexibility is that many sensible change initiatives get de-prioritized or cancelled, and companies can find it difficult to react quickly to rapid changes in the business environment.

This may call for additional customization of the ERP product by modifying the software code. However standard ERP products are not designed for extensive customization which introduces errors and prolongs implementation. Most vendors of standard ERP products discourage customization and levy hefty charges for customization.

Moreover the process of defining the exact scope of customization is also subject to the “inadequate yardstick” error. Customizations are typically discussed on a “white board” and then implemented in the product. Customizations thus implemented may not always match the actual solution changes needed.

c. Upgrades exacerbate the difficulty with solution changes

This problem gets further compounded during the implementation of upgrades of the ERP package to the next release. Customization changes need to be retrofitted to the new version of the product. This complicates the upgrade process and prolongs the lead time to implement upgrades. Moreover, ERP vendors’ de-support deadlines for current releases force customers to upgrade, going through the pain of applying the customization to the new release.

d. Finally solutions become unusable

The diagram shows how the fitment gap increases over time due to growth in requirements. At some point, the gap becomes so large that the product becomes unusable. This may force the company to buy a new product or implement a major release. This new purchase may close some of the gap, but implementation lead times and further growth in requirements cause the gap to again begin to widen.

(9)

Lack of fitment caused a failed ERP implementation at a midsize food manufacturer. This specific ERP product was focused on the needs of the Food Industry and incorporated several “industry best practices”. However it did not fit the unique business needs of this organization. This company had certain key unique processes that were not met by the standard Food industry ERP product. The ERP implementation project ran into serious difficulties, impacting both the schedule and cost. Ultimately the company was forced to discard the ERP solution.

PROJECT RISK

Unexpected fitment issues and consequent need for customization cause project schedules and costs to deviate from the plan. An ahead-of-schedule product replacement need would stress corporate budgets.

a. Projects get delayed

Customization adds work, consumes additional resources and affects the project. Another factor that affects ERP implementation is the added complexity of product configuration. Products are designed on the basis of a “one size fits all” assumption. Products are therefore made feature rich for use across diverse industries or diverse organizations within an industry. This calls for additional set up time to deselect unwanted functionality and configure the behavior of the chosen system. It may not be possible to always accurately estimate the time and cost for configuration – this could present unexpected challenges and throw the project off track.

(10)

Complexity of product configuration was a likely cause in the failure of the ERP implementation at a US manufacturer of confectionary products. The company had trouble pushing orders through the new system, resulting in shipment delays and deliveries of

incomplete orders.10

b. Costs go out of control

Companies often estimate project costs inaccurately during the selection of the ERP system. Usually, the focus is on initial costs - solution, implementation and other hardware/software costs. Initial costs may be misleadingly low, but the total cost of ownership over the lifetime of the solution may be much higher than budgeted.

Cost elements that may be missed out in the initial estimate include:

Integration and testing with other applications that need to co-exist with the ERP

Migrating data from legacy systems to the new ERP system

Training users on the new processes

Customizations that need to be made

Rolling up customizations during upgrades

Forced upgrades just to keep up with vendor support

HOW CAN THESE RISKS BE MITIGATED?

a. It is the process

ERP systems exist to support the organization’s business processes. Organizations often ignore the need to define an optimal process and then use the technology as an enabler for the process.

In many instances, organizations either try to adopt a process that is inherent in the ERP solution, even if it does not fit their business requirements, or they try to shoehorn their legacy processes into a software package that is not designed to support their processes. In both cases, they sub-optimize the capabilities in the technology and fail to take advantage of the opportunity to streamline their business process – the entire point of technology implementations.

The road to success lies in defining optimal business processes and then implementing an enterprise application that mirrors targeted processes. Further, change should be managed by identifying corresponding business process changes and making those changes to the application.

(11)

b. Need for agility

This requires flexible and agile enterprise applications that are driven by business processes, and that can be changed when processes change. Implementing the solution in terms of “loosely coupled” services with service-oriented architecture provides a good solution alternative.

c. VirtualWorks - an agile platform

For example, the Ramco VirtualWorks® platform enables such agility with personalized

enterprise solutions that are assembled from existing and new software components. Existing components offer industry best practices. Personalized and new components address unique processes. VirtualWorks enables a business process driven approach to solution definition and deployment - on a model based platform. VirtualWorks turns business process models into software. Customization of components is at the model level and not at the level of software code. Software is generated automatically from the model through the use of code generators.

The platform supports changing the implemented solution “on demand” as solution changes can be made anytime by changing the associated application model.

d. Mitigating risk with VirtualWorks

This approach mitigates risk as:

The business process driven approach helps overcome the constraints of features and

functions lists.

VirtualWorks turns specified processes directly to software. Solution fitment is therefore

greatly improved.

The solution can be quickly visualized via personalized previews that help users confirm

scope and functionality.

Every organization gets a personalized solution as Ramco maintains a unique model for

each client. Customization is no longer an “evil” but is encouraged to enable organizations to obtain a solution that meets their unique business needs.

VirtualWorks supports Change-On-Demand. Organizations are not therefore locked into

the initial solution.

The maintenance process is executed via Change-On-Demand. Instead of

vendor-determined upgrades, vendors get personalized upgrades on demand.

VirtualWorks has a layered architecture where business processes are separated from

the technology layers. This enables organizations to change the technology platform when needed without having to replace the complete solution.

(12)

By turning specified processes into agile enterprise applications with Change-On-Demand, VirtualWorks ensures continual fit and reduced risk.

e. Continuous alignment of the solution

A closed loop approach enables a systematic method of improving the solution over time and ensuring sustained fit. This comprises four distinct stages:

Design business processes (ProcessWorks): design efficient processes that combine a

company’s unique processes with industry standard practices

Enable business processes (VirtualWorks): turn business processes into software that mirrors desired processes

Operate your application: the organization operates the application and enjoys its benefits

Assess business processes (DecisionWorks): analyze business processes that are

executing in various applications, understand weaknesses and provide input to improve business processes.

Change-On-Demand: adapt the application to meet changing business needs

Organizations therefore take control of their enterprise solution and adjust it to meet their unique business needs.

(13)

CONCLUSION

ERP and other enterprise applications implementation is risky due to the lack of fit between the business processes anchored in the product and the business processes that the company needs to run. This often leads to a scenario where organizations need to customize

the Enterprise Application to suit business needs. Customization helps companies realize

targeted business processes and achieve business objectives.

However due to the “one size fits all” design of products, customization makes product maintenance challenging. Customizations need to be redone on new releases making the release management process difficult. Vendor de-support deadlines force customers to upgrade and go through the pain of applying the customizations to new releases. On the other hand, if organizations adopt the vanilla processes embedded in the product they run the considerable risk of losing their differentiating processes and achieving a solution that does not meet targeted objectives.

A different approach is required that calls for agile and flexible enterprise applications that are business-process driven. The Ramco VirtualWorks platform turns specified processes into software, with the ability to change the solution on demand (Change-On-Demand). VirtualWorks helps companies to retain unique business processes and manage change. As the resulting solution exactly matches desired processes, solution fitment is dramatically improved. Change-On-Demand ensures that incomplete or changing business requirements are no longer a stumbling block, but only call for adjustments to be made to the application model.

Risk is mitigated, as organizations take control of their enterprise software, with the exact processes and changes they need – at the time they need it.

Ramco Systems Corporation www.ramco.com

3150 Brunswick Pike, Suite 100 Phone 609.620.4800 Fax 609.620.4860

ERP Risk Mitigation. An Overview. May Ramco Systems Corporation