EDUCATION ROLLOUT-SPREADING THE KNOWLEDGE

Congratulations, the implementation team has done a fine job to date. They are knowledgeable in the product applications, confident as a result of good integrated testing, and have documented business poli­cies, processes, and procedures. Now the software education and new processes must be conveyed to the other users in the organization.

Commonly observed problems with education rollout: (1) Assumes skills the new students don't have (for example, P.C. skills). (2) In­structors won't "sell" the new way of doing things. (3) Not enough time is scheduled. (4) Implementation team members' skills as instruc­tors are not adequate. (5) Logistics problems (location, scheduling). (6) Students listening but not doing. (7) No follow-up time or activi­ties. (8) Too close or too far from the go-live date.

When education rollout is reached, top management frequently as­sumes that the tough work is done and that the organization can sprint to the finish. Going too fast or taking shortcuts during this phase will either cause tremendous post-live problems or completely ruin the project. Remember, education rollout is the ultimate change manage­ment challenge. What it took a crack implementation team months to absorb is being rolled out in a fraction of the time to those never before involved with the project. Sound like a challenge? It sure is! Be pre­pared for it.

DATA CONVERSIONS—LOADING UP

A routinely exercised implementation process involves mapping data­bases from a current computer system into a new system. Candidates for this type of transfer include product records, customer accounts, vendor master, and sales history. Although generally a sound techno­logical approach, experience has shown that results may not always meet expectations for a variety of reasons. First, the "from" and "to" file formats are rarely compatible, so either old data doesn't fit or new files contain "voids." Secondly, it is generally assumed that old (i.e., current) data is accurate. If not, then one is migrating mistakes at the speed of light. Third, the formatting schemes, e.g., customer I.D., may be obsolete and not desirable to perpetuate, but data conversion makes it convenient and economical to do so. Call this third situation an op­portunity missed. Finally, there is so much confidence in the electronic process that it is too easy to rationalize not checking results. Having itemized many of the potential caveats, it still may be appropriate to do data conversion, just be sure to take steps to verify accuracy prior to and after transfer. Experience with data conversions has led to a healthy skepticism. The risks associated with a poor conversion are obvious. At the least, it can perpetuate mistakes or distort new data. At worst, it can disrupt business and service.

SYSTEMS OPERATION

When an implementation involves transitioning from one platform to another, or one operating system to another, there is a definite need for the I.S. personnel to become well versed in the new structure of things and be able to leverage the advantages of the new environment. Strange as it might seem, this need, and the education to address it, is frequently downplayed or even neglected altogether in the project plan. The re­sults can be disastrous. Period end close routines, ideal candidates for automation are left to user diligence. Background processing routines are not started or stopped properly. Interim upgrades and software fixes are time consuming and prone to error. These along with many other technical tasks simply are not addressed with the appropriate timing and resources. The solution: Factor this education and technology uti­lization into the project plan and execute it with the same diligence afforded any other task. Nothing will extinguish the user enthusiasm faster than system performance problems.

THE INTERNAL HELP DESK

As the implementation rolls out, new users in particular are going to require supplemental guidance and problem solving assistance with the product. The best procedures and education efforts will definitely minimize, but never eliminate, this requirement. Common mistakes with the help desk are (1) waiting too late in the implementation plan to put the structure and training of personnel in place; (2) working around rather than through the help desk; (3) not providing adequate coverage (i.e., weekends, time zones, etc.); (4) not putting a sound solution structure in place. The help desk will not be able to solve all problems on the spot, but they must have the available resources to get the solution in a timely manner. Unresolved user concerns or questions can result in loss: lost business, reduced customer service, or mistakes and "emergency workarounds" that can corrupt data and domino into other problems. Don't delay or downplay the use and purpose of the help desk.

POST-IMPLEMENTATION ACTIVITY

Shortly after an implementation that is live and running the business with at least moderate success, a huge psychological sigh travels through the organization. This is well earned as long as it is not accompanied by an immediate 100 percent shift to the next project and a lack of closure on the current project. During the implementation process, many things will be properly prioritized to be done as post-implementation enhancements. Examples might be custom screens or reports. If these issues are still value justified and were only delayed because of re­source constraints, then they should be completed. To not do so is to leave value to the organization on the table. The tree has been climbed— harvest all of the fruit possible! In reality, this new ERP solution be­comes part of the organizations ongoing continuous improvement pro­cess. Finally, don't forget recognition as an essential post-implementa­tion activity.

CONCLUSION

These areas in a systems implementation are not the only ones that are critical, but they do seem to be the ones most vulnerable to critical errors. There are instances in this paper where a problem is identified and is not followed by a fix. That's because the fix is the reciprocal of the problem. Example: Help desk developed too late—implied fix, start it early in the process. Where the suggested solution was not obvious, some solution commentary was hopefully given.