“Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © Chapter 7 Deciding to Go ERP.

“Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 ©

Chapter 7

Deciding to Go ERP


Business Case Rationales

• Business case rationales typically fall into four categories• Technology• Business Process• Strategic• Competitive


Why is the Rationale or business case important?

• Want to make the “right’ decision, so develop a good business case

• Business case can facilitate choice of processes or evaluative measures• Gives guidance to the design team

• Business case can provide a basis for the evaluation of the quality of the design/implementation


Technology Motivations

Motivation No. of Firms Percent• Systems not Y2K Compliant 42 27%• Disparate Systems 37 24• Poor Quality Systems 26 17 /Visibility of Information• Business Processes or 19 12 Systems Not Integrated• Difficult to Integrate 12 8 Acquisitions• Obsolete Systems11 7• Unable to Support Growth 8 5


Technology Rationales: Y2K

• We really sold (ERP) on the Year 2000. ... If you have systems that are 20, 25 or 30 years old, the Gartner Group ... has indicated that it will cost you anywhere from $1.10 to $1.65 per line of code to change for year 2K. If you have 4,000,000 lines of code you are talking about a lot of money. Additionally, the legacy systems are not there, there is nobody there to maintain them and there is nobody who understands them. So if you had to fix it up for the year 2K it would take you millions and millions of dollars, with a terrific risk. In essence we sold this system on a year 2 K basis.


Technology Rationales: Disparate Systems

• Disparate systems limit the ability of firms to integrate different business units. Recall Geneva Steel

• we have ... a mainframe ... (and)... a primitive accounting system ... we have lots and lots and lots of different kinds of computers. They have a hard time talking to each other. We have a large number of mini computers out there that are different kinds, that have different software .... Our system is a road map from hell. ..


Technology Rationales:Poor Quality Existing Systems

• We (Microsoft) had just had a very bad budget process. ITG (the Information Technology Group) and Finance had developed a new budget tool and it didn’t work. .... It was not fun. ... I was just back from vacation, and Steve Ballmer was just back from Wal-Mart. Steve knocked and opened my door. I knew it was Steve, he has a really distinctive knock. He walked in and said, “You guys [expletive deleted]!” I got the message.


Technology Rationales:Difficult to Integrate Acquisitions

• We wanted more insight into how our processes were doing. ... Your processes have to change. As a company that acquired so many companies, [Brown Ferris] didn’t have uniform processes. Part of our challenge was to get 500 places using standard procedures.


Technology Rationales:Measurement

• Oftentimes technology rationales are measured on a “yes-no” basis• Is the new system Y2K compliant?• Does the new system allow us to eliminate this road

map from hell?• Can we get rid of our existing budgeting system with

this new software?• Typically can specify particular measurement

goals.


Business Benefits

Benefit Number of Firms Percent

• Personnel Reductions 44 20%• Inventory Reductions 42 19• IT Cost Reduction 27 13• Productivity Improvements 23 11• Order Management Cycle Time 19 9• Cash Management 16 7• Revenue/Profit 15 7• Procurement 12 6• Financial Cycle Close 10 5• Maintenance 8 4


Business Process Rationales

• Designed to aim at specific improvements in efficiencies or cost savings or revenue enhancements.

• Typically include a specific number • For example, “decrease inventory by 40%”

• Can provide guidance regarding design


Business Process Rationales:Personnel Reduction

• “We will have fewer accountants and probably have fewer information systems people. Because one of the things we are considering is contracting out a chunk of that function. A great deal of what we do, we have cost accountants do, lots of things, not just by hand, it is not that primitive, they do a lot of work that won’t need to be done once SAP is implemented.”


Business Process Rationales:Productivity Improvements

• “To get the project (cost) justified we intentionally focused on the tangible items the board would understand and that we could clearly articulate and make commitments to deliver.” (Owens Corning)

A one percentage point cost reduction deriving from global economies of scale in raw material purchases

A one percentage point cost reduction deriving from fewer warehouses and lower freight cost

Improvement in reliability-oriented maintenance generating lower plant maintenance costs


Business Process Rationales:Financial Close

• Firms often specify speeding the closing process as a goal• One firm wanted to cut their closing time from 24 days to 6

days.


Strategic Rationale

• Choose ERP to implement a specific strategy• As part of an E-business strategy, a firm could implement

an ERP system• As part of a strategy to focus on the consumer, a firm could

implement “Available to Promise” (ATP)


Competitive Rationale

• “A lot of ERP purchases are premised on the need to just stay in business.”

• The competition has it can take two approaches• Implement because the competition has it• Focus on why the competition has it and see if it fits your

company and what benefits can be gathered


Competitive Rationale

• On June 24, 1996, Oracle’s Application Division announced that “Several companies went live with their Oracle Applications implementations during the quarter, including Silicon Graphics, Inc. and Quantum Corporation, both of whom successfully deployed large-scale implementations.” In addition, at the same time, Oracle’s Application Division announced that “among the customers added this quarter included ... Western Digital ....” (Quantum’s Competitor)


Business Case Rationale

• Can be used as a guide to help design and evaluate success.

• Why is it being implemented? Use this as a basis to assess the quality of the implementation


How Does a Firm Decide Whether or Not to Go ERP?

• Hard vs. Soft Data• Use of the Measurement Criteria• Organization Culture


Role of Top Management

• What is the role of top management in deciding to go ERP?• Only a few executives in a firm can make such a big

decision• Voice of Change must include domain area since processes

will change


Hard vs. Soft Data

• Whether the data is ‘hard’ or ‘soft’ can influence the decision• The Y2K data was hard data. They (top management) believed

that data.


Measure Costs Throughout the Life Cycle

• Measurement of project costs is necessary to provide a budget and actual for the project

• Costs start in the decision to go ERP and move in thru the rest of the life cycle, through the stabilization period


Organization Culture

• Some organizations use detailed analysis, whereas others do not• In some cases it is a matter of the organization’s culture


Cost Benefit Analysis

• Use it, but keep in mind ...• Costs can be disguised or hidden or inaccurate• Benefits can be fuzzy or unanticipated


Chapter 8

Choosing an ERP System


Two Basic Approaches

• There are two basic approaches that are used as bases of choosing ERP software• Requirements Analysis (“As Is”) • Best Practices Analysis (“To Be”)


“As Is” Analysis

• As is refers to the current system and its current capabilities

• The system “as it is” right now


Requirements Analysis (“As Is”)

• “As Is” the ways things are.• Organization determines what their processes and

artifacts currently are and use that “as is” model to establish requirements that software is judged against.

• Typically, the software that best meets the requirements is the one chosen by the firm


Requirements Analysis - Evaluating Features

• Typically, requirements are features that the software “must have”• In addition, sometimes “would like to have” also is

gathered.• Likely to use a numeric scale of say 1-5 for each

feature, based on how important the feature is• For missing features, typically changes to the

software are seen as a gradation of change, e.g., “enhancement” or “customization”


How many requirements?

• Timberjack’s requirement analysis took six months and generated > 1,000 requirements

• Another firm took eight months and generated 1,500 requirements

• If it takes a long time, then requirements can (will?) change


How long will it take?

• Can be a substantial effort and take a while!• Typically 1 - 3 months


Who Should Be Doing Analysis?

• Trade-off between current employees who know how work is done, and managers, who see work from a different perspective. ...

• Which processes should be captured:• Past• Current, or• New?


Help for Doing Requirements Analysis

• Consultants specialize in requirements analysis, e.g., Big 5• There are existing packages that facilitate requirements

analysis, e.g., “The Requirements Analyst”


Requirements Analysis - Granularity

• Requirements are not equal granularity.• Some are whole best practices, while others are fields

(e.g., date)• Able to manage orders following best practice methods of

placement, control and expediting• Able to Use EDI with Certain Vendors• Able to set up vendor schedules• Able to track actual date


Advantages of Requirements Analysis

• Classic System Choice Process, so it is generally understood

• Establishes a bench mark that can be used to judge fit of software

• Provides a document that can be used for communication and to generate buy-in


Disadvantages of Requirements Analysis

• “As Is” analysis can be very • time consuming, slowing the implementation• costly (e.g., one firm spent $100,000)

• May (will) be impossible to specify all software requirements

• If there are too many requirements then vendors may not fully respond to the RFP


Disadvantages of Requirements Analysis

• Lose chance to reengineer by focusing on the ‘‘As Is” model• Cements existing processes without evaluation as to their

quality• Requirements are not stable, so it is likely that

requirements can only chase reality• Requirements are only a snap shot


Format

• Typically a list, along with a relative ranking of the importance (1,2,3,4,5)

• Scripted• Loosely Scripted -- “show me what you have”• Tightly Scripted -- “can you handle this data?”


“To Be” Analysis• Process of determining which best practices should

be used by a particular organization, i.e., how should the organization process information, and choose the software on that basis

• Focuses, not on where the organization is, but where it wants to be.

• Search often includes Big 5 best practices, and ERP best practice capabilities


Gap Analysis

• Match “AS IS” and “TO BE” to determine if any gaps.• How do we evaluate gaps?• Count them?• Rate importance?• ...


Both Requirements Analysis and Gap Analysis Ignore Important Issues

• Cost• Installation time• Flexibility• User interface• Upgradability• Implementation Personnel• Reliability …


Cost Factors - Mini Case:Which Do You Choose?

Upgrade Oracle SAP

Implementation $3-5 M $4-8 M $6-10 M

Software Development $2-4 M $1-3 M minimal

No. of Users (Seats) 15-20 10-15 8-10


Both approaches ...

• basically assume that majority wins. How do you choose, the software that has the most requested features or the most valuable features or ..?

• can focus on artifacts (e.g., invoice) rather than processes


Emerging Approach

• Increasingly, consultants are promulgating the approach where no “as is” model is developed, no gap model is developed …

• Go straight to the “to be” model, since that is what really counts

• Typically, with this approach the consultant knows both your organization and the software


Emerging Approach

• Instead, just choose one of the better ERP packages and choose the best practices available within that package.• Systems are so good that any of the systems will have

processes that are “good enough”


How do firms choose?A Case Study

• Company: Chesapeake Display and Packaging (CDP)

• They used a five step approach, including a vote as to which everyone preferred.• Form Blue Ribbon Committee• Contact Vendors to Arrange Demos• Ask Vendor for Proof of Rapid Implementation• Vote• Make Choice


1. Form Blue Ribbon Team

• A Blue Ribbon Team (BRT) was chosen for their knowledge of the business and business processes

• There were some big picture people• The committee was limited to no more than ten people


2. Contact Vendors to Arrange Demo’s

• A limited number of first tier vendors were chosen, contacted and asked to prepare a demo for the BRT

• Vendors were given unlimited access to the BRT for three weeks.

• Demos lasted 1-2 days• Vendors choose the hardware and software that they

preferred


3. Ask the Vendor for Proof of Rapid Implementation Ability

• Vendors were asked ...• Show your software can handle our business• Show you can implement in the time required• Show expertise in understanding the industry


4. Vote

• After the demos, there were three candidates, Baan, J.D. Edwards and SSA.

• In order to choose, the BRT was asked to rank 1 to 3 based on “Best functional fit” and “Best implementation personnel”


5. Software Recommendation

• J.D. Edwards was seen as offering • Superior financial capabilities• One integrated solution• Human resources and payroll• Advanced object oriented tool set• A planning module that allowed for scheduling on a cost

basis


So, What do you ...

• Like about the way they selected their system?• Not like about the way that they selected their system?


Chapter 9

Designing ERP Systems

Part I


Customize Applications or Change Business to Fit Software?

Choose Application to fit 37%business and customize a bit

Customize Applications to fit business 5%

Reengineer Business to fit application 41%

No Policy 17%


On the Relevance of “As Is” and “To Be” Modeling

• Since “As Is” analysis generates models of existing processes, the relevance of “As Is” modeling is dependent on the extent to which processes stay the same

• Since “To Be” analysis generates models of processes chosen to be implemented, its relevance depends on the extent of change to be made in existing processes.


“As Is”

• If a firm is planning extensive reengineering (>40%) from survey were, then the “As Is” model is not very important. Instead the “to be” model drives the process.

• However, if minimal reengineering is planned then it can be critical to do an “As Is” model so that the proper software can be chosen.


Extent of Change to Organizational Processes Planned

Minimal ExtensiveQua

lity

of F

it of

Sof

twar

e to

“As

Is” P

roce

sses

Loos

e Fi

tTi

ght F

it

“As Is” RequirementsAnalysis is Critical

“As Is” RequirementsAnalysis is not

Necessary


“As Is”

• Consider a firm that performs an “as is” analysis and finds a loose fit between existing processes and the ERP software they choose.• If minimal reengineering is planned, then there may be

a lost chance to choose software that matches their processes

• If extensive reengineering is planned and there is a tight fit with existing processes, then that close match can limit their ability to do reengineering and may result in backsliding.


Extent of Change to Organizational Processes Planned

Minimal ExtensiveQua

lity

of F

it of

Sof

twar

e to

“As

Is” P

roce

sses

Loos

e Fi

tTi

ght F

it

Lost Chance toChoose Softwarethat Meets Needs

Potential to Back-Slide to Existing

Processes


“To Be”

• If there is only limited change of the software planned then the “To Be” model is basically constrained to the processes available in the software

• If the software is to be modified, then the “to be” model becomes more like a clean slate analysis, since the choices are beyond the software.


Extent of Change to Software Planned

Minimal Extensive

Qua

lity

of F

it of

Sof

twar

e to

“To

Be”

Pro

cess

es

Loos

e Fi

tTi

ght F

it

“To Be” Analysis isTechnology-Enabled

Portfolio Choice

“To Be” Analysis is Clean Sheet Reengineering


Two Dimensions ...

• There are two dimensions of change …• Change in Software• Change in Organizational Processes

• Resulting in reengineering ranging from “little r” to “big R” reengineering.

“Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 ©Extent of Change to Software

Minimal ExtensiveExte

nt o

f Cha

nge

to O

rgan

izat

iona

l Pro

cess

es

Exte

nsiv

eM

inim

al

“Small r”

“Big R”


Minimal Organization and Software Change

• Small r reengineering offers fast and cheaper implementation

• However, with small r, you miss the chance to be a champion

Extent of Change to SoftwareMinimal Extensive

Cha

nge

to O

rg.

Proc

esse

sEx

tens

ive

Min

imal

“Small r”

“Big R”


Extensive Organizational and Minimal Software

• “SAP customers often have to change their businesses to use the software, but the cost and the change is worth it because the software lets the company operate more efficiently.”


Cha

nge

to O

rg.

Proc

esse

sEx

tens

ive

Min

imal

“Small r”

“Big R”


Extensive Organizational and Minimal Software

• Trash Hauler industry taking SAP software to the dump. Allied Waste and Waste Management have abandoned their SAP initiatives because

“SAP expects you to change your business to go with the way the software works.”


Cha

nge

to O

rg.

Proc

esse

sEx

tens

ive

Min

imal

“Small r”

“Big R”


Minimal Organizational and Extensive Software

• A project manager at Nestles indicated that their choice of processes for their SAP implementations included best practices beyond those included in the software. • Some of their existing processesand best practices from their consultants’database of best practices were chosen, forcing a change in the software.


Cha

nge

to O

rg.

Proc

esse

sEx

tens

ive

Min

imal

“Small r”

“Big R”


Disadvantages

• We have learned the hard way, if you modify the software there will be a cost. The cost comes when you do the modification initially, when you do an upgrade, and when you support the software over time. ...

• Customization to different divisional requirements also can make it difficult to implement the software in other divisions. Although the manager of SAP services at Deere Co. indicated that for their ERP project, the customizations went well, it was also noted (Lamonica 1998)• ... what hasn’t worked well is establishing standards and

templates that can be rolled out to other divisions.


Extensive Organization and Extensive Software

• Boeing and BAAN … What was the payoff? • As noted by one Boeingconsultant (Busse 1998),“Prior to ... (the new system)... people had tunnel vision,now people see up anddownstream ...”


Cha

nge

to O

rg.

Proc

esse

sEx

tens

ive

Min

imal

“Small r”

“Big R”


Extensive Organization and Extensive Software

• Advantages: First mover advantages for the adopter; development of a package that can be sold to similar firms to the ERP firm; costs and risks are shared by both

• Disadvantages: Changing software is expensive and inhibits ability to get to next version. Adopters are likely large firms with market power.


Evolution from Big R to Small r Reengineering

• In some cases, ERP firms partner with implementing firm in an effort to expand the product capabilities.• Extensive software changes can result in industry specific

versions of the software• As the software is made to conform with unique industry

requirements, it becomes “small r” for those on the third or fourth wave.


Implementation Failure and Success Factors

• The highest probability of a successful implementation is when there is minimal change to both organization and software.• This does not mean all organizations should pursue that

approach.• Change to organization processes can mean resistance to

change, choice of the wrong best practices, etc.


Implementation Failure and Success Factors

• Extensive change to software draws heavily on the organization to implement large IT projects and IT change management

• See diagram …• Bottom line, firms must assess what will make their

implementation successful?


Which Quadrant … Which Approach?

• Depends …which is best for your firm?

Highest Probabilityof Successful

Implementation

“Small r”

Potential Project Failure because of Process Changes

Potential Project Failure because of

Process Changes and IT Changes to Software

“BIG R”

Potential Project Failure because of ITChanges to Software

Extent of Change to Software

Minimal Extensive

Cha

nge

to O

rg.

Proc

esse

s

Exte

nsiv

eM

inim

al

“Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © Chapter 7 Deciding to Go ERP.

Documents

Transcript of “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © Chapter 7 Deciding to Go ERP.