In a previous article we got acquainted with basic ECM entities and features that will help us to understand how ECM can be used in practice and reduce product time-to-market. Let’s look at our example.

We will be transported to the imaginary enterprise with some introductory notes. We are a company that produces carbonated soft drinks. Our company has a branched hierarchy and owns a few factories. We have a global company (BVRG) that is an engineering company and a few local companies that are manufacturing plants.

At the global company, the chief technologist works with a team who develops new drinks, improves existing recipes, including looking for ways to reduce production waste and save resources. All our companies are consolidated in one ERP, and they use the ECM module.

Enterprising technologists have recently developed a recipe for a new drink.

The product manager in the global company has created a new item of our new carbonated soft drink (item number FP-1010). He also configured the 1^st version: created formula (because producing drink is process manufacturing), production route and attached some documents. The product has passed all laboratory tests, received a high assessment of quality control, confirmed by analysis certificates, and went through many routine steps to launch the market. This drink was produced by only one plant (BVRG) for several months. The consumer liked the new product, and we decided to expand production. The production facilities of the factories USP2 and USMF allow it to be done.

In order not to create items from scratch for each of these plants, some settings from the previous article have been made in D365FO: they allow you to completely duplicate the item, its version with all its contents, to other companies in the system. This function launches the wizard and guides you through the release process step by step: As a result, the product was copied from BVRG to the selected 2 legal entities.

Then product owners should make sure that all information has been transferred correctly and accept or reject the release. As a result of the check – no errors were found, so we accept the release and activate the versions in each of the legal entities:

Now USP2 and USMF legal entities have all the necessary data for production accounting in the system.

Our enterprises have been producing the product for quite a long time. We firmly hold our positions in the market of non-alcoholic beverages, our customers and consumers trust us.

Recently, we have been actively defending our position on environmental protection. We know that a huge amount of plastic waste in the world is empty beverage bottles. First of all, the responsibility for the preservation and protection of the environment lies with us. Therefore, the company set a goal: to reduce the amount of packaging material for the finished product.

We are now using a preform for pouring a drink weighing 50.7 g. We produce approximately 91,250,000 bottles of the finished product per year, which is about 4,626,375 tons of plastic annually.

After discovering the situation, we decided to switch to a lightweight preform – 49,8 g.

This will allow us to use less plastic in production (approximately 82 tons per year less) and save a little on materials at the same time.

We buy a test batch of preforms from a supplier, pour several pallets of the beverage as a production test. Further steps are to carry out all kinds of tests: vertical load test, tear test, cracking test, drop test and others. As a result of the successful completion of the tests, a decision is made to launch the lightweight preform into large-scale drink production.

For correct accounting, it is necessary to change the production specification in the ERP. Clearly, this process in the system will have the next steps: change request creating, reviewing the change request, change order creating.

The technologist creates a “change request” in the system, where he selects the item, indicates what needs to be changed, attributes of the request (reason, priority), attach the necessary documentation and / or related information and send it for approval.

A change request is processed by a group of responsible users (product owners).

The chief technologist accepts the request (1 on the screenshot), and his next step is to initiate a change order. The system allows him to do this directly from the change request (2 on the screenshot).

The following details are filled in the order: name, category, priority, the item to be changed, desired result of the change. The next options of result are available: new version, new variant, new product, no changes. We select ‘new version’, since we track changes by the versions. Then we go to the tab below, find the ‘Formula’ section.

In the formula, we find the line with the item that we want to replace (namely the preform with a weight of 50,7g), and delete the line. Next, we add a new line to the formula – 49,8g lightweight preform. After the changes, the formula header and lines in the change order will look like this:

Since only one version can be active at a time, it is necessary for the previous version to specify the ‘Effective to’ date so that the periods do not overlap.

After all the necessary changes have been made, we validate, accept the change order, and process it.

As a result, the status of change order will be changed, and for item FP-1010 the new version (V.002) will be created. We activate the version and now it is available for using from specified date:

Since our company is global and is the initiator of changes, the next step is to transfer these changes from the current legal entity to the remaining 2.

To do this, launch the wizard from the change order that generated a new version for us:

Further, the chain of actions is the same as after the release of the item (that we did before): review of the open release of the item, validation, acceptance, and activation of the new version.

All our companies have completely switched to using a lightweight preform.

Our upper management noticed the benefits of previous experience, in particular the economic benefit. It was decided to extend the practice to other finished products that use a PET-preform to reduce product time-to-market. And with the current product they decided to experiment a little more: to lighten the preform one more time. Based on the composition of the drink and the CO2 pressure inside the bottle, the lightest that suppliers could offer us is the 47,9g preform.

The processes for changing the specification are no different from the previous ones, so we will omit them. It is important that there are 3 versions in total for the finished product FP-1010. Each of the companies may use different versions for some reason.

Now we assume that the following situation takes place: the BVRG company produces drinks according to the 3rd version, where the lightest preform is involved – 47,9g, and the USMF and USP2 companies – on the 2nd.

The finished product according to the 3rd version is produced only for a few days.

The first batches are already in the distributors’ warehouses. A week later, we received complaints from them that a leak was found inside the pallets with drink, and they do not intend to keep leaking products in their warehouses. They sent us photo-confirmations and indicated the numbers of the batches for which this problem was noticed. The person in charge of the sale generates a change request by attaching confirmations:

The product owners receive the request and start to investigate the issue. They use the batch tracking functionality, through which they receive all information about the movement of the batch, and it’s on-hand:

The product owner concludes that all problematic batches were produced according to the 3rd version of the item, where there was one significant change – the secondary preform lightening.

Through the batch tracking function, we can easily track for which customers the problem batch was shipped to. Sales managers receive notifications and recall problematic batches. Pallets in our warehouses are blocked for shipments. Temporarily, it was decided to return to the 2nd version, while investigations are carried out why the preform used in the 3rd version gave a leak. In the system it will look like this: deactivation of version 3, activation of version 2.

Let’s summarize. In this article, we tried to describe the real experience of the enterprise as closely as possible. It follows from the above that this functionality makes life much easier for enterprises.

The Engineering Change Management Add-in for Dynamics 365 Supply Chain Management delivers strong product data management, version control, and product change management required by today’s manufacturers to succeed in a world of constantly shrinking product lifecycles, increased quality and reliability requirements, and increased focus on product safety. It helps manufacturers streamline and reduce the cost of managing product data, reduce errors in production, reduce waste when making design changes, and control the introduction of new products.