For a start, let’s walk through the high-level business process of product retirement. Typically, we decide to retire a product when we are doing a periodic review of our product offerings and looking at whether it makes sense to keep selling a product or not.
The first thing we will do once we decide to retire a product is to create change documentation and start our paper trail of product obsolescence. Then, we will route that change through any relevant departments for approval. For example, we might want to alert marketing, so they can update our catalogs to remove the retired item, or we want to update sales so they can change product forecasts.
Once we have got approval to retire the item, we need to identify whether there is an item that would be sold as an alternative so that way we can update the product record to drive sales to the alternative/replaced product.
We will also need to determine what to do with any remaining stock or work-in-progress orders for our inventory for the item that we are making obsolete.
Once we have gone through all of the processing steps, we will finish by updating our product life cycle state to reflect that it is now obsolete. We don’t ever want to delete old products from Dynamics since we want to keep the transaction history integrity. All we need to do is update the product so it can no longer be sold or produced.
Engineering Change Management – Workflow
There are two out-of-the-box workflows that we can configure in the system:
- Change Request Workflow;
- Change Order Workflow.
Change Order Workflow
If we look at the change order workflow, there are different approvals steps, and tasks available to achieve maximum control and automation in the whole process – be it a new engineering launch process or a product change/retirement process.
The first step would be ‘approve engineering change order’, which approvals the change order. Once the change order is submitted with the product impact details, the next step is approval. Approval can be assigned to a specific group of users – product managers or product owners, depending on the approval process.
The next step is the process changes, which is executed after the change order is approved. This is an automated step that will create the engineering product and engineering product version and all the related details, such as the BOM formula route in the engineering organization.
Then, the flow moves to the process dependency step, which is a task, and a placeholder, to complete any dependency of a specific change. For example, if the product formula is changing.
The next step is a ‘release/activate product’. Once the dependencies are taken care of, then the new engineering product version needs to be activated in the engineering organization. Note that this task is just a placeholder to activate the version – it does not automatically activate the product version.
The following step is ‘collect/process release proposal’. This automation step releases the new version of the engineering product to the operational legal entity based on the release policy setup. The automation works if the product impact is either none of the new variant/product from an existing product. Meaning the product has been at least released once.
So if you create a completely new product in the change order, then the new product requires the release product structure-function to be executed manually. Creating and releasing a proposal does not release the product to the operational legal entity automatically as part of the workflow.
The last step we have in the workflow is ‘complete the change order’. This step will basically mark the change order as complete so that nobody can make any changes to the change order, and we can finalize our change order.