Strategies for Selecting and Transitioning to a new Enterprise Resource Planning System DAN KOCER, PE

Transcription

1 Strategies for Selecting and Transitioning to a new Enterprise Resource Planning System DAN KOCER, PE KOCER CONSULTING + ENGINEERING

2 Introductions Kocer Consulting + Engineering We help you improve profits by designing, improving and launching streamlined manufacturing, distribution and supply chain operations and systems. Strong ERP and WMS knowledge along with warehouse, material handling, and facility layout expertise. Organized and thorough Project Managers to expand your bandwidth for getting things done. SOP s and training. In business for 16 years. Helped over 200 distribution and supply chain companies. Long-term relationships with our customers and their employees. Management experience with supply chain and engineering roots. We take a broad view to problem solving: Operations, Systems, Financials, Facilities, Equipment and People. 2

3 3

4 4

5 5

6 Common Reasons for Replacing Your ERP? Reached the maximum number of users. Customer is asking for information that your current system can not provide. New complexities in the business model outsourcing, traceability, multiple sites. Improved Efficiencies Eliminate administrative steps. Inventory Accuracy. Order Accuracy. Real Time Visibility for Inventory, Orders, Shipments. 6

7 Selection Process N Management authorizes project Define and diagram current state (flow) Define future requirements and diagram to be state Team review and buy-in? Y Generate requirements Requirements Document Determine long list of possible solutions Evaluate and develop short list Create RFI based on requirements and send to short list Review responses for fit to requirements Narrow short list to 2 finalists: - interviews -references -plan & budget Demonstration and selection with client Refine: -SOW -Contract -Detailed plan -ROI Staff availability and business timing Contract signed Vendor engaged 7

8 Driven by Business Objectives Define the Business Objectives to be supported by the ERP System Define Your Current Operations and transactions Determine the Gaps that Need to be filled 8

9 Define the Future State Functional Requirements 9

10 Process Mapping the Flow of Business As Is and To Be in Swim Lanes 10

11 The Decision Ladder $ New ERP System Third Party Bolt-Ons (WMS, CRM, MRP) Purchase Additional Modules Configure Existing System Schedule 11

12 Key Strategy: Minimize Modifications Coders May Not Fully Understand the Complexities of ERP. Problems with Standard Upgrades and Updates. Problems with adding new modules as you grow. Risk of losing the custom code description and knowledge. Keeping it standard allows more flexibility to bring in other experts. Need to keep pace with changing business regulations and laws. 12

13 Hundreds of Choices 13

14 The Selection Strategy Define the Unique or Uncommon Requirements o Industry Focus o Business Model Focus o Unique Operations Research and provide the long list of Candidates for Software/Implementation Teams RFI the Request for Information Short List Interviews and References Final 2 On-Site Demos Collaborative Evaluation and Selection 14

15 Define the Unique or Uncommon Requirements Example: Uncommon business needs Combination of source lot tracking and company lot tracking Additional lot attributes that change with time Changing unit-of-measure Tracking inventory by salesperson Sending work out for coating Bookings and blanket PO s Fabrication Spare parts Intercompany Transactions between Mex and US Pricing updates Bonus calculations 15

16 Model Examples: Research and provide the Long List The Epicor Model Epicor provides the implementation team and the Software The Microsoft Dynamics Model - Microsoft provides software only Configured and Installed by a value-add Resource (VAR) Each VAR is unique with different industry knowledge and skills 16

17 COST Ranges of Systems $200 K SoloGlobe $150 K Kare Visual Warehouse $100 K Accellos / HighJump Appolis ~ PanaTrack FUNCTIONALITY VENDOR COMPARISON 17

18 RFI Evaluation to Get to the Short List Ability to meet requirements Responsiveness and ability to provide the work when needed Within Budget range Expertise and Experience in the Customer s Industry Expertise and Experience with similar business models Company Stability Depth of Bench Ongoing Support and Responsiveness Software Life Cycle Status: Flagship or Sunset? 18

19 RFI Evaluation (Example) 19

20 Vendor Selection Criteria (Example) 1. Have Agricultural Segment business experience to help company knowledgeably streamline their business process, and to talk the same language. 2. Demonstrate a high degree of competency with Navision (NAV). 3. Be experienced with distribution of living organisms or plant materials. 4. A hands-on company who would work directly with company personnel and relate directly with them, not just as a technical implementer. 5. Use Native NAV to its fullest capability, and avoid custom modifications where native NAV will suffice. Avoid unproven custom software modifications. 6. Give good advice as to best practices used in other agricultural companies to help company optimize their own processes. 7. Have a robust implementation process and plan so that nothing is overlooked, critical milestones are defined and met, and necessary processes are engaged and completed minimizing risk and expense. 20

21 Selection of the Final Two Interviews of the Assigned PM References from Similar Customers Terms of Agreement Budget Schedule On-Line Demonstrations Collaborative Evaluation 21

22 Final Selection Site Visits Demos Have vendor/var show how they accomplish tasks important to you List topics ahead of time for them to cover Use a subset of your company data to add relevance for the audience Consider needs today and down the road Don t want a sunset system! Is system well established? Are they investing in the future? Cost is only one piece: Maintenance, Platform, Ease of Use, Reports Collaborative Selection Keep two options until the contract is signed 22

