Change request

Recommended approach to Sage X3 Change control management

Practical experience shows that regular meetings combined with electronic automation are a viable approach to "change management" for many organizations.

It is generally regarded as good practice in the delivery of controlled design and production "changes" to schedule regular review meetings. Whether for incremental releases, or major "changes", these should include a formal review of the business case, risk analysis discussions, and to sign off the requirements.

The Sage X3 Change Control management functionality assumes this process is taking place in your organization.

The Change request function is the central function for managing the delivery of "change" for issues that will benefit your company or your customers. It controls every stage of the "change management" process within the context of a maintenance cycle or a "change" to a design or production model. From the initial creating of a "request for change" through to the conclusion or delivery of that change, it manages business risk at every stage.

Changes are important in the development of a product and for the ongoing maintenance of a product. As the initial stage in the change control process you use the Change request function to raise, or create "change requests". You might receive a "request" to meet a change to the marketplace, solve a specific problem or to add value to a design or production model. You use the Change request function to gather the critical information, including "in-flight" (cold call) information into one central repository. The change request forms the details of the requirements; it becomes the business case supporting a specific request for a "change".

Having created the initial change request, the Change request function then uses standardized procedures to enable efficient handling of all subsequent stages in the change cycle:

• Key personnel can be assigned to the change request that can identify and understand the requirements. These personnel will also be able to control the consequence of any changes.
• It provides visibility of all proposed changes and the impact of those changes on key commitments.
  Personnel authorized for involvement in your "change management" process can therefore ensure the technical impact of the "change" meet your business needs and goals for product delivery. With easy access to data and the critical information needed for the assessment of the business case for the requirements, business risk is managed and minimized.
• The requirements can be adapted where necessary to respond to the customer's changing business requirements. Unauthorized or unintended deviations can be prevented.
• The approach to be taken to deliver the requirements, and therefore to meet the objectives for the request can be outlined.

As a key event occurs to the change request, confirmation by email is sent to the appropriate personnel if the associated CCMEMAILxx–Email xxxx parameter (TC chapter, CCM group) is set. For example, the project manager will receive an email when the change request has been reviewed and the status progressed to In planning. The creator of the change request will receive an email when the change request is either completed or rejected. Each email contains a URL (uniform resource locator) to the change request enabling the recipient to access the change request directly from the email.

You use the Change request function, therefore, to manage your end to end "change" processes in full. When combined with regular meetings (see Recommended approach to Sage X3 Change control management above) it provides a highly effective and efficient control mechanism in the rejection or successful delivery of a "change".

How to locate a specific change request

If you access this function directly from the menu all change requests in your organization's database are displayed in a grid, or table. You can locate a specific change request quickly and easily by running a Filter. Filters provide simple and fast access to a range of, or specific, change requests, some of which are associated with your Sage X3 user code. You can find the available filters in the Action panel.

You can manipulate the results of a filter run using the standard Sage X3 query functionality. With the query functionality you can reorder the data, switch the columns and apply the filters at the top of every column. There are no restrictions on the number of times you can run or clear filters or sort orders, or move columns. You can manipulate the data until the results you require are displayed.

To redisplay the full list of change requests, simply select No filter. If you have used any column filters you will need to clear them to completely reset the filter. Your repositioned columns and sort orders do not need to be returned to their default settings as they will be retained.

Use the standard Sage X3 functionality available on every row to select your change request from the final filtered list.

Using your personal home page to locate your tasks quickly and easily

You can tailor your personal home page to display specific groups of change requests. Some of these will provide you with direct access to tasks (actions) awaiting your input.

The following gadgets display change requests at key stages of the processing cycle. They are provided for you to add to your home page as Representations (Modules = Change Control, Categories = No category):

• Change requests for my approval
  This gadget shows all change requests awaiting, or currently in review, where your Sage X3 user code matches a transaction line awaiting approval.

• Change requests to manage
  This gadget shows all active change requests where your Sage X3 user code is the assigned change manager.

• Change requests to plan
  This gadget shows all change requests awaiting, or currently in planning, where your Sage X3 user code matches the assigned planner (project manager).

• Change request
  This gadget shows all change requests in the database.

• Change requests created
  This gadget shows all the change requests you have created.

Each gadget displays a spot view of the selected, or filtered data at the point you run it. You can use the standard Sage X3 query functionality to manipulate the results in the gadget until it displays the results you require.

You can select and progress a change request directly from the gadget using the standard Sage X3 functionality available on every row.

Prerequisites

  Refer to documentation Implementation

Screen management

The Change request function contains a Header section and one section per feature of the requirement:

• Header information. The header information provides key tracking information. It contains the key field Status, which indicates the current stage of this requirement in the change cycle.
• Request details. This is the main section for this function. You use it to articulate the business case for this requirement.
• Originators. Use this section to provide requester contact information.
• Approvers. Use of this section is optional. This section is used by the change manager for this change request and subject matter experts within your organization. Access to the fields is controlled by the Status field in the Header section.
• Rejection. This section is used by the change manager for this change request when this requirement is formally rejected. Access to the fields is controlled by the Status field in the Header section.
• Attachments. This section is optional. You use it to attach documents that support the business case for the requirement in its entirety, from its creation to its closure.

Header

The Header section provides key tracking information. The critical field in the header information is the Status field. This field indicates the current stage of this requirement in the change cycle. The change manager for this change request uses it to control the progress of these requirements through the change cycle.

Change managers

As the change manager for this change request you ultimately have full control over these requirements and the progress of them through the change cycle. To advance or reverse the status of this change request you need to be logged in as the current change manager for this change request.

Tab Request details

Changes are important in the development of a product and for the ongoing maintenance of a product. You use this section to articulate the business case for this requirement. This section also displays the name of the person who created this change request and when they created it.

• You can state the reason for this requirement.
• A requirement needs to apply to a specific product.
  You can create this requirement for a specific product if you know the product code. If you do not know the product code add a short, free-format description of it. A subject matter expert will then use your description to trace the actual product code.
  If the product is version managed, you can add an additional level of detail by specifying which major and minor version this requirement is for.
• The key element of the business case is a statement that describes the expected benefit of the change. This requirement might be suggested, for example, to add value to a design or enhance the product experience for the customer, or to improve delivery schedules.
  You can provide this statement in a free-format narrative field.
• You can define the likely impact of this requirement and the urgency of it.

You also use this section to assign personnel to this requirement that will be able to control the consequence of any changes.

• This requirement needs to be managed through the critical checkpoints to the conclusion, or closure of it.
  You can assign this requirement to the default, or an appropriate "change manager". A change manager is a subject matter expert with the authority to approve or reject any suggested changes. They might be a member of your organization’s change control team, such as a development manager or a test lead. Alternatively, they might be a product manager that assesses the business case for all requirements.
• You can reassign this requirement to a different change manager if, and when necessary.
• You can assign the default, or an appropriate project manager to be responsible for managing the "change".
• A different project manager can be assigned to this requirement if, and when necessary.

Tab Originators

You use this section to provide requester contact information as "originator" information. Requesters, or "originators", can be any individual that has identified this requirement or the need for this change.

You are advised to provide the name and contact details for at least one originator against this change request. This will ensure someone with knowledge of the issue is contactable should the requirements need clarification at any stage in the processing cycle.

Examples of change originators are:

• A product manager that has identified the need for a new or a changed feature in your company’s line of business.
• A network architect that has identified new-generation hardware with improved functionality to replace obsolete network hardware.
• A network engineer that has identified a method of upgrading the capacity of a device or link to handle increased traffic.
• A service manager that has identified the need to update your company’s vendor contracts or procedures.
• A Tier 1, 2, or 3 support engineer that has identified a defective part in a network element.
• A security manager requesting a configuration and documentation change in response to a newly discovered vulnerability.

Tab Approvers

This section is used by the change manager for this change request and subject matter experts that have been assigned to provide input into these requirements. If you are a stakeholder or member of your company's "change board" or steering committee, you can use it to view post-review decisions or conclusions.

Change managers

As the change manager for this change request you use this section to assign this change request to subject matter experts. Subject matter experts, or "approvers", are individuals within your organization that can provide input into these requirements. They are often associated with your organization's "change board".

"Approvers" you assign to review this change request should have the expertise to adequately assess these requirements from both a business and a technical perspective. You can assign entities, or types of transactions specific to their areas of expertise for them to review, or the whole request to review. You might assign a regional sales manager, for example, to review the business case and the requirements for your customers (entity). For your purchases (entity), you might, for example, assign a service manager. Some organizations have product managers that are capable of adequately assessing complete requirements from both a business and a technical perspective. If this applies to your organization you might assign a single product manager for example, to review the complete business case and the requirements.

Each approver you assign to this change request will be notified by email of the entities they need to review, if the CCMEMAILAP–Email approver parameter (TC chapter, CCM group) is set. The email will contain a URL (uniform resource locator) to this change request. With this parameter set, reassigning an entity to a different approver to review triggers an email to both the original and the new approver. Additionally, deleting an entity from the list of entities for review will trigger an email to the assigned approver.

You, in turn will be notified by email when the approvers have set approval statuses for their entities, if the CCMEMAILCM–Email change manager parameter (TC chapter, CCM group) is set.

 As approvers have authority to approve or reject these requirements it is important that you give due consideration to which subject matter experts you assign.

• You can only assign "approvers" to this change request while the status is In review.
• As the change manager for this change request you are the only Sage X3 user authorized to assign "approvers" to it.
• "Approvers" need to be authorized Change control management subject matter experts.
• You can associate multiple "approvers" with this change request.
• You can associate a single "approver" with multiple entities (or transaction types).
• You do not have authorization to set the approvers post-review decisions.
• You are responsible for manually advancing this change request to the next stage in the processing cycle.
• Having a complete set of approver post-review decisions is a not a prerequisite to changing the status of this change request.

Approvers

As an "approver" you have been assessed as having the expertise to review the business case and the requirements for this change request.

You will receive notification by email of any entity you are required to review, if the CCMEMAILAP–Email approver parameter (TC chapter, CCM group) is set. The email will contain a URL (uniform resource locator) to this change request. You should assess these requirements for each entity from both a business and a technical perspective.

Upon completion of your review you notify the change manager for this change request and the stakeholders by setting a post-review decision against each entity. One comment field per entity is available to you which you could use to quantify your decision. You could use it, for example, to state assumptions or make recommendations to the project manager responsible for planning the requirements. The change manager cannot set your approval status or add comments on your behalf.

The change manager is notified by email immediately if you have rejected an entity, if the CCMEMAILCM–Email change manager parameter (TC chapter, CCM group) is set. If you have approved the requirements, this parameter triggers email notification to this effect when an approval status for all assigned entities has been set.

• You need to meet the following conditions to be able to update your assigned entities:
  • You need to be logged into Sage X3 with your user name.
  • You need to have approval for involvement in your company's "change management" process as an approver, that is, your CCMAPPROVE–Approver user parameter (TC chapter, CCM group) is set to Yes.
• If site restrictions are in place, visibility of and access to this change request is determined by the value of the Site field:
  • If the Site field contains a value you need to have a profile code which has approval for the defined site.
  • If the Site field is blank, that is the change request is valid for multiple sites, you will have unrestricted visibility and access to this change request. Your profile code, however, needs to have approval for the transaction site.
• You can only set an "approval status" while the status of this change request is In review.
• Your post-review decisions are not a prerequisite to the status of this change request being changed.
• The change manager is not permitted to set your post-review decisions or add comments on your behalf.

Tab Rejection

This section is used by the change manager for this change request. If you are a stakeholder or member of your company's "change board" or steering committee, you can use it to view the formal rejection reason and conclusions.

Change managers

As the change manager for this change request you use this section to formally reject this requirement. This is mandatory if the change control team assess that the requested "change" will not improve the original and the business case is weak.

This change request needs to be at Rejected status for the fields in this section to be available for entry. As a minimum, you need to define the reason the change control team is formally rejecting these requirements.

You can expand upon the reason for rejection in a free-format narrative field. If you attach any relevant supporting documentation in the Attachments section you can use this field to add a note to this effect.

The Sage X3 user that created this change request will be notified by email of this decision.

• You can only set a rejection reason if the status of this change request is Rejected.
• As the change manager for this change request you are the only Sage X3 user authorized to reject it.
• Having all approver post-review decisions at Rejected status is a not a prerequisite to the status of this change request being set to Rejected.
• A notification email is not sent if the Sage X3 user code displayed in the Change manager and Created by fields are identical (Request details section).

 You will lose all information in this section if you subsequently revert the status of this change request to In review.

Tab Attachments

Use the Attachments section to provide documentation to support the business case for this change request. The documentation can be of any type and support the business case in its entirety, from creation and assessment through to a successful completion or rejection.

You are advised to provide all documentation deemed critical to the success of this change request. You can attach any documentation gathered by the stakeholders to solve a problem or achieve an objective. This includes conditions articulated by the customer or formal notice supporting the rejection of a request for change. This will ensure a paper trail of evidence is available should the requirements need clarification at any stage in the processing cycle.

