COMPANY PROFILE
What is one of the first problems users have when confronting a new software system? They have no idea how to do anything, and the solution is for someone to hand them a manual. The difficulty in interpreting huge user manuals can be alleviated by writing your own brief user's guide for the specific, immediate shop floor uses of the software. A software system is worse than useless if it becomes a hindrance to those who use it.
Training is better. A simple how-to run-through with someone who already knows the software can make the difference between getting it and not. Yet we often make the assumption of sitting everyone down in an all-day session that covers all the ins and outs of this mammoth system. The IT people may love it, but those who are less technically inclined may be left more confused than before. We've all sat through training sessions where perhaps 5% of the material covered is applicable to us. Yet it is easy to overlook the labor costs of having everyone cooped up for hours more than necessary in the name of "training."
If possible, work with the trainers to develop specific, targeted sessions. List everyone who needs training. Classify what their job type is and how they will be using the system. Break out the training sections that apply to them. Have the trainer give extra classes that cover only what each group needs to know and understand. This is usually just a few chapters to each group. Those receiving the training get exposed to far less extraneous material. The time spent in training is more productive for those that are there.
Software is often purchased based upon what managers believe the operator needs or the functions that the information technology department wants to have. While operators can easily describe the difficulties they have with a system after it is implemented, they may not be able to immediately identify potential problems with a software package from the sales presentation. This is where engineers with a system-wide perspective become crucial.
Let's use the example of a document management software system. Many companies have one. Even more need one. We needed something to help track where every electronic document and drawing was. What was purchased was the cheapest option, which the salesperson said was "the barebones version of what we needed." It turned out to be the mere architecture of the system. No database had been set up. No sorting protocols. No user interface to search for documents. Since we went cheap, we'd get to do all the programming to create the interface that we had seen in the demo.
If someone with technical expertise had been sitting alongside the procurement personnel while they were negotiating, it would have been possible to ask, "What exactly do you mean `bare bones version?' " The whole document management system idea was scrapped because we received something worse than useless, and three weeks of trying to build up a homegrown solution around the purchased skeleton got us nowhere.