Change request

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.

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’s 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 on the requirements.

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 1 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 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 receives an email when the change request is reviewed and the status progressed to In planning. The creator of the change request receives 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 it provides a highly effective and efficient control mechanism in the rejection or successful delivery of a "change".

How to find 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 find 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 that you can run or clear filters or sort orders, or move columns. You can manipulate the data until the results you need are displayed.

To redisplay the full list of change requests, select No filter. If you’ve used any column filters, you 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 because they’re 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 find 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 or actions awaiting your input.

The following gadgets display change requests at key stages of the processing cycle. They’re 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've 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 need.

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 home section and one section per feature of the requirement:

• Home section. The home information section provides key tracking information. It contains the Status field which indicates the current stage of the requirement in the change cycle.
• Request details. This is the main section for this function. You use it to articulate the business case for the 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 the change request and subject matter experts within your organization. Access to the fields is controlled by the Status field in the home section.
• Rejection. This section is used by the change manager for the change request when the requirement is formally rejected. Access to the fields is controlled by the Status field in the home 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.

Home section

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

Change managers

As the change manager for the change request you ultimately have full control over the requirements and the progress of them through the change cycle. To advance or reverse the status of the change request, you need to be logged in as the current change manager for the 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 the requirement. This section also displays the name of the person who created the change request and when they created it.

• You can state the reason for the requirement.
• A requirement needs to apply to a specific product.
  You can create the 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 uses 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 the requirement is for.
• The key element of the business case is a statement that describes the expected benefit of the change. The 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 the requirement and the urgency of it.

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

• The requirement needs to be managed through the critical checkpoints to the conclusion, or closure of it.
  You can assign the 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 the 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 the 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 the requirement or the need for the change.

You’re advised to provide the name and contact details for at least 1 originator against the change request. This ensures that someone with knowledge of the issue is contactable if the requirements need clarification at any stage in the processing cycle.

Examples of change originators are:

• A product manager that's identified the need for a new or a changed feature in your company’s line of business.
• A network architect that's identified new-generation hardware with improved functionality to replace obsolete network hardware.
• A network engineer that's identified a method of upgrading the capacity of a device or link to handle increased traffic.
• A service manager that's identified the need to update your company’s vendor contracts or procedures.
• A Tier 1, 2, or 3 support engineer that's 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 the change request and subject matter experts that are assigned to provide input into the requirements. If you’re 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 the change request, you use this section to assign the change request to subject matter experts. Subject matter experts, or "approvers" are individuals within your organization that can provide input into these requirements. They’re often associated with your organization's "change board".

"Approvers" you assign to review the 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 the change request is notified by email of the entities they need to review, if the CCMEMAILAP–Email approver parameter (TC chapter, CCM group) is set. The email contains a URL (uniform resource locator) to the 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, triggers an email to the assigned approver.

You, in turn are 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.

Approvers

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

You’re notified by email of any entity that you need to review, if the CCMEMAILAP–Email approver parameter (TC chapter, CCM group) is set. The email contains a URL (uniform resource locator) to the change request. You should assess the requirements for each entity from both a business and a technical perspective.

Upon completion of your review you notify the change manager for the 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’ve rejected an entity, if the CCMEMAILCM–Email change manager parameter (TC chapter, CCM group) is set. If you’ve approved the requirements, this parameter triggers email notifications to this effect when an approval status for all assigned entities has been set.

Tab Rejection

This section is used by the change manager for the change request. If you’re 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 the change request you use this section to formally reject the 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.

The 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 the 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 the change request is notified by email of this decision.

Tab Attachments

Use the Attachments section to provide documentation to support the business case for the 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’re advised to provide all documentation deemed critical to the success of the 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 ensures that a paper trail of evidence is available if the requirements need clarification at any stage in the processing cycle.

To ensure that the 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 at New, In review, In planning, Being implemented, or Completed status. After a change request starts 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 the 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 the change request has advanced to In planning or Being implemented.
• You’re logged in as the current change manager for the change request.

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

Edit	Select the Edit action to update an existing change request. The Create action is only available while the change request is active and 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's 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 the "change" on key commitment groups. Appropriate quantities and the financial implication in base currency of the change are displayed for each group. Access to detailed information for each individual transaction type is available after you select this action. 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 the 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 the change request is changed from New to In review. The generation process can take a few minutes if it’s reading a large volume of data. 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 the change request.

Plan	Select the Plan action to define or view the action plan that delivers the scope of the requirements for the change request. 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 the change request.

Subcontract BOM revision

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

Product version management

This action is displayed if the product on the 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 that 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 2 choices when creating a change request:
1: If you know the product code, you enter 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 uses your description to trace the correct product code and they add it to the Product field. After the Product field is populated, the Description field becomes unavailable for entry.
The change manager for the 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 1 "active" change request per product code. This means that if another change request is being processed for the product code on the change request you can only create the change request. The status of the 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 the change request? How significant is the change likely to be? Select an appropriate value for this field to ensure that 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 in the Change manager field. A change manager is an active Sage X3 user who has been approved for involvement in your company's CCM process. 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 in the Planner field. A planner is an active Sage X3 user who has been approved for involvement in your company's CCM process. 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 is displayed if the Sage X3 user code selected is not valid. 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 the change request, you need to be logged in as the current change manager for the change request and the status of the 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’s 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 Finished status.

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 the change request is being or has been formally rejected. To do this, the status of the change request needs to be set to Rejected.

The Reason for rejection field must contain a value

Why are you rejecting the 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’re 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 that 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’re aware of these consequences before acting.

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's associated with the selected customer or supplier.

You do not have permission to delete this line

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

Tables used

  Refer to documentation Implementation