A successful implementation is a true team effort, requiring the active support and participation of management, and all team leaders and end-users. Many of these same issues occur, when doing a major upgrade.

Often, years after implementation, there is a need for re-training, due to large-scale changes in employees and staff, and/or a change in focus in terms of the business plan itself. I believe that there is a need to maximize value in the current application, before incurring expense in seeking alternatives. The problem of execution will still remain.

The current focus on Windows-like interfaces and web enablement is, in some sense, a distraction from the primary focus of delivering the correct part, of high quality, to the customer, on time. THERE IS A DIFFERENCE BETWEEN INFORMATION, AND INFORMATION TECHNOLOGY. Peter Drucker is the one who said that, in a Delphi conference a few years ago, and it is a valid point. You can buy technology, but you must generate information.

The following are some ideas, as I think back on a successful "go-live", which included hand-written conversion programs from a non-MultiValue database, and full user testing and piloting. Many of the following concepts hold true for major upgrades to existing systems, as well.

Set a realistic "go-live" date, using the experience of those who have gone through a similar process. If this date is not realistic, there is an immediate loss of morale, since the senior people will sense that the users will not be ready, and cannot thrive with false expectations, and attendant pressures.

Active and ongoing encouragement by top management is essential. The implementation team cannot live in fear of missing a "deadline". If top management is continuously kept apprised of progress, the chance of unfavorable surprises in minimized. If a department manager insists on calling his or her own meeting during scheduled training sessions, only top management can re-focus the overall effort.

Cross-functional teams are needed, in addition to module teams. Certain issues should be gone over by Planning, Purchasing and Accounting, together. Other issues should remain with specific module teams. Make sure that these teams are empowered to make suggestions. "Line" personnel should be included, not just managers.

A strong implementation leader is required to represent top management’s' desire to "go live" on time. The leader must insist on continuous training, and continuous improvement. The "go-live" point is only a waystation on the route to a sound implementation.

Schedule specific times for training. On a previously successful implementation, each module team (PDC, MPO, MPS, etc.) met for one hour, three times per week, at the same time. If someone was missing from a meeting, they were paged by the implementation leader (who, by the way, was in nearly every meeting).

Middle management must be on board as "champions" of the effort. They must also find ways to work around the fact that product must still be built and shipped, while training is going forward.

Keep expectations high - do not lay blame during training. This is the time to make mistakes, and to find out what people do not understand. If a user sees an "error message", they should be told to notify their team leader, and not believe that they have created a problem. This is the time to identify obvious software issues and problems. Make users aware that they do not earn any credit for finding their way around errors!

This is a good opportunity to win over senior employees, by giving them responsibility as trainers. Since senior people often have the most practical knowledge, they will work harder to utilize the new software, so as to supervise the training of junior personnel.

Raise expectations as the pilot progresses. Once confidence is gained, most people want to do even better.

Identify key reports and data, which you want to keep (emulate) from your existing legacy system. If upgrading, note which custom processes are no longer utilized, with an eye to removing unneeded customization to baseline software.

Identify key new requirements. The earlier this is done, the more likely that modifications can be delivered before "go-live". Try several data conversions, and assess the results via reports.

Re-judge your "go-live" date. Set a realistic timeline, and then PUSH! The conversion will not happen if people participate "when they have the time".

Announce a specific "go-live" date, and not a length of time. For example, your target is September 1st, not "3 months".

If you are forced to move out the "go-live" date, believability, and therefore momentum, begins to drop. One more reason to set a realistic date. Continue to work hard, even after "go-live".

Provide a mechanism so that suggested improvements can be held for review. Use a "Tracking" package that is database-oriented.

Keep the initial pilot simple, with few part structures, vendors, customers, etc.

A SAMPLE INITIAL PILOT

5 Top Assemblies, with shared sub-assemblies (for rollup samples). If your BOMs are "shallow" (few levels deep), use a larger group of Assemblies and components. Make certain that all components and sub-assemblies, within the Top Assemblies, are present.

All required BOMs (Bills of Material), and BOOs (Bills of Operation, or Routings). Valid Standard Costs for all Parts. Several Customers and Vendors, Work-Centers, Line-Masters, etc.

All Default Tables (AR-TABLE, AP-TABLE, PO-TABLE, WO-TABLE, SO-TABLE, etc.) are to be filled in.

Place Parts in Inventory through Material Movement Entry. Learn to analyze Inventory through Inventory Balance Inquiry, and various Inventory reports.

Create Purchase Orders, Work Orders, Sales Orders, Outside Process PO's, MPS, Firm Planned WO's, Repetitive Schedules, Return-to-Vendors, RMA's, etc. Per the modules that you have purchased, make a list of tasks, such as the examples provided.

Enter Forecasts, run the Master Production Schedules and enter Planned Orders. Re-run MPS, and use reports to see the results. Authorize the MPS Version and run the MRP. Learn to "peg" requirements using the software provided.

Ship and Invoice Sales Orders, and apply Cash to AR's. Run "Aging", and other key reports. Generate AR Statements.

Receive PO's, and enter Invoices (and Hand-Invoices), and cut Checks. Run "Aging" and other key reports.

Create appropriate Journals for AP, AR, CASH, ASSETS, PAYROLL, WORK ORDERS, STOCK, LABOR, CHECKS, etc., and post the GL. Review the results.