Making the integration process work

By Nancy Glenn and David Braun

The good thing about IT/IS solutions is if you have correctly defined your problem and integrate the solutions well, they actually work. 

Every day around the world, manufacturers reap tangible financial benefits provided by an information system. The bad thing is when a project goes badly, it quickly turns into a nightmare that can cost time, money, and reap huge tolls in human frustration. 

How do you keep this from happening? 

The integration process can be broken down into four steps that help focus and ensure a successful technology choice.

  1. Goal setting
  2. Assess needs
  3. Team creation
  4. Evaluate solutions

Let us look at goal setting first.

Consider corporate standards and directions: The corporate IT direction should partially set your goals before your project ever starts. Find out what the standards are for the technology direction in your company before you tackle any problem. If corporate direction is to move toward Linux, then installing an NT solution does not make sense, and vice versa. 

Knowing corporate or facility policies will allow you to build the right list of requirements for the packages you will evaluate later. The rest of the goals should provide measurable expectations about how manufacturing process will behave after the solution is in place. 

Comparing/contrasting this to how processes behave today is a first step to calculating an expected return on investment (ROI). A goal of this type would be something like "We will put in place a solution that will reduce scrap by 10%." Alternatively, "We will integrate a solution that allows corporate management to view current WIP within a three-minute snapshot." 

The truth is it is hard to achieve a high ROI on projects that require lots of initial infrastructure to get started where the potential benefits don't directly map into bottom line figures. 

Consider existing infrastructure: Be sure you know where in your software and hardware's life cycle your facility is. Have you had the same revision of software or hardware for a number of years now? Is it under active support from the vendor, or is it scheduled to be unsupported? Unsupported software and/or hardware become a true nightmare from a support and management perspective. 

When you are considering new technologies that must coexist with an unsupported system, it usually means one of two things, a completely new system, or additional code to support the load of the internal staff. This type of scenario is typical in the manufacturing environment because the traditional attitude is "If it's not broken, don't fix it."

However, it is important to realize that just like the manufacturing equipment itself, software/IT has to do periodic maintenance as well. IT solutions must keep living, but the manufacturing floor may not want to change them.

Consider your acceptable level of risk: It is important to include goal statements for the overall performance of the system. These should reflect the level of risk you are willing to accept from an information system. How much downtime is acceptable? What will you do if a part of the system fails? If you are running a 24/7 manufacturing facility, a four hour per week downtime for backups is not acceptable. If you only run five days a week, this is easily tolerable. 

Consider if the information collected by the system needs to be collected through rapid transactions in real time from the equipment or if human time is acceptable. 

Performance tradeoffs are the hardest to figure out. The higher the performance the more costly and less flexible the system will be.

The other thing to consider is how important the data is that you are collecting and who needs access to it in what period. Does the CEO really need to monitor the temperature in a vat in Tokyo from the boardroom at sub-second intervals?

Consider existing data sources: When you are setting goals for your new technology, it is important to consider if that technology will be interdependent on data from an older legacy system. If the integration into the older system is going to be costly and difficult, it may make sense to use a third framework or code set to integrate the two.

Another consideration is what the legacy systems are really doing and how important they are to the manufacturing process. Low-level integration with these systems may require downtime. Legacy system integration may also result in unsupported code from the vendor, which results in homegrown support of the system.

Once your goals are well defined, you are ready to move on to the second step. The Channel Talk department will look at this second step and subsequent steps in the October InTech


Nancy Glenn ( is a system architect at the Delco Electronics division of Delphi Automotive Systems. David Braun (dbraun@ works in the super-computing center at Purdue University.