E1 & Application Change Request Process

E1 Change Requests

All E1 Change Requests should have an incident or service request that initiated the change.

Create a change request from the incident or service request.
1. Click on Associate à Change Initiated by this ticket

Fill out ‘Associate a change’ form
1. New Change – select
2. Workspace – IT
3. Requester – this should be the person that reported the issue or workstream lead (not typically an IT person)
4. Subject – this will default from the Ticket Title – Update to an end user friendly description of the change
5. Change Type – enter the appropriate change type
  1. Standard - Routine and low-risk modifications in a processes or system. These alterations are well-defined, with established procedures for implementation and pre-approved. No approval needed.
  2. Minor - Encompass alterations that are more substantial than Standard Changes but still manageable in terms of risk. They involve moderate complexity and require a formal review and approval process. These Changes demand careful planning, impact assessment, and coordination among different departments or teams. Approval needed.
  3. Major – denote substantial transformations that influence multiple dimensions of an organization. These shifts have a significant impact and necessitate extensive assessment, planning, and stakeholder engagement. The intricacy of these changes calls for a structured Change Management approach, often requiring a dedicated change board for approval processes. Major Changes may involve strategic realignments, organizational restructuring, or comprehensive technological updates. Effective communication and thorough planning are crucial to minimize risks and enhance the positive effects of such fundamental changes. Approval needed.
  4. Emergency – Emergency Changes are rapid-response modifications enacted to address critical situations, such as system failures or security breaches. Characterized by urgency, they aim to swiftly contain and rectify the issues at hand. While the approval process might be expedited, documentation remains essential to ensure accountability and future reference. Despite the urgency, Emergency Changes still require effective communication to keep stakeholders informed. The goal is to restore operational normality promptly while learning from the ITIL Incident Management to prevent similar emergencies in the future. At minimum verbal acknowledgement needed. Approval can be postmarked.
6. Status – Open is defaulted
  1. Open - change number assigned & minimum info required. SLA timer not running.
  2. Planning – in documentation state & being prepared for an approval request. SLA timer running.
  3. Awaiting Approval – in approval queue waiting on Change Advisory Board (CAB) meeting. SLA timer paused.
  4. Pending Release – approved and pending implementation. SLA timer running.
  5. Pending Review – implemented and to be reviewed on next CAB meeting. SLA timer stopped.
  6. Closed – change record closed.
7. Priority - the assessment of the relative importance of a change. How urgent is for us to do this?
  1. Low
  2. Medium
  3. High
  4. Urgent
8. Risk - the risk of the of the change.
  1. Low
  2. Medium
  3. High
  4. Very High
9. Group – Select appropriate JDE Group – majority of time it will be JDE Functional
10. Agent – Select the appropriate Agent – majority of time it will be a Business Analyst
11. Description – this will default from the ticket description - update to document the change made
12. Planned Start Date – dependent on change (for E1 changes, use Change Control Mtg Date)
13. Planned End Date – Anticipated in Production Date - dependent on change (for E1 changes, use date following Change Control Mtg Date)
14. Actual Implementation Date – LEAVE THIS BLANK – this date will be filled in once the change is moved to PD
15. Department – Will default from the Requester
16. Category – Select Enterprise Applications
17. Sub-Category – Select JDE (E1) – this selection brings up additional field required for E1 related changes
18. Item – Select the appropriate workstream
19. OMW Project ID / ASU#, ESU#, SP# / Tool Release # - enter the appropriate E1 information
20. Type of update
  1. ASU – Application Software Update
  2. CNC Configuration
  3. DD – Data Dictionary
  4. Environment Refresh
  5. ESU Electron Software Update
  6. Manual PD Configuration
  7. Project – OMW
  8. SP – Service Pack
21. Object – enter object(s) from OMW project or enter N/A if not an OMW project
22. Version – enter version(s) from OMW project or enter N/A if not an OMW project
23. Table Generation & Data Source - Enter N/A if no table or enter table object name and data Source (schema or library where the table resides). Need details if table should be generated in PD.
24. Emergency Promotion
  1. Yes – if this is selected, the Change Type above (2e) should be Emergency
  2. No
25. Emergency Promotion Reason – required if Emergency Promotion is Yes. Enter the reason for the Emergency Promotion and timing needed to be in PD. Emergency Promotions would fall outside of the weekly Wednesday PD Build/Deployment.
26. Business Owner – Enter the Workstream Lead
27. UDO in Project – Select Yes or No
28. Link to Spec Documentation – enter the link or state if the documentation is attached to the incident/service request
29. Testing Doc/Signoff Link – enter the link or state if the documentation is attached to the incident/service request
30. Maintenance Window – n/a
31. Attach Files – any files related to the change can be added here
Click on Associate to create the Change Request and associate to the ticket
Open Change Request created in Step 3
Fill Out Planning Section
1. Reason for Change – Enter a reason for this change – be descriptive. ‘The Business requested’ is not a valid reason.
2. Impact – Enter what is the potential impact to users and/or the application
3. Rollout Plan – Enter the rollout plan, this could be as simple as promoting the change or detailed if the change is more involved.
4. Backout Plan – Enter the plan to back the change out of production if necessary
Move Status to ‘Planning’ and Click Update
When ready to Review Change with Change Control Board, Move Status to ‘Awaiting Approval’ and Click Update
Change Requests in ‘Awaiting Approval’ status will be reviewed during the Change Control meeting on Wednesday. If the Change is approved, the status will be moved to ‘Pending Release’.
After the Change is moved to production, Lisa Bussa will update the Actual Implementation Date and update the status to ‘Pending Review’
Changes in ‘Pending Review’ status will be reviewed during the Change Control Meeting and Lisa Bussa will update the status to ‘Closed’ after review.

