Investment in up-front time vital

By Nancy Glenn and David Braun

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

Once your goals are well defined, you are ready to move on to the second and next steps. 

  1. Goal setting    (InTech covered this in Channel Talk, September 2006, page 65, www.isa.org/link/CTsept06.)
  2. Assess needs
  3. Team creation
  4. Evaluate solutions

Assess needs

This is the step when you look at the details of the problem within your layer of the information infrastructure, as well as how that impacts all the other layers. 

What specifically are you trying to fix about your process? For example, if you are trying to lower scrap rate by 10%, what is really causing the high scrap rate you want to lower? Is it defects caused by an automated material handling system? Is it lack of process verification? Is obsolete material going to scrap because customer order changes are not showing up rapidly enough in the manufacturing flow? 

In as many cases as possible, base your needs assessment on real data, and first hand observations. This data gathering and evaluation may take some investment of time up front, but it will help you be more certain the solution you are putting in place will be effective. 

As you document your needs, remember to interpret your needs in the context of the long-range plans defined during the goal-setting step.

Let's move to the teams' wishes and wants. This is where it is especially useful to have a domain specialist with an IT background onboard. When considering needs assessment, you have to be able to step outside of the box and look at the bigger picture of the problem. Otherwise, the scope of the project may be too narrow. 

At Delphi Delco Electronics Systems, needs assessment emanates from the internal computer integrated manufacturing (CIM) group, and then each engineering, operation, and maintenance group potentially affected by the new system tacks on their wishes and wants to the list. 

Commonality was calculated, and the best approach chosen was the one that will cover most of the needs. Keep in mind needs and wishes are often the same thing, merely appearing at different points in time. It is not unusual for today's wishes to be tomorrow's needs. 

By understanding how the manufacturing floor wants the system to grow, it is possible to make wiser choices about the current deployed technology. Although you may not be able to solve all the wishes today, you can be sure you will not put in place a system that makes those wishes impossible tomorrow.

It is critical to remember at this point no one person or one department will be able to define accurately the needs of the project. It will take combined insights from operations, maintenance, engineering, IS/IT, and maybe even upper management to define and eventually implement a solution. 

Cooperation and unfettered flow of information and ideas between departments will be a critical success factor. That is why team creation is so important.

Team creation

In order for a technology integration to be successful in the manufacturing environment, it must have the support of people from many internal organizations. 

Build a cross-functional project team that will survive from the birth of the project (Needs Assessment) until implementation and release into production. It is important all team members be chosen for their expertise in their area and are empowered by their organizations to act as representatives and make decisions and commitments. 

This is especially true as the project moves into an implementation phase when planning and scheduling are critical. Although there will probably be only one person in charge of the actual schedule, all team members will need to give input and commitment dates for activities in their arena.

If your integration project is going to be large (a million dollars or more) and you do not have experienced staff who have successfully completed a technology integration, consider hiring a technology consultant to add to your team. 

This is a team member whose purpose is to be an expert in the technologies, as well as experienced in what works and what does not work in the real world of production.  

This is NOT a project manager. This person's role is strictly one of idea generation and to help the team think outside the corporate box. Be sure the person's job is such that they are free to give constructive criticism and to prevent you from wasting time and money. Their job is not just telling you what you want to hear.

Evaluate solutions

Now that a team is in place and there are defined needs, it is time to begin evaluating potential solutions for the problem. Throughout this process, remember the more information you can give vendors about your needs and requirements, the better you will be able to tell if a solution "fits" for you.

The first rule of technology evaluation is to ask detailed, specific questions. If you do not understand the answer, or do not think it really answers your question, ask more questions. Ask questions about not only the technology itself, but also how the technology addresses your needs and long-range goals.

Ask an uninterested, expert, third party questions about the information given to you by vendors, or for their opinions about proposed solutions. People from most IT business sectors will give you an opinion for free. 

Make use of your technology consultant now, if you have one. Take your time and do not be afraid to make a vendor back up any claim. It is worth the investment in up-front time to gather as much data as possible about the proposed solutions at this point, rather than getting disastrous and expensive surprises during the actual integration.

This soon becomes a time for making decisions, but resist the urge to jump to a decision too rapidly. Here are the decisions you will face:

  1. Will you buy the software or create it in-house?
  2. Will your solution be open or proprietary?
  3. Do you replace legacy systems or integrate with them?
  4. To which architectural designs will you commit?

We'll answer these questions and finish this analysis in the November 2006 InTech.

ABOUT THE AUTHORS

Nancy Glenn (nancy.d.glenn@delphi.com) is a system architect at the Delco Electronics division of Delphi Automotive Systems. David Braun (dbraun@purdue.edu) works in the supercomputing center at Purdue University.