23 Key Factors in the ERP System Agreement Buy performance and not just Software Functional Requirements License Agreements Any promises made during the sales round Refined Budget Payment Milestones Improved Schedule Project Manager Maintenance Agreement Hardware Requirements Scope of Work that will be provided Acceptance Criteria 23

24 Revisit Business Objectives Comprehensive Turnkey Budget Expected Savings/Benefits Ensure Everyone is On Board Project Approval 24

25 Key Considerations and Decisions Internal Project Resources Internal Sponsor Project Manager representing the Customer Business timing Software VAR workload and availability 25

26 Strategies for Managing the Implementation Team Structure, Roles and Responsibilities Project Management, Communication and Progress Tracking Collaboration and Teamwork Hardware Decisions Configuration Acceptance Testing Training Go-No Go Criteria Fall-back plan and risk mitigation Transition Plan 26

27 Team Structure, Roles and Responsibilities Executive Project Sponsor Steering Committee Project Manager Impacted Managers Ops management Systems Management Site and Facilities Management Consulting Resources Software Providers Systems Consultants Engineers Hardware Suppliers Project Team Representatives from each Functional Area 27

28 Project Management, Communication and Progress Tracking Project Management, Communication and Progress Tracking Budget Tracking Schedule Tracking Action Item List Steering Committee Updates Project Status Meetings Status Reports Issue Lists Ground Rules for Communication and Sharing Information 28

29 Schedule (Example) Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec PHASE I Statement of Work Kick Off Setup Cleanup Development Scenario Building Training - Core Team Testing Report Development SOPs Written End User Training Go-Live Prep Go-Live Post Go-Live Support PHASE II Development Testing SOPs Written Training 29

30 Action Item List (Example) 30

31 Status Report (Example) 31

32 Issue List (Example) 32

33 Ground Rules (Example) Ground Rules Participation 1) Everyone needs to be responsible for completing their assigned tasks on time 2) Own your work 3) Not every person will be able to attend all meetings and participate in every activity the project will still move along 33

34 Communications Rules (Example) Communications Written is always better is the best Use Tasks in SharePoint and always assign them to an individual Tell people if things are changing when in doubt, tell everybody Sharing SharePoint will be the single point of truth, so make sure you update documents there Prevent confusion by doing things the same way Dates: use YYYYMMDD format Docs: use NAME DATE. XXX Try to use the same terms you have special names for things, we need to focus on the NAV names Make sure you understand your internal suppliers and internal customers their processes and their deliverables to you 34

35 Collaboration and Teamwork Team Buy-In at Each Milestone User Group Participation Welcome and Incorporate Feedback 35

36 Hardware and Hosting Decisions On Premise Hosting, Cloud, and Software-As-A-Service o It comes down to the company capabilities and infrastructure o How many sites you have o Expertise of staff o Current IT infrastructure (network, servers, communications) o Restrictions (ITAR or other regulations for example) Licensing of software o Subscription Agreement o Traditional Upfront License purchase agreement 36

37 Configuration Decisions Reflects your company s future state Sites Organization Keep it flexible The perils of smart numbering Set it up so the system can do the work Make it easy to get it right with workflow Scrub and Test Move your data! 37

38 Acceptance Testing No Surprises No Surprises for the Vendor on what is required No Surprises during Go-Live for the Customer Separate Test Environment Real Data Types of tests Unit Testing Exception Testing Volume Testing System for capturing issues, ranking importance, and tracking resolution 38

39 Test Script (Example) 39

40 Training Strategies Train the Trainer Super Users Separate training environment Develop Standard Operating Procedures (SOP s) prior to training even if they are changing Cheat Sheets Hands on Real Data 40

41 Strategies for Go-Live Don t try to fix the bicycle while you are riding it Go-No Go criteria written in advance Fall-back plan and risk mitigation Transition Plan Manufacturing schedules Inventory and vendor notifications Roles and responsibilities for day of go-live Customer notifications Added support and resources during the transition period Avoid the hero tendency it s sometimes more heroic to say We are not ready yet. 41

42 The Go / No-Go Decision: System Go-Live Readiness Checklist Criteria for the Go/No-Go Decision Description Criteria Complete System The new Live database is on its Go-Live hardware It has been performance (stress) tested and accepted on that hardware Work Around Complete by Go-Live Acceptable Not Acceptable Users have tested all devices (desktops, laptops, barcode readers, etc.) that will be used with the new system They all connect without a problem Verified you can lock users out of the current live database to not make transactions, yet let them still see information for research Users cannot transact but can review information within their security parameters Remote access is available and tested for those who need it Process works At least one complete test conversion has been done and executed within the allotted cut-over time All code and releases have been applied, tested, and work Done successfully within a time-limited window Process complete All set up has been completed, tested, and works Process complete External interfaces (bank downloads for example) have been tested, and work Process works The new Live database has all the master information in it, and has been verified correct Testing is complete, all processes work, finances tie-out Process complete Process complete All reports that are necessary to run the business are done, tested, and work All issues on the 'Issues List' that must be done prior to go-live have been completed, tested, and accepted Data conversion checklist is set, with sequence of conversion Process complete for required reports - optional reports at stakeholder's discretion Process complete Process complete 42

43 The Go / No-Go Decision: People Go-Live Readiness Checklist Criteria for the Go/No-Go Decision Description Criteria Complete People All Logins have been created, tested and work Process works Work Around Complete Not by Go-Live Acceptable Acceptable Security has been created, is in place, tested, and works (you can Process works elect not to turn it on) System training is complete and confirmed (tested) New operations process training is complete and confirmed (tested) Staff is available - all key members will be present All sites and people who will use the system have been trained All people affected have been trained whether they use the system or not All are available Key staff participating in the Go-Live event have been notified of their duties All staff have been notified of the event Process complete Process complete Contact information is in one place for all individuals participating in Go-Live Training documents have been distributed for reference Process complete Process complete New operating procedures have been written and have been distributed for reference Process complete. This may affect nonsystem users as well 43

44 The Go / No-Go Decision: Company Go-Live Readiness Checklist Criteria for the Go/No-Go Decision Description Criteria Complete Company / Organization There is an agreed upon detailed step-by-step action plan of what will Plan exists and signed off by all stakeholders happen at Go-Live with staff assigned to specific duties Work Around Complete by Go-Live Acceptable Not Acceptable Building access has been established for the Go-Live event Process complete There is an agreed upon roll-back plan There are agreed upon contingency plans for stages of the Go-Live Plan exists and signed off by all stakeholders Plan exists and signed off by all stakeholders There is an agreed upon communication plan to let others know what is happening Vendors have been notified that their paperwork or process might change Process complete Plan exists and signed off by all stakeholders Customers have been notified that their paperwork or process might change Super-Users are available for answering questions and resolving issues at all sites. Regular progress meetings have been scheduled throughout the event There is an agreed upon plan to manage the Issues List Process complete Process complete Plan exists and signed off by all stakeholders There is a designated central area to manage the cut-over (a "war room") with enough workspace for visitors, and enough materials to support the coordination phones, remote video access to all sites, whiteboards, etc. Process complete 44

45 Multi-Site, International ERP Implementation Situation: Failed ERP implementation led to reliance on work-arounds. Customer service suffered, reports would not run, inventory was unmanageable, and customers were lost. Task: Re-implement the ERP software incorporating best practices for the business, create reports that worked, and reduce time to delivery. A VAR who understood the complexities of agri-business was crucial to success. Action: Using the same selection process for a VAR as for new software, a vendor was selected to guide the company through the re-implementation process. The requirements gathered were a key factor to reducing time and cost of the re-implementation. Employee fatigue from the previous failed implementation was closely managed. A phased approach was used to make sure key current operations were successful. Result: The software was re-implemented in 12 months for key operations. Optional and new functionality was brought up three months later, extending the value to the company. 45

46 Multi-Site Third Party Cold Storage Company Situation: An on-going implementation of software that was selected based on the size and popularity of the ERP System. After two years they were still trying to get it to work, with nothing to fall back on. The company was losing business because they were unable to service customers quickly. Task: Quickly select and transition to a different ERP Solution. Get the company onto a system that would allow them to manage their inventory and service their customers with the proper functions. Action: The requirements were analyzed and a niche software vendor was located that met their exact needs. Result: The new software was selected, implemented and live in Four months. Decisions were made quickly because they were already in the worst case scenario of not having a functional ERP. 46

47 Fast Growing Local Manufacturer Situation: An ERP system had been selected and was being implemented by the software publisher the project was one year behind schedule, the business could not manage engineering changes, couldn t find or track inventory, and could not tell their customers where their orders were. Task: Get the software implemented, and adopt best practices. Enable bar code scanning for improved reliability and lot/serial tracking to meet customer and regulatory needs. Action: An implementation team was built to address specific customer requirements, perform testing, and training that the publisher never was able to do. The team focused on primary requirements to make bar code scanning functional, change management processes for engineering, and define MRP stages so customers would know where their orders were. Result: The implementation was completed and best practices imbued into the organization. Bar code scanning reduced data entry errors and MRP provided a consistent process view. 47

48 Summary of Key Strategies Clearly Define your objectives, Gaps and Desired future state before you look at solutions Evaluate lower rungs of the systems ladder before assuming you need a new ERP System o Current System Capabilities o Modules o Third-Party Bolt-Ons Avoid custom code modifications whenever possible Your VAR and Installation team is just as important as the Software Purchase Performance instead of Software Use the Future State functional requirements as your compass Test thoroughly and systematically, managed by the customer not the software provider/installer Develop a handful of Super Users, Train the Trainer approach 48

49 Summary of Key Strategies (continued) Don t shortcut Training Materials o SOP s o Cheat Sheets o Hands-On Training using real data Give the users a voice and capture their concerns and feedback Recognize the time commitment and make the proper resource adjustments Clearly define the project and committee roles and responsibilities, with support from the top. If you don t have an expert ERP system Implementer on staff, hire an outside PM to manage this for you. 49

50 Questions? 50