CONCEPT AND PRODUCT (SOFTWARE) EDUCATION

Most software is written with terminology referencing concepts and procedures identified in the APICS body of knowledge. Many compa­nies assume that their personnel, specifically their selection and imple­mentation team members, have a common understanding of those con­cepts. This is rarely the case. This situation leads to misinterpretation and potential disaster in the selection and implementation process. An investment in APICS concept education, therefore, is priceless if done early in the implementation or selection process. That's why APICS-educated team members add sizzle to the project and increase the odds of success.

Software product education is generally the first step after selec­tion and installation of hardware and software. The education process is frequently conducted by application experts in the software over a brief period of time and delivered to the implementation team. The team is often faced with a totally foreign environment: new software, new platform functionality, new terminology, etc.

There are various outcomes of this "education" activity. Some partici­pants glaze over and tune out, some may develop a fear of the application and, in a few cases, some may come away with a familiarization of the product. What's wrong? First of all, the education expectation is probably not valid. Initial product education is probably, at best, product orienta­tion. The delivery technique for the orientation needs to be one that is empathetic to the users' background, and the goal should be to set the foundation for future learning through self-education or assisted educa­tion. Adequate time and resources need to be invested at this step because these set the initial perceptions, morale, and momentum for the project. Whenever possible, the educator should use examples or references to the users' products and industry.

PROCESS OWNERSHIP—WHOSE PROJECT IS THIS, ANYWAY?

The issue around process ownership occurs most frequently when the software organization or other third party vendor plays a significant role in project management, product education, business process re-engineering, or any combination of those roles. In spite of the well-intentioned approach, sometimes the wrong thing happens. The orga­nization is light on resources, so they supplement with outside assis­tance. Okay so far. The third-party sources are competent and add value to the process. Great again! Somewhere in the implementation process the organization begins to become psychologically dependent on its contracted help. They think, for example, of using third-party resources to write procedures, do rollout education, etc. The warning flags should be going up. When will the organization take ownership of the imple­mentation and its processes?

ERP implementations are far too integral a part of the organization's destiny to be considered turnkey efforts. At the end of the project, the consultants will move on. What will be left as far as the understanding and competency with the new system? Will it be able to grow beyond initial startup goals? This kind of situation generally develops as a re­sult of a mutual mistake on the part of both client and consultant. The client does not step in and take ownership, and the consultant does not proactively force this to happen. A seamless transition is the goal. Talk about it, keep it in the forefront, end up with "your" system, not "their" system.

TO MOD OR NOT TO MOD

My Rules

Rule # 1. Do as little modification to the product as possible for so many reasons they can only be mentioned here. Things like cost, re­sources, quality, upgrades, and accountability are enough to sink most modification requests.

Rule # 2. If you absolutely must have a modification, be sure the process is well defined and diligently followed. Some of the most com­mon reasons modifications cause problems are (1) poor specification— user doesn't define the need; (2) no planned budget for mods; (3) ca­sual acceptance—didn't test what was written; (4) late discovery—too late in the cycle to write, program, test, accept, and incorporate; (5) timing of delivery—don't know when it will be done.

What can be done? Manage modifications as if they were priceless time bombs that could ruin your project. Report on them constantly, facilitate their development cycle, and be sure they are essential. When should modifications be completed? Before integrated testing, confer­ence room pilot, or whatever the piloting activity is called. One final caution: don't justify a modification so people can "keep doing things the way we've always done them." Mods are a weak but expensive excuse for avoiding change management.

INTEGRATED TESTING

At one or more times in the implementation, there is a need to simulate running the business in a cross-functional way with the new software. This activity has many names, so for convenience let's call it inte­grated testing. Some of the common problems with this activity are as follows: (1) Users are not ready to conduct the process. (2) The pro­cesses being tested do not cover the business requirements. (3) Ex­pected results are not identified. (4) Expected results are not verified. (5) Discrepancies to expectations are not documented and resolved.
(6) Cross-functional results are not verified.

The purpose of this exercise is to verify and demonstrate confi­dence in the organization's ability to use the software to run the com­pany. Successful process tests become the framework for procedures and final process documentation. This activity is a command perfor­mance. To the extent that it is treated lightly or incompletely, the downstream activities of the project plan are in jeopardy. Want to take the sizzle out of your project? Treat this phase lightly. It will put your fire out.

To Be Continued