database - the case of ERP applications


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

database - the case of ERP applications

  1. 1. Databases for large scale integration Focus on ERP projects
  2. 2. Enterprise Wide Applications <ul><li>As the name indicates… </li></ul><ul><li>Keywords: </li></ul><ul><ul><li>Integrated </li></ul></ul><ul><ul><li>Centralised </li></ul></ul><ul><ul><li>Best practice </li></ul></ul><ul><ul><li>Cross functional </li></ul></ul><ul><ul><li>“ mega packages” </li></ul></ul><ul><ul><li>Costly (inc. hidden costs) </li></ul></ul><ul><ul><li>Highly complex </li></ul></ul><ul><ul><li>High impact on business </li></ul></ul>
  3. 3. Definition <ul><li>No simple definition </li></ul><ul><li>American Production and Inventory Control Society (APICS) </li></ul><ul><li>an accounting-oriented information system for identifying and planning the enterprise-wide resources needed to take, make, ship, and account for customer orders </li></ul><ul><li>Transaction-oriented / operational </li></ul>
  4. 4. Family of applications <ul><li>Enterprise Resource Planning systems </li></ul><ul><li>Supply Chain Management </li></ul><ul><li>Customer Relationship Management </li></ul><ul><li>Other more specialised applications such as planning, warehouse management … </li></ul><ul><li>Merging into ERPII / XRP –encompassing all aspects of the business </li></ul>
  5. 5. A Complete Family Tree CRM Early 00’s Sales Force Automation Contract Management Customer Service & Support Marketing Automation Documentation Management SCM Logistics Electronic Invoicing Electronic Marketplaces Contract Management Late 90’s Early 00’s ERP II Product Data Management Engineering Change Orders New Product Introduction Collaborative Product Design
  6. 6. Time frame and key milestones EOQ Safety Stock BOMP Work Orders MRP MRPII ERP ERM / ERPII 1950s 1965 1975 1990 2000 More functions become Integrated in the process to add up to complete business solution
  7. 7. 1950’s: unlimited demand Deliver Customer Make Supplier
  8. 8. 1960’s : inventory costs money! Deliver Customer Make Buy Supplier Plan
  9. 9. 1960’s : inventory costs money Deliver Customer Make Buy Supplier Plan MRP
  10. 10. 1970’s : first wave of integration MRP II Sell Customer Make Buy Supplier Plan MRP Deliver
  11. 11. 1980’s : sales order processing MRP II Sell Customer Make Buy Supplier Plan MRP Deliver SOP
  12. 12. 1990’s : back-office integration MRP II Sell Customer Make Buy Supplier Plan MRP Deliver ERP Accounting & Finance Human Resources
  13. 13. 2000’s : the extended enterprise MRP II Sell Customer Make Buy Supplier Plan MRP Deliver ERP Accounting & Finance Human Resources Service CRM SCM
  14. 14. What’s next? MRP II Sell Customer Make Buy Supplier Plan MRP Deliver ERP Accounting & Finance Human Resources Service CRM SCM Design ERP II
  15. 15. Goals of ERP implementations <ul><li>Standardisation / centralisation </li></ul><ul><li>Control – eg: integration of financial data </li></ul><ul><li>End fragmentation of legacy systems </li></ul><ul><li>More visibility on key processes </li></ul><ul><li>Optimisation / productivity gains </li></ul><ul><li>Competitive advantage? </li></ul><ul><li>Platform for other projects = infrastructure / backbone </li></ul><ul><li>Mechanism for integration of latest technologies (eg: RFID) </li></ul>
  16. 16. Other strong points <ul><li>No more uncoordinated applications – eg quality control </li></ul><ul><li>No more re-keying </li></ul><ul><li>Solution to reporting problems across the board </li></ul><ul><li>“ Sorting out” HR </li></ul><ul><li>Harmonising nomenclatures – eg: product codes, inventory files … </li></ul>
  17. 17. Problems with ERP <ul><li>Impact on business processes (eg: flexibility) </li></ul><ul><li>Understanding the “fit” problem </li></ul><ul><li>Doubtful benefits realisation (50% failure rate?) </li></ul><ul><ul><li>Measurability </li></ul></ul><ul><ul><li>True origin of benefits </li></ul></ul><ul><li>Impact on firm in wider sense </li></ul><ul><ul><li>People </li></ul></ul><ul><ul><li>Clients / suppliers / partners… </li></ul></ul><ul><li>Cost / disruption factor </li></ul><ul><ul><li>$ </li></ul></ul><ul><ul><li>Time </li></ul></ul><ul><ul><li>Learning curve </li></ul></ul><ul><li>Coping with evolution (version control) </li></ul>
  18. 18. <ul><li>Gorry and Scott Morton (1971) </li></ul><ul><li>“ The integrated management information systems ideas so popular in the literature are a poor design concept. More particularly, the integrated or company wide database is a misleading notion and even if it could be achieved, it would be exorbitantly expensive” </li></ul>Gorry A. and Scott Morton. M. (1971) A Framework for Management Information Systems, Sloan Management Review , Fall, 55-70.
  19. 19. <ul><li>Dearden (1972) </li></ul><ul><li>“ The notion that a company can and ought to have an expert (or a group of experts) create for it a single, completely integrated super-system - an MIS - to help it govern every aspect of its activity is absurd” </li></ul>Dearden, A (1972) MIS is a mirage, Harvard Business Review , January / February
  20. 20. Preparing for the implementation <ul><li>Multi-disciplinary </li></ul><ul><li>Full time </li></ul><ul><li>Decision making power </li></ul><ul><li>Budget </li></ul><ul><li>Representative – team leads </li></ul><ul><li>Balance between allegiance to team and to area of competence </li></ul><ul><li>Team spirit </li></ul><ul><li>Team awareness </li></ul><ul><li>Must have support from organisation </li></ul>
  21. 21. Business Integration <ul><li>Focus on end-to-end process rather than single activity </li></ul><ul><ul><li>Cross functional </li></ul></ul><ul><ul><li>Multi-competence </li></ul></ul><ul><li>Reduced autonomy </li></ul><ul><li>Increased communication </li></ul><ul><li>Increased reliance on tools </li></ul><ul><li>Rationalisation of process? </li></ul><ul><li>Benefits do not accrue where the system is most constraining </li></ul>
  22. 22. How it works Inventory Shop floor control Sales management Field services planning ………… .. Workflow Workflow Workflow Workflow
  23. 23. How it works ERP Module ERP Module Independent versus complementary integration One way versus two way integration + see figure 16.4 Traceability Drill Down Data Flow Inventory Shop floor control Sales management Field services planning ………… .. Workflow Workflow Workflow Workflow
  24. 24. Example of Business Integration <ul><li>MUTAIR case study </li></ul><ul><li>Meals for plane travelers </li></ul><ul><li>Before: quality / high value service </li></ul><ul><ul><li>Culinary business (chefs in toques) </li></ul></ul><ul><ul><li>Dedicated buying </li></ul></ul><ul><ul><li>Price not an issue </li></ul></ul><ul><li>After: commodity </li></ul><ul><ul><li>Drastic price reduction </li></ul></ul><ul><ul><li>MRP type scheduling / purchasing </li></ul></ul>
  25. 25. Mutair case study <ul><li>Process integration: </li></ul><ul><ul><li>p/o, receiving, issue, inventory, invoicing, accounts payable & accounts receivable </li></ul></ul><ul><ul><li>Bulk buying from agreed suppliers </li></ul></ul><ul><ul><li>Tough negotiation on price of RMs </li></ul></ul><ul><li>But, rationalisation does not always work </li></ul><ul><ul><li>80% of jobs are OK </li></ul></ul><ul><ul><li>Rest cannot be planned (delays, change of schedule, special meals…) </li></ul></ul><ul><li>Dysfunctional use of system => dysfunctional ERP </li></ul>
  26. 26. What can go wrong <ul><li>Integrated systems rely on actors to “play the game” </li></ul><ul><ul><li>Need good perception of system </li></ul></ul><ul><li>Here, actors impeded by system </li></ul><ul><ul><li>Inaccurate data entry </li></ul></ul><ul><ul><li>Physical stock VS theoretical stock </li></ul></ul><ul><ul><li>Faxed P/Os post-entered / never entered (supplier does not exist) </li></ul></ul><ul><ul><li>Ghost deliveries reached the loading bay </li></ul></ul><ul><ul><li>Either goods sent back (no stocks) </li></ul></ul><ul><ul><li>or invoice cannot be reconciled (payment impossible) </li></ul></ul><ul><ul><li>Emergency orders must be entered somehow => wrong codes used </li></ul></ul><ul><li>Overall performance of the process decreases </li></ul><ul><ul><li>May keep going at local level </li></ul></ul><ul><ul><li>But overall vision is totally inaccurate </li></ul></ul><ul><li>Might as well have implemented nothing </li></ul>
  27. 27. Where problems originate? <ul><li>In preparation phase for project </li></ul><ul><li>Lack of managerial awareness of risks / opportunities </li></ul><ul><li>Lack of understanding of how to select software </li></ul><ul><li>Lack of vision of the business impact </li></ul><ul><li>Wrong scope (eg: areas pull out and weaken project) </li></ul><ul><li>Not enough money for proper analysis </li></ul><ul><li>Wrong team (not at the right level / too militant) </li></ul>
  28. 28. Communication <ul><li>Political / change management dimension </li></ul><ul><li>Internal aspects </li></ul><ul><ul><li>Expected support (we need you!) </li></ul></ul><ul><ul><li>Properly justify project (?) </li></ul></ul><ul><ul><li>Explain change in roles </li></ul></ul><ul><ul><li>Give assurances (when possible) </li></ul></ul><ul><li>External aspects </li></ul><ul><ul><li>Be upfront about new rules </li></ul></ul><ul><ul><li>Adopt participative approach? </li></ul></ul><ul><ul><li>Seek collaboration / leverage other firms’ systems </li></ul></ul><ul><li>Perception of system / team </li></ul>
  29. 29. Benefit realisation <ul><li>Only occurs when definitive targets sought </li></ul><ul><li>Only occurs if analysis was realistic and did not neglect downsides </li></ul><ul><li>May be more intangible than measurable </li></ul><ul><ul><li>Head count </li></ul></ul><ul><ul><li>Upfront implementation cost </li></ul></ul><ul><ul><li>Length of learning curve </li></ul></ul><ul><ul><li>Investment may not be exhausted by current usage (stage 2 / ERP2 etc…) </li></ul></ul><ul><li>Whose benefits are those anyway?!?! </li></ul><ul><ul><li>Case of the multi-national </li></ul></ul><ul><ul><li>Case of a dominant coalition </li></ul></ul>
  30. 30. Team Characteristics <ul><li>Typical size: 25 to 60+ FTE </li></ul><ul><li>Team leads: 10 to 20 </li></ul><ul><li>Functional area experts </li></ul><ul><li>Special roles: </li></ul><ul><ul><li>Project manager </li></ul></ul><ul><ul><li>Integration manager </li></ul></ul><ul><ul><li>Data conversion and migration </li></ul></ul><ul><ul><li>Training manager </li></ul></ul><ul><ul><li>Hardware / IT specialist </li></ul></ul><ul><ul><li>Platform expert </li></ul></ul><ul><ul><li>Communication about project (internal & external) </li></ul></ul>
  31. 31. Collecting requirements <ul><li>Interviews with key individuals </li></ul><ul><li>Observation of activities </li></ul><ul><li>Consultation of documentation </li></ul><ul><li>Surveys </li></ul><ul><li>Targets: </li></ul><ul><ul><li>Staff </li></ul></ul><ul><ul><li>Suppliers </li></ul></ul><ul><ul><li>Customers </li></ul></ul><ul><ul><li>Other constituencies when needed (eg: vendors…) </li></ul></ul>As-Is + New requirements
  32. 32. Overall Scope arbitration <ul><li>Time and cost often already decided </li></ul><ul><li>Time boxing used to segregate </li></ul><ul><li>Trade off with having to do it again next year </li></ul><ul><li>Arbitrate between requirements </li></ul><ul><ul><li>Out of scope </li></ul></ul><ul><ul><li>Conflict between areas </li></ul></ul><ul><ul><li>Conflict with proposed project scope </li></ul></ul><ul><li>Steering committee (Director level) </li></ul>
  33. 33. The ITT <ul><li>Trade off between detail and speed of processing of information </li></ul><ul><ul><li>Cover everything </li></ul></ul><ul><ul><li>Sample the functionality </li></ul></ul><ul><ul><li>Buy on faith </li></ul></ul><ul><li>Available in generic format (see handout) </li></ul><ul><li>But always better when tailor made to fit business goals </li></ul><ul><li>See notion of fit in previous notes </li></ul><ul><li>Also prepare ITT to facilitate analysis </li></ul><ul><li>But some vendors will ignore the format </li></ul>
  34. 34. Comparing tenders <ul><li>Likely they all look good </li></ul><ul><li>Need a rigid set of criteria to decide </li></ul><ul><ul><li>Criteria </li></ul></ul><ul><ul><li>Type of criterion </li></ul></ul><ul><ul><li>Relative weight </li></ul></ul><ul><ul><li>Rules for computing overall score </li></ul></ul><ul><li>How many would you like to end up with? </li></ul><ul><li>Decide on shortlist </li></ul>
  35. 35. Shortlisted firms <ul><li>On or off site presentation </li></ul><ul><li>Intense meeting </li></ul><ul><li>Any item unclear in ITT </li></ul><ul><li>Any contentious point </li></ul><ul><ul><li>User requirements </li></ul></ul><ul><ul><li>Price </li></ul></ul><ul><ul><li>Support / maintenance contract </li></ul></ul><ul><ul><li>Technical characteristics (eg: response time) </li></ul></ul><ul><li>Then leave lawyers finish it off </li></ul><ul><li>Don’t expect a clear cut answer </li></ul><ul><li>Recommend for board level decision </li></ul>
  36. 36. Next steps <ul><li>Agree on exact schedule </li></ul><ul><li>Freeze scope again </li></ul><ul><li>Schedule participation of all required users / technical staff </li></ul><ul><li>Communicate communicate communicate </li></ul><ul><li>Run awareness workshops etc… </li></ul><ul><li>Negotiate re-skilling arrangements </li></ul><ul><li>Ring fence resources and budgets </li></ul><ul><li>Prepare for IMPLEMENTATION </li></ul>
  37. 37. Implementation phase <ul><li>Create fine configuration of package </li></ul><ul><li>Define roll out strategy </li></ul><ul><li>Schedule implementation in phases </li></ul><ul><li>Organise data loads </li></ul><ul><li>Go live (s) </li></ul><ul><li>Define criteria for ramp up period (duration to full capacity) </li></ul><ul><li>Measure progress and report </li></ul>
  38. 38. ERP roll outs <ul><li>Core team (global) </li></ul><ul><li>Local implementation teams </li></ul><ul><li>Roll out step: </li></ul><ul><ul><li>Initial meeting with local pm </li></ul></ul><ul><ul><li>Local team set up </li></ul></ul><ul><ul><li>Bringing local team up to speed </li></ul></ul><ul><ul><li>Understand implications of template at local level </li></ul></ul><ul><ul><li>Create additional workarounds </li></ul></ul><ul><ul><li>Define criteria for acceptance / rejection of additional demands </li></ul></ul>
  39. 39. Also take intangible benefits into account Only changes that pay for themselves within 12 months Duration of payback period (comparison of 2 and 10) 10 – Pay back / Return on Investment In case where total resource usage goes beyond Alliage budget, steering committee may recommend scope enlargement in special cases Project requirements to be checked against accumulated usage of key resources. <ul><li>Number of man days </li></ul><ul><li>IT </li></ul><ul><li>Users </li></ul><ul><li>QC </li></ul>9 – Costs bullet points max Only changes with minimal training requirements Yes / No / Minimal 8 - Training Reference of QMS approuval document required Only properly documented And QMS approuved changes Yes / No / Minimal 7 – Change in SOP trade off to point 4 above Only low risk changes will be considered High / Medium / Low 6 - Risk Impact on Alliage project focuses on the impact on time of delivery of deliverables Only changes without overall impact on the project will be considered Yes / No 5 - Impact on project Only unambiguous Yes will be considered Yes / No / Maybe 4 - Support Project Business objectives Except for “must have” additions ** Only standard functionality will be considered Yes / No 3 - SAP standard functionality Full justification for perceived saving must be presented See point 9 below Number of transactions * time saved per time interval 2a – Savings Quantified Difficulty in ensuring consistent reporting of impact Only high impact changes will be considered High / Medium / Low 2 - Impact on Business Global changes are implemented at local level primarily Only global changes will be considered Global / Local 1 - Scope Comment Decision Input values Factor
  40. 40. Training <ul><ul><li>Design training courses and develop material </li></ul></ul><ul><ul><li>Schedule training overall </li></ul></ul><ul><ul><li>Select and train trainers </li></ul></ul><ul><ul><li>Create facilities / sandpit </li></ul></ul><ul><ul><li>Book staff for training sessions </li></ul></ul><ul><ul><li>Coordinate training </li></ul></ul><ul><ul><li>Create assessment mechanism and monitor progress </li></ul></ul>
  41. 41. Data transfers into an application <ul><li>First time system implementation </li></ul><ul><li>Data warehousing projects </li></ul><ul><li>Database version upgrade </li></ul><ul><li>ERP projects </li></ul><ul><li>Move to new version </li></ul><ul><li>Called a migration </li></ul><ul><ul><li>From a manual system </li></ul></ul><ul><ul><li>From old to new system </li></ul></ul>
  42. 42. Data transfers between systems <ul><li>Static data (eg. Customers) </li></ul><ul><li>Dynamic data (eg. sales orders) </li></ul><ul><ul><li>Additional problems with a live system </li></ul></ul><ul><li>Open items </li></ul><ul><li>Balances </li></ul><ul><li>Conversion or interfaces often required </li></ul>
  43. 43. Data Upload <ul><li>Several rounds: </li></ul><ul><ul><li>Trials </li></ul></ul><ul><ul><li>Static data </li></ul></ul><ul><ul><li>Open items </li></ul></ul><ul><ul><li>Dynamic data - transactions </li></ul></ul><ul><ul><li>Balances </li></ul></ul><ul><li>Staging areas </li></ul><ul><ul><li>Local initially </li></ul></ul><ul><ul><li>Then central area </li></ul></ul><ul><li>Upload into live system </li></ul><ul><ul><li>Specific predefined sequence (RDB) </li></ul></ul><ul><ul><li>Extract, translate, load </li></ul></ul><ul><ul><li>Rental of platform specific tools from vendor </li></ul></ul>
  44. 44. Go live <ul><li>A single point in time </li></ul><ul><li>First transaction routed through system – eg sales order </li></ul><ul><li>In reality loads of data already in – incremental approach </li></ul><ul><li>Plenty can still wrong although not right away </li></ul><ul><li>Over first few weeks – ramp up to full capacity </li></ul>
  45. 45. Post Go Live <ul><li>Team is disbanded </li></ul><ul><ul><li>Back into business </li></ul></ul><ul><ul><li>Promoted </li></ul></ul><ul><ul><li>Next wave of roll out </li></ul></ul><ul><li>Structure is permanently altered – eg: shared services </li></ul><ul><li>ERP team put in place </li></ul><ul><ul><li>Data experts / maintenance </li></ul></ul><ul><ul><li>Application experts – on-going developments and fixes </li></ul></ul><ul><ul><li>Platform experts – uptime </li></ul></ul><ul><ul><li>Business analysts – look to future releases and future requirements </li></ul></ul><ul><ul><li>Typical size 20 /25 staff full time for a multinational </li></ul></ul><ul><ul><li>Various names used – eg: knowledge centre </li></ul></ul>
  46. 46. The story continues <ul><li>Dysfunctional ERP => uninstall </li></ul><ul><li>Next phase in implementation </li></ul><ul><ul><li>More modules </li></ul></ul><ul><ul><li>More sites </li></ul></ul><ul><ul><li>More interfaces to legacy systems </li></ul></ul><ul><li>Update to new version </li></ul><ul><li>Merger and acquisition => change to other platform </li></ul>