Understanding ‘Minor Changes’

‘Minor change’ is a widespread terminology used for many different topics that may vary for each customer/industry. It needs to be properly described and detailed with real world examples, to avoid confusion on the true need expressed by the customer.

Generally, “minor change” refers to a change of a product in a specific domain (engineering, manufacturing, simulation etc.) that may not require any traceability and that may not have an impact on any other domains in the enterprise. Sometimes an issue arises during the initial scope that is considered “minor” by one group, but viewed differently in other domains. For example, minor changes in engineering may not be considered as such in the simulation domain, where accuracy can be greatly impacted due to the engineering “minor” change.

With this understanding, minor changes should be considered as those changes that do not affect engineering, manufacturing, simulation or any other domain.

Valid Cases:

Typically, these are typos to be fixed on the definition of the object, such as the description of the Engineering Item.

Non-Valid Cases:

Detailed research analysis reveals that many companies store non-engineering attributes on the Engineering Item itself, such as procurement or manufacturing attributes. This leads to modification of released Engineering Items for the sake of editing those attributes. Evolution of this non-engineering content on a released Engineering Item may lead the company to modify the entire released Engineering Item. Our recommendation in this case is to use the preferred platform objects to store the proper content in the appropriate place:

• Engineering content ▶️ Engineering Items
• Manufacturing content ▶️ Manufacturing Items
• Procurement ▶️ Manufacturer Equivalent Item
• etc.

Focus on the “Form/Fit/Function” Paradigm:

In some cases, qualification of “minor changes” is defined by their impact on the form, fit or function (FFF) of the parts that define its characteristics. If none of the FFF is impacted, then we can assume that the change is minor. Note that each company has its own definition of the FFF that affects the required level of traceability of each modification.

Again, a detailed analysis of the cases reveals that most of the time the modification of one of the FFF would lead to impacts on Manufacturing or Simulation processes.

Supported Use Cases Related to Fixing Minor Changes like Typos:

A user with the correct privileges can fix an issue like a typo on a released Engineering Item. The use case is being referred to as “correction” process, on which no new revision is being created to resolve this typo.

Two roles in the organization have the privilege to perform updates on released content in the platform as an exception process without going through revise or change processes:

• Platform administrator
• Collaborative space owner

These users can demote the released object, fix the issue and then promote it again to released state.

Supported Use Cases Related to Fixing Major Changes:

When the company decides that a change is worth tracking to avoid uncontrolled inconsistencies, the following tools enable tracking of such modifications:

• Manual creation of a new revision (revise process)
• Usage of a change process to create and approve new revision (change management)

Major Changes on Released Engineering Item – Revise and Replace with Latest Revision:

Let’s assume you have an assembly that is completely released and a new revision of one child was created by a user. This new revision now needs to be linked to the parent, but since the parent is released, it must be revised and the new child revision needs to replace the existing one (which is not “Latest”).

 See this example – Product Structure Editor:

The easiest way to do all these actions in a single panel is to use the “Update Revisions“ command:

• Select the parent (in Released state)
• Run the command from the tool bar

The following panel allows you to make your decisions:

For the released parent, the action will be: Create New Revision

For the child that already has a later revision, the action will be: Replace by New Revision

The newly created assembly revision (In Work) will now include the latest child revision (also In Work):

Final word:

Companies need to be aware of changes that:

• Have an impact on the same/other domains, and as such would require traceability
  • Such changes should be performed in a controlled manner (using revision control, change process etc.).
  • As soon as a new revision is being asked to track an evolution, it means the customer is seeking traceability. This is a good hint that the change is likely not to be “minor,” even though there is a cost to bubble up.
• Have no impact on the same/other domains (typos in the product attributes), and as such would not require traceability through an official new revision.
  • In such cases, the administrator/collaborative space owner can resolve the issue by fixing the typos (demoting the released object, modifying its content and re-promoting it back to Released)

Platform ​​​​​​​Tips_and_Tricks ​​​​​​​🧡Configured_Product_Development