Change request
Recommended approach to Sage X3 Change control management
Practical experience shows that regular meetings combined with electronic automation are a viable approach to "change management" for many organizations.
It is generally regarded as good practice in the delivery of controlled design and production "changes" to schedule regular review meetings. Whether for incremental releases, or major "changes", these should include a formal review of the business case, risk analysis discussions, and to sign off the requirements.
The Sage X3 Change Control management functionality assumes this process is taking place in your organization.
The Change request function is the central function for managing the delivery of "change" for issues that will benefit your company or your customers. It controls every stage of the "change management" process within the context of a maintenance cycle or a "change" to a design or production model. From the initial raising of a "request for change" through to the conclusion or delivery of that change, it manages business risk at every stage.
Changes are important in the development of a product and for the ongoing maintenance of a product. As the initial stage in the change control process you use the Change request function to raise, or create "change requests". You might receive a "request" to meet a change to the marketplace, solve a specific problem or to add value to a design or production model. You use the Change request function to gather the critical information, including "in-flight" (cold call) information into one central repository. The change request forms the details of the requirements; it becomes the business case supporting a specific request for a "change".
All registered Sage X3 users can raise change requests.
Having raised the initial change request, the Change request function then uses standardized procedures to enable efficient handling of all subsequent stages in the change cycle:
- Key personnel can be assigned to the change request that can identify and understand the requirements. These personnel will also be able to control the consequence of any changes.
- It provides visibility of all proposed changes and the impact of those changes on key commitments.
Personnel authorized for involvement in your "change management" process can therefore ensure the technical impact of the "change" meet your business needs and goals for product delivery. With easy access to data and the critical information needed for the assessment of the business case for the requirements, business risk is managed and minimized. - The requirements can be adapted where necessary to respond to the customer's changing business requirements. Unauthorized or unintended deviations can be prevented.
- The approach to be taken to deliver the requirements, and therefore to meet the objectives for the request can be outlined.
As a key event occurs to the change request, confirmation by email is sent to the appropriate personnel if the associated CCMEMAILxx–Email xxxx parameter (TC chapter, CCM group) is set. For example, the project manager will receive an email when the change request has been reviewed and the status progressed to In planning. The creator of the change request will receive an email when the change request is either completed or rejected. Each email contains a URL (uniform resource locator) to the change request enabling the recipient to access the change request directly from the email.
You use the Change request function, therefore, to manage your end to end "change" processes in full. When combined with regular meetings (see Recommended approach to Sage X3 Change control management above) it provides a highly effective and efficient control mechanism in the rejection or successful delivery of a "change".
How to locate a specific change request
If you access this function directly from the menu all change requests in your organization's database are displayed in a grid, or table. You can locate a specific change request quickly and easily by running a Filter. Filters provide simple and fast access to a range of, or specific, change requests, some of which are associated with your Sage X3 user code. You can find the available filters in the Action panel.
You can manipulate the results of a filter run using the standard Sage X3 query functionality. With the query functionality you can reorder the data, switch the columns and apply the filters at the top of every column. There are no restrictions on the number of times you can run or clear filters or sort orders, or move columns. You can manipulate the data until the results you require are displayed.
To redisplay the full list of change requests, simply select No filter. If you have used any column filters you will need to clear them to completely reset the filter. Your repositioned columns and sort orders do not need to be returned to their default settings as they will be retained.
Use the standard Sage X3 functionality available on every row to select your change request from the final filtered list.
Using your personal home page to locate your tasks quickly and easily
You can tailor your personal home page to display specific groups of change requests. Some of these will provide you with direct access to tasks (actions) awaiting your input.
The following gadgets display change requests at key stages of the processing cycle. They are provided for you to add to your home page as Representations (Modules = Change Control, Categories = No category):
- Change requests for my approval
This gadget shows all change requests awaiting, or currently in review, where your Sage X3 user code matches a transaction line awaiting approval.
- Change requests to manage
This gadget shows all active change requests where your Sage X3 user code is the assigned change manager.
- Change requests to plan
This gadget shows all change requests awaiting, or currently in planning, where your Sage X3 user code matches the assigned planner (project manager).
- Change request
This gadget shows all change requests in the database.
- Change requests created
This gadget shows all the change requests you have raised.
Each gadget displays a spot view of the selected, or filtered data at the point you run it. You can use the standard Sage X3 query functionality to manipulate the results in the gadget until it displays the results you require.
You can select and progress a change request directly from the gadget using the standard Sage X3 functionality available on every row.
Prerequisites
Refer to documentation Implementation
Screen management
The Change request function contains a Header section and one section per feature of the requirement:
- Header information. The header information provides key tracking information. It contains the key field Status, which indicates the current stage of this requirement in the change cycle.
- Request details. This is the main section for this function. You use it to articulate the business case for this requirement.
- Originators. Use this section to provide requester contact information.
- Approvers. Use of this section is optional. This section is used by the change manager for this change request and subject matter experts within your organization. Access to the fields is controlled by the Status field in the Header section.
- Rejection. This section is used by the change manager for this change request when this requirement is formally rejected. Access to the fields is controlled by the Status field in the Header section.
- Attachments. This section is optional. You use it to attach documents that support the business case for the requirement in its entirety, from its creation to its closure.
Header
The Header section provides key tracking information. The critical field in the header information is the Status field. This field indicates the current stage of this requirement in the change cycle. The change manager for this change request uses it to control the progress of these requirements through the change cycle.
Change managers
As the change manager for this change request you ultimately have full control over these requirements and the progress of them through the change cycle. To advance or reverse the status of this change request you need to be logged in as the current change manager for this change request.
| Description (field TITLE) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Use this field to provide a short description of this requirement (maximum 30 characters). This field is mandatory. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Status (field CRSTATUS) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Use this field to indicate the current stage of this 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 this requirement. This section also displays the name of the person who created this change request and when they created it.
- You can state the reason for this requirement.
- A requirement needs to apply to a specific product.
You can raise this requirement for a specific product if you know the product code. If you do not know the product code add a short, free-format description of it. A subject matter expert will then use your description to trace the actual product code.
If the product is version managed, you can add an additional level of detail by specifying which major and minor version this requirement is for. - The key element of the business case is a statement that describes the expected benefit of the change. This requirement might be suggested, for example, to add value to a design or enhance the product experience for the customer, or to improve delivery schedules.
You can provide this statement in a free-format narrative field. - You can define the likely impact of this requirement and the urgency of it.
You also use this section to assign personnel to this requirement that will be able to control the consequence of any changes.
- This requirement needs to be managed through the critical checkpoints to the conclusion, or closure of it.
You can assign this requirement to the default, or an appropriate "change manager". A change manager is a subject matter expert with the authority to approve or reject any suggested changes. They might be a member of your organization’s change control team, such as a development manager or a test lead. Alternatively, they might be a product manager that assesses the business case for all requirements. - You can reassign this requirement to a different change manager if, and when necessary.
- You can assign the default, or an appropriate project manager to be responsible for managing the "change".
- A different project manager can be assigned to this requirement if, and when necessary.
There can only be one "active" change request per product code. This means that if another change request is being processed for the product code on this change request you can only raise this change request. It needs to remain at New status until the other change request has been closed. Only then can you advance this change request for this product code to the review stage, then on through the change cycle.
| Product (field PRODUCT) | ||||||||
|
Use this field to identify the product. Type in, or select the product code. If you do not know the product code leave this field blank and type a short description of the product in the Description (if product unknown) field.
You can use the following for guidance when raising this change request for this product. Question: Does this product exist on a different change request? Answer: No: You can raise this change request for this product. Yes: You can raise this change request for this product.
You cannot change this product code once this change request has started 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 this change request then close it (the status needs to be set to Closed). You can then raise a new change request for the correct product code, noting the restrictions and rules above.
|
||||||||
| Description (if product unknown) (field PRODDESC) | ||||||||
|
Use this field if you do not know the product code. Type in a short description of the product (maximum 50 characters). A subject matter expert will use your description to trace and enter the correct product code for this requirement. This field is not available for entry or amendment once a product code has been added to the Product field.
|
||||||||
| Major version (field ECCVALMAJ) | ||||||||
|
Use this field to indicate which version of the selected product this change request applies to. Major versions might be used where there have been increased or significant changes to the current form, fit or function. Type in, or 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) | ||||||||
|
Use this field to indicate which minor version of the product this change request applies to. 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. Type in, or 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) | ||||||||
|
Use this field to indicate which site, location, or sites this change request applies to. If this change request applies to a single site type in, or select from the Sites table (FACILITY) 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 once this change request has started 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 this change request then close it (its status needs to display Closed). You can then raise 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) | ||||||||
|
Use this field to provide a target completion date for this requirement. |
||||||||
| Reason for change (field REASON) | ||||||||
|
Use this field to summarize the reason for this requirement. This field is mandatory. |
||||||||
| Severity (field SEVERITY) | ||||||||
|
Use this field to indicate the importance of this 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 (cosmetic): The requirement is regarded as the least-critical, lowest-priority, for consideration when time permits. |
||||||||
| Change impact (field IMPACT) | ||||||||
|
Use this field to provide an assessment of the impact this 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.
|
||||||||
| Change manager (field CCMUSRID) | ||||||||
|
Use this field to identify the subject matter expert who has 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 this 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 have been defined in their CCMROLE–Role and CCMDEPT–Department user parameters (TC chapter, CCM group). The change manager you define in this field ultimately has full control over these 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 will be 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 will be notified when the action plan has been completed or if the change request is rejected. The email will contain a URL (uniform resource locator) to this change request. This field is mandatory.
|
||||||||
| Planner (field PLANNER) | ||||||||
|
Use this field to identify the project manager who will be responsible for planning the scope of the requirements and key deliverables for this change request. The default planner is the Sage X3 user defined in the CCMPLADEF–Default planner parameter (TC chapter, CCM group). You can assign this change request to a different planner, if required. Simply type in, or 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 have been defined in their CCMROLE–Role and CCMDEPT–Department user parameters (TC chapter, CCM group). They will receive confirmation of this by email, if the folder level CCMEMAILP–Email planner parameter (TC chapter, CCM group) is set. The email will contain a URL (uniform resource locator) to the action plan. This field is mandatory if the status of this change request is In planning.
|
||||||||
| Additional information (field CRDESC) | ||||||||
|
Use this field to provide a clear statement describing the goal of these requirements. Your statement should be measurable. It should include criteria that needs 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:
|
||||||||
| Created by (field CREUSER) | ||||||||
|
The code and name of the Sage X3 user that raised this change request. The Sage X3 user displayed in this field will be notified by email when key change request events occur, if the CCMEMAILCR–Email creator parameter (TC chapter, CCM group) is set. For example, they will be notified when the change request is completed or if the change request is rejected. The email will contain a URL (uniform resource locator) to this change request.
|
||||||||
| Reassigned by (field CHGMANUSR) | ||||||||
|
This field, if populated, displays 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 this requirement or the need for this change.
You are advised to provide the name and contact details for at least one originator against this change request. This will ensure someone with knowledge of the issue is contactable should the requirements need clarification at any stage in the processing cycle.
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 is needed without the name and contact details for at least one originator.
Examples of change originators are:
- A product manager that has identified the need for a new or a changed feature in your company’s line of business.
- A network architect that has identified new-generation hardware with improved functionality to replace obsolete network hardware.
- A network engineer that has identified a method of upgrading the capacity of a device or link to handle increased traffic.
- A service manager that has identified the need to update your company’s vendor contracts or procedures.
- A Tier 1, 2, or 3 support engineer that has identified a defective part in a network element.
- A security manager requesting a configuration and documentation change in response to a newly discovered vulnerability.
All registered Sage X3 users can add originator information to any new or in-progress change request, that is at New, In review, In planning, Being implemented, or Completed status. Once a change request has started the change cycle, however, only the change manager or the user that added the originator information can amend or delete it.Field descriptions
Customer
| Customer (field CUSTOMER) |
|
Use this field to identify the customer requesting this change. Type in, or select from the BP Customers table (BPCUSTOMER) the code of the customer to be associated with this change request as an "originator". |
| Contact (field CUSTCONTACT) |
|
Use this field to identify the contact within this customer's organization that can be contacted about this change. Type in, or select from the Contacts (relationship) table (CONTACTCRM) the code of the contact to be associated with this change request as an "originator".
|
Supplier
| Supplier (field SUPPLIER) |
|
Use this field to identify the supplier requesting this change. Type in, or select from the BP Suppliers table (BPSUPPLIER) the code of the supplier to be associated with this change request as an "originator". |
| Contact (field SUPPCONTACT) |
|
Use this field to identify the contact within this supplier's organization that can be contacted about this change. Type in, or select from the Contacts (relationship) table (CONTACTCRM) the code of the contact to be associated with this change request as an "originator".
|
User
| User (field USER) |
|
Use this field to identify the Sage X3 user requesting this change. Type in, or select from the Users table (AUTILIS) the code of the Sage X3 user to be associated with this change request as an "originator". The query displays each user's Role and Department if appropriate values have been defined in their CCMROLE–Role and CCMDEPT–Department user parameters (TC chapter, CCM group). |
Other
| Contact (field EXTCONTACT) |
|
Use this field to identify the contact requesting this change. Type in, or select from the Contacts (relationship) table (CONTACTCRM) the code of the contact to be associated with this change request as an "originator". |
Tab Approvers
This section is used by the change manager for this change request and subject matter experts that have been assigned to provide input into these requirements. If you are a stakeholder or member of your company's "change board" or steering committee, you can use it to view post-review decisions or conclusions.
Change managers
As the change manager for this change request you use this section to assign this change request to subject matter experts. Subject matter experts, or "approvers", are individuals within your organization that can provide input into these requirements. They are often associated with your organization's "change board".
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 this change request should have the expertise to adequately assess these requirements from both a business and a technical perspective. You can assign entities, or types of transactions specific to their areas of expertise for them to review, or the whole request to review. You might assign a regional sales manager, for example, to review the business case and the requirements for your customers (entity). For your purchases (entity), you might, for example, assign a service manager. Some organizations have product managers that are capable of adequately assessing complete requirements from both a business and a technical perspective. If this applies to your organization you might assign a single product manager for example, to review the complete business case and the requirements.
Each approver you assign to this change request will be notified by email of the entities they need to review, if the CCMEMAILAP–Email approver parameter (TC chapter, CCM group) is set. The email will contain a URL (uniform resource locator) to this change request. With this parameter set, reassigning an entity to a different approver to review triggers an email to both the original and the new approver. Additionally, deleting an entity from the list of entities for review will trigger an email to the assigned approver.
You, in turn will be notified by email when the approvers have set approval statuses for their entities, if the CCMEMAILCM–Email change manager parameter (TC chapter, CCM group) is set.
As approvers have authority to approve or reject these requirements it is important that you give due consideration to which subject matter experts you assign.
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 this change request to In planning or Rejected status.
- You can only assign "approvers" to this change request while the status is In review.
- As the change manager for this change request you are the only Sage X3 user authorized to assign "approvers" to it.
- "Approvers" need to be authorized Change control management subject matter experts.
- You can associate multiple "approvers" with this change request.
- You can associate a single "approver" with multiple entities (or transaction types).
- You do not have authorization to set the approvers post-review decisions.
- You are responsible for manually advancing this change request to the next stage in the processing cycle.
- Having a complete set of approver post-review decisions is a not a prerequisite to changing the status of this change request.
Approvers
As an "approver" you have been assessed as having the expertise to review the business case and the requirements for this change request.
You will receive notification by email of any entity you are required to review, if the CCMEMAILAP–Email approver parameter (TC chapter, CCM group) is set. The email will contain a URL (uniform resource locator) to this change request. You should assess these requirements for each entity from both a business and a technical perspective.
Upon completion of your review you notify the change manager for this change request and the stakeholders by setting a post-review decision against each entity. One comment field per entity is available to you which you could use to quantify your decision. You could use it, for example, to state assumptions or make recommendations to the project manager responsible for planning the requirements. The change manager cannot set your approval status or add comments on your behalf.
The change manager is notified by email immediately if you have rejected an entity, if the CCMEMAILCM–Email change manager parameter (TC chapter, CCM group) is set. If you have approved the requirements, this parameter triggers email notification to this effect when an approval status for all assigned entities has been set.
- You need to meet the following conditions to be able to update your assigned entities:
- You need to be logged into Sage X3 with your user name.
- You need to have approval for involvement in your company's "change management" process as an approver, that is, your CCMAPPROVE–Approver user parameter (TC chapter, CCM group) is set to Yes.
- If site restrictions are in place, visibility of and access to this change request is determined by the value of the Site field:
- If the Site field contains a value you need to have a profile code which has approval for the defined site.
- If the Site field is blank, that is the change request is valid for multiple sites, you will have unrestricted visibility and access to this change request. Your profile code, however, needs to have approval for the transaction site.
- You can only set an "approval status" while the status of this change request is In review.
- Your post-review decisions are not a prerequisite to the status of this change request being changed.
- The change manager is not permitted to set your post-review decisions or add comments on your behalf.
| User (field APPRUSER) |
|
Use this field to identify the subject matter expert that has the expertise to review the business case and the requirements for this 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. Type in, or 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 have been defined in their CCMROLE–Role and CCMDEPT–Department user parameters (TC chapter, CCM group). They will receive confirmation of this by email, if the folder level CCMEMAILAP–Email approver parameter (TC chapter, CCM group) is set. The email will contain a URL (uniform resource locator) to this change request.
|
| Entity (field TRANSTYPE) |
|
Use this field to identify a specific entity or type of transaction that needs to be assessed for the suggested change. The assigned approver will assess this entity for these requirements from both a business and a technical perspective. The list of entities is defined in Local menu 2039–Transaction type. |
| Approval status (field APPRSTAT) |
|
Use this field to indicate 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) |
|
Use this field to summarize your decision on your review of the business case and requirements for the assigned entity (maximum 50 characters). 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 this change request. If you are a stakeholder or member of your company's "change board" or steering committee, you can use it to view the formal rejection reason and conclusions.
This change request can only be rejected by the change manager assigned to it.
You can locate rejected change requests quickly and easily using the standard Sage X3 query functionality. Simply 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 this change request you use this section to formally reject this requirement. This is mandatory if the change control team assess that the requested "change" will not improve the original and the business case is weak.
This change request needs to be at Rejected status for the fields in this section to be available for entry. As a minimum, you need to define the reason the change control team is formally rejecting these requirements.
You can expand upon the reason for rejection in a free-format narrative field. If you attach any relevant supporting documentation in the Attachments section you can use this field to add a note to this effect.
The Sage X3 user that raised this change request will be notified by email of this decision.
- You can only set a rejection reason if the status of this change request is Rejected.
- As the change manager for this change request you are the only Sage X3 user authorized to reject it.
- Having all approver post-review decisions at Rejected status is a not a prerequisite to the status of this change request being set to Rejected.
- A notification email is not sent if the Sage X3 user code displayed in the Change manager and Created by fields are identical (Request details section).
You will lose all information in this section if you subsequently revert the status of this change request to In review.
| Reason for rejection (field REJECTCOD) |
|
Use this field to summarize the reason the change control team is formally rejecting this requirement. This field is mandatory. |
| Additional information (field REJDESC) |
|
Use this field to expand upon or explain the defined rejection reason. Type in a statement that quantifies the decision to formally reject this request for change. |
| Rejected by (field REJECTUSR) |
|
This field, if populated, displays the code and name of the Sage X3 user to formally reject this change request. |
Tab Attachments
Use the Attachments section to provide documentation to support the business case for this change request. The documentation can be of any type and support the business case in its entirety, from creation and assessment through to a successful completion or rejection.
You are advised to provide all documentation deemed critical to the success of this change request. You can attach any documentation gathered by the stakeholders to solve a problem or achieve an objective. This includes conditions articulated by the customer or formal notice supporting the rejection of a request for change. This will ensure a paper trail of evidence is available should the requirements need clarification at any stage in the processing cycle.
To ensure this change request can support the business case through to its conclusion you can attach all formats of documentation, for example, documents, spreadsheets, images, portable document formats (PDF), text files. The only restriction being the length and format of the filename, which needs to be less than or equal to 30 characters with no special characters, including spaces.
All registered Sage X3 users can add attachments to any new or in-progress change request, that is at New, In review, In planning, Being implemented, or Completed status. Once a change request has started the change cycle, however, only the change manager or the user that added the attachment can amend or delete it.
Examples
Documentation that support the assessment of the business case:
- A drawing of a specific component before and after the change.
- A list of customers that will benefit from the requested change.
Documentation that support the reason a request for change has been formally rejected by the change control team:
- A questionnaire that demonstrates that the requirement will not benefit the stakeholders.
- A specification that defines the specific reason for the implemented design.
| Attachment (field CRNOTES) |
|
Use this field to attach documentation to this change request that supports the business case for this requirement. Select and attach the required file.
|
| Description (field NOTEDES) |
|
Use this field to summarize the content of the associated document. Type in a meaningful description (maximum 50 characters) which can be used to identify this document quickly and easily. For example, this document might be a design specification, specification change, standards requirement, user requirement, impact analysis-customers or a formal rejection notice. |
| Category (field NOTECAT) |
|
Use this field to categorize the associated document. Select the category that best suits the associated document. You can use this field in conjunction with the Description field to identify or categorize this document quickly and easily. |
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 this change request. The following actions are only available when the following conditions are met:
- The product code defined in the Product field is version managed.
- The status of this change request has advanced to In planning or Being implemented.
- You are logged in as the current change manager for this change request.
|
Edit |
Select the Edit action to update an existing change request.
|
|
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 this "change" on key commitment groups. Appropriate quantities and the financial implication in base currency of this change are displayed for each group. Access to detailed information for each individual transaction type is available after you select this action.
|
|
Plan |
Select the Plan action to define or view the action plan that will deliver the scope of the requirements for this change request.
|
|
Manufacturing BOM revision |
This action is displayed if your organization manufactures the product on this change request. |
|
Subcontract BOM revision |
This action is displayed if your organization procures the product on this change request from a subcontractor. |
|
Product version management |
This action is displayed if the product on this change request is version managed but is not manufactured or procured from a subcontractor. |
Limitations
You can only assign a single product code to a change request.
Only one "active" change request is permitted per product. This is to ensure a change to a product is either seen through to its conclusion and the delivery of that change, or the change request is closed.
Error messages
In addition to the generic error messages, the following messages can appear during the entry :
You have not entered a product code. If you do not know the product code enter a description of it.or
You can only change the status of this Change request when the Product code has been defined
Each change request applies to a single product code. You have two choices when raising a change request:
1: If you know the product code, you type the code in the Product field (or you can select the required code).
2: If you do not know the product code, you can provide a short description of the product in the Description (if product unknown) field. A subject matter expert will use your description to trace the correct product code and they will add it to the Product field. Once the Product field has been populated the Description field will become unavailable for entry.
The change manager for this change request can only advance it through the change cycle when the correct product code has been identified and recorded.
or
Change request $1$ is being processed for the product code. It must remain at status 'New'.
or
A change request ($1$) is currently in progress for this product
Each change request applies to a single product code. Also, there can only be one "active" change request per product code. This means that if another change request is being processed for the product code on this change request you can only raise this change request. The status of this change request needs to remain as New until the other change request has been closed.
The Reason for change field must contain a valueor
The Change impact field must contain a value
or
The Severity field must contain a value
Why are you raising this change request? How significant is this change likely to be? Select an appropriate value for this field to ensure the appropriate "change control" team can be assigned to review the business case for the requirements.
The general parameter CCMCMDEF must contain a valueor
User $1$ is not a Change Manager – see user parameter CCMCHGMAN
Each change request needs to have a nominated change manager (Change manager field). A change manager is an active Sage X3 user who has been approved for involvement in your company's CCM process. This means that the Active checkbox on their Sage X3 user record is selected and their "change manager" approval CCMCHGMAN–Change manager parameter (TC chapter, CCM group) is set to Yes. One "change manager" user should be nominated as the default change manager for all new requirements. You define the default change manager by adding their Sage X3 user code to the folder level CCMCMDEF–Default change manager parameter (TC chapter, CCM group), but only after their user parameter has been set.
User $1$ is not a PlannerEach change request needs to have a nominated project manager or planner (Planner field). A planner is an active Sage X3 user who has been approved for involvement in your company's CCM process. This means that the Active checkbox on their Sage X3 user record is selected and their "planner" approval CCMPLANNER–Planner parameter (TC chapter, CCM group) is set to Yes. One "planner" user should be nominated as the default planner for all new requirements. You define the default planner by adding their Sage X3 user code to the folder level CCMPLADEF–Default planner parameter (TC chapter, CCM group), but only after their user parameter has been set.
User $1$ is not a valid useror
User $1$ is not an Approver for Change Requests
or
User $1$ is not an Approver
This message will be displayed if the Sage X3 user code selected is invalid. This might be because they are not an active Sage X3 user or because they have not been set up as having "CCM authorization". Parameters
To be able to assign an "approver" to this change request you need to be logged in as the current change manager for this change request and the status of this change request needs to be In review.
Updating Impact analysis data. Wait a few minutes then refresh this page.or
Impact analysis data is currently being created by Batch Server Task: $1$. Wait a few minutes then refresh this page.
This message is displayed by the batch server process while the impact analysis is being created or updated. It is also displayed if you attempt to refresh the screen while the impact analysis is being created or updated.
The creation of an impact analysis can take a few minutes if the process is reading a large volume of data. You can check the status of the batch server process using the Query management function (AREQUETE). You can view the impact analysis when it shows the status Finished.
You can only add rejection attachments if the status of this Change request is 'Rejected'You can only assign this attachment to the Rejection category if this change request is being or has been formally rejected. To do this the status of this change request needs to be set to Rejected.
The Reason for rejection field must contain a valueWhy are you rejecting this change request? Select the reason in the Reason for rejection field to ensure the decision made by the "change control" team is recorded formally. You are advised to expand upon the selected reason in the Additional information field.
Status cannot be moved from $1$ to $2$or
You can only proceed if the status of this Change request is 'Plan'
or
Plan has not yet been implemented and completed
or
Plan must be at Pending status
or
This Change request is now closed. Amendment is forbidden.
Each change request needs to follow the standard processing cycle.
For a change request that will be processed through to completion the standard cycle is: New > In review > In planning > Being implemented > Completed > Closed.
For a change request that will be rejected the standard cycle is: New > In review > Rejected > Closed or New > Rejected > Closed.
The current stage in the processing cycle is displayed in the Status field. Controls are in place to ensure a change request can only advance to the next stage in the processing cycle when the current stage is completed. For example, the action plan needs to have been implemented in full before the status of a change request can be advanced to Completed.
or
Rejection details will be removed
Selected stages in the processing cycle allow the status of the change request to be reverted back one stage, for example, from Being implemented to In planning. There can, however, be consequences in doing so. Ensure you are aware of these consequences before taking this action.
Sending email notification impossible. Failure in retrieving workflow email address for $1$The email address on the user record is either missing or incorrect. Email notifications cannot be sent to this user.
[Name] is not a contact for [BP]You can only add a contact that is associated with the selected customer or supplier.
You do not have permission to delete this lineYou can only delete lines if you are logged in as the current change manager for this change request.
Tables used
Refer to documentation Implementation