Engineering change management (also known as ECM) is used by manufacturers to track and process updates to product information. They do this for a few main reasons:
- ECM helps increase traceability within the product life cycle. With ECM, the system has a workflow that tracks requests for changes and records approvals throughout the change process;
- ECM allows for greater control in the product control process. You can have different owners of different products and route changes to the proper approvers. You also can control what types of transactions the product is ready for; implement mandatory checklists that products have to clear before they are ready for use;
- Lastly, one of the great things about ECM is the ability to take what is historically paper or manual processes and put them into the system. Using system workflows, we can avoid playing phone tag or digging through our inbox to find the engineering sign-off on a new product.
Types of companies that use ECM
As we have already mentioned, ECM is traditionally a tool used by manufacturers, but within this industry or horizontal companies to support their product lifecycle.
One common reason manufacturers will use ECM is if they have a maker engineer to order fulfillment models. In these kinds of cases, there is a lot of activity going back and forth between the product design team, customer, and other departments like sales and production. ECM helps support this collaboration ensuring the proper design procedures are followed.
Another common attribute of any ECM user is if the product or process is highly complex. ECM allows for greater visibility and control, especially when managing product changes in that kind of environment.
Global companies with a large footprint also benefit from using ECM to define product ownership across their teams, control product rollouts to different entities, and improve communications within different departments across the globe.
Lastly, another common type of company that will use ECM is a heavily regulated company. For such, the traceability aspect of ECM functionality allows them to make sure that they are in compliance with government regulations and give them the tools they need to pass regulatory audits.
Product Lifecycle Process
New Product Creation process with ECM
First, let’s talk about the new product creation process and how that incorporates ECM and Dynamics.
New Product creation typically starts either as a part of a cyclical process of reviewing and updating product offerings or as a result of a customer requesting a product that we don’t currently stock.
The first step in getting a new product set up is to define what the product will be and how we will make it. This is not something that’s specifically tracked in the ECM module and Dynamics, but we might use the project management and accounting module in Dynamics to track the related research and development expenses, as well as our initial production runs.
Once we know how to make the product, we can complete the initial setup of the product. We define information such as ownership, system classification, etc. We can use approvals to make sure that our information is complete and correct.
Next, we send the information about the product and how to make it to any of our manufacturing sites that will produce it. We can choose what data should be controlled by our central engineering org and what will be controlled by each specific location.
Each manufacturing site will review the information sent and create the final setups needed for them to begin production. Again, using ECM controls to ensure that all steps are completed and approved before transacting.
Finally, we update the product lifecycle state to reflect that we are ready to launch the product for use in transactions.
Product Change Process with ECM
After products have been launched and are in use, we will likely need to make updates throughout the product lifecycle. Normally, updates are driven either by a periodic process of reviewing product offerings, or they might come up ad hoc throughout the product lifespan.
Once the request has been raised, we will typically want to investigate whether the change is feasible and what the implications are of that change. For complex changes, we may use projects to track the costs of the research or test runs in production – just like we do for new products.
If we decide to approve the change (and determine that it should be an update to our existing product), we will create change documentation to track what the changes are, as well as various approvals we want to capture for the change. We will also analyze the business impact of the change and identify any on-hand or work-in-progress inventory.
Once approvals are completed, we can release the updated product information to the manufacturing entities – just like we did with the product launch.
When we are making a significant change to our product, especially regarding the Bill of Materials, we may address the disposal of old versions of inventory in a couple of different ways. We might simply scrap the inventory and record that in the system, or it might have a promotion to sell the remaining inventory at a reduced price to deplete the stock as quickly as possible.
We might also want to look at work-in-process production orders and determine what action we want to take for those specifically.
Product Retirement Process
Finally, at the end of the product lifecycle, we are going to retire our product.
Once we have decided that our product is due for retirement, whether that’s because we have a new product to replace it or it’s just not a profitable product anymore, we will start our same change documentation process to record that we are retiring this product and go through all the proper steps our business defined as workflow.
One of the key points here is that we will update the product lifecycle state to indicate that it is no longer available for use in sales or procurement transactions, for example. It will allow us to maintain visibility into the product by keeping it in a system (and not deleting it) but preventing it from being used.
Finally, we need to think about how we are going to dispose of obsolete inventory if we still have inventory on hand and as we are going into the product obsolescence process.
