| Consultant's Corner |
by Bill Cowley |
| The conference was great. You met everyone, asked the right questions, watched the demonstrations and gathered your information. You left feeling invigorated with new ideas but a little tired. The next day, at your desk, you log in and the bubble bursts and elation evaporates like dew in a desert morning. You are three major releases behind. You must upgrade before you can enjoy the new features you learned about. How do you tackle this project? |
| NOTE The steps shown below are basic steps for making significant upgrades. Minor upgrades may omit or shorten some steps but the overall process (learn-test-document) remains constant. ERP is a mission critical application. It’s worth careful planning to avoid pitfalls and to assure success. |
Communicate Early and Often – I believe projects work best when they are transparent. Share both the good and the bad. Use many different methods to share information. Include meetings, emails, and a network folder for all documentation. |
| Select the Team – Don’t attempt to upgrade in a vacuum. You don’t know everyone’s job well enough to go without their input. Gather a team with representatives from each department. They will be your testers and troubleshooters. They are your champions. They will know if the new process works or not. |
| Document the process - This applies to everyone. It is not be limited to FDA or SOX compliance issues. Keep the documentation simple and clear. You don’t get extra points for complexity. |
| Your documentation provides three functions: 1) It shows what you did and what you tested 2) The results are recorded and 3) When signed and dated, it is the proof of the process. |
| You will live with the success or failure. You must be sure it does what you think it does. I have had simple upgrades fail due to seemingly unrelated issues. It is much better to fail beforehand in test, than to suffer needlessly afterwards. |
| Approval for the upgrade – Do this first. Keep management apprised of your intent and upgrade plan. |
| Timeline – When should we upgrade? Pick a target date and a backup (Plan B) date. Talk it over with your management and your team. |
| Major Upgrades take time to run, test and document. Weekends allow upgrades with minimal impact on business operations but vendor software support may need to be secured and scheduled in advance for Go Live weekend. Who will you call when something goes wrong? |
| - Meetings: How often and where? Check your progress often. Take notes and publish a summary. You need a minimum of who attended the meeting, areas of discussion and actions taken/planned. |
| - Test environment setup date (practice the upgrade and new features without risking the live system). |
| - TEST Upgrade date – Upgrade Steps – What is required? Download any instructions. Include the new options and functions setup instructions. These will be your Upgrade Checklist. Note any and all customizations (reports, triggers, etc). You may need to add steps to re-write the previous changes for the new version. |
| - Learn and Train – When will Logins be available for orientation and “Playtime” in Test to get familiar with the changes. Set Training sessions schedule dates for new features or process changes. |
| - Formal testing dates (begin and end dates) using Workflow checklists. You need to know that users can get their jobs done at Go Live. They may be slower with the new process than before the upgrade but everyone knows what to do and knows it works. |
| - Create Checklists from all daily workflow processes. Simply list the steps, in Word or Excel. Include your company’s approvals, routings, and reports in each process. Then assign the team member to each step. Include a space for Results and Initials/Date. Each team member must be familiar with the daily operation. If they are too far removed from the details, they won’t recognize a minor error. |
| - Error Tracking - When a problem is found, who is told? You will have errors. You want to find them all and solve them before the final upgrade. You do not want to be surprised at Go Live. Change any test documents/simulations and retest until satisfied. |
| - User acceptance signoff (Test database): After completing all updated workflow simulations, the team gathers to discuss any open issues preventing upgrading the production system. If nothing is pending, the team signs a “User Acceptance” form. |
| - Production (live) cutoffs for transactions: Assure all transactions have been entered and data points run. Data points are the comparison reports used to verify critical data before and after. AP Aging, AR Aging, Costed Stock & QC Status, WIP Value, PO Commitments and GL Trial Balance are good starting points. |
| - Backup databases: They are easy to do and easier to forget. Run backups of all databases and directories affected by the upgrade. This is your parachute if all else fails. |
| - Upgrade the Production system: You have done it all before as practice, now it’s REAL. Follow and sign-off all of the steps. It may seem silly, but you don’t want to miss a step because you misremembered. |
- User acceptance signoff (Live Database): After running and comparing data point reports and entering saved transactions, the team gathers to discuss any open issues preventing the release of the production system. If nothing is pending, the team signs a “User Acceptance” form. |
| - Go Live Day in production: All users perform their daily tasks. Errors are reported to the Project Leader and resolutions found. |
| - Celebrate: You did a good job and succeeded. I will leave it up to you as to when and how much. |
| It may be a little tedious but it wasn’t as bad as you thought it would be. I have used this process with FDA Validations, SOX Compliance and many times just for my own sanity. |
| …wc |
The full version of this article can be found at http://www.gurusome.com/Upgrades.htm with a sample workflow simulation sheet…wc
|
|
|
  |
|