Bridging the Gap: Engineering to Manufacturing

The gap between engineering and manufacturing is legendary. Some would say it is similar to the Hatfields and the McCoys.


The gap between engineering and manufacturing is legendary. Some would say it is similar to the Hatfields and the McCoys. To truly bridge the gap, we have to first understand the nature of the differences, and build a bridge that supports those discrepancies.

The divide is further exasperated by the fact that organizationally, engineering and manufacturing do not converge and report to a common interest until nearly the top of the organization chart. The only real way to bridge the gap is to bridge the differences separating them.

Product vs Process

Designers are focused on meeting a client's need; the product should be "only so long, only so wide, will hold X amount." Designers are challenged with available materials and cost constraints. While most designers are aware of the environment their product will be manufactured in, and often have the availability of test labs, their priorities are meeting client needs within a timeframe and a cost structure.

The manufacturing team has the opposite perspective. They are less concerned with the product and how it fits the client's needs, and more concerned with being able to produce it in a timely manner. Concerns of the manufacturer start with sourcing materials and optimizing the asset of the plant - the equipment, materials and people to produce the most products with their available resources. Manufacturers schedule the workload, assure the proper equipment and trained personnel are available, comply with regulatory and EH&S requirements, and handle issues and non-conformances. Their goal is to get the product out the door, to specification, on time.

Although these two worlds are intricately involved from an overall company perspective, if you are to bridge the gap between them, it is important to understand how very different their day to day focus and objectives are.

Design vs Execution

Despite "design for manufacturing" initiatives and other attempts to bring these disciplines together, their orbits only naturally collide at the turnover of the product. Creating turnover activities and gates that give the two sides an opportunity to work together and understand the other department's goals and constraints is essential. There are two times when engineering and manufacturing intersect with respect to a product: when the product is initially produced and if there is an issue or update to the product that needs to be addressed.

Launching Products

When products are launched, many industries have standards for assessing and mitigating risk.

FMEA and control plans are standards in the aerospace and automotive industries, and are quickly being adopted in medical device and other manufacturing verticals. FMEAs identify and rank the things that could go wrong when producing a product. There are product, or design, FMEAs (dFMEAs) that identify flaws with the production of the product itself. There are process FMEAs (pFMEAs) that identify flaws with the logistics and process of producing the product. Finally, there are Control Plans, the operational counterparts to FMEAs, which are the tactical actions to mitigate the risk.

FMEAs all too often are created and then "vaulted" into dead document status. There are a few key things that can make them an active and effective communication vehicle to bridge the divide between manufacturing and engineering.

  1. Be sure that your FMEA team is cross functional and contains shop floor operators or supervisors from where the product will be produced.
  2. Don't make the team so big that it takes on a committee endeavor.
  3. Provide an ability for each discipline to share goals and constraints.
  4. If possible, have floor access or even video of areas of concern.
  5. Provide an update mechanism so that as the product goes to production, assumptions can be validated and effective feedback provided to make the FMEA reality-based.

Creating FMEAs with the right input is half the battle in bridging the gap. The second half is assuring that the document doesn't simply get vaulted with all of the valuable insight falling by the wayside. The information in FMEAs should actually be used to drive control plans, which in turn drive inspection plans, equipment planning and calibration, work instructions, employee training, etc. The most productive place to create FMEAs is not in an engineering system, where it is the end of the line, or a stand-alone system where it is an island, but in an Enterprise Quality Management (EQM) system where it can be used to drive important downstream manufacturing functions, initiating the "push" of data into manufacturing.

The Change Process

The second area where we want to bridge the gap between manufacturing and engineering is during the change process. As with the launch process, we want to promote information exchange in both directions.

Changes can happen for a variety of reasons, and by a variety of players: 1) customer complaints/suggestions; 2) supplier change requests; and 3) internal requests driven by both issues and suggestions. Regardless of the source, they all need to be evaluated. Engineering changes are in fact divided into three distinct steps:

  • Engineering change request (ECR)
  • Engineering change notice (ECN)
  • Engineering change order (ECO)

