You want to upgrade.  Now what???                                                Wm.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?

The steps shown below are basic steps for significant upgrades.  Minor upgrades may omit or shorten some steps but the overall process (Learn-Test-Document) must remain intact.  ERP is a mission critical application.  It cannot stop. Therefore, you must mitigate the risk.  Remember what Mom told you, “It is all fun and games until someone loses an eye”…

Communicate Early and Often – I believe projects work best when they are transparent. Share the Good and the Bad. Use many different methods to share information. Include meetings, emails, and a network folder for all documentation.

Build Consensus – Share the new features, functions and fixes freely. The Release Notes and Fix lists are a terrific source of information. Each department will help test the new version.  Get them see the benefits of their effort. Get them excited and let everyone work together for the change.

Select the Team – Don’t attempt this by yourself. You don’t know everyone’s job good enough to skip 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 documents 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 do to seemingly unrelated issues.  It is much better to have it fail in test, before hand, than to suffer needlessly afterwards.

An auditor taught me a simple truth.  Regardless of meetings schedules or tasks checked as completed, if there is no documentation (notes, checklists, minutes, whatever) then it didn’t happen.  It is like trying to process an expense report with no receipts.  It didn’t happen without the proof.

Approval for the upgrade – Do this first. Keep management apprised of your intent and upgrade plan. Outline the reasons for the change, the team members, the risk assessment and timeline.  Include your Budget estimates and Rollback steps if the upgrade fails in production.  Get this document signed by management. 

Note: Rollback steps do not need to be complicated. They can be as simple as:” If upgrade fails, restore database and directory structures from the pre-upgrade backup”.

Timeline – When should we upgrade?  Pick a target date and a backup (Plan B) date. Talk it over with your management and your team. Each company is different but common themes develop. Month ends are bad for upgrades.  Finance has to close the books.  You shouldn’t risk that deadline. Mid-month seems a better choice.  You have some time to resolve any issues before Month End. Quarter end is also a bad choice.  People are focused on Sales/Shipments and not upgrades.  Also, if the upgrade takes longer than expected, you don’t want to impact the sales numbers.

Major Upgrades take time to run, test and document.  Weekends allow upgrades with minimal impact on business operations.  Weekend overtime hours may need to be approved in advance.  Software support may need to be secured and scheduled, in advance, for GoLive weekend.  Who will you call when something goes wrong?

Timeline Milestones (include “Who” is responsible):

·         Meetings:  How often and where?  Check your progress often.  Take notes and publish summary.  These don’t need to be Board Meeting Minutes with every detail recorded and glass of wine discussed.  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).

o   Will new servers or temporary workstations be used?

o   Will new servers be promoted to production on GoLive?

o   Will we access Test using Terminal Server or Test laptops?

o   Are temporary licenses required?

·         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. As you upgrade, make notes of changes and additions to the checklist.  This will become the basis for the production upgrade.

·         Learn and Train

o   Date Logins are available for orientation & “Playtime” in Test (get familiar)

o   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 GoLive.  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 like “Procure to Pay”.  Document the steps from Vendor creation, purchase order placement, receipts entry and then AP voucher entry and payment steps.  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. Errors will only become apparent at GoLive and then everything stops until the problem is fixed.

These checklists will be used for user orientation, in TEST, and for formal User Testing & Acceptance. The first user on each list performs the task, prints out a screenshot or report, initials and dates the step and passes everything to the next person on the list. The next person reviews the packet for mistakes and then performs the next task, and so on.  When the tasks are completed, the checklist and the documents are forwarded to the Project Leader.  The Project Leader notes the receipt on the Master Process List.

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 GoLive.  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.  Management then reviews the process and gives final approval for the upgrade.

·         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.   You may want to save some transactions to enter after the upgrade to test the upgraded database. Personally, I do not like to enter fictitious data in the production database.

·         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. 

·         GoLive Day in production

All users perform their daily tasks.  Errors are reported to the Project Leader and resolutions found. 

·         Day 1 Signoff by team.

At the end of Day 1, the Team meets to discuss and document any open issues.  Estimated resolutions are noted and approved by the team.

·         Management Approval of upgrade process and documents.

The Upgrade Approval document is supported by all completed checklists, workflows, and test documents.

·         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 following link opens an Excel worksheet with Samples of the Workflow Simulations described above...

WorkFlowSimulationsSample.xls