concurrent engineering

Anecdotal Evidence for the Use of Concurrent Engineering

Concurrent engineering is the practice of including manufacturing, purchasing, service and any other personnel outside of the design team in a project.  The so-called non-designers bring their unique perspective to the project in order to make it more usable, manufacture-able, source-able  serviceable, etc.  Of course the term non-designer is not true.  Anyone with input to the project influences the design and therefore is a designer of the system.

Concurrent engineering contrasts with the more traditional, design it and throw it over the wall to manufacturing and service.  I'm still surprised how much of this still goes on today.  There are also the companies that claim to do concurrent engineering, but stakeholders outside of engineering aren't brought into the project until it's too late.  The same communication problems, manufacturing problems, sourcing problems, and lack of understanding how the product is used in real life continues.  These problems all have costs, some that are hard to quantify, but are real nonetheless.

It's pretty obvious where I stand on this issue.  I've seen where concurrent engineering provides real bottom-line benefits.  As a former design engineer, it was a pain, but the end result was better.  I suppose fully concurrent project teams aren't more common because of the cost associated with removing productive people and placing them on a project team.  There's also the issue of quantifying the benefit of concurrent engineering so justifying the cost can be difficult, especially for a small manufacturer.

The remainder of this article is some of the anecdotal benefits I've seen from concurrent engineering of systems.

What's Necessary for a Concurrent Engineering Project

  1. All team members must have sign-off authority.  By sign-off, it can be formal or informal.  What's really important is that all members have a say and can't be steam-rolled by one faction of the team. The game rock-paper-scissors comes to mind.  There needs to be checks and balances among all members of the team.  This kind of balance could lead to chaos, so #2 is needed.
  2. Someone needs to analyze trade-offs among stakeholders.  This could be the project leader, systems engineer, or someone with a holistic perspective.  What's important is to have someone responsible for balancing trade-offs among stakeholders to strike a balance that makes the final system (product and delivery system) as valuable as possible.  There is a systems engineering maxim that optimizing a subsystem will hinder overall system effectiveness.  For example, if a product is designed solely for manufacturability, it may be manufactured efficiently, but no one will want to buy it.  A more balanced solution between manufacturability and marketability is needed to maximize overall system value.  What's needed is a referee for the stakeholders.

Marketing/Sales

Marketing and sales should be a part of the team from day one of the project.  They are many times the conduit for the voice of the customer and developing system requirements.

  • They should continue on the team throughout the project to provide input on trade-offs from a business perspective and to monitor any changes in customer needs.
  • Marketing and sales also are invaluable for finding customers willing to test prototypes and pilots.

Field Operations/Field Service/Repair & Maintenance

Anyone who has to deal with the system during and after deployment should be included.  This is especially true during the requirements gathering phase of the project.

  • Designing new parts that are efficient for the product may have negative effects on the overall delivery system.  Example: If a 1/2 HP motor is needed for a new application, but a 1 HP motor is carried on service trucks, it may make more sense to use a 1 HP motor that is less efficient for the application, but more effective from a service, inventory and supply chain perspective.
  • Input on on serviceability issues.
  • Input on the concept of operations.  How will the system be used?  What are the issues when the system is used?
  • Input on potential failure issues.  Can provide valuable input to FMEA.
  • Input on requirements.  People with operating experience have unique insights into what the customer needs, and therefore should have input into system requirements.

Manufacturing

From day one of the design process, manufacturing needs to be involved.

  • Developing the product structure that works with the manufacturing process.  This includes using the MRP/ERP system in an effective manner.
  • Fabrication/welding/assembly suggestions.
  • Use of existing materials and components.  Example:  If a laser cutter has a sheet metal magazine that holds 10 different gauges and material types of sheet metal, it may make sense to design using these materials to avoid hand feeding the machine with special materials.  Manufacturing can provide input in trade-off studies between design performance and manufacturing issues.
  • Effective use of manufacturing assets.  What items can be efficiently made in-house?  What needs to be outsourced?  Recommend design changes to move from outsourced to in-house.

Supply Chain/Purchasing

Suppliers and internal purchasing personnel should also be included as early as possible in the design process.
  • Suppliers can provide assistance with design concepts and minimizing costs before they are locked into the design.
  • Purchasing can provide input into the development of new components or the use of existing components.  Example:  If a new gearmotor is specified by engineering, purchasing can provide a check and balance as to whether an existing gearmotor can be made to work or whether a new gearmotor is justified.  The simple act of questioning why a new part number is needed can be very effective at reducing inventory and boosting purchase quantities.  Many design engineers have a bad habit of designing new components without investigating whether an existing component could be used with some tweaks (I'm guilty of this!).

Conclusion

The ultimate goal of a product development project should be to maximize the value of the complete system. That includes the product and the product delivery system.  Including multiple stakeholders and mandating their participation as active members of the project team will greatly improve the bottom line.

Leave a Comment

Your email address will not be published. Required fields are marked *