Product design changes are inevitable. In fact, they are an essential part of the product lifecycle. Changes to a product design are triggered and implemented mostly (but certainly not only) during design, prototyping and test iterations in response to a new market requirement, a cost take-out campaign, changes in cost or availability of a critical component, issues discovered in manufacturing or even in field repair, and myriad other reasons.
Engineering Change Orders
Industry uses different terms and acronyms to identify the design change process: engineering change order (ECO), engineering change request (ECR) and engineering change notice (ECN). Your company may prefer yet another term. Yet, one thing that large product organizations have in common: they take a highly formal and structured approach to managing design and manufacturing process changes.
Design changes may be necessary in response to, say, a new market requirement. A typical ECO process identifies the reason for the change in the product design or manufacturing process, details of the design or process change, and potentially other information such as cost impact analysis.
This sounds great until you take a hard look at actual ECOs.
Many ECOs are Preventable
The figure below shows a breakdown by root cause of ECOs at a large industrial equipment manufacturer. Careful review of the classification of ECOs in this chart reveals that many ECOs are preventable. A few examples of avoidable design mistakes that resulted in an ECO:
- A design feature that does not match the capabilities of a preferred supplier, for example, special manufacturing process or machinery.
- Drawing errors.
- A design that cannot be manufactured to meet quality targets, for example, because of inadequate wall thickness or incorrect draft angle in plastic molding.
- A design exceeds the part’s cost target.
Detailed analysis of these ECOs reveals a multitude of factors that contribute to the high rate of preventable ECOs—in my research I have seen it as high as 80%—and the waste they create. But fundamentally, most, if not all, of these factors can be rolled up into a single general root cause: engineering organizations do not capture and use knowledge, experience, and best practices effectively. Under pressure to accelerate the pace of getting new products to the market and the emphasis on agile development methodologies, engineering teams may decide to skip the formalities and not document ECOs fully and in a manner that newly acquired experience, knowledge, and best practices can be reused in future designs.
As I commented in another blog post:
Organizations that do not retain detailed change history are bound to repeat design and manufacturing errors, going through unnecessary design iterations and manufacturing rework.
When is the Best Time to Implement an ECO?
Common wisdom, especially if you have a quality engineering bent, is to implement an ECO as soon as possible. While this is very rational decision if an ECO is to address a safely issue, there may be reasons to hold off and not implement other classes of ECOs right away.
When an ECO is issued for a product that is already in volume production, the design change may result in scrapping work in process, part obsolescence, disposal of “bad” inventory, or rescinding a supplier contract. On the other hand, not executing that ECO will result in continued product failures, service calls and warranty expenses.
But with the understanding of these differing views, business owners can make a rational business decision: should the ECO be implemented sooner in order to prevent failures and the associated costs and damage to the brand image? Or, perhaps, should the ECO be delayed in order to minimize direct losses in inventory and work in progress?
Recommendations
The ECO process is an essential product lifecycle activity and should be managed as such.
- The root cause, the corrective actions, and other information such as cost impact analysis need to be incorporated into the PDM system so that design and manufacturing errors are not repeated. In particular, recording the design intent behind every design and process changes can accelerate design time, reduce design iterations, and promote quality.
- In the same vein, a centralized view of cross-product ECOs can facilitate faster and efficient root cause analysis of design and quality issues.
- Managing ECOs inside the PDM software also helps implementing any number of derivative activities such as updating work instructions, supplier communication, and compliance verification.
- Finally, PDM, together with ERP, are ideally suited to provide the additional context necessary to perform a detailed impact analysis and prioritize ECOs.
As a parting thought, here is one use of ECOs with which I do not entirely agree. I worked with a manufacturer of high-tech equipment that fully embraced the ECO formality and integrated it methodically and painstakingly into the product development process. The engineering team tracked the rate of new ECOs to determine what they believed was an indicator of “design maturity”: when the number of new ECOs fell below a certain threshold, the design was deemed ready to enter volume production.
In my opinion this strategy represents the exact opposite of a PDM-centric knowledge-based development, where design and knowledge reuse are use to reduce the rate of design errors at the root instead of going through the iterative ECO process. But that’s a topic for another post.
The Next Generation of PDM
More teams are using Cloud, Analytics, Mobile, and Social tools to speed up product development. Independent analyst firm, Consilia Vektor, explains how this changes Product Data Management (PDM) as you know it and how this can help your team work smarter.
