1 / 46

Preparing for ERP

Preparing for ERP. Team creation. Multi-disciplinary Full time Decision making power Budget Representative – team leads Balance between allegiance to team and to area of competence Team spirit Team awareness Must have support from organisation. Team Characteristics.

libitha
Télécharger la présentation

Preparing for ERP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Preparing for ERP

  2. Team creation • Multi-disciplinary • Full time • Decision making power • Budget • Representative – team leads • Balance between allegiance to team and to area of competence • Team spirit • Team awareness • Must have support from organisation

  3. Team Characteristics • Typical size: 25 to 60+ FTE • Team leads: 10 to 20 • Functional area experts • Special roles: • Project manager • Integration manager • Data conversion and migration • Training manager • Hardware / IT specialist • Platform expert • Communication about project (internal & external)

  4. Collecting requirements • Interviews with key individuals • Observation of activities • Consultation of documentation • Surveys • Targets: • Staff • Suppliers • Customers • Other constituencies when needed (eg: vendors…) As-Is + New requirements

  5. Scope arbitration • Time and cost often already decided • Time boxing used to segregate • Trade off with having to do it again next year • Arbitrate between requirements • Out of scope • Conflict between areas • Conflict with proposed project scope • Steering committee (Director level)

  6. Business Integration • Focus on end-to-end process rather than single activity • Cross functional • Multi-competence • Reduced autonomy • Increased communication • Increased reliance on tools • Rationalisation of process? • Benefits do not accrue where the system is most constraining

  7. Workflow Workflow Workflow Workflow Sales management Shop floor control Field services ………….. Inventory planning How it works

  8. Workflow Workflow Workflow Workflow Data Flow Traceability Drill Down Sales management Shop floor control Field services ………….. Inventory planning How it works Independent versus complementary integration One way versus two way integration + see figure 16.4 ERP Module ERP Module

  9. Example of Business Integration • MUTAIR case study • Meals for plane travelers • Before: quality / high value service • Culinary business (chefs in toques) • Dedicated buying • Price not an issue • After: commodity • Drastic price reduction • MRP type scheduling / purchasing

  10. Mutair case study • Process integration: • p/o, receiving, issue, inventory, invoicing, accounts payable & accounts receivable • Bulk buying from agreed suppliers • Tough negotiation on price of RMs • But, rationalisation does not always work • 80% of jobs are OK • Rest cannot be planned (delays, change of schedule, special meals…) • Dysfunctional use of system => dysfunctional ERP

  11. What can go wrong • Integrated systems rely on actors to “play the game” • Need good perception of system • Here, actors impeded by system • Inaccurate data entry • Physical stock VS theoretical stock • Faxed P/Os post-entered / never entered (supplier does not exist) • Ghost deliveries reached the loading bay • Either goods sent back (no stocks) • or invoice cannot be reconciled (payment impossible) • Emergency orders must be entered somehow => wrong codes used • Overall performance of the process decreases • May keep going at local level • But overall vision is totally inaccurate • Might as well have implemented nothing

  12. Where problems originate? • In preparation phase for project • Lack of managerial awareness of risks / opportunities • Lack of understanding of how to select software • Lack of vision of the business impact • Wrong scope (eg: areas pull out and weaken project) • Not enough money for proper analysis • Wrong team (not at the right level / too militant)

  13. Communication • Political / change management dimension • Internal aspects • Expected support (we need you!) • Properly justify project (?) • Explain change in roles • Give assurances (when possible) • External aspects • Be upfront about new rules • Adopt participative approach? • Seek collaboration / leverage other firms’ systems • Perception of system / team

  14. Benefit realisation • Only occurs when definitive targets sought • Only occurs if analysis was realistic and did not neglect downsides • May be more intangible than measurable • Head count • Upfront implementation cost • Length of learning curve • Investment may not be exhausted by current usage (stage 2 / ERP2 etc…) • Whose benefits are those anyway?!?! • Case of the multi-national • Case of a dominant coalition

  15. The ITT – more details • Trade off between detail and speed of processing of information • Cover everything • Sample the functionality • Buy on faith • Available in generic format (see handout) • But always better when tailor made to fit business goals • See notion of fit in previous notes • Also prepare ITT to facilitate analysis • But some vendors will ignore the format

  16. Other methods – Commercial presentations • The armies of darkness…. • Be prepared / ready to question • Vendors: • Will always look good / sound good • Possible to preview software • Unlikely to be caught off guard • Consultants: • Sound also very good • Try to ensure stable participation • Seek experience of very similar project / industry

  17. Site visits • Similar (completed) implementation site • Volunteered by vendor (with prior agreement) • Very realistic • Can talk to actual / current users • Can go down to area specific detail • Can ask about actual support received from vendor • But unlikely to hear a horror story

  18. Comparing tenders • Likely they all look good • Need a rigid set of criteria to decide • Criteria • Type of criterion • Relative weight • Rules for computing overall score • How many would you like to end up with? • Decide on shortlist

  19. Shortlisted firms • On or off site presentation • Intense meeting • Any item unclear in ITT • Any contentious point • User requirements • Price • Support / maintenance contract • Technical characteristics (eg: response time) • Then leave lawyers finish it off • Don’t expect a clear cut answer • Recommend for board level decision

  20. Next steps • Agree on exact schedule • Freeze scope • Schedule participation of all required users / technical staff • Communicate communicate communicate • Run awareness workshops etc… • Negotiate re-skilling arrangements • Ring fence resources and budgets • Prepare for IMPLEMENTATION

  21. Implementation phase • Create fine configuration of package • Define roll out strategy • Schedule implementation in phases • Organise data loads • Go live (s) • Define criteria for ramp up period (duration to full capacity) • Measure progress and report

  22. ERP roll outs • Core team (global) • Local implementation teams • Roll out step: • Initial meeting with local pm • Local team set up • Bringing local team up to speed • Understand implications of template at local level • Create additional workarounds • Define criteria for acceptance / rejection of additional demands

  23. Training • Design training courses and develop material • Schedule training overall • Select and train trainers • Create facilities / sandpit • Book staff for training sessions • Coordinate training • Create assessment mechanism and monitor progress

  24. Data transfers into an application • First time system implementation • Data warehousing projects • Database version upgrade • ERP projects • Move to new version • Called a migration • From a manual system • From old to new system

  25. Data transfers between systems • Static data (eg. Customers) • Dynamic data (eg. sales orders) • Additional problems with a live system • Conversion or interfaces often required

  26. What can go wrong • Data not available • feature activated from implementation onwards • Massive manual data entry (?) • Eg: different account structure • Incomplete data • Some fields are missing • Inconsistent data (eg: engineering vs accounts) • Wrong level of granularity • Data not clean - incorrect • Most new system requires changes due to their different data structure / activity system

  27. Data cleaning must address • Different department record same info under different codes • Multiple records of same company (under different names) • Fields missing in input tables (eg: a/c #) • Different depts. Record different addresses for same customer • Use of different units for time periods

  28. Labour intensive tasks • Data entry • Data validation • Working on solving conflicts • Allocating new codes • Solution = introduce as much automation as possible • SQL • Custom conversion programmes to extract, modify and upload data • Filtering • Parsing (eg: excel) • Staging areas for conversion in progress

  29. Example 1 – the supplier file New supplier code to include city where firm is based Assignation of category based on amounts purchased OLD Sup code Sup name Sup address City Phone 4 digits

  30. Example 1 – the supplier file New supplier code to include city where firm is based Assignation of category based on amounts purchased OLD Sup code Sup name Sup address City Phone 4 digits NEW Sup code Sup name Sup address… Phone Cat 3 letters + 1,2,3 depending 4 digits on total purchases last year

  31. Example 2 – New Cost Accounting Structure Maintenance department expenditure: 1 account => separate accounts for different production activities OLD Intervention code Desc. Date Labour Parts Total

  32. Example 2 – New Cost Accounting Structure Maintenance department expenditure: 1 account => separate accounts for different production activities OLD Intervention code Desc. Date Labour Parts Total NEW Intervention code Desc. Date labour Parts Total Account Will data still be available? Will an archive be maintained?

  33. Example 3: merging files • Complete customer file based on Accounts, Sales and Shipping OLD (finance) CustID name address city account number credit limit balance OLD (sales) CustID* name address city discount rates sales_to_date rep_name OLD (Shipping) CustID** name address city Preferred haulier

  34. Example 4: change of business practices • Payment by bank draft for international customers • Automatic payment into account for national customers • Payment direct into account for all customers

  35. Data Upload • Several rounds: • Trials • Static data • Open items • Dynamic data - transactions • Balances • Staging areas • Local initially • Then central area • Upload into live system • Specific predefined sequence (RDB) • Extract, translate, load • Rental of platform specific tools from vendor

  36. Go live • A single point in time • First transaction routed through system – eg sales order • In reality loads of data already in – incremental approach • Plenty can still wrong although not right away • Over first few weeks – ramp up to full capacity

  37. Post Go Live • Team is disbanded • Back into business • Promoted • Next wave of roll out • Structure is permanently altered – eg: shared services • ERP team put in place • Data experts / maintenance • Application experts – on-going developments and fixes • Platform experts – uptime • Business analysts – look to future releases and future requirements • Typical size 20 /25 staff full time for a multinational • Various names used – eg: knowledge centre

  38. What can happen then • Dysfunctional ERP => uninstall • Next phase in implementation • More modules • More sites • More interfaces to legacy systems • Update to new version • Merger and acquisition => change to other platform

  39. Conclusion: the ERP community Site B Site C Site n… Client - HQ Site A External Parties: Regulatory bodies Auditors Industry Experts ERP Vendors ERP Consultants

  40. Conclusion: managing change Perception of staff Post-implementation Allocation of work Go Live Package bought High Interest And motivation Indifferent Roll out Low Motivation Fear Time Business as Usual – Low morale Increasing Enthusiasm Anxiety Benefits Begin to appear

  41. Conclusion: Critical issues in ERP implementation • Deciding scope of project • HRM and setting up the team (and budget) • difficulty in making a transition from an old model to an ERP model • Preserve previous learning • overestimation of the pace of change of some stakeholders (technical change is not sufficient) • difficulty in obtaining any direct ROI

  42. Conclusion: What happens to competitive advantage?

  43. Conclusion: Working on a stronger rationale • Prove the need for ERP • Davenport’s questions: • How might ERP strengthen out comp. Adv.? • How might it erode …? • What will the ERP’s effect on the org. culture? • Do we need to extend the system across all functions? • Do we need to rollout globally? • Are there any alternatives?

  44. Conclusion: Sales versus Needs

More Related