Application (Non-E1) Change Requests

All Application (Non-E1) Change Requests should have an incident or service request.

Create a change request from the incident or service request
1. Click on Associate à Change Initiated by this ticket

A screenshot of a computerAI-generated content may be incorrect.

Fill out ‘Associate a change’ form
1. New Change – select
2. Workspace – IT
3. Requester – this should be the person that reported the issue or workstream lead (not typically an IT person)
4. Subject – this will default from the Ticket Title – Update to an end user friendly description of the change
5. Change Type – enter the appropriate change type
  1. Standard - Routine and low-risk modifications in a processes or system. These alterations are well-defined, with established procedures for implementation and pre-approved. No approval needed.
  2. Minor - Encompass alterations that are more substantial than Standard Changes but still manageable in terms of risk. They involve moderate complexity and require a formal review and approval process. These Changes demand careful planning, impact assessment, and coordination among different departments or teams. Approval needed.
  3. Major – denote substantial transformations that influence multiple dimensions of an organization. These shifts have a significant impact and necessitate extensive assessment, planning, and stakeholder engagement. The intricacy of these changes calls for a structured Change Management approach, often requiring a dedicated change board for approval processes. Major Changes may involve strategic realignments, organizational restructuring, or comprehensive technological updates. Effective communication and thorough planning are crucial to minimize risks and enhance the positive effects of such fundamental changes. Approval needed.
  4. Emergency – Emergency Changes are rapid-response modifications enacted to address critical situations, such as system failures or security breaches. Characterized by urgency, they aim to swiftly contain and rectify the issues at hand. While the approval process might be expedited, documentation remains essential to ensure accountability and future reference. Despite the urgency, Emergency Changes still require effective communication to keep stakeholders informed. The goal is to restore operational normality promptly while learning from the ITIL Incident Management to prevent similar emergencies in the future. At minimum verbal acknowledgement needed. Approval can be postmarked.
6. Status – Open is defaulted
  1. Open - change number assigned & minimum info required. SLA timer not running.
  2. Planning – in documentation state & being prepared for an approval request. SLA timer running.
  3. Awaiting Approval – in approval queue waiting on Change Advisory Board (CAB) meeting. SLA timer paused.
  4. Pending Release – approved and pending implementation. SLA timer running.
  5. Pending Review – implemented and to be reviewed on next CAB meeting. SLA timer stopped.
  6. Closed – change record closed.
7. Priority - the assessment of the relative importance of a change. How urgent is for us to do this?
  1. Low
  2. Medium
  3. High
  4. Urgent
8. Risk - the risk of the of the change.
  1. Low
  2. Medium
  3. High
  4. Very High
9. Group – Select appropriate Group – majority of time it will be Non-ERP Application, DSI, EDI or Varsity
10. Agent – Select the appropriate Agent – majority of time it will be a Business Analyst
11. Description – this will default from the ticket description - update to document the change made
12. Planned Start Date – dependent on change (for E1 changes, use Change Control Mtg Date)
13. Planned End Date – Anticipated in Production Date - dependent on change (for E1 changes, use date following Change Control Mtg Date)
14. Actual Implementation Date – LEAVE THIS BLANK – this date will be filled in once the change is moved to PD
15. Department – Will default from the Requester.
16. Category – Select Enterprise Applications
17. Sub-Category – Select Application other than JDE (E1)
18. Attach Files – any files related to the change can be added here.
Click on Associate to create the Change Request and associate to the ticket.
Open Change Request created in Step 3
Fill Out Planning Section
1. Reason for Change – Enter a reason for this change – be descriptive. ‘The Business requested’ is not a valid reason.
2. Impact – Enter what is the potential impact to users and/or the application
3. Rollout Plan – Enter the rollout plan, this could be as simple as promoting the change or detailed if the change is more involved.
4. Backout Plan – Enter the plan to back the change out of production if necessary.
Move Status to ‘Planning’ and Click Update
When ready to Review Change with Change Control Board, Move Status to ‘Awaiting Approval’ and Click Update
Change Requests in ‘Awaiting Approval’ status will be reviewed during the Change Control meeting on Wednesday. If the Change is approved, the status will be moved to ‘Pending Release’.
After the Change is moved to production, Lisa Bussa will update the Actual Implementation Date and update the status to ‘Pending Review’
Changes in ‘Pending Review’ status will be reviewed during the Change Control Meeting and Lisa Bussa will update the status to ‘Closed’ after review.