The Bloodbath Of Debates About FFF And Revisions
Oleg Shilovitsky
CEO @ OpenBOM | Innovator, Leader, Industry Pioneer | Transforming CAD, PLM, Engineering & Manufacturing | Advisor @ BeyondPLM
The original article was published on my Beyond PLM blog
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.
Wow, Oleg Shilovitsky?I didn't think it was possible for you to rock this boat any harder but you've managed to do it. Nice work. This is a complex issue, one that you have been talking about for years.
Every time you're right Oleg. We need to think about Product changes dynamically and not statically; There is two levels Version (Revision) and Iteration to manage work in conception (R&D and ME). Some organization consider versioning only in R&D area. That's completely wrong. Just an example. Do you how A320 has parts and more over changes from 1989 first of commercial flight ? Do you how many changes are mandatory in a flying aircraft during its life ? What's the full change process ? That's not easy but there are some solutions working efficiently. You need the right configuration life cycle able to manage changes safely in real time. best way is to link PLM to ERP and MES in both side. Please tell me if you think about that and if you are working on this subject. Thank you to everybody and specially Oleg
Manager Project Engineering bij BOAL Systems
4 年Oleg Shilovitsky The possibility of making revisions could also be seen as a tool that allows you to manage the history of your product or document. If you are creating a new part number in order to avoid making revisions, you are not managing the history. You will end up with two almost identical parts, that have no relation to each other. Over time, no one will know the difference anymore. Subsequently it will be only a matter of time until someone applies the wrong one risking the same “lethal” consequences. So, making a new part does not solve the problem. If the risks are so high, that the consequences are called: “lethal”, you might want to perform a proper Failure Mode and Effect Analysis (FMEA) on the changes, in order to manage that risk. It has nothing to do with the choice of making revisions or creating new parts. What is your view on that?
Business Consultant, Industry 4.0 at iK3M Consulting
4 年Philippe DECROIX
Business Analyst & PLM Consultant - ECBA
4 年I support your point of View Oleg. In the Grand Scheme of Things (GST... is that a recognized TLA?) there is a need for revisions. It’s easy to “win” the debate against it in a narrow minded scope. But once you put on the shoes of all stakeholders and have walked a few miles, you get the point.