You are currently browsing the category archive for the ‘ECO’ category.
I believe we are almost at the end of learning from the past. We have seen how, from an initial serial CAD-driven approach with PDM, we evolved to PLM-managed structures, the EBOM and the MBOM. Or to illustrate this statement, look at the image below, where I use a Tech-Clarity image from Jim Brown.
The image on the right describes perfectly the complementary roles of PLM and ERP. The image on the left shows the typical PDM-approach. PDM feeding ERP in a linear process. The image on the right, I believe it is from 2004, shows the best practice before digital transformation. PLM is supporting product innovation in an iterative approach, pushing released information to ERP for execution.
As I think in images, I like the concept of a circle for PLM and an arrow for ERP. I am always using those two images in discussions with my customers when we want to understand if a particular activity should be in the PLM or ERP-domain.
Ten years ago, the PLM-domain was conceptually further extended by introducing support for products in operations and service. Similar to the EBOM (engineering) and the MBOM (manufacturing), the SBOM (service) was introduced to support product information for products in operation. In theory a full connected cicle.
Asset Lifecycle Management
At the same time, I was promoting PLM-practices for owners/operators to enhance Asset Lifecycle Management. My first post from June 2010 was called: PLM for Asset Lifecycle Management and Asset Development introduces this approach.
Conceptually the SBOM and Asset Lifecycle Management have a lot in common. There is a design product, in this case, an asset (plant, machine) running in the field, and we need to make sure operators have the latest information about the asset. And in case of asset changes, which can be a maintenance operation, a repair or complete overall, we need to be sure the changes are based on the correct information from the as-built environment. This requires full configuration management.
Asset changes can be based on extensive projects that need to be treated like new product development projects, with a staged approach that can take weeks, months, sometimes years. These activities are typical activities performed in PLM-systems, not in MRO-systems that are designed to manage the actual operation. Again here we see the complementary roles of PLM (iterative) and MRO (execution).
Since 2008, I have worked a lot in this environment, mainly in the nuclear and process industry. If you want to learn more about this aspect of PLM, I recommend looking at the PLMpartner website, where Bjørn Fidjeland, in cooperation with SharePLM, published a course on Plant Information Management. We worked together in several projects and Bjørn has done a great effort to describe the logical model to be used instead of a function-feature story.
Ten years ago, we were not calling this concept the “Digital Twin,” as the aim was to provide end-to-end support of asset information from engineering, procurement, and construction towards operation in a coordinated manner. The breaking point in the relation between the EPCs and Owner/Operators is the data-handover – how much of your IP can/do you expose and what is needed. Nowadays, we would call striving for end-to-end data continuity the Digital Thread.
Hot from the press in this context, CIMdata just published a commentary Managing the Digital Thread in Global Value Chains describing Eurostep’s ShareAspace capabilities and experiences in managing an end-to-end information flow (Digital Thread) in a heterogeneous environment based on exchange standards like ISO 10303-239 PLCS. Their solution is based on what I consider a more modern approach for managing digital continuity compared to the traditional approach I described before. Compare the two images in this paragraph. The first image represents the old/current way with a disconnected handover, the second represents ShareAspace connected approach based on a real digital thread.
The Service BOM
As discussed with Asset Lifecycle Management, there is a disconnect between the engineering disciplines and operations in the field, looking from the point of view of an Asset owner/operator.
Now when we look from the perspective of a manufacturing company that produces assets to be serviced, we can identify a different dataflow and a new structure, the Service BOM (SBOM).
The SBOM provides information on how a product needs to be serviced. What are the parts that require service, and what are the service kits that are possible for that product? For that reason, service engineering should be done in parallel to product engineering. When designing a product, the engineer needs to identify which the wearing parts (always require service in time) and which parts might be serviceable.
There are different ways to look at the SBOM. Conceptually, the SBOM could be created in close relation with the EBOM. At the moment you define your product, you also should specify how the product will be services. See the image below
From this example, it is clear that part standardization and modularization have a considerable benefit for services downstream. What if you have only one serviceable part that applies to many products? The number of parts to have in stock will be strongly reduced instead of having many similar parts that only fit in a single product?
Depending on the type of product, the SBOM can be generic, serving many products in the field. In that case, the company has to deal with catalogs, to be defined in PLM. Or the SBOM can be aligned with the As-Built of a capital product in the field. In that case, the concepts of Asset Lifecycle Management apply. Click on the image to see a clear picture.
The SBOM on its own, in such an environment, will have links to specific documents, service instructions, operating manuals.
If your PLM-system allows it, extending the EBOM and MBOM with an SBOM is not a complex effort. What is crucial to understand is that the SBOM has its own lifecycle, which can even last longer than the active product sold. So sometimes, manufacturing specifications, related to service parts need to be maintained too, creating a link between the SBOM and potential MBOM(s).
ECM = Enterprise Change Management
When I discussed ECM in my previous post in the context of Engineering Change Management, I got the feedback that nowadays, everyone talks about Enterprise Change Management. Engineering Change Management is old school.
In the past, and even in a 2014 benchmark, a customer had two change management systems. One in PLM and one in ERP, and companies were looking into connecting these two processes. Like the BOM-interaction between PLM and ERP, this is technology-wise, never a real problem.
The real problem in such situations was to come to a logical flow of events. Many times the company insisted that every change should start from the ERP-system as we like to standardize. This means that even an engineering change had to be registered first in the ERP-system
Luckily the reach of PLM has grown. PLM is no longer the engineering tool (IT-system thinking). PLM has become the information backbone for product information all along the product lifecycle. Having the MBOM and SBOM available through a PLM-infrastructure allows organizations to streamline their processes.
Aras – digital thread through connected structures
And in this modern environment, enterprise change management might take place mostly in a PLM-infrastructure. The PLM-infrastructure providing a digital thread, as the Aras picture above illustrates, provides the full traceability to support configuration management.
However, we still have to remember that configuration management and engineering change management, first of all, are based on methodology and processes. Next, the combination of tools to be used will vary.
I like to conclude this topic with a quote from Lee Perrin’s comment on my previous blog post
I would add that aerospace companies implemented CM, to avoid fatal consequences to their companies, but also to their flying customers.
PLM provides the framework within which to carry out Configuration Management. CM can indeed be carried out without PLM, as was done in the old paper-based days. As you have stated, PLM makes the whole CM process much more efficient. I think more transparent too.
Conclusion
After nine posts around the theme Learning from the past to understand the future, I walked through the history of CAD, PDM and PLM in a fast mode, pointing to practices and friction points. In the blogging space, it is hard to find this information as most blog posts are coming from software vendors explaining why their tool is needed. Hopefully, these series have helped many of you to understand a broader context. Now I want to focus on the future again in my upcoming blog posts.
Still, feel free to contact me and discuss methodology topics.
Picture by Christi Wijnen – a good friend and photographer in the Netherlands
Some of you following my blog this year might not feel so connected with the content I have written many posts related to digitization and the future needs for model-driven approaches, not so much about topics that might keep you awake at this time.
When I look in my blog statistics, the most popular post is ECO/ECR for Dummies, leading with more than 30.000 views since I wrote this post in 2010. You can read the original post here: ECR/ECO for Dummies (2010)
Meanwhile, in most companies, the scope of PLM has broadened, and instead of a change process within the engineering department, it will be part of enterprise change management, connecting all options for change. Therefore, in this post, I will explain the basics of a modern enterprise change process.
It can start with an Issue
Already 10 years ago I was promoting the Issue-object in a PLM data model as this could be the starting point for many activities in the enterprise, product-related, technology-related, customer-related and more.
My definition of an Issue is that it is something happening that was not expected and requires follow-up. In our day-to-day life, we solve many issues by sending an e-mail or picking up the phone, and someone down the chain will resolve the issue (or make it disappear).
The disadvantage of this approach is that there is no collective learning for the organization. Imagine that you could see in your PLM-system how many issues there were with a project, can you learn from that and improve it for the future. Or when you notice you have had several costly issues during manufacturing, but you were never aware of them, because it happened in another country and it was solved there.
By creating issues in the PLM-system related to the object(s), it concerns (a product, a part, a customer, a manufacturing process, an installation, …..) you will create traceability and visibility based on global facts. By classifying the issues, you can run real-time reports on what is happening and what has happened unforeseen in your enterprise.
The challenge is to find a user-interface that can compete with e-mail as an entry point. So far PLM-system providers haven’t invested in highly user-friendly Issue management, leaving the email path possible. PLM Vendors – there is work to do!
Next, depending on the Issue various follow-up processes can start en some of them will be connected. See the diagram below and forgive me my graphical talent.
In this post we will focus only on the ECR and ECO path, leaving the other processes above open for next time.
The Engineering Change Request-process
The term ECR, meaning Engineering Change Request, might not be correct anymore for requested changes in an enterprise. Therefore, sometimes, you might also see the term CR only, without the reference to Engineering. For example, in the software world, you will not follow the same process as used for the hardware world, due to the different lifecycle, speed, and cost involved with software changes. I will focus only on the ECR here.
As the picture above shows, there are two entry points for an engineering change request. Either someone in the enterprise has an issue that leads to an ECR, or someone in the enterprise has an idea to improve the products and sends it in as a request.
The next steps are quite standard for a typical ECR-process:
Analysis
In the Analysis step assigned individuals will evaluate the request. If it is well understood. Potential solution paths will be evaluated and rated. In case it is a change on a running product, what is the impact of performing this change on current products, current, and future manufacturing, finance, etc. In the analysis-phase there will be no detail design, it is more a feasibility study. In companies already having a well-structured PLM and ERP infrastructure, many of the impact analysis can be done rather fast, as for example the “Where Used” capability is a standard in every PLM-system.
CCB
The abbreviation stands for Change Control Board, a term also used in the software industry. In the case of hardware products, the CCB usually consists of engineering, manufacturing, purchasing, finance and potentially sales, based on the context of the ECR. This group of people decides what will be the next step of the ECR. They have four options:
- Ask for further analysis – a decision is not possible.
- Mandate the proposed change to be planned immediately by promoting it to an Engineering Change Order, which means the change is going to be executed as needed (Immediate for example in case of a product stop/customer issue – Longer Term when old stock needs to be consumed first)
- The proposed change can become a Candidate for the next product release/upgrade and put on hold to be implemented together with other candidates for a release.
- The ECR can also be Cancelled meaning the proposed change will potential not create business benefits for the company. Implementing the change might create more complexity as desired.
Engineering Change Order
The image above is an illustration of a possible flow for an ECO. When an ECO is launched a first analysis and planning is required. The ECO can be based on multiple ECRs, or the ECO can be depending on other ECO’s that need to be coordinated.
The ECO process is quite similar to a release process. There will be multidisciplinary collaboration (mechanical/electrical/ …) leading to a complete engineering definition (based on the EBOM). Next Manufacturing Preparation and Planning can be done, where the implementation at the manufacturing plant(s) will be depending on the ECO context.
Note: When only a change in manufacturing will be implemented, for example when certain parts/materials are not available or affordable, we do not name it an ECO but an MCO instead. MCO stands for Manufacturing Change Order and assumes the engineering specification will remain the same.
Conclusion
The ECR/ECO-process is slowly changing due to digitization and a broader implementation scope for PLM – it is no longer a mechanical engineering change process. The availability of digital connected information will offer a base for algorithms in the future, speeding up the process and reducing the effort for a CCB during the ECR-process.
Will these processes still be there in 2025?
Last week I published a dialogue I had with Flip van der Linden, a fellow Dutchman and millennial, eager to get a grip on current PLM. You can read the initial post here: A PLM dialogue. In the comments, Flip continued the discussion (look here). I will elaborate om some parts of his comments and hope some others will chime in. It made me realize that in the early days of blogging and LinkedIn, there were a lot of discussions in the comments. Now it seems we become more and more consumers or senders of information, instead of having a dialogue. Do you agree? Let me know.
Point 1
(Flip) PLM is changing – where lies the new effort for (a new generation of) PLM experts. I believe a huge effort for PLM is successful change management towards ‘business Agility.’ Since a proper response to an ECR/ECO would evidently require design changes impacting manufacturing and even after-sales and/or legal. And that’s just the tip of the iceberg.
You are right, the main challenge for future PLM experts is to explain and support more agile processes, mainly because software has become a major part of the solution. The classical, linear product delivery approach does not match the agile, iterative approach for software deliveries. The ECR/ECO process has been established to control hardware changes, in particular because there was a big impact on the costs. Software changes are extremely cheap and possible fast, leading to different change procedures. The future of PLM is about managing these two layers (hardware/software) together in an agile way. The solution for this approach is that people have to work in multi-disciplinary teams with direct (social) collaboration and to be efficient this collaboration should be done in a digital way.
A good article to read in this context is Peter Bilello’s article: Digitalisation enabled by product lifecycle management.
(Flip) What seems to be missing is an ‘Archetype’ of the ideal transformed organization. Where do PLM experts want to go with these businesses in practice? Personally, I imagine a business where DevOps is the standard, unique products have generic meta-data, personal growth is an embedded business process and supply chain related risks are anticipated on and mitigated through automated analytics. Do you know of such an evolved archetypal enterprise model?
I believe the ideal archetype does not exist yet. We are all learning, and we see examples from existing companies and startups pitching their story for a future enterprise. Some vendors sell a solution based on their own product innovation platform, others on existing platforms and many new vendors are addressing a piece of the puzzle, to be connected through APIs or Microservices. I wrote about these challenges in Microservices, APIs, Platforms and PLM Services. Remember, it took us “old PLM experts” more than 10-15 years to evolve from PDM towards PLM, riding on an old linear trajectory, caught up by a new wave of iterative and agile processes. Now we need a new generation of PLM experts (or evolving experts) that can combine the new concepts and filter out the nonsense.
Point 2
(Flip) But then given point 2: ‘Model-based enterprise transformations,’ in my view, a key effort for a successful PLM expert would also be to embed this change mgt. as a business process in the actual Enterprise Architecture. So he/she would need to understand and work out a ‘business-ontology’ (Dietz, 2006) or similar construct which facilitates at least a. business processes, b. Change (mgt.) processes, c. emerging (Mfg.) technologies, d. Data structures- and flows, e. implementation trajectory and sourcing.
And then do this from the PLM domain throughout the organization per optimization. After all a product-oriented enterprise revolves around the success of its products, so eventually, all subsystems are affected by the makeup of the product lifecycle. Good PLM is a journey, not a trip. Or, does a PLM expert merely facilitates/controls this enterprise re-design process? And, what other enterprise ontologism tools and methods do you know of?
Only this question could be a next future blog post. Yes, it is crucial to define a business ontology to support the modern flow of information through an enterprise. Products become systems, depending on direct feedback from the market. Only this last sentence already requires a redefinition of change processes, responsibilities. Next, the change towards data-granularity introduces new ways of automation, which we will address in the upcoming years. Initiatives like Industry 4.0 / Smart Manufacturing / IIoT all contribute to that. And then there is the need to communicate around a model instead of following the old documents path. Read more about it in Digital PLM requires a Model-Based Enterprise. To close this point: I am not aware of anyone who has already worked and published experiences on this topic, in particular in the context of PLM.
Point 3
(Flip) Where to draw the PLM line in a digital enterprise? I personally think this barrier will vanish as Product Lifecycle Management (as a paradigm, not necessarily as a software) will provide companies with continuity, profitability and competitive advantage in the early 21st century. The PLM monolith might remain, but supported by an array of micro services inside and outside the company (next to IoT, hopefully also external data sets).
I believe there is no need to draw a PLM line. As Peter’s article: Digitalisation enabled by product lifecycle management already illustrated there is a need for a product information backbone along the whole (circular) lifecycle, where product information can interact with other enterprise platforms, like CRM, ERP and MES and BI services. Sometimes we will see overlapping functionality, sometimes we will see the need to bridge the information through Microservices. As long as these bridges are data-driven and do not need manual handling/transformation of data, they fit in the future, lean digital enterprise.
Conclusion:
This can be an ongoing dialogue, diving into detailed topics of a modern PLM approach. I am curious to learn from my readers, how engaged they are in this topic? Do you still take part in PLM dialogues or do you consume? Do you have “tips and tricks” for those who want to shape the future of PLM?
Let your voice be heard! (and give Flip a break)
This time an article explaining the basics of the Engineering Change Request (ECR) and Engineering Change Order (ECO) as they are common processes across many different industries, often named different, either by the customer or by the PLM supplier.
Although with the new social, WEB 2.0 collaboration, we find new and interesting concepts of engineering collaboration, I wanted to make sure also the ‘old’ processes are described and available for those who need a reference to it.
This post is related to some of my previous educational posts, listed here below:
BOM for Dummies: Engineering to Order
BOM for Dummies: Build to Order
The Engineering Change Processes(es)
In a manufacturing organization, there are is a need to manage many changes in different stages of the product lifecycle. In the conceptual phase, it is mainly the requirements and the change of requirements against the customer or market needs that need to be managed.
Later during the design and manufacturing preparation, there are changes to be communicated between the shop floor and engineering department, which are still internal. Here depending on the organizational structure we talk about change notifications to other departments and suppliers as long as the product is not yet released. These changes can often occur ad-hoc and for that reason not embedded in processes
After the release of a product, we need to manage changes in a controlled manner. This is done through engineering change process, where theoretically we have two types of processes:
The Engineering Change Request (ECR)
An engineering change request can start from anywhere in- or outside the organization and can have a certain level of importance. But the process is similar
The start node can be a customer reporting a problem or an enhancement request from the customer for the future. It can be a service engineer reporting a severe problem (to be solved now) or an enhancement request for the future.
It can be someone in production reporting a manufacturing problem (to be solved now) or an enhancement request. It can be a purchasing agent –working in ERP – reporting that a part is no longer available (to be solved now) or that a part becomes obsolete (to be solved in the future)
The analyze node can be a product manager in case it is related to a product enhancement request, it can be a lead engineer in case of issues to be solved immediately and of course it can be a group of people
The Change Control Board (CCB) can be a group of people – product management, production, purchasing, marketing, who decide on what to do with this proposed change. Their decision is based on the analysis done in the previous step.
The CCB has four options.
- They can request for further analysis, which means the process goes one step back or they can move the process forward.
- The option with no impact is to decline the ECR, which means there is no economical or marketing reason to implement the requested change. It might be clear that this option is only applicable for an enhancement request and not for a severe issue.
In case the request makes sense, it will be approved, but in situations that it is not critical for the current product release, it will be put on hold. This means that only when the product is going to be changed, it will be evaluated if this requested change can be implemented at the same time. Usually at major releases of the product, sometime when the product requires a change, and it is easy to implement.
In case of an urgent issue, immediately an (Engineering Change Order) ECO is planned and in case of a severe issue, it might even lead to several ECOs. This means the requested change needs to be implemented and engineering gets the order to implement this request. It might be, depending on the timing, that some other approved ECRs might be combined with this approved ECR as they can be managed in one change.
The Engineering Change Order
An Engineering Change Order is the process to implement a change. An Engineering Change Order can be based on one or more ECRs, depending on the urgency. In general, an ECO can be generalized as follows:
Or in case no new engineering activities are required, the major steps are followed as below – mainly when the change does not affect the engineering definition – which flow will be used to start depends on the result of the ECR:
The execution of the engineering change order contains the following steps:
The start node can be a product manager, engineering manager or lead engineer who defines which ECR(s) are going to be implemented. The implemented ECR’s are the ones approved by the CCB. The ones that required immediate implementation, in case of a critical situation or the ECRs that were approved and on hold in case of a platform update
This is the step where engineering changes are defined and implemented. Often using the CAD system and changing the engineering BOM
The approval node marks the formal approval of the engineering work, which means engineering believes the engineering process has been completed and the design is ready for manufacturing. It is not a formal release as manufacturing engineering can still find issues that require re-engineering due to manufacturing issues
Note: this generic process is only applicable where the engineering definition is separated from the manufacturing definition. This usually happens in Configure To Order or Make to Stock business processes, as the time between engineering change and manufacturing is not extremely critical.
The manufacturing node is important for companies delivering standard or generic products. In this stage the engineering BOM is translated into a manufacturing BOM, changing the engineering definition into a specific definition for manufacturing – in PLM after this stage the MBOM would be released to ERP.
Note: In many companies, the manufacturing definition is not directly visible in the engineering change order process. For two reasons:
- Engineering is already taking the manufacturing tasks into account, when defining an engineering change. This means the company is working with a kind of hybrid BOM, not 100 % pure an engineering BOM and not 100 % pure a manufacturing BOM. This method is often used in the engineering to order process or in companies where the product definition is very basic (single discipline – understandable impact)
- Historically companies are used to define their manufacturing BOM in ERP. Engineering provides a BOM, which is used as the base for manufacturing planning in the ERP system. This is a very common situation in many companies and leads to a disconnect between these departments for engineering and manufacturing.
Change Notifications
Change notifications are more used during the go-to-production phase of a product. This happens when between engineering and manufacturing there are several steps defined – engineering release, prototype phase, manufacturing definition. In this case notifications of an upcoming change, an approved changed or discovered issue. As these activities are internal and often need to happen add-hoc they are not supported by processes but by notifications inside PLM systems (and/or connected to email systems)
Some PLM remarks:
- ECRs can be originated from anywhere. From a PDM user, an ERP user, a marketing person, a service engineer and for sure a customer. Which means implementing ECRs completely requires cross domain services between different systems in your company. However the place where information will be collected, reviewed and decided on, is the PLM system – as change requests are affecting the product knowledge (IP) for current and future products
- ECO should always start from the PLM side, planning and implementing an engineering change. After finalization the released data will be pushed to ERP for execution
Next week I will share my thoughts about ‘classic’ PLM, PLM 2.0 and all the new social collaboration . Also I hope to meet you in January in London at the PLM Innovation 2011 congress
Jos Voskuil's Weblog 
Jos, what a ride you have had! And looking at some of the spaghetti system architectures of even today's businesses,…
Congratulations, Jos! I'm very happy that you'll stay active in the PLM world and continue with your blogs - during…
Jos, welcome to the world of (part-time) retirement. Enjoy your AOW. Thanks Dick, you have the experience now - enjoy…
Thanks for all the valuable thoughts you have shared with us Jos, hope your 'new career' will bring you lots…
Great.. Congratulations on reaching yet another milestone... your blog is very thought proving and helps us to think in multiple…