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 creating the initial "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.

Note - warningThe Sage X3 Change Control management functionality assumes that this process is taking place in your organization.

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 a single, central repository. The change request forms the details of the requirements. It becomes the business case supporting a specific request for a change.

Note - information All registered Sage X3 users can create change requests.

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 meets 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 take 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. The project manager receives an email when the change request is reviewed and the status progresses 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 display in a grid or table. You can find a specific change request quickly and easily by running a Filter. 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. 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 display.

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. You do not need to return repositioned columns and sort orders to their default settings.

Use the standard 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 user code is the assigned change manager.
  • Change requests to plan
    This gadget shows all change requests awaiting, or currently in planning where your 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 that you run it. You can use the standard 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 functionality available on every row.

Prerequisites

Note - informationRefer to the documentation on 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 that 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 the 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 that created the change request and when they created it.

  • You can state the reason for the requirement and name or describe the product.
  • You can add a statement that describes the expected benefit of the change.
  • You can state 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 default or an appropriate change manager that will manage the requirement through the critical checkpoints to the conclusion, or closure of it, and the project manager to be responsible for managing the change.

Note - information There can only be one active change request per product code. This means that you can only create the change request if another change request is being processed for the same product code. It needs to remain at New status. Only after the other change request is closed can you advance the change request for this product code to the review stage, then on through the change cycle.

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.

Note - information Originators can explain the business case in greater detail or answer questions about why their request or solution is better than the original. It might be difficult to obtain this information if it’s needed without the name and contact details for at least one originator.

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.
Note - information All registered Sage X3 users can add originator information to any new or in-progress change request that's at New, In review, In planning, Being implemented, or Completed status. After a change request starts the change cycle, only the change manager or the user that added the originator information can amend or delete it.

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.

For an overview of this tab for your particular role, select the appropriate link in the following list:

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.

Note - information A change board is a body that exists to support the authorization of changes and to assist change management in the assessment and prioritization of changes.

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 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 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 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.

Note - warningAs approvers have authority to approve or reject the requirements, it's important that you give due consideration to which subject matter experts you assign.
Note - information Your organization's change board should consider the point at which the decision to approve or reject the full change request is made. Essentially, at which stage in the review process you should manually advance the change request to In planning or Rejected status.
Note - information
  • You can only assign approvers to the change request while the status is In review.
  • As the change manager for the change request, you’re 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 the 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’re responsible for manually advancing the change request to the next stage in the processing cycle.
  • Having a complete set of approver post-review decisions is not a prerequisite to changing the status of the change request.

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 to the change request. 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. 1 comment field per entity is available to you, which you could use to quantify your decision. You could use it 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 is set.

Note - information
  • 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. Your CCMAPPROVE–Approver user parameter (TC chapter, CCM group) is set to Yes.
  • If site restrictions are in place, visibility of and access to the 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 with approval for the defined site.
    • If the Site field is blank, the change request is valid for multiple sites. You have unrestricted visibility and access to the 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 the change request is In review.
  • Your post-review decisions are not a prerequisite to the status of the 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 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.

Note - information The change request can only be rejected by the change manager assigned to it.
Note - tip You can find rejected change requests quickly and easily using the standard query functionality. Select the value Rejected in the Closed state column or for in progress change requests, the Status column, or select Rejected in both columns.

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.

Note - information
  • You can only set a rejection reason if the status of the change request is Rejected.
  • As the change manager for the change request, you’re the only user authorized to reject it.
  • Having all approver post-review decisions at Rejected status is not a prerequisite to the status of the change request being set to Rejected.
  • A notification email is not sent if the user code in the Change manager and Created by fields in the Request details section are identical.
Note - warningAll information in this section is deleted if you subsequently revert the status of the change request to In review.

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.

You can attach all documentation formats including documents, spreadsheets, images, PDFs (portable document formats), 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 supports 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 supports the reason a request for change was 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:

Bullet point  CCMCRREASON: Change requests by reason

Bullet point  CCMCRSEVERITY: Change requests by severity

Bullet point  CCMCRSTATUS: Change requests by status

This can be changed using a different setup.

Action panel

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.

Edit

Select the Edit action to update an existing change request.

Note - information 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 display for each group.

Access to detailed information for each individual transaction type is available after you select this action.

Note - information

To display the Impact analysis action, you need to select the standard browser Refresh (F5). The Impact analysis action only displays 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.
Note - warning The quantities and financial implication figures are applicable to all sites associated with the product. They're not calculated specifically for a 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.

Note - tip 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 displays if your organization manufactures the product on the change request.

Subcontract BOM revision

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

Product version management

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

Limitations

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

Bullet point 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

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 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 is 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 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 is 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 that is 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 is 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 that is 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 is 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 displays 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".

Note - informationRefer to the general 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.

The batch server process displays this message while the impact analysis is being created or updated. It also displays if you attempt to refresh the page 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 was 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 displays 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

At some stages in the processing cycle, the status of the change request can be reverted 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

Note - informationRefer to the documentation on Implementation.