You are currently browsing the category archive for the ‘ECO’ category.

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)

 

Advertisements

clip_image002_thumb.pngThis time an article explaining the basics of the EngineeringChange 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

BOM for Dummies: Configure to Order

BOM for Dummies: BOM and CAD

Connecting PLM and ERP: Post 1, Post 2, Post 3

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

clip_image002

clip_image004The 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)

clip_image006

 

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

 

 

clip_image008

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.

clip_image010In 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.

clip_image012In 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:

clip_image014

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

dontmiss.pngNote: 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:

  1. 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)
  2. 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

%d bloggers like this: