The Bloodbath Of Debates About FFF And Revisions

There are very few topics in PLM vocabulary that can raise fewer debates that these three letters – FFF, which stands for Form, Fit and Function. Combined with Part Revision they can create a bloodbath of discussions. Earlier this week, Yoann Maingon made all PLM and Configuration Management pundits on LinkedIn to jump on his article saying Has FFF killed? To sum up Yoann’s question, here is my favorite passage:  

So here, the configuration management issue was the fact that two parts were defined as interchangeable when apparently under certain circumstances (high vibrations) they weren’t.

Considering parts interchangeable when they actually aren’t is an issue, but it is a human decision, so we cannot rely on having 100% decision correct, therefore, if any these decision can have lethal impacts we need to find more poka-yoke-like systems to prevent a bad decision to be reaching the field.

I would have a less technical rule. Don’t hide versions, make sure any change rings a bell in the supply chain and in production. Or, assume the consequences and allow one of your chief engineer to go in jail for an ECO sign-off he has no memory of.

Yoann’s proposal to expose revisions (or versions) triggered a waterfall of comments. He was blamed in re-inventing the wheel and attempting to kill FFF, which is possibly one of the biggest CM holy cows. Check for comments on LinkedIn here. There are almost 100 comments at this moment and counting up. Here are a few of them that I captured:

Paul Van der Ree, Configuration Engineer bij Avantes.
The change process (relation between document revision and part number) has been well-defined for ages. No need to redefine any of it. Parts don’t have revisions or versions, period.

Joe Brouwer President at TECH-NET INC.
“Now I actually tend to like the idea of not revising a part once it reached production state!” I am sure every engineering and manufacturing company would love that. But it is impossible. How many automotive recalls are there. The 737 MAX is parked, hopefully, to fly again. You do not know the nature of engineering. You really need to sit down with an engineer in an engineering group and view the process. Engineers make errors. You are expecting an engineer to see all the problems.

Jos Voskuil, PLM Consultant.
Having read Paul Van der Ree ‘s comment I have to agree with Paul that parts should not have revisions. Revisions come from documents…the PLM confusion comes from the lack of methodology and that’s why users implement “their best practices” not being blocked by a PLM system to do so.

In my view, these three comments are good representations of the opinions – CM practice is a holy cow and nothing can change it, engineers make errors and changes are absolutely natural and part once created will never change.

Will Configuration Management Change?

Configuration Management practices and standards came out of the necessity of very complex and sophisticated product development. Back in the 1960s, complex products such as defense systems presented an ultimate level of sophistication. Today, even small drone manufacturing company demanding to manage product configurations and serial numbers (https://www.openbom.com/blog/openbom-helps-auto-modality-to-track-product-configurations-based-on-serial-numbers). Every single product today is a combination of mechanical, electronic and software. Very often, the software is cloud-based and connected to actual physical products. This level of sophistication combined with agile product development methods might require re-thinking of some fundamentals of CM.

Product Development, Engineering Changes, Engineering to Order

In manufacturing, one size doesn’t fit all. In an ideal world, part and assembly once created never change and if they do change the rules of FFF will apply. I can bring examples when the company required to communicate changes in revisions during development. For complex engineering to order products, the development will be ongoing for 6-8 months and revisions will be made. Product development and contractors’ communication is another example of when work will be revised.

Data Management and Best Practices

This one is my favorite. For many years, I’ve seen tons of examples when companies were trying to force customers to follow the right methodology by applying strong constraints in software tools. While the development of out of the box products is still much easier than providing flexible platforms, in my view, flexibility is always a winner for the long run. Therefore, I’d be concerned by the attempts to restrict companies for doing something that methodologically not right. The first goal of data management to provide a tool to accurately capture data, provide traceability and manage changes. To provide methodology can be a very nice addition to that, but not vice versa.

What is my conclusion? Change is the most constant state. So, things will change and having data management infrastructure to capture changes and manage revisions is absolutely needed. Most existing PLM platforms were born to manage CAD documents, therefore they have not been a tool for configuration management and revision control. Huge progress was done by software CM tools in the last two decades. Unfortunately, PLM systems are trailing behind in their capability to track changes, manage revisions and support configuration management principles. Especially when it comes to a current state of modern product development. A product complexity combined with the complexity of communication in manufacturing created an unprecedented level of data management challenges PLM vendors will continue to face in the coming decade. Just my thoughts…

Best, Oleg

Disclaimer: I’m co-founder and CEO of OpenBOM developing cloud based bill of materials and inventory management tool for manufacturing companies, hardware startups, and supply chain. My opinion can be unintentionally biased.