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".
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" 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.
Description (field TITLE) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The short description of the requirement (maximum 30 characters). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Status (field CRSTATUS) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The current stage of the requirement in the change cycle.
Change cycle status summary
|
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.
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. It needs to remain at New status until the other change request has been closed. Only then can you advance the change request for this product code to the review stage, then on through the change cycle.
Product (field PRODUCT) | ||||||||
The product code. If you do not know the product code, leave this field blank and enter a short description of the product in the Description (if product unknown) field. You can only assign a single product code to a change request. You should also be aware that for successful "change management" 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. You can use the following for guidance when creating the change request for this product. Question: Does this product exist on a different change request? Answer: No: You can create the change request for this product. Yes: You can create the change request for this product.
You cannot change this product code after the change request starts the change cycle, for example, when its status has advanced to In review. If you do need to change it and the change cycle has started, reject the change request then close it. The status needs to be set to Closed. You can then create a new change request for the correct product code, noting the restrictions and rules above. You need to be logged in as the current change manager for the change request to change its status. |
||||||||
Description (if product unknown) (field PRODDESC) | ||||||||
Use this field if you do not know the product code. Enter a short description of the product up to a maximum of 50 characters. A subject matter expert uses your description to trace and enter the correct product code for the requirement. This field is not available for entry or amendment after a product code has been added to the Product field. The change request can only be progressed when the product has been traced and the code defined in the Product field. |
||||||||
Major version (field ECCVALMAJ) | ||||||||
The major version of the product that applies. Major versions might be used where there have been increased or significant changes to the current form, fit, or function. Select a version code from the list of version codes displayed. This field is not available for entry if the product code defined in the Product field is not version managed. |
||||||||
Minor version (field ECCVALMIN) | ||||||||
The minor version of the product that applies. Minor versions might be used where there have been minor features or changes to the current form, fit, or function, or significant fixes applied to a specific major version. Select a revision or minor version code from the list of version codes displayed. This field is not available for entry if the product code defined in the Product field is not version managed. |
||||||||
Site (field SITE) | ||||||||
The sites or locations where the change request applies. If the change request applies to a single site, select the required site code. A change request applies to a single site if either of the following conditions apply:
Leave this field blank if multiple sites are, or have, reported the issue. You cannot change the site code after the change request starts the change cycle, for example, when its status has advanced to In review. If you do need to change it and the change cycle has started, reject the change request then close it. The status needs to display Closed. You can then create a new change request for the correct site, noting the restrictions and rules for the selected product code. Refer to the Product field for further information. |
||||||||
Required date (field DATEREQ) | ||||||||
The target completion date for the requirement. |
||||||||
Reason for change (field REASON) | ||||||||
The reason for the requirement. |
||||||||
Severity (field SEVERITY) | ||||||||
The importance of the requirement. The following 4 severity levels are associated with change requests. Critical: The requirement needs to be satisfied for the solution to succeed. The requirement is therefore considered critical for the quality of the product or the success of the new design. Major: The requirement is regarded as high-priority and should be included in the solution if possible. Moderate: The requirement is regarded as desirable but not necessary. Minor or cosmetic: The requirement is regarded as the least-critical, lowest-priority, for consideration when time permits. |
||||||||
Change impact (field IMPACT) | ||||||||
The assessment of the impact the requirement will have on the current form, fit, and function.
Major: The requirement will impact the form, fit, function, or the technical specification. The requirement is therefore considered reportable. Minor: The requirement will not impact the form, fit, function, or the technical specification. Unknown: The impact of the requirement on the current design is not known. The acceptable deviation from the original design will vary from organization to organization, product to product, and part to part, and should be considered. For example, an interchangeable part such as a different bottle lid color might require a new part number in some companies but not others. |
||||||||
Change manager (field CCMUSRID) | ||||||||
The subject matter expert with the authority to categorize, prioritize, approve, or reject, and monitor the suggested change. The default change manager is the Sage X3 user defined in the CCMCMDEF–Default change manager parameter (TC chapter, CCM group). You can assign the change request to a different change manager, if required. Simply type in, or select a user code from the list of users approved for involvement in your "change management" process as "change managers". The query displays each user’s Role and Department if appropriate values are defined in their CCMROLE–Role and CCMDEPT–Department user parameters (TC chapter, CCM group). The change manager that you define in this field ultimately has full control over the requirements and the progress of them through the change cycle. They have administrative rights to advance or reverse them through the stages of the change cycle as they deem necessary. To assist with their decision making, they’re notified by email when key change request events occur, if the folder level CCMEMAILCM–Email change manager parameter (TC chapter, CCM group) is set. For example, they’re notified when the action plan is completed or if the change request is rejected. The email contains a URL (uniform resource locator) to the change request. You can only change the default or the assigned change manager if you meet 1 of the following conditions:
If you’ve assigned yourself as the change manager, you will not receive a notification email. |
||||||||
Planner (field PLANNER) | ||||||||
The project manager responsible for planning the scope of the requirements and key deliverables for the change request. The default planner is the Sage X3 user defined in the CCMPLADEF–Default planner parameter (TC chapter, CCM group). You can assign the change request to a different planner. Select a user code from the list of users approved for involvement in your "change management" process as project managers or "planners". The query displays each user’s Role and Department if appropriate values are defined in their CCMROLE–Role and CCMDEPT–Department user parameters (TC chapter, CCM group). They receive confirmation of this by email if the folder level CCMEMAILP–Email planner parameter (TC chapter, CCM group) is set. The email contains a URL (uniform resource locator) to the action plan. You need to enter this field the change request is at In planning status. You can only change the default or the assigned project manager if you meet 1 of the following conditions:
If you’ve assigned yourself as the planner, you will not receive a notification email.
|
||||||||
Additional information (field CRDESC) | ||||||||
The clear statement describing the goal of the requirements. The statement should be measurable. It should include criteria that need to be met for the design or production "change" to be considered successful in terms of cost, scheduling, or quality. You can also use this field to provide the following information:
Your statement is critical to the success of these requirements. It’s used when defining the deliverables for the design or production model. It's also used to avoid scope creep. Your information should not specify how the change should be carried out. |
||||||||
Created by (field CREUSER) | ||||||||
The code and name of the Sage X3 user that created the change request. The Sage X3 user displayed in this field is notified by email when key change request events occur, if the CCMEMAILCR–Email creator parameter (TC chapter, CCM group) is set. For example, they’re notified when the change request is completed or if the change request is rejected. The email contains a URL (uniform resource locator) to the change request. Notification emails are only sent if the Sage X3 user code displayed in the Change manager field (CCMUSRID) is different from the user code. |
||||||||
Reassigned by (field CHGMANUSR) | ||||||||
The code and name of the last Sage X3 user to change the Change manager field (CCMUSRID). |
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.
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.
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.
Customer
Supplier
User
User (field USER) |
The Sage X3 user requesting the change. Select the code of the Sage X3 user to be associated with the change request as an "originator". The query displays each user's Role and Department if appropriate values are defined in their CCMROLE–Role and CCMDEPT–Department user parameters (TC chapter, CCM group). |
Other
Contact (field EXTCONTACT) |
The contact requesting the change. Select the code of the contact to be associated with the change request as an "originator". |
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".
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, 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.
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.
- 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 (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.
- 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.
User (field APPRUSER) |
The subject matter expert with the expertise to review the business case and the requirements for the change request. Subject matter experts, or "approvers" are authorized for involvement in your "change management" process. They might be, for example, a member of your organization's "change board". They have the authority to approve or reject the suggested change for an assigned area of expertise. Select a user code from the list of users approved for involvement in your "change management" process as subject matter experts. The query displays each user's Role and Department if appropriate values are defined in their CCMROLE–Role and CCMDEPT–Department user parameters (TC chapter, CCM group). They receive confirmation of this by email, if the folder level CCMEMAILAP–Email approver parameter (TC chapter, CCM group) is set. The email contains a URL (uniform resource locator) to the change request.
|
Entity (field TRANSTYPE) |
The specific entity or type of transaction that needs to be assessed for the suggested change. The assigned approver will assess the entity for the requirements from both a business and a technical perspective. The list of entities is defined in the 2039–Transaction type local menu. |
Approval status (field APPRSTAT) |
The current status of the decision in the review of the business case and requirements for the assigned entity.
Approved: If your review concludes that the business case for the requirements is valid for the assigned entity and is approved. Rejected: If your review concludes that the requirements for the assigned entity have no business case to support them and are rejected.
|
Reason (field APPRREASON) |
The summary of your decision on your review of the business case and requirements for the assigned entity. You could use it, for example, to state assumptions or make recommendations to the project manager responsible for planning the requirements. |
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.
The change request can only be rejected by the change manager assigned to it.
You can find rejected change requests quickly and easily using the standard Sage X3 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.
- 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 Sage X3 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 Sage X3 user code displayed in the Change manager and Created by fields in the Request details section are identical.
Reason for rejection (field REJECTCOD) |
The reason the change control team is formally rejecting the requirement. |
Additional information (field REJDESC) |
An explanation of the defined rejection reason. Enter a statement that quantifies the decision to formally reject the request for change. |
Rejected by (field REJECTUSR) |
The code and name of the Sage X3 user to formally reject the change request. |
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
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. 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. |
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 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
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.
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 valueor
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 valueor
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 PlannerEach 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 useror
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
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 valueWhy 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.
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 lineYou can only delete lines if you’re logged in as the current change manager for the change request.
Tables used
Refer to documentation Implementation