I think Form-Fit-Function is dying a slow, cruel death.
So the final edition of this year’s The Future of CM’ newsletter will answer the question: Is Form-Fit-Function (FFF) doomed?
Form-Fit-Function is incomplete
FFF has been misused or incorrectly used as a tool to identify the impact of changes to a part. It is often used to see whether you can ‘revise’ the part instead of re-identifying it (a.k.a. rolling the part number). That is the wrong mindset. It is actually about interchangeability and traceability and understanding the risks involved in our re-identification decisions. Even when FFF can be achieved, there can be reasons to still require a new part number. While FFF is a valuable tool, it is incomplete and difficult to use in the context of highly complex systems. A proper impact assessment needs to be conducted by a cross-functional team.
“What is often forgotten is that while form, fit and function (FFF) still applies, there are changes to the way service has to deal with the part. This is something that is not seen if you let the design engineer make re-identification decisions where manufacturing engineers or service engineers have a better view on these types of things. Next to that traceability is often overlooked in re-identification decisions. For instance, the need to re-identify a part because you need traceability that otherwise cannot be ensured. “
It starts with requirements. Interchangeability can be assessed against the requirements the part must conform to. While the following example is very simplistic, it shows how to deal with requirements in the context of interchangeability. If the requirement is that the part must have the color’ Bright Red’ / PMS: 2347 C / HEX COLOR: #E10600 / RGB: (225,6,0) / CMYK: (0,94,100,0). Then a part that is blue or even red that deviates from the bright red is not the same and, therefore, cannot be interchangeably used. However, when color is not a requirement, then whether the part is blue or red is not essential and can be used interchangeably. For instance, if the part is not outward-facing. Or when tolerances are used to indicate the color, for example, RGB (225±15,6,0), all parts that fall within that tolerance are fully interchangeable. If a difference in color matters, there must be a requirement for it.
Changing requirements
Requirements can change, but that does not mean you can blindly change requirements and expect all existing parts to conform. That is why when you change requirements; you have to verify this. There is no issue when existing parts can conform to the updated and/or added requirements. However, when that is not the case, you need to issue new requirements and new parts because the existing parts will keep conforming to the old requirements, while the new ones will need to conform to the new requirements.
So if the current requirement is that the part must have the color Bright Red RGB (225±15,6,0) and all existing parts are currently conforming to RGB (225±10,6,0), changing the requirement tolerance from 15 to 10 is not an issue. However, if you want to change the tolerance from 15 to 5: RGB (225±5,6,0), you must create a new requirement and issue a new part number.
In other words, the impact assessment of a change is crucial in understanding the impact on the existing documentation and the re-identification decision for parts.
Increasing complexity
More and more products are increasing in complexity. For a large part, this is because software starts to play a role. So the number of dependencies increases significantly. Software over-the-air updates increase complexity as well. Also, the context in which the products are being used or maintained drives up dependencies. For instance, if the same product is sold or used as a service. When it is used as a service downtime, cuts into the revenue. When you sell a product, your focus is more on selling instead of focusing on uptime.
While FFF is incomplete, it is also difficult to assess with this increased complexity. Not one person knows everything about the part or the product. We need a cross-functional team to assess the impact of a change and come to the right decision. A mechanical engineer needs input from the software engineer when there is a dependency. But also, the supply chain expert, manufacturing engineer, and service engineer are required to fully understand the real impact a change will have.
For instance, if in the field, service uses different tools to replace a part because of the conditions in the field than used in the factory, the impact of the change can be different for the factory and field. And sometimes you just need a mitigation when you are in the field and do not have access to anything better:
Uncredited picture originally found on crazyhyena.com (no longer exists)
On top of this, all kinds of regulations like RoHs, Reach, CFR 820 part 11, etc. increase complexity as well.
Understanding risks
Whether the change to a part results in a new number or you keep using the same number depends on risks and the number of risks you want to take. When deciding to re-identify a part, you reduce interchangeability and traceability risks. Safety-related parts will likely be more often re-identified to mitigate the risk of interchangeability and traceability associated with the change. On the other hand, parts that have a limited impact on safety or the product’s performance are likely less often re-identified as risks are perceived more acceptable.
Other aspects that can impact the risks are (not exhaustive):
Commonality – how often is the part reused
Interfaces – amount and type of interfaces
Regulations – amount and type of regulations that apply
Stock – the amount of stock internal and at the supplier or customer
Fielded Products – the number of products in use and their accessibility
Manufacturer – who manufactures the part and which tier supplier
…and many more
Even when you do not want to issue a new part number, assessing the risk is vital to understanding the risks involved and identifying mitigation strategies to deal with the risks appropriately.
So is FFF Doomed?
No FFF is not doomed, but the application of the FFF tool requires cross-functional collaboration and an end-to-end understanding of the impact of a change. Having insight into all the dependencies is not an easy feat. And with the risk of repeating myself, it requires a CM Baseline, as I have described in previous articles (see below for the complete list).
It might also require smart classification of changes and parts to help people understand the context they are dealing with. Is it just a replacement of a standard component, or are you changing a part to increase performance? Is the product in which the component is used a coffee cup or a car?
What do you think about FFF? Feel free to share your opinion. The FFF discussion is far from over.
Find out more on Form-Fit-Function, Interchangeability, and Traceability in these articles: