Change Management Tutorial#

Estimated time to read: 13 minutes

The purpose of Change Management in Critical Manufacturing MES is to control and track changes related to Versioned Entities, in a way that maintains compliance, traceability, and operational integrity.

The key features of Change Management in MES are the following:

1. Version and Revision Control

   • Managing different Versions and Revisions for all the change-controlled objects, to ensure that only approved versions are deployed on the shop floor.
   • Although Smart Tables are not versioned entities, it is possible to enable Change Control to keep track of their modifications (more information available in the Smart Tables User Guide and an example will be explained in the Change Controlled Smart Tables section).

2. Traceability and Auditability

   • Ensuring that all changes (who, what, when and why) are logged and traceable for audit and compliance.

3. Regulatory Compliance

   • Supports good practice standards, guaranteeing all changes go through formal approval processes like Change Set requests, and role-based approval.

4. Collaboration and Approval Workflow

   • Coordinates changes across cross-functional teams (QA, Production, IT) with clearly defined approval hierarchies.
   • The approval workflow is represented by a State Model in MES, where it is possible to have multiple approvers with a defined sequence.
   • Hierarchies can be achieved by managing Change Set state reviewers. These concepts will be explored in the Implicit Change Set section.

5. Rollback Capabilities

   • Facilitates rollback to prior configurations or workflows in case of failure or defects in the new version, by:
     • Sending the Change Set to rework
     • Rejecting the Change Set
     • Changing the active version to a prior version, if the Change Set is already approved.

6. Process Standardization

   • Promotes standardized approaches to modifications, reducing variability and ensuring consistent manufacturing practices.

Overview#

This tutorial is organized into several sections, each focusing on specific functionalities related to Change Sets. The structure is as follows:

• Change Set Operations: to learn about the various operations you can perform on a Change Set, and understand how these actions affect the associated versioned entity instances.
• Manual vs Implicit: to understand the differences between manual and implicit Change Set. This section explains configuration for each type and includes practical use cases and demonstration videos, such as:
  • Manual Change Set with Approval Role and Effective on Approval
  • Implicit Change Set using approval context with Approval Workflow
  • Send Implicit Change Set to Rework with Approval Workflow
  • Using Approvers and Observers in an Implicit Change Set with Approval Workflow
• Change Set Items with Different Approval Roles: to learn how to configure and manage Change Set Items that require different Approval Roles within the same Change Set.
• Change Controlled Smart Tables: to explore the available options for change management in Smart Tables and how Change Sets can be applied in these scenarios.
• Additional Notes: to discover other advanced operations, including transferring and comparing Change Set Items, taking ownership of a Change Set, and using Employee delegation.

Each section is designed to provide detailed instructions, configuration guidance, and examples to help you get the most out of Change Management functionality.

Change Set Operations#

Change sets and versionable entities operate side-by-side. Operations performed at the Change Set level are reflected in the state of the entity for which the Change Set was created.

The image below explains the possible operations at Change Set level and the consequences they have on the respective entity.

For non-versioned entities, it is not necessary to create a change set to maintain control of changes. The lifecycle of these entities is simpler, as once created, they become Active and when terminated, they become Terminated.

Manual VS Implicit#

Change Sets can be manual or automatic (implicit). The image below describes the differences between these two types:

• Manual Change Set: requires the manual creation and configuration of the Change Set for each new version/revision that is created for the versioned entity. The Change Set can be created previously or at the time of creating the new entity version/revision.
• Implicit Change Set: does not require manual creation of the Change Set. As soon as a new version/revision is created, the Change Set is automatically created based on the settings applied at the entity level in question.

Manual Change Set#

Setup#

For the Change Set to be created manually, edit the entity properties, by going to the Entity Types Page, and select the entity that will be the target of change control. It must have the following configuration:

• Automatic Change Set = False
• If Use Change Set Approval Context = True, the Smart Table ChangeSetApprovalContext will be resolved and the Role/workflow configured in the Smart Table needs to be the same as the one defined in the Change Set. If the Role/workflow in the Change Set is different from the one defined in the Smart Table, then an error will be thrown.

Approval Role and Effective on Approval#

The first example to be demonstrated uses two Roles:

• Operator: This Role is not defined as an Approval Role, but it can Request Approval
• Process Engineer: It is defined as an Approval Role; only a user belonging to this Role has permissions to Approve, Reject or send the Change Set for Rework

The video below explores this example of a Change Set in which an intervening party is required to approve the changes of a versioned entity.

Implicit Change Set#

Setup#

For the Change Set to be created automatically, edit the entity properties, by going to the Administration Menu > Entity Types, and select the entity that will be the target of change control. It must have the following configuration:

• Automatic Change Set = True
  • Additional fields become enabled and need to be defined (Name Generator to be used in the Change Set, Approval Mode, etc.)
• Change Set Name Generator: Name Generator to be used as the Change Set name once it is automatically created. The Name Generator needs to be created in advance, through Administration > Name Generator.
• Approval:
  • It is possible to define a specific Role or workflow responsible for the Change Set approval. According to the selection (Role/Workflow), the field under it displays a dropdown list with the possible Roles/Workflows of approval.
  • Workflow is used when a sequence of Roles is required to perform the approval. This approval sequence must be defined in advance by creating a State Model. Note that the Entity Type defined in the State Model must be "Change Set"
  • If the dropdown list for either Role or Workflow is left empty and the property Use Change Set Approval Context is set to False, there will be no approval Role/workflow associated with the Change Set (here the system will behave the same way as when the Change Set is manually created and the flag Requires Approval is set to False).
• Use Change Set Approval Context: If true and if no Role and workflow were specified above (in the dropdown list), the ChangeSetApprovalContext Smart Table will be resolved and, according to the context, a Role/workflow of approval will be associated with the Change Set.
• Enable Automatic Approval: If true, if no Role and workflow are specified, and if the flag Use Change Set Approval Context is set to False, the Change Set will be automatically approved, without the need of selecting the Request Approval button.

Approval Context#

In this scenario, the ChangeSetApprovalContext Smart Table will be used to automatically create the Change Set with the workflow defined in the table for the Document Entity Type.

The video below walks through all the steps from creating the Document version, to approving the various workflow states and marking the version as Effective.

To do this, the State Model that represents the workflow needs to be created beforehand. In this example, the Maintenance Technician and Process Engineer Roles were used, as presented in the diagram below.

Change Set Rework#

After requesting the Change Set approval, there are three possible outcomes:

• Approve the Change Set: - When approving the Change Set, its system state becomes Approved and the Change Set is Terminated - In case of an approval workflow, during the several stages of the State Model, the Change Set is maintained In Approval and, in the last state, it becomes Approved and the Change Set is Terminated
• Send the Change Set to rework: - When sending the Change Set to rework, its system state changes to Created and it is necessary to perform Request Approval again (the cycle starts from the beginning) - It is possible to add a comment when sending the Change Set to rework - The comment is visible in the Change Set history
• Reject the Change Set: - When rejecting the Change Set, its system state becomes Rejected and the Change Set is Terminated - It is possible to add a comment when sending the Change Set to rework

The scenario in the video below will describe the Rework example, with an Approval Workflow with the Roles of Maintenance Technician and Maintenance Engineer, and where it will be possible to confirm the behavior described above.

Approvers and Observers#

This scenario will explore the possibility of having two stakeholders in the Approval Workflow states defined in the Change Set.

These stakeholders are called Reviewers and can be classified as Approvers or Observers, with the following responsibilities:

• If the Reviewer is set as Approver, they must explicitly approve the Change Set at a certain state (this action is mandatory and relevant).
• If the Reviewer is set as Observer, they can add, approve or reject, but their response is not required and not relevant to the approval of the Change Set, but will be retained in the historical details of the state transition approval.

The next video explains the scenario with a workflow involving the following Roles and states:

• Roles: Operator; Maintenance Technician; Maintenance Engineer; Quality Engineer; Process Engineer
• State Model Workflow: - Maintenance Modifications - Observer: Maintenance Technician - Approver: Maintenance Engineer - Quality Verification - Observer: Quality Technician - Approver: Quality Engineer - Final Approval - Approver: Process Engineer

In this example, no Roles are defined in the State Model. The stakeholders are only configured in the Change Set as Reviewers. However, it is possible to also define Roles for each state in the State Model. If defined this way, the order to approve/reject a Change Set can be defined as: Reviewer Observer > Reviewer Approver > State Model Approver.

If the State Model has an Approver Role associated with it, and if a Reviewer Approver is also defined, it is necessary for the Reviewer Approver to take his decision first:

• The State Model Approvers can only take their decision after the Reviewer Approvers tak their decision
• If the Reviewer Approver rejects the Change Set, its state will change to terminated and the decision of the State Model Approver is no longer needed.

Change Set Items with different Approval Roles#

A single Change Set can have multiple Items with different Approval Roles.

It is possible to create Change Set Items directly in the Change Set by selecting the "Items" section and pressing "Create."

To change individual Approval Roles for a specific Change Set Item, within the same "Items" menu, it is needed to select the desired items and select "Manage Change Set Items".

It will then be possible to have a common Change Set where the Approval Role is different from the various Approval Roles for each Change Set Item.

In this scenario, for Change Set Items to become Effective, the process involves first approving each Change Set Item individually. To do this, after Requesting Approval, choose the desired item and select "Approve Items."

Only after all items have been approved can the final approval of the common Change Set be performed.

Change Controlled Smart Tables#

Although Smart Tables are not versioned entities, it is also possible to enable change control so that all changes are managed via a Change Set.

The video below demonstrates how to change the settings of a Smart Table so that it behaves as described, and how this is reflected when some changes need to be made to it.

Additional Notes#

Transfer and Compare Items#

It is also possible to perform other operations at the Change Set Items level:

• Transfer – Transfer one or more items from one Change Set to another
• Compare – Compare the differences between the new version/revision and the other version/revision before approving it

Take Ownership#

A Change Set can be viewed in two different ways:

• Change Set without an Owner: If a Change Set has no assigned Owner, any User can request approval for it.
• Change Set with an Owner: If a Change Set has an assigned Owner, only that specific User can request approval.

This is where the “Take Change Set Ownership“ action comes into play. A User can choose to take ownership of a Change Set, which then allows them to initiate the approval request for that workflow.

Employee Delegate#

For Change Sets with Approval Workflow, where Employees are defined as Approvers, if the defined Employee is unavailable for a period of time to approve the Change Set, it is possible to delegate this approval to another Employee.

This can be done through the Employee page, under Manage Employee Delegates.