# Change Management

## Key Features

| ### Change Management Process
| The Change Management module includes all functionality required to create new objects and manage the modification of existing objects under the control of a strict change management process.
| It can be configured easily how "strict" /formal the change management process should look like.
| Basically, a change operation will typically follow the steps depicted below:
| ### Create a new object
| In the Change Management module there are two different procedures to create a new object: ad-hoc process formal process
| Ad-hoc process
| In an ad-hoc process an object is directly created via the corresponding object mask by referencing an available Work Order/Work Set. In this case the creation of a Work Request/Work Order as the first step is skipped. It is only required to reference an available Work Order/Work Set in the object mask.
| Formal process
| When creating a new object in a formal process, the object is created by specifying the change operation defined at the Work Request mask. When specifying a change operation, the corresponding object mask will be opened, thus enabling the user to create a new object by referencing an available Work Request/Work Order.
| To create a Work Request a unique number has to be entered in the Work Request mask (Start > Change Management > Work Request). You can further specify a Work Request by filling certain fields of the Work Request mask such as Purpose, Urgency, Change Kind, Project and Interchangeability.
| When creating a Work Request a preliminary Work Order with the same number is created automatically. When the Work Request is released, the Work Order becomes a persistent order. It is also possible to skip the creation of a Work Request and only create a Work Order. If a Work Request has to be created first is basically subject to company specific processes.
| When creating a Work Request/Work Order, a Work Set is automatically created. It is possible to create additional Work Sets for a Work Order and move objects and/or object relations from one Work Set to another one.
| When creating a Work Request first, it is subject to company specific processes if the Work Request is released before defining the intended change operations. It is also possible to release the Work Request after all change operations have been completed.
| Interchangeability
| The interchangeability defines if old and new versions of the affected objects are interchangeable and if all objects must be replaced together as a group (setwise) or can be replaced as independent objects (non-setwise). The interchangeability is selected from a selection menu in the Interchangeability field of the Work Request mask or at the Work Set mask. The following values are available:
Interchangeability | Description | Setwise
Upward and downward | New objects can replace old ones and vice versa | no
Not affected | Objects are not affected | no
Upward and downward collectively | All new objects can collectively replace old ones and vice versa | yes
Upward collectively only | All new objects can collectively replace old ones but not vice versa | yes
Upward only | New objects can replace old ones but not vice versa | no
| The collective interchangeabilities can only be performed setwise.
| ### Change an existing object/object relation
| Create Work Request/Work Order
| Identical to the formal process of creating a new object, a Work Request/Work order has to be created in order to initiate the change of an existing object/object relation.
| Define change operations and the affected objects
| The intended change operations have to be defined at the Change Operations tab of the Work Request/Work Order mask. Simultaneously, the affected objects of the change operations have to be defined as well. In the Change Management module the following change operations are available:
Key | Change Operation | Description
Add | Add | Create a new object
Assign | Assign | Assign an existing object to a Work Set
Copy | Copy w/o structure | Copy an object without structure
Copy all | Copy all structures | Copy an object with complete structure
Copy sel | Copy with structure | Copy an object with selective structure
Correct | Correct | Correct an object that had been released before
Create | Create | Create a new object
Group | Group | Groups other operations
Inactivate | Withdraw | Withdraw an object (set an object invalid)
Modify | Modify Attribute | Change an object
None | No Operation | Dummy Operation
Replace 1 1 | Replace 1-1 | Replace an object with another one
Replace 1:1 all | Replace 1-1-all | Replace all occurrences of an object
Replace 1:n | Replace 1-n | Replace an object with several other objects
Replace 1:n all | Replace 1-n-all | Replace all occurrence of an object with several other objects
Replace n:1 | Replace n-1 | Replace several objects with one object
Upgrade | Upgrade | Convert legacy data by setting them under control of Change Management.
Version | Version w/o structure | Version an object without copying the structure
Version all | Version all structures | Version an object with complete structure
Version sel | Version with structure | Version an object with selective structure
| This list can be configured according to your demands (System > Change Management > Lookup Values).
| For all change operations that create several new objects (e.g. Copy with structure, Version with structure) the top level object may not be controlled by Change Management whereas the child object is controlled by Change Management. In this case the system will prompt an error message indicating that a Work Set is required for the child object. This problem can be solved by defining a default Work Set which can be used for the child object!
| Please note that the available change operations are different for objects and object relations!
| The Change Operations tab will also indicate the following values: Effectivity View
| Effectivity
| The effectivity indicates when the objects/relations assigned to a change operation will become valid (effective) or invalid by means of the given Work Order/Work Set. The effectivity of objects/relations is typically identical to the release date of the Work Set. The effectivity is symbolized by the following signs: |> = valid from (start sign) >| = valid until (stop sign)
| View settings
| For the change operations "Replace 1-1-all" and "Replace 1-n-all" it is a requirement to select a so-called "view" setting. The attribute "view" describes the kind of relation between objects. In most cases the view to be selected is "STR" (structure).
| Please note that there are also "view" settings in order to filter and display objects in different "version views" as e.g. "development" or "production" (View > Filter >View). It is also subject to these "view" settings if preliminary records are displayed.
| Perform change impact analysis
| After the change operations and the affected objects have been defined, the affected products of the change operations can be identified. The corresponding procedure is called the "Change Impact Analysis" which performs an automatic "where-used" query for the products where the affected objects are used. When performing the Change Impact Analysis the interchangeability defined at the Work Set is taken into account. In consequence, affected products have to be recalculated if the interchangeability of a Work Set has been changed or if change operations have been moved in/out of a Work Set. The final list of affected products will display different products according to the following interchangeability settings: Interchangeability is defined as "setwise" = Only those products are displayed that are affected by every single change operation defined in the Work Set. All other products are marked as "suppressed". Interchangeability is defined as "non-setwise" = All products are displayed that are affected by any of the change operations defined in the Work Set.
| When applying the Change Impact Analysis to several Work Sets of one Work Order, a conflict can occur due to different interchangeability settings. This is usually the case when a product is subject to two different interchangeability settings. Since there is no automatism, such conflicts have to be resolved manually.
| Specify change operations
| When specifying a change operation a preliminary object is created.
| Since several users may be involved when specifying a change operation, a functionality to repeat the specification due to possible errors is provided. A repeated specification is not possible if a Work Set is already executed or completed. Also, a re-specification is only supported for top-level change operations (change operations without parent objects). When performing a repeated specification, the previous settings of the change operation are reloaded and can be modified.
| It is not possible to specify several objects at the same time!
| Please note that for the change operations "Revision" and "Copy with structure" the previous settings are not restored. If the attributes of a new object revision have to be modified, the object revision can be edited directly.
| For the change operations "Assign", "Upgrade", "Inactivate" and "Correct" a repeated specification does not make sense and is therefore not supported.
| Execute the Set
| When executing a Work Set the preliminary flag on the associated objects will be removed thus creating persistent objects. The persistent objects will become visible to all users in the view settings "Development" or "Global".
| The execution of a Work Set is not necessarily required as a separate step since the associated objects will be implicitly executed when a Work Set is completed.
| Change status to "Approved"
| Since the effectivity of objects/relations is controlled by the Work Set, it is possible to release several affected objects via a Work Set. For this functionality the new state "Approved" was added to the lifecyle definition of the corresponding object types (e.g. items, documents, BOM positions). The lifecycle definitions can be quite different according to the variety of different objects. However, before any of these objects can be released, the state "Approved" has to be passed first. Other states are possible too, but an system internal transition to the state "Released" must be defined. Affected objects are automatically released when the corresponding Work Set is completed. Then the effectivity date of the Work Set and the affected objects are identical.
| Please note, that when a change applies to an object relation, the relation can only be released if either the child object has already been released or if it is assigned to the same Set as the relation itself. In the later case it is necessary to set both the affected object as well as the relation to the state "Approved" before the relation can be released by completing the corresponding Work Set.
| Complete the Set
| When completing a Work Set all associated objects will be released in state. This is a necessary prerequisite to finally execute the change operations.
| Execute change operation
| The execution of change operations is slightly different according to the object types. If a change operation applies to a single object, the change operation to be executed is selected from the context menu of the corresponding object mask. In case of an object structure (e.g. BOM position), the relation has to be highlighted first before a change operation can be selected from the context menu.
| Correct/Modify a change operation
| Change operations that have already been executed and are deemed incorrect can be corrected. Corrections can be applied to incorrect objects and relation records. The incorrect object/relation will be duplicated, allowing the user to perform the necessary corrections. When performing a correction a separate Work Set will be created. The Modification of objects/relations aims at changing incorrect attributes like Quantity or Unit.
| It is not recommended to correct a change operation because a correction implies the modification of product data that has already been released. A correction is exclusively intended to correct errors in the documentation.
| Please note, that when a corrected record is stored it is automatically released and cannot be updated another time.