Lean MIS can't miss: Manufacturing information systems

InTech, Nov 2006 by Glenn, Nancy, Braun, David

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

You've established your goals, decided what the needs are, and picked out the team to make it all happen. This month, we'll look at and appraise your solutions.

1. Goal setting (www.isa.org/link/CT0906)

2. Assess needs (www.isa.org/link/CT1006)

3. Team creation (www.isa.org/link/CT1006)

4. Evaluate solutions

As we move into the fourth phase of this integration, you'll see the decisions facing you as these:

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?

Build versus buy

Building software in house requires a long-term commitment in staffing to write and maintain the software. If there is no solution on the market for your problem, this may be your only solution.

However, do not be deluded into thinking this is always the cheaper solution. This requires staff be trained and remain up to date n an object oriented programming language.

If your staff is fluent in FORTRAN, COBOL, or C, for example, they will require training. An object-oriented approach will be critical to any large integration project in order to keep the project flexible and manageable.

One way to lessen the impact of inhouse development is to consider a technology transfer. Partnering with an outside software vendor to develop the needed software, then releasing the software to them to productize, gives you free lifetime maintenance in return.

This lessens the development burden for them, but lowers your ongoing maintenance costs for the system. If this is not a feasible solution, try thinking broader in your software design, and look for other departments who may need software of a similar function and design the software to be re-usable, lowering the overall burden.

For example, Delphi Delco Electronics Systems has a custom developed common lot flow-card system being implemented in the IC Semiconductor tabs that can manage, revise, and create the paper travelers for lots.

The Quality department is looking at the possibility of using the same system to manage, revise, and create their quality documents.

Another effective means for reducing the burden of software cost is to purchase non-domain specific components; examples include application servers, software libraries, and databases. These technologies are reusable and not tied to a particular domain vendor.

If you must purchase domain products, look for solutions that use generic components like these so you can get some reuse for future projects.

Open versus proprietary

Solutions for purchase come in two general flavors, proprietary and open.

Proprietary solutions do not have an open, published Application Programming Interface (API) and require vendor-provided custom solutions for modifications or integration with other solutions.

The biggest problem with proprietary solutions is vendor lock in. Changing a vendor for any part of your architecture requires changing all of the other parts as well.

If you have a long-term commitment to a solution and do not foresee much change in your manufacturing processes over the next 10 years, this may be an acceptable risk for you.

An open solution is one where the vendor provides a standard, published API and can interchange data with or execute functionality in other software packages. This approach gives you the ability to replace a portion of your manufacturing IT infrastructure without replacing many other parts.

For example, if a new and much improved Advanced Process Control (APC) system becomes available on the market, you could replace you current APC solution without also replacing your CIM or MES solution.

This is the most flexible approach to software integration but requires some programming "glue" to allow all of the pieces to interoperate. This will require some custom code, either outsourced or developed in-house.

Coping with legacy systems

Legacy systems can be an integrator's worst headache. They are often proprietary, use outdated programming languages, and cannot share data between systems.

The point will inevitably come to decide if that system should undergo integration or if replacement with an open system the best idea. Both are valid options, but a general rule of thumb is if you expect the legacy system or the hardware it runs on to become unsupported in five years or less, it is a better investment to replace it.

If the system has a lifetime of more than five years, integration with software glue is a valid choice as well. The key to legacy systems is to develop non-proprietary hooks.

Such a hook allows you to publish an open API into the system while the hook makes the proprietary calls into the legacy system. These are hooks where you might pay half to integrator to develop and they get the right to sell it to others.

The key to legacy system integration is to develop a complete hook the first time, and not piece by piece. The piece-by-piece method works on a short-term basis but will cost a lot more in the end.