Engineers play critical role in software implementation and selection

Software is often seen as a quick fix for any problem. It can also be the problem. Lack of foresight in installation can lead to confusion and failure. Selecting the wrong tool for the job will make the new process worse than the one that was meant to be improved.

There is always a gap between how software systems should work and how they do work. Whether you’re making plastic, push toys or printing presses, the principles of shaping up and straightening out the electronic side of your operations are the same.

Training overcomes many problems

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.

Engineers can bridge the gap

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, they are aware of gaps within the 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.

As professionals trained to look for potential problems before implementation, engineers are more likely to ask the questions that others overlook. Furthermore, since they are familiar with the current hardware and software, they are 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-a-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, this is a good time to do it. 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 multimillion-dollar 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 realized only if things are done right.

Tailoring the software

Here’s an actual example of a project involving the tailoring of software to a plant’s requirements. The plant wanted a shop floor data management system that would allow it to track bills of material, manufacturing routers, defect data and nonconformances all the way down to the individual piece part. Engineers, managers and purchasers sat down together and hashed out a list of what the software had to be able to do. They purchased a software system that had the features they needed. Then they tailored it to the actual process flow.

Engineering found it necessary to map out the process flow for more than a dozen products. Then IT set the new software up with routers, bills of material and defect mapping specific to each product. Yet the work proved worth the effort. With the new software came the ability to have cycle time reports generated at the click of a mouse. Reports listing how long repairs have been in queue are straightforward and easy to read. This information would have taken hours to compile before the implementation. Furthermore, the tracking of items and subassemblies down to the individual electronic component allowed accurate activity-based costing to be put in place for the repair shop.

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 to change the software based on their understanding of your particular application and can change the software later if necessary. This capability 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.

Beta testing crucial

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 processing demands of the new software than whether the color scheme of the default menus is hard to read at 3 a.m. in the machine shop. The end users should be involved in any beta test where possible. However, engineers should be the first beta testers and be involved in system test. Engineers often see discrepancies between live screens and screen captures in user guides that IT will miss but users will find important. The system should be almost entirely debugged with daily users begins before beta testing. Anything less will destroy confidence in the system before you even get it out the door to the shop floor.

Engineers offer an understanding the operator’s point of view. And their experience of detailed documentation allows engineers 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.

The Bottom Line…

Engineers should play a key role in software purchasing and testing.

Focused, targeted training is crucial to successful software implementation.

Software simulation must occur before systems go “live.”

Author Information

Tamara Wilhite is a degreed industrial engineer, currently employed in the defense industry as a product data management software support specialist. She can be reached at tamarawilhite@hotmail.com .”

Emerson, Air Liquide develop industrial gas measurement system

Emerson Process Management in cooperation with Air Liquide Large Industries U.S. LP, an American subsidiary of Air Liquide, has developed of new software enabling highly accurate measurement of Air Liquide’s industrial gas products. The just-released government NIST 23 standards for the calculations and properties of industrial gases and steam are embedded in the special code created by Emerson as part of a multi-year contract with Air Liquide Large Industries U.S. LP.

Charles N. Harper, Director of National Supply & Pipeline Operations for Air Liquide Large Industries U.S. LP said, “This software was developed in conjunction with our agreement to purchase a substantial number of Emerson ROC809 remote operations controllers for the measurements of our products we must make for custody transfer and billing purposes.”

Intergraph acquires Alias

Intergraph Corp., a global provider of spatial information management software, has acquired Alias Ltd, a global provider of piping design automation software.

“The acquisition of Alias is consistent with our Strategic Plan to allocate capital and focus resources on our core industries where we believe Intergraph has differentiated capabilities,” said R. Halsey Wise, Intergraph president and CEO. “Alias provides our Process, Power & Marine division a complementary critical piping technology and enhanced expertise in deliverables automation that will allow Intergraph to continue delivering the productivity improvements that our customers desire and deserve.”

“The Alias acquisition is the positive culmination of a long-standing partnership between our two companies, and we believe there are many natural synergies in combining the two organizations,” said Gerhard Sallinger, president of Intergraph’s Process, Power & Marine Division.

Fieldbus Foundation updates specs

The Fieldbus Foundation has announced that an updated version of its FOUNDATION fieldbus specifications is now available. The new specification defines features that enhance fieldbus functionality and provide additional incentives for automation equipment suppliers to expedite the foundation’s implementations.

Specification 6.0 includes powerful new features standardized in Device Description Language technology — a text-based language describing the digital communication characteristics of intelligent devices and equipment parameters in an operating system and user interface-neutral environment. DDL enables a host system manufacturer to create a single engineering environment capable of supporting any device, from any supplier, using any communications protocol, without the need for custom software drivers for each device type.

The updated DDL specification extends the concept of interoperability to the HMI and diagnostic data level with improved visualization and graphical features. New features focus on device data organization, graphical visualization consistency, and support for persistent data storage. These enhancements are backward and forward compatible due to the nature of the IEC 61804-2 standard.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.