erp risk mitigation

13
Ramco Systems Corporation 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

Upload: others

Post on 11-Jan-2022

8 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: ERP Risk Mitigation

Ramco Systems Corporation

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

Page 2: ERP Risk Mitigation

2 of 13

Ramco Systems Corporation

Table of Contents

INTRODUCTION ....................................................................................................................... 3

WHAT RISKS CAUSE SUCH FAILURES?.............................................................................. 4

FITMENT RISK.........................................................................................................................................4

Fitment Issues during Selection............................................................................................................5

Fitment Issues during Implementation .................................................................................................6

Fitment Issues post Implementation.....................................................................................................7

PROJECT RISK .......................................................................................................................................9

HOW CAN THESE RISKS BE MITIGATED?......................................................................... 10

CONCLUSION......................................................................................................................... 13

Page 3: ERP Risk Mitigation

3 of 13

Ramco Systems Corporation

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 Study by the research company Walker Information

Page 4: ERP Risk Mitigation

4 of 13

Ramco Systems Corporation

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.

Page 5: ERP Risk Mitigation

5 of 13

Ramco Systems Corporation

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.

Page 6: ERP Risk Mitigation

6 of 13

Ramco Systems Corporation

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

Page 7: ERP Risk Mitigation

7 of 13

Ramco Systems Corporation

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.

9 Derek Slater in the CIO magazine February 1999

Page 8: ERP Risk Mitigation

8 of 13

Ramco Systems Corporation

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.

Page 9: ERP Risk Mitigation

9 of 13

Ramco Systems Corporation

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.

Page 10: ERP Risk Mitigation

10 of 13

Ramco Systems Corporation

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.

10 Craig Stedman in ComputerWorld October 1999

Page 11: ERP Risk Mitigation

11 of 13

Ramco Systems Corporation

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.

Page 12: ERP Risk Mitigation

12 of 13

Ramco Systems Corporation

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.

Page 13: ERP Risk Mitigation

13 of 13

Ramco Systems Corporation

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 Lawrenceville, NJ 08648