ECO Objections and remarks
As I’m now in the business of editing PLM software with Ganister. I have been involved in defining what would be a correct way of dealing with configuration management (CM)...
Filter by Category
Filter by Author
Worked for 10 years in PLM as a user, integrator and software editor, I like to have a very wide approach of PLM. I share my thoughts about various functionnal bricks of PLM but also about the technological stack supporting PLM.
As I’m now in the business of editing PLM software with Ganister. I have been involved in defining what would be a correct way of dealing with configuration management (CM)...
Posted by Yoann Maingon
Now that we have seen the most simple change in my previous blog post, let’s talk about the revision mechanical engineers will hate : THE NON-INTERCHANGEABLE REVISION !!!...
Posted by Yoann Maingon
On my french blog I wrote a blog post about some suggestions for a flexible configuration management solution. I’ll reproduce the article in English soon for a broader...
Posted by Yoann Maingon
Wow, this blog took a dramatic 180° turn. Don’t worry, this is still talking about PLM and more precisely about the Fit, Form, Function (and Safety for some companies)...
Posted by Yoann Maingon
When it comes to PLM, it is difficult to have a clear opinion on business models. These last few days I have seen multiple business models and pricing configuration from PLM...
Posted by Yoann Maingon
I wish you all a happy new year. My blog colleagues all came up with predictions for either the coming years or like oleg and Jos, for 2030. There are some very interesting...
Posted by Yoann Maingon
I just stumbled upon a video from CNBC just yesterday about the rise of Open Source. It gave me a strange reaction at first. Open source is getting bigger every day. NPM packages...
Posted by Yoann Maingon
What is the language your PLM solution has been built with? It is something that barely comes up in PLM evaluation. Does it matter? I think so, but in order to know why it matters...
Posted by Yoann Maingon
PLM solutions are mostly web-based nowadays. To access the main User Interface of these PLM solutions you need a web-browser. Web browers are eating 3 languages: HTML CSS...
Posted by Yoann Maingon
Many years ago, I had fun creating a stopmotion video to explain what PLM is. Today I wanted to gather all the videos on youtube which actually have “what is plm” in...
Posted by Yoann Maingon
As I’m now in the business of editing PLM software with Ganister. I have been involved in defining what would be a correct way of dealing with configuration management (CM) focusing on the change management process. To bring my ideas to this CM process I’ve looked back to the objections and remarks I received. These are the main inputs I’ve brought to build a greater ECO.
In a few solutions I have seen the Engineering Change Order was revising all the necessary parts and documents. At the end of the process, validating the engineering change would automatically release the new revisions. When you run a demo, this is great, usually impressive and helps explaining a smooth change management story. But some people came up to me and said: “you can’t validate 10 parts at the same time”. And I believe that is scary when you think about it. So some solutions separated the document validation process believing that Parts could all be released at once, once documents would be individually validated. But it means getting back to the old document centric PDM system. Validation doesn’t only rely on drawings, it can contain simulation results, costs,…
I had a discussion about it with a Manager from a large PLM company and we agreed on one point. The main reason why this exists is because for a long time the PLM was managing part and document records. It was more a safe than an actual workspace. Therefore records where only entered when validation was done. And usually was done elsewhere.
Releasing everything at once is a bad idea.
In most ECO solution I have seen. you have a grid in which you can define what you are doing with the product structure your are changing. It usually helps understanding what the ECO is about. Like changing a quantity on a BOM relationship would be defined there.
The problem is that, when you run your process, at some point your parts will be in an editable mode. There, you can do the same changes outside the ECO grid. Update a CAD assembly for example from your CAD system. Will it update the ECO grid explaining that something changed on a BOM relationship? It should and I believe some solution already do it.
You shouldn’t go into to much details about the change you are planning to do in the ECO grid. You should define what nodes will change but of course a report should be always reporting what has changed. ECO is about what can be changed, and then reporting what has changed.
The interchangeability question is still running. After my article “Has FFF Killed?” Martijn Dullaart wrote another article (linkedin comments) about it and I don’t believe we agree much about revisions and interchangeability.
I’m trying to describe a configuration management system that does not care if a node is a part, a document, or a assembly process. Many statements start with “Part has no revision in production, this is written in CAD-Mag 1983”). I do believe we can challenge this statement by understanding why it was said in the first place.
Part Revision being interchangeable was a trick used by mechanical engineers to avoid pilling up changes at the top of an assembly. This was when part validations were done with 8 physical signatures on a piece of paper! The electronic manufacturing world and the software world (I’d have to ask the chemical industry) do not use the same rule.
But back to our ECO definition and the use of interchangeability, I still believe this is up to the company who implements it. Therefore a good change management process should allow companies to use this rule with the correct warning. Interchangeability are always decided within a known context.
Part ReUse is always a tricky thing to demonstrate when we get objections. Engineers tell me : “If I have an issue on a screw and I need to replace it with another reference, than all the impacted assemblies should be revised”. The limit is in terms of responsibilities. How do you make sure that all assemblies should be impacted the same way. Therefore I believe the impact should be decided for each assembly. And this could be done in a collection of ECOs, because the initial change may trigger various changes with various related projects, people, timelines,…
The ECO acronym often means Engineering Change Order, but more and more we are asked for Enterprise Change Orders. That is the reason why I’m trying to always think about nodes without giving them types in the first place. Later, once you validate your system you test it with real references and real types (parts, documents, …)
Then I’m told : “but the ECO will be enormous if you have to change something impacting a whole thread from requirements to support”. First, if your ECO covers the full digital thread, it is not so bad. And then I believe a full change from requirements to production and support could be split in multiple related ECOs (the top ECO being either an ECO, or a project).
This post is way longer than I anticipated. To sum up this post :
Happy 2021 for everyone and I’ll try to write more than last year !
As an enterprise-wide data management platform, one of the main PLM goal is to provide the users with the right data at the right moment. The digital thread should provide a...
On my french blog I wrote a blog post about some suggestions for a flexible configuration management solution. I’ll reproduce the article in English soon for a broader...
Don’t miss any post by subscribing