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

2. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © Business Case Rationales Business case rationales typically fall into four categories Technology Business Process Strategic Competitive

3. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

4. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © Technology Motivations Motivation No. of FirmsPercent Systems not Y2K Compliant4227% Disparate Systems3724 Poor Quality Systems2617 /Visibility of Information Business Processes or 1912 Systems Not Integrated Difficult to Integrate 12 8 Acquisitions Obsolete Systems11 7 Unable to Support Growth 8 5

5. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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.

6. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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...

7. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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.

8. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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.

9. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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.

10. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © Business Benefits BenefitNumber of Firms Percent Personnel Reductions4420% Inventory Reductions4219 IT Cost Reduction2713 Productivity Improvements2311 Order Management Cycle Time19 9 Cash Management16 7 Revenue/Profit 15 7 Procurement12 6 Financial Cycle Close10 5 Maintenance 8 4

11. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

12. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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. ”

13. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

14. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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.

15. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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)

16. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

17. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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)

18. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

19. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © How Does a Firm Decide Whether or Not to Go ERP? Hard vs. Soft Data Use of the Measurement Criteria Organization Culture

20. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

21. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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.

22. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

23. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © Organization Culture Some organizations use detailed analysis, whereas others do not In some cases it is a matter of the organization ’ s culture

24. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © Cost Benefit Analysis Use it, but keep in mind... Costs can be disguised or hidden or inaccurate Benefits can be fuzzy or unanticipated

25. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © Chapter 8 Choosing an ERP System

26. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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 ” )

27. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © “ As Is ” Analysis As is refers to the current system and its current capabilities The system “ as it is ” right now

28. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

29. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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 ”

30. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

31. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © How long will it take? Can be a substantial effort and take a while! Typically 1 - 3 months

32. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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?

33. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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 ”

34. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

35. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

36. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

37. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

38. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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? ”

39. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © “ 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

40. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © Gap Analysis Match “ AS IS ” and “ TO BE ” to determine if any gaps. How do we evaluate gaps? Count them? Rate importance?...

41. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © Both Requirements Analysis and Gap Analysis Ignore Important Issues Cost Installation time Flexibility User interface Upgradability Implementation Personnel Reliability …

42. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © Cost Factors - Mini Case: Which Do You Choose? UpgradeOracleSAP Implementation $3-5 M$4-8 M$6-10 M Software Development$2-4 M$1-3 Mminimal No. of Users (Seats)15-2010-15 8-10

43. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

44. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

45. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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 ”

46. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

47. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

48. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

49. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

50. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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 ”

51. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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

52. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © So, What do you... Like about the way they selected their system? Not like about the way that they selected their system?

53. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © Chapter 9 Designing ERP Systems Part I

54. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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 application41% No Policy17%

55. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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.

56. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © “ 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.

57. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © Extent of Change to Organizational Processes Planned MinimalExtensive Quality of Fit of Software to “ As Is ” Processes Loose Fit Tight Fit “ As Is ” Requirements Analysis is Critical “ As Is ” Requirements Analysis is not Necessary

58. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © “ 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.

59. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © Extent of Change to Organizational Processes Planned MinimalExtensive Quality of Fit of Software to “ As Is ” Processes Loose Fit Tight Fit Lost Chance to Choose Software that Meets Needs Potential to Back- Slide to Existing Processes

60. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © “ 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.

61. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © Extent of Change to Software Planned MinimalExtensive Quality of Fit of Software to “ To Be ” Processes Loose Fit Tight Fit “ To Be ” Analysis is Technology-Enabled Portfolio Choice “ To Be ” Analysis is Clean Sheet Reengineering

62. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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.

63. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © Extent of Change to Software MinimalExtensive Extent of Change to Organizational Processes Extensive Minimal “ Small r ” “ Big R ”

64. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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 Software MinimalExtensive Change to Org. Processes Extensive Minimal “ Small r ” “ Big R ”

65. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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. ” Extent of Change to Software MinimalExtensive Change to Org. Processes Extensive Minimal “ Small r ” “ Big R ”

66. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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. ” Extent of Change to Software MinimalExtensive Change to Org. Processes Extensive Minimal “ Small r ” “ Big R ”

67. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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 processes and best practices from their consultants ’ database of best practices were chosen, forcing a change in the software. Extent of Change to Software MinimalExtensive Change to Org. Processes Extensive Minimal “ Small r ” “ Big R ”

68. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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.

69. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © Extensive Organization and Extensive Software Boeing and BAAN … What was the payoff? As noted by one Boeing consultant (Busse 1998), “ Prior to... (the new system)... people had tunnel vision, now people see up and downstream... ” Extent of Change to Software MinimalExtensive Change to Org. Processes Extensive Minimal “ Small r ” “ Big R ”

70. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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.

71. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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.

72. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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.

73. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © 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?

74. “Enterprise Resource Planning Systems”, D. E. O’Leary, 2000 © Which Quadrant … Which Approach? Depends …which is best for your firm? Highest Probability of 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 IT Changes to Software Extent of Change to Software MinimalExtensive Change to Org. Processes Extensive Minimal