To ensure this change request can support the business case through to its conclusion you can attach all formats of documentation, for example, documents, spreadsheets, images, portable document formats (PDF), text files. The only restriction being the length and format of the filename, which needs to be less than or equal to 30 characters with no special characters, including spaces.

All registered Sage X3 users can add attachments to any new or in-progress change request, that is at New, In review, In planning, Being implemented, or Completed status. Once a change request has started the change cycle, however, only the change manager or the user that added the attachment can amend or delete it.

Examples

Documentation that support the assessment of the business case:

• A drawing of a specific component before and after the change.
• A list of customers that will benefit from the requested change.

Documentation that support the reason a request for change has been formally rejected by the change control team:

• A questionnaire that demonstrates that the requirement will not benefit the stakeholders.
• A specification that defines the specific reason for the implemented design.

Reports

By default, the following reports are associated with this function :

  CCMCRREASON : Change requests by reason

  CCMCRSEVERITY : Change requests by severity

  CCMCRSTATUS : Change requests by status

This can be changed using a different setup.

Action panel

• Edit
• Excel
• List of change requests
• Contacts
• Impact analysis
• Plan

You can use the following actions to increment or increase the version of the product to reflect the changes being delivered by this change request. The following actions are only available when the following conditions are met:

• The product code defined in the Product field is version managed.
• The status of this change request has advanced to In planning or Being implemented.
• You are logged in as the current change manager for this change request.

• Manufacturing BOM revision
• Subcontract BOM revision
• Product version management

Edit	Select the Edit action to update an existing change request. Note:  The Create action is only available while this change request is active, that is, it is not at Closed status.

Excel

Select the Excel action to export the list of all change requests in the database to a Microsoft® Excel spreadsheet file for further analysis.

List of change requests

Select the List of change requests action to return to the list of all change requests in the database.

Contacts

Select the Contacts action to add and store details for an "in-flight" (cold call) requester. They might be an external contact that is not connected with your company or a new contact for your customer or supplier. The new "contact" is added to the Contacts (relationship) table (CONTACTCRM).

Impact analysis

Select the Impact analysis action to display a high level assessment summary in real time of the impact of this "change" on key commitment groups. Appropriate quantities and the financial implication in base currency of this change are displayed for each group. Access to detailed information for each individual transaction type is available after you select this action. Note:  To display the Impact analysis action you need to select the standard browser "refresh" (F5). The Impact analysis action is only displayed when the following conditions are met: The status of this change request has advanced to In review. The system has finished generating the impact analysis data. The impact analysis is generated automatically using real-time data when the status of this change request is changed from New to In review. The generation process can take a few minutes if it is reading a large volume of data. Note:  The quantities and financial implication figures are applicable to all sites associated with the product. They are not calculated specifically for the site specified on this change request (if specified).

Plan	Select the Plan action to define or view the action plan that will deliver the scope of the requirements for this change request. Note:  For the Plan action to be available, the status of a change request needs to have reached In planning in the change cycle.

Manufacturing BOM revision

This action is displayed if your organization manufactures the product on this change request.

Subcontract BOM revision

This action is displayed if your organization procures the product on this change request from a subcontractor.

Product version management

This action is displayed if the product on this change request is version managed but is not manufactured or procured from a subcontractor.

Limitations

 You can only assign a single product code to a change request.

 Only one "active" change request is permitted per product. This is to ensure a change to a product is either seen through to its conclusion and the delivery of that change, or the change request is closed.

Error messages

• Generic messages

In addition to the generic error messages, the following messages can appear during the entry :

You have not entered a product code. If you do not know the product code enter a description of it.
or
You can only change the status of this Change request when the Product code has been defined

Each change request applies to a single product code. You have two choices when creating a change request:
1: If you know the product code, you type the code in the Product field (or you can select the required code).
2: If you do not know the product code, you can provide a short description of the product in the Description (if product unknown) field. A subject matter expert will use your description to trace the correct product code and they will add it to the Product field. Once the Product field has been populated the Description field will become unavailable for entry.
The change manager for this change request can only advance it through the change cycle when the correct product code has been identified and recorded.

Another change request is being processed for this product - only one per product can be processed
or
Change request $1$ is being processed for the product code. It must remain at status 'New'.
or
A change request ($1$) is currently in progress for this product

Each change request applies to a single product code. Also, there can only be one "active" change request per product code. This means that if another change request is being processed for the product code on this change request you can only create this change request. The status of this change request needs to remain as New until the other change request has been closed.

The Reason for change field must contain a value
or
The Change impact field must contain a value
or
The Severity field must contain a value

Why are you creating this change request? How significant is this change likely to be? Select an appropriate value for this field to ensure the appropriate "change control" team can be assigned to review the business case for the requirements.

The general parameter CCMCMDEF must contain a value
or
User $1$ is not a Change Manager – see user parameter CCMCHGMAN

Each change request needs to have a nominated change manager (Change manager field). A change manager is an active Sage X3 user who has been approved for involvement in your company's CCM process. This means that the Active checkbox on their Sage X3 user record is selected and their "change manager" approval CCMCHGMAN–Change manager parameter (TC chapter, CCM group) is set to Yes. One "change manager" user should be nominated as the default change manager for all new requirements. You define the default change manager by adding their Sage X3 user code to the folder level CCMCMDEF–Default change manager parameter (TC chapter, CCM group), but only after their user parameter has been set.

User $1$ is not a Planner

Each change request needs to have a nominated project manager or planner (Planner field). A planner is an active Sage X3 user who has been approved for involvement in your company's CCM process. This means that the Active checkbox on their Sage X3 user record is selected and their "planner" approval CCMPLANNER–Planner parameter (TC chapter, CCM group) is set to Yes. One "planner" user should be nominated as the default planner for all new requirements. You define the default planner by adding their Sage X3 user code to the folder level CCMPLADEF–Default planner parameter (TC chapter, CCM group), but only after their user parameter has been set.

User $1$ is not a valid user
or
User $1$ is not an Approver for Change Requests
or
User $1$ is not an Approver

This message will be displayed if the Sage X3 user code selected is invalid. This might be because they are not an active Sage X3 user or because they have not been set up as having "CCM authorization".
 Parameters

You do not have permission to add lines

To be able to assign an "approver" to this change request you need to be logged in as the current change manager for this change request and the status of this change request needs to be In review.

Updating Impact analysis data. Wait a few minutes then refresh this page.
or
Impact analysis data is currently being created by Batch Server Task: $1$. Wait a few minutes then refresh this page.

This message is displayed by the batch server process while the impact analysis is being created or updated. It is also displayed if you attempt to refresh the screen while the impact analysis is being created or updated.

The creation of an impact analysis can take a few minutes if the process is reading a large volume of data. You can check the status of the batch server process using the Query management function (AREQUETE). You can view the impact analysis when it shows the status Finished.

You can only add rejection attachments if the status of this Change request is 'Rejected'

You can only assign this attachment to the Rejection category if this change request is being or has been formally rejected. To do this the status of this change request needs to be set to Rejected.

The Reason for rejection field must contain a value

Why are you rejecting this change request? Select the reason in the Reason for rejection field to ensure the decision made by the "change control" team is recorded formally. You are advised to expand upon the selected reason in the Additional information field.

Status cannot be moved from $1$ to $2$
or
You can only proceed if the status of this Change request is 'Plan'
or
Plan has not yet been implemented and completed
or
Plan must be at Pending status
or
This Change request is now closed. Amendment is forbidden.

Each change request needs to follow the standard processing cycle.
For a change request that will be processed through to completion the standard cycle is: New > In review > In planning > Being implemented > Completed > Closed.
For a change request that will be rejected the standard cycle is: New > In review > Rejected > Closed or New > Rejected > Closed.
The current stage in the processing cycle is displayed in the Status field. Controls are in place to ensure a change request can only advance to the next stage in the processing cycle when the current stage is completed. For example, the action plan needs to have been implemented in full before the status of a change request can be advanced to Completed.

Existing plan will be removed
or
Rejection details will be removed

Selected stages in the processing cycle allow the status of the change request to be reverted back one stage, for example, from Being implemented to In planning. There can, however, be consequences in doing so. Ensure you are aware of these consequences before taking this action.

Sending email notification impossible. Failure in retrieving workflow email address for $1$

The email address on the user record is either missing or incorrect. Email notifications cannot be sent to this user.

[Name] is not a contact for [BP]

You can only add a contact that is associated with the selected customer or supplier.

You do not have permission to delete this line

You can only delete lines if you are logged in as the current change manager for this change request.

Tables used

  Refer to documentation Implementation