Not by software alone

bear2008 · 发表于 2009-1-3 14:10:36

Software is often seen as a quick fix for any process problem. Bottlenecks in the supply chain? Buy MRP software. Process out of control? Buy process-monitoring software. Unfortunately, software can also be the problem.

Lack of foresight in installation can lead to confusion. Selecting the wrong tool for the job will make the new process worse than the one that was meant to be improved. Inappropriate training leads to a slower learning curve and greater errors. How can engineers improve this new frontier in process improvement via software? There are several key areas to target.

Lack of training or lack of understanding the software despite training is the first and often greatest stumbling block. Users may have a vague idea how to perform various functions. Yet calls to the helpdesk often result with the advice of “look at the manual” or “it should be in your training documentation.” The difficulty in interpreting an eight-inch thick user guide led me to write up our own eight-page user’s guide for our specific immediate shop floor uses of the data management software. This soon became our standard practice. A few more acts like that and I ended up in the technical support world, translating training and user guides into documents users could actually use. Having been a user and a lead in the assistance of general users, I had both system understanding and understanding of how users actually used the system.

User training is better than simply handing users a manual at the time of sale before disappearing. A simple how-to run-thru 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 computer gurus may love such in-depth sessions, but those who are less technically inclined may be left more confused than before. We’ve all sat through training sessions where perhaps 10 percent of the material covered is actually applicable to us. Users have told me that they heard the names of the different servers the system used, but now need help because they are not sure how to log in.

Work with the trainers to develop specific, targeted sessions for each type of user. 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 several extra classes that will cover only what each group need to know and understand. Line workers, engineers, system administrators, and data entry staff should all receive separate and tailored training sessions. Those receiving the training get exposed to far less extraneous material. The time spent in training is more productive for those that are there.  The modest investment of time and energy to create user group specific training leads to a greater return on investment of the training sessions for users.

Software is often purchased based upon what managers believe the operators’ need 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 representative’s presentation. This is where engineers with a system wide perspective become crucial.

Engineers are the liaison between the shop floor and management. They understand what the end users need from the software. They are often the only ones present during software demonstrations who understand those shop floor concerns. Furthermore, engineers are aware of gaps within our current systems that others may not realize are needed. It is easier to request that a preferred feature be added before the software is paid for than after. Furthermore, since we are familiar with the current hardware and software, we more likely to see potential snarls in trying to fit one more software cog into the production machine.

And how is the software cog going to fit into your existing corporate machine? Are you going to tailor your existing processes to the new software? Are you going to tailor the software to your existing processes? There are pros and cons to both methods. If you must dovetail your processes to the software, it requires changes to your process flow. On the other hand, changing your work procedures to fit the software provides a perfect opportunity to eliminate unnecessary operations from the process. The software’s fit into the new process flow also provides reinforcement for the new process flow. Changing your process to fit the software is too often a round peg in square hole proposition; many find that the software simply adds complication to what had been an efficient operation before.

If you don’t have a map of your current processes, new software implementations are a good time to build one. Management is more likely to allow the resources necessary to figure out how things are done – and time to determine how to do them better - if a successful multi-million-software implementation depends on it. If the new software reinforces the improvements made in the process flow, the software implementation gains a new payback that wouldn’t have been realized otherwise. However, this benefit is only realized if things are done right.

Tailoring software to your individual application has its own problems. Working with the software provider delays the implementation of the software, and increases the cost of the software. Training your own people to be able to tailor the software takes them from other critical projects. However, it means they are able change the software based on their understanding of your particular application and can change the software later if necessary. This requires working with the software extensively. It may require learning some crash programming. It always requires debugging. Preferably, this should occur during beta testing of the software, before its full implementation.

Another critical area engineers often overlooked is the beta testing of software.  Engineers have often understood the traits of a good human-machine interface. Programmers are more likely to be focused on server demands than whether the color scheme is hard to read at 3 a.m. by the machine shop personnel. The end users should be involved in any beta test. However, engineers should be the first beta testers and in system test where possible. More importantly, the system should be almost entirely debugged before beta testing with daily users begins. Negative impressions carried away from system test will be hard to counter if any issues arise during roll out.

No one had been concerned about beta testing the software in a trial plastic extruder control panel. What happens when you bump up against a touch control screen with your whole arm, rather than hitting a single button as the interface expects to happen? The interface locked up, causing the equipment to shut down because the software had no idea how to handle the simultaneous input, and a few motors were damaged in the process. The minor bug was fixed the day before we went live.
Other problems emerged that would have been discovered if we had run through a simulation of multiple days of operation.

How closely should you monitor each line? What do you do when something goes out of process control boundaries? If the simulation doesn’t cover the extreme events, the system may not handle those extreme events correctly. Yet these are exactly the times software is most needed – to catch those events humans may not be able to realize until it is too late.

When dealing with molten plastic extruders, higher pressure improves the quality of mixing. This is true as long as the pressure does not get too high. I once had an operator who realized that if one screen filtering the output was good, and a second screen not only improved the output but also built up pressure, making the quality even better. Hence, it was decided that four screen filters must be even better than just two. The monitoring software did not do much to alert someone outside the immediate area of excessive pressure. A flashing red light was thought to be enough. Yet the shop floor had hundreds of flashing lights, from forklifts to extruder feeders to pressure gauges.

The pressure buildup caused the screen filters to get blown out somewhere around 700 PSI. Fortunately, no one was hurt when the molten plastic ejected out like toothpaste before flowing like melted crayon on the ground. The mess took a few days to clean up. If we had bothered to ask the day-to-day operators what sorts of “freak events” to expect to have to make the system robust enough to handle, we would have realized that this sort of thing had happened in the past and should have been planned for. Maintenance staff were then required to physically check the pressure readings at each production line each shift. The monitoring software was supposed to do that. Yet there was no notification e-mail provision that pressure had reached critical levels, though this would have been an easy bit of code to insert into the system software.  If programming had asked the operators what they needed the software to do, it might have had better primary and secondary notification methods in place. If engineering had been more involved in beta testing, we might have realized what it needed to not allow operators to do and had it raise a flag when too many screens were installed. Hindsight, though, is 20/20.

Engineers are the liaisons between the floor and the IT staff. The combination of understanding the operator’s point of view and the experience of detailed documentation allows an engineer to be able to hand the programmer a detailed listing of what needs to be changed and what it should be changed to. Engineers must play a role in the software purchasing, implementation, and documentation processes, just as they do in the manufacturing process. They can have as great an impact on the efficiency and effectiveness of software changes and upgrades as they can have with traditional manufacturing.

However, process improvement will never be accomplished by software alone. Engineers need to be involved in software selection, implementation and testing if it is to become an improvement over the past processes.

kamel · 发表于 2009-1-5 14:35:20

truthful insight! Good writing!

The pity is very few decision maker understands this!

bear2008 · 发表于 2009-1-7 14:52:39

thanks a lot

帐号		自动登录	找回密码
密码			注册

[原创] Not by software alone

评分