Engineering Changes

With an ECR, engineers need to get as much information regarding the need for the change and the source of the problem. Engineers generally have to rely on going "door-to-door," accessing spreadsheets, CRM systems, supplier databases, and more. Often, they make changes without complete access to information. And, just as manufacturing people don't want to wade through long documents to find a part number, engineers don't want to wade through nonconformance logs and have to make a half day of calls looking for information - they need the information at their fingertips. EQM systems can once again bridge the gap. With EQM, engineers have automated access to information regarding all complaints, suggestions and nonconformances. Not all EQM systems are created equal, but the more robust systems provide a product view of information. Engineers can look from a product perspective and have access to all the information they need: customer communications, photos or video, drawings, floor notes, work instructions, etc.

Once a change is approved, a change notice is the go-ahead to make all of the required updates to support a change. The ECN is the most errorprone stage of the change process because it is where the change gets thrown over the wall from engineering to manufacturing. If all the updates aren't made properly, a piece of equipment isn't calibrated properly, the inspection plan isn't updated, and the wrong material is put on the line. Or, employees aren't trained in a new process, and instead of fixing a problem, a new one is created. The key to bridging this gap is to have the ECR information flow seamlessly into an ECN, systematically flagging all work instructions, inspection plans, equipment/calibration, employee training, etc. By tying systems that hold the information together in a way that drives downstream processes, work can flow seamlessly between the two organizations.

The engineering change order says when to start the change. This has long been the domain of ERP systems and is done well. Synchronization with the ECN process being accurate and complete will assure that when the change commences all of the pieces and parts are in place to make the change successful.

Finally, in closing the loop, engineers often send their designs and changes over the wall, never sure how effective they really are. By using the product-view of an EQM system they can understand if Cp and Cpk have been reduced, and what the effect has been on overall defects and PPMs.

Document vs Data

Probably the best opportunity for building bridges between the two groups is to bridge shared information. As CAD systems evolved into PDM/PLM systems, it was suggested by both software vendors and by engineering staffs that manufacturing groups be given read access to their documents. The concept was sound; by sharing information and by making the final designs and specifications centrally available, that information could bridge the gap between these two groups. That theory would have worked if manufactures were product centric - or document centric like engineers were.

The reality of inspectors, equipment technicians or quality engineers accessing a CAD or PLM vault and looking up a design document in order to get the correct tolerance/revision of a part is not always practical. For those that have spent any time in a busy receiving bay, on a production floor, or in a quality fire drill, this is obvious. Just like engineers in our change request scenario wouldn't be expected to wade through nonconformance and customer suggestion logs looking for their information, it isn't practical, or productive, to have manufacturing people searching through document vaults.

Bridging the Gap

The reality is that people on the floor need data, and they need it pushed to them when it has been updated. Inspectors need the inspection criteria for a specific part from a specific supplier; equipment people need the internal diameter of a revised part spec - and they typically need it quickly. Often, to support these functions, clerks set up stand-alone spreadsheets, or elaborate notification systems are set up to trigger changes to the various spreadsheets around the floor, the quality office, and the inspection bays whenever changes are made.

IQS is one of the few vendors that has an automated connection mechanism that strips part characteristics from drawings in a CAD or PLM vault and automatically populates a highly-integrated EQM system. Once IQS activates the engineering bridge, characteristics are automatically brought over and kept in sync across all of the areas that drive a quality product.

By bridging the data to and from manufacturing, we bridge the communication gap. The two jobs are far too different, and too complex, to have one become an expert at the others' jobs and systems. By exchanging the information they need to do their jobs, and providing views that are tailored to their work needs, technology, and specifically EQM systems can go along way to bridge the divide.

May June 2008
Explore the May June 2008 Issue

Check out more from this issue and find your next story to read.