L12 Erp Life Cycle

2,485 views

Published on

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,485
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
196
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

L12 Erp Life Cycle

  1. 1. ERP Life Cycle
  2. 2. ERP Life Cycle <ul><li>Technology Enabled or Clean State Reengineering </li></ul><ul><li>Deciding to go ERP </li></ul><ul><li>Choosing an ERP </li></ul><ul><li>Designing an ERP </li></ul><ul><li>Implementing ERP Systems </li></ul><ul><li>After Going Live (Stabilization Period) </li></ul><ul><li>ERP Risks : Success and Failure Factors </li></ul>
  3. 3. Technology Enabled vs. Clean State Reengineering
  4. 4. Technology Enabled Reengineering <ul><li>A particular technology (or portfolio of technologies) is chosen as a tool to facilitate reengineering. </li></ul><ul><ul><li>Thus, reengineering choices are a function of the technologies chosen. </li></ul></ul><ul><ul><li>The technology drives the reengineering. </li></ul></ul>
  5. 5. Clean State Reengineering <ul><li>Process design starts with a clean state </li></ul><ul><li>Also referred to as “starting from scratch” </li></ul><ul><li>Theoretically, no limits </li></ul>
  6. 6. Somewhere Between the Two <ul><li>In actuality, there are few projects that are “purely” clean slate or technology enabled </li></ul><ul><li>More of a spectrum </li></ul>Technology Enabled Clean Slate Most Firms
  7. 7. Advantages of Technology Enabled <ul><li>ERP provides a tool to facilitate change </li></ul><ul><li>ERP helps structure complex reengineering efforts </li></ul><ul><li>Tools help explain and rationalize efforts </li></ul><ul><li>ERP bounds the design, limiting overload </li></ul><ul><li>Design is feasible </li></ul><ul><li>There is Evidence that the design will work </li></ul><ul><li>Designs likely are cost effective </li></ul><ul><li>Designs likely can be implemented in a timely manner </li></ul><ul><li>There is software available </li></ul>
  8. 8. Advantages of Clean State <ul><li>Not constrained by a particular tool </li></ul><ul><li>Not constrained to a limited set of processes </li></ul><ul><li>Evolution is not limited by a particular technology </li></ul><ul><li>Can develop a design that others cannot access </li></ul><ul><li>There is evidence that firms think they should reengineer and then implement </li></ul><ul><li>May be the only option </li></ul>
  9. 9. Which Firm Should Use Which Approach? <ul><li>Depends on </li></ul><ul><li>Firms Size </li></ul><ul><li>Available Resources </li></ul><ul><li>Time Pressure </li></ul><ul><li>Strategic Gain </li></ul><ul><li>Uniqueness of solution </li></ul>
  10. 10. Deciding to Go ERP
  11. 11. Business Case Rationales <ul><li>Business case rationales typically fall into four categories (only remember process) </li></ul><ul><ul><li>Technology- separate diff. business units </li></ul></ul><ul><ul><li>Business Process- </li></ul></ul><ul><ul><li>Strategic </li></ul></ul><ul><ul><li>Competitive </li></ul></ul>
  12. 12. Technology Rationales: Disparate Systems <ul><li>Disparate systems limit the ability of firms to integrate different business units. </li></ul><ul><li>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 .... </li></ul>
  13. 13. Business Process Rationales <ul><li>Designed to aim at specific improvements in efficiencies or cost savings or revenue enhancements. </li></ul><ul><li>Typically include a specific number </li></ul><ul><ul><li>For example, “decrease inventory by 40%” </li></ul></ul>
  14. 14. Business Process Rationales: Productivity Improvements <ul><li>“ 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.” </li></ul><ul><ul><ul><li>A one percentage point cost reduction deriving from global economies of scale in raw material purchases </li></ul></ul></ul><ul><ul><ul><li>A one percentage point cost reduction deriving from fewer warehouses and lower freight cost </li></ul></ul></ul><ul><ul><ul><li>Improvement in reliability-oriented maintenance generating lower plant maintenance costs </li></ul></ul></ul>
  15. 15. Strategic Rationale <ul><li>Choose ERP to implement a specific strategy </li></ul><ul><ul><li>As part of an E-business strategy, a firm could implement an ERP system </li></ul></ul><ul><ul><li>As part of a strategy to focus on the consumer, a firm could implement “Available to Promise” (ATP) </li></ul></ul>
  16. 16. Competitive Rationale <ul><li>“ A lot of ERP purchases are premised on the need to just stay in business.” </li></ul><ul><li>The competition has it can take two approaches </li></ul><ul><ul><li>Implement because the competition has it </li></ul></ul><ul><ul><li>Focus on why the competition has it and see if it fits your company and what benefits can be gathered </li></ul></ul>
  17. 17. Choosing an ERP System
  18. 18. Two Basic Approaches <ul><li>There are two basic approaches that are used as bases of choosing ERP software </li></ul><ul><ul><li>Requirements Analysis (“As Is”) </li></ul></ul><ul><ul><li>Best Practices Analysis (“To Be”) </li></ul></ul>
  19. 19. Requirements Analysis (“As Is”) <ul><li>“ As Is” the ways things are. </li></ul><ul><li>Organization determines what their processes and artifacts currently are and use that “as is” model to establish requirements that software is judged against. </li></ul><ul><li>Typically, the software that best meets the requirements is the one chosen by the firm </li></ul>
  20. 20. “ To Be” Analysis <ul><li>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 </li></ul><ul><li>Focuses, not on where the organization is, but where it wants to be. </li></ul><ul><li>Search often includes Big 5 best practices, and ERP best practice capabilities </li></ul>
  21. 21. Emerging Approach <ul><li>Increasingly, consultants are promulgating the approach where no “as is” model is developed, no gap model is developed … </li></ul><ul><li>Go straight to the “ to be ” model, since that is what really counts </li></ul><ul><li>Typically, with this approach the consultant knows both your organization and the software </li></ul>
  22. 22. Designing ERP Systems
  23. 23. Minimal Organization and Software Change (try to explain with help of below dia.) <ul><li>Small r reengineering offers fast and cheaper implementation </li></ul><ul><li>However, with small r, you miss the chance to be a champion </li></ul>Extent of Change to Software Minimal Extensive Change to Org. Processes Extensive Minimal “ Small r” “ Big R”
  24. 24. Extensive Organizational and Minimal Software <ul><li>“ 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.” </li></ul>Extent of Change to Software Minimal Extensive Change to Org. Processes Extensive Minimal “ Small r” “ Big R”
  25. 25. Minimal Organizational and Extensive Software <ul><li>A project manager at Nestles indicated that their choice of processes for their SAP implementations included best practices beyond those included in the software. </li></ul><ul><ul><li>Some of their existing processes </li></ul></ul><ul><ul><li>and best practices from their consultants’ </li></ul></ul><ul><ul><li>database of best practices </li></ul></ul><ul><ul><li>were chosen, forcing a </li></ul></ul><ul><ul><li>change in the software . </li></ul></ul>Extent of Change to Software Minimal Extensive Change to Org. Processes Extensive Minimal “ Small r” “ Big R”
  26. 26. Disadvantages <ul><li>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. ... </li></ul><ul><li>Customization to different divisional requirements also can make it difficult to implement the software in other divisions. </li></ul>
  27. 27. Extensive Organization and Extensive Software <ul><li>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 </li></ul><ul><li>Disadvantages: Changing software is expensive and inhibits ability to get to next version. Adopters are likely large firms with market power. </li></ul>
  28. 28. Which Quadrant … Which Approach? <ul><li>Depends …which is best for your firm? </li></ul>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 Minimal Extensive Change to Org. Processes Extensive Minimal
  29. 29. Designing ERP Systems M A Ps
  30. 30. <ul><li>Models </li></ul><ul><ul><li>Organization models (e.g., B2C, B2B, Auctions, Centralized, Decentralized…) </li></ul></ul><ul><li>Artifacts </li></ul><ul><ul><li>(e.g., Charts of accounts and Vendor numbering schemes…) </li></ul></ul><ul><li>Processes </li></ul><ul><ul><li>(Sales order, Customer management, Procurement…) </li></ul></ul>What are MAPs?
  31. 31. Why are MAPs important? <ul><li>The quality of the MAPs will have a huge impact on the overall success of the ERP implementation. </li></ul><ul><ul><li>MAPs that are not efficient or effective for a particular firm can drag down the overall performance of that firm. </li></ul></ul><ul><ul><li>Similarly, MAPs that meet the needs of a firm can push it to better performance, giving it a competitive edge. </li></ul></ul>
  32. 32. Where do MAPs come from? <ul><li>Nestles’ decided that it would implement common MAPs in all three of its United States divisions. </li></ul><ul><li>Each of the three division’s existing MAPs became candidates, that would be evaluated. </li></ul><ul><li>Both SAP and the advising consultant’s best practices databases were used to generate candidates MAPs. </li></ul><ul><li>In some cases, hybrid MAPs were developed, based on multiple sources of information. </li></ul><ul><li>A multifunctional team used both sets of inputs to decide on company standard artifacts and business processes. </li></ul>
  33. 33. ERP Implementation: Big Bang vs. Phased
  34. 34. Big Bang <ul><li>In a full big bang, an entire suite of ERP applications is implemented in all locations in a matter of days. </li></ul><ul><ul><li>Big Bang employs a three step process. </li></ul></ul><ul><ul><ul><li>Virtually all processes and artifacts are chosen and implemented in the software (e.g., 8 months) </li></ul></ul></ul><ul><ul><ul><li>System is tested by process and then by interfaces between processes (e.g., 8 months) </li></ul></ul></ul><ul><ul><ul><li>Old system is turned off. New system is then implemented and minor changes made. </li></ul></ul></ul>
  35. 35. Phased <ul><li>At the extreme, modules are implemented one at a time, possibly one location at a time </li></ul><ul><ul><li>For example, one implementation did the following: </li></ul></ul><ul><ul><ul><li>Phase 1 - Finance, controlling, accounts receivable, accounts payable, and purchasing (12 months) </li></ul></ul></ul><ul><ul><ul><li>Phase 2 - Materials management, production planning and quality planning (7 months) </li></ul></ul></ul><ul><ul><ul><li>Phase 3 - Remainder (5 months) </li></ul></ul></ul><ul><ul><li>Using a phased approach, the new system is implemented in a structure of legacy systems . </li></ul></ul>
  36. 36. When should you use Big Bang? <ul><li>When you have top management’s support </li></ul><ul><li>When there are sufficient peak resources available. </li></ul><ul><li>When there is limited time to implement the system. </li></ul>
  37. 37. When should you use Phased? <ul><li>When you need to generate support from top management </li></ul><ul><li>When there are insufficient peak resources </li></ul><ul><li>When the risk of Big Bang is too high </li></ul><ul><li>When there is plenty of time </li></ul>
  38. 38. Small Large Organization Complexity Complex Simple Big Bang Phased Linkages Between Organization Size and Complexity and Implementation Approach Organization Size
  39. 39. Extent of Controls Loose Tight Organization Structure Tall Flat Big Bang Phased Linkages Between Organization Hierarchy and Control, and Implementation Approach
  40. 40. Extent of Change To Be Made To ERP Modules Minimal Extensive Number of Modules in the Implementation Many Few Linkages Between Implementation Approach and ERP Modules Big Bang Phased
  41. 41. Alternative Implementation Issues (only names) <ul><li>Waved Approach </li></ul><ul><li>Aggressive Implementation </li></ul><ul><li>Running in Parallel </li></ul><ul><li>Many “big bangs” </li></ul>
  42. 42. Waved Approach <ul><li>Each “wave” delivers functionality to a different business unit or geographical area </li></ul><ul><li>Example: </li></ul><ul><ul><li>Year One - implement G/L </li></ul></ul><ul><ul><li>Year Two - Convert A/R and cost management </li></ul></ul>
  43. 43. Waved Approach <ul><li>Advantages of Waves </li></ul><ul><ul><li>Waves provide feedback as to how the implementation is proceeding </li></ul></ul><ul><ul><li>Employees learn in the beginning of the wave and leverage that learning </li></ul></ul><ul><ul><li>Each successful wave keeps momentum going </li></ul></ul><ul><ul><li>Waves are flexible. If new releases occur then they can be embedded in the waves </li></ul></ul>
  44. 44. Aggressive Implementation <ul><li>Not big bang, but more aggressive than phased </li></ul><ul><li>Temporary links really are temporary. </li></ul><ul><li>Aggressive plans are made to release legacy system </li></ul>
  45. 45. Run in Parallel <ul><li>If the legacy system is allowed to run at the same time as the new system then the two systems can run in parallel. </li></ul><ul><li>There are some advantages and disadvantages of this approach </li></ul><ul><ul><li>Advantages: can go back, can check results </li></ul></ul><ul><ul><li>Disadvantages: costly, may inhibit new system </li></ul></ul>
  46. 46. Multiple Big Bangs <ul><li>Increasingly, firms are beginning to say that they are doing a big bang implementation, in phases. </li></ul><ul><li>This is a break from the classic big bang and phases, basically ‘big banging’ around the world, from one division to another. </li></ul>
  47. 47. Post-Implementation
  48. 48. The Stabilization Period <ul><li>Lasts from 3 to 9 months </li></ul><ul><li>“ Most companies should expect some dip in performance at the time they go live and should expect that they’ll need to manage through that dip.” </li></ul><ul><li>Why? </li></ul><ul><ul><li>New software and processes for users </li></ul></ul><ul><ul><li>System ‘bugs’ </li></ul></ul><ul><ul><li>Technical issues… </li></ul></ul>
  49. 49. Post-Support from ERP Team <ul><li>Detecting and responding to system bugs </li></ul><ul><li>Answering user questions </li></ul><ul><li>Changing system parameters </li></ul><ul><li>Responding to changing reporting needs </li></ul><ul><li>Upgrading the software/hardware </li></ul>
  50. 50. Evaluate Success <ul><li>Timing </li></ul><ul><ul><li>When benefits could be realized and measured </li></ul></ul><ul><ul><li>During the 1 st or 2 nd year AFTER going live </li></ul></ul><ul><li>Determining if the system meets the criteria set out for it in the beginning (choice rationale) </li></ul><ul><li>Independent measures or a weighted portfolio of measures? </li></ul>
  51. 51. Balance Scorecard Financial Customer Learning & Growth Internal Business Processes
  52. 52. Post-Implementation Budget <ul><li>There must be a budget and corresponding plan to support the complete project. </li></ul><ul><li>Complete project management means managing through the entire project life cycle. </li></ul>
  53. 53. ERP Risk
  54. 54. Types of Risk <ul><li>Risk occurs throughout the ERP life cycle </li></ul><ul><ul><li>Types of risk and extent of their impact vary as we move through the ERP life cycle </li></ul></ul><ul><li>Three basic types of risk </li></ul><ul><ul><li>Technical </li></ul></ul><ul><ul><li>Business </li></ul></ul><ul><ul><li>Organizational </li></ul></ul>
  55. 55. Risk Definitions <ul><ul><li>Technical risk - risks arising due to information processing technology, sensor technology, and telecommunication technology </li></ul></ul><ul><ul><li>Business risk - risks deriving from models, artifacts and processes adopted as part of ERP </li></ul></ul><ul><ul><ul><li>Do they match? Are they consistent? Do partners processes match up? </li></ul></ul></ul><ul><ul><li>Organizational risk - risks deriving from the environment in which the system is placed - including personnel and organization structure </li></ul></ul>
  56. 56. Technical Business Organizational Deciding to go ERP Choosing an ERP System Designing Implementing After Going Live Training Risk Matrix
  57. 57. Technical Risks and ERP Life Cycle <ul><li>Deciding to go ERP </li></ul><ul><ul><li>Firms that have kept up with technology are likely to better understand the risks associated with ERP systems. </li></ul></ul><ul><ul><li>Try to see what has worked in the past </li></ul></ul>Technical Business Organizational Deciding Choosing Designing Implementing Going Live Training
  58. 58. Technical Risks and ERP Life Cycle <ul><li>Choosing an ERP system </li></ul><ul><ul><li>Virtually all software choice can be manipulated, since it is a political process </li></ul></ul><ul><ul><li>Requirements change as new technology becomes available. </li></ul></ul>Technical Business Organizational Deciding Choosing Designing Implementing Going Live Training
  59. 59. Technical Risks and ERP Life Cycle <ul><li>Designing </li></ul><ul><ul><li>One company designed an ERP contract, based on computing capacity, so the vendor had to fix any problems with insufficient capacity </li></ul></ul>Technical Business Organizational Deciding Choosing Designing Implementing Going Live Training
  60. 60. Technical Risks and ERP Life Cycle <ul><li>Implementing and Going-Live </li></ul><ul><ul><li>Upon implementation and going-live, capacity … six transactions a minute … 360 per hour … or 3600 for a ten hour day … was not enough </li></ul></ul><ul><ul><li>Needed more network capacity </li></ul></ul>Technical Business Organizational Deciding Choosing Designing Implementing Going Live Training
  61. 61. Technical Risks and ERP Life Cycle <ul><li>Training </li></ul><ul><ul><li>Risk that mainframe IS personnel, might have to be re-tooled to client-server technology </li></ul></ul><ul><ul><li>ERP system may require different technical people with different skills </li></ul></ul>Technical Business Organizational Deciding Choosing Designing Implementing Going Live Training
  62. 62. Business Risks <ul><li>Deciding whether or not to do ERP </li></ul><ul><ul><li>Must have the resources to do the project </li></ul></ul><ul><ul><ul><li>Firms get going on ERP and then find that they don’t have the resources. </li></ul></ul></ul><ul><ul><ul><li>This typically means that either the organization fails or the project fails. </li></ul></ul></ul><ul><ul><li>Must meet needs of the business </li></ul></ul><ul><ul><ul><li>What is needed by the firm’s partners? </li></ul></ul></ul>Technical Business Organizational Deciding Choosing Designing Implementing Going Live Training
  63. 63. Business Risks <ul><li>Choosing an ERP System </li></ul><ul><ul><li>Determine specific requirements, e.g., transaction handling capabilities </li></ul></ul><ul><ul><ul><li>Fox Meyer - system could do 10,000 invoice lines, but they needed 420,000 </li></ul></ul></ul><ul><ul><li>The business risk is that the ERP Vendor can not meet the company’s needs </li></ul></ul>Technical Business Organizational Deciding Choosing Designing Implementing Going Live Training
  64. 64. Business Risks <ul><li>ERP Design </li></ul><ul><ul><li>Design is a political process. As a result, there is a risk that the design is sub-optimal. </li></ul></ul><ul><ul><li>There is also the risk that processes designed by one group in the organization will not interface well with processes designed by other groups. </li></ul></ul><ul><ul><li>There is the risk of project stopping </li></ul></ul><ul><ul><ul><li>This project would have changed how people work and reduced staffing by half. It was the easiest thing to cut because people did not have the stomach for it </li></ul></ul></ul>Technical Business Organizational Deciding Choosing Designing Implementing Going Live Training
  65. 65. Business Risks <ul><li>Implementing </li></ul><ul><ul><li>The project will take longer than expected </li></ul></ul><ul><ul><li>The project will cost more than expected </li></ul></ul>Technical Business Organizational Deciding Choosing Designing Implementing Going Live Training
  66. 66. Business Risks <ul><li>Going Live </li></ul><ul><ul><li>If the ERP is not working properly, there could be problems with customers and suppliers. </li></ul></ul><ul><ul><li>Hershey Foods Inc. lost most of their Halloween, Thanksgiving and Christmas sales due to a poorly functioning ERP system. </li></ul></ul>Technical Business Organizational Deciding Choosing Designing Implementing Going Live Training
  67. 67. Business Risks <ul><li>Training </li></ul><ul><ul><li>Training should provide users with process and system information </li></ul></ul><ul><ul><li>The main business risk is that timing is too short and too late. </li></ul></ul>Technical Business Organizational Deciding Choosing Designing Implementing Going Live Training
  68. 68. Organizational Risks <ul><li>Deciding whether or not to do ERP </li></ul><ul><ul><li>Reportedly, one of the biggest risks is that top management is not involved. </li></ul></ul><ul><ul><li>Another risk is that the domain areas are not involved and committed (Microsoft) </li></ul></ul>Technical Business Organizational Deciding Choosing Designing Implementing Going Live Training
  69. 69. Organizational Risks <ul><li>Choosing an ERP System </li></ul><ul><ul><li>Choosing the right consultant is the biggest challenge (Risk) </li></ul></ul>Technical Business Organizational Deciding Choosing Designing Implementing Going Live Training
  70. 70. Organizational Risks <ul><li>ERP Design and Implementation </li></ul><ul><ul><li>Models of organizations are built into the software, as a result, there are risks that the models do not match (e.g., Microsoft) </li></ul></ul>Technical Business Organizational Deciding Choosing Designing Implementing Going Live Training
  71. 71. Organizational Risks <ul><li>Going Live </li></ul><ul><ul><li>Cultural issues that relate to “big R” reengineering create organizational risk. </li></ul></ul><ul><ul><ul><li>One firm went from compensation based on number of units sold to salary to accommodate the ERP system </li></ul></ul></ul>Technical Business Organizational Deciding Choosing Designing Implementing Going Live Training
  72. 72. Organizational Risks <ul><li>Training </li></ul><ul><ul><li>Employees not accustomed to data input will take on the task. </li></ul></ul><ul><ul><li>If users don’t know how to use the system, it will fail. </li></ul></ul><ul><ul><li>There may be inadequately trained personnel after implementation due to poor training or attrition. </li></ul></ul>Technical Business Organizational Deciding Choosing Designing Implementing Going Live Training

×