Instructions and Field Description
This section describes all of the fields of the Information Technology Services Change Management Request For Change (RFC) form. Use it as a guide to complete the RFC form.
If a field name is red it is required for the Status and options selected.
Information on the Tabs/Sections:
| Field name | Input type | Information to enter | notes |
|---|---|---|---|
| Request Title | text | The brief title of the change, shows on reports and the select screen in the RFC workspace | Required to save RFC |
| Severity of Event | Select one | A summery of the severity or urgency of this change. Normally left at medium. | Can effect approval esclation. |
| Status | Select one | The current state of the RFC in its life-cycle. | |
| Status of | Draft | The initial status of a change request. Many fields are not required in this status so you can work on gathering informaion and input from others. | |
| Status of | Awaiting Change Manager Approval | Place an RFC in ths status to begin the approval process. The system escalates this RFC to the managers of the Assignees for aproval. (People's managers are from a lookup table in the RFC workspace and updates should be requested via ticket of either the footprints team or Loren.) (Contact Loren if your manager is out and you need this step bypased.) | Select this status to start the workflow |
| Status of | Awaiting CAB Approval | Once the manager(s) approve in "Awaiting Change Manager Approval" this is the next step. The CAB (Change Adversary Board) is the members of Directors+ and they review and approve your request. | This status is never selected, it is generated by workflow |
| Status of | Implementation | The status once "approved". Approved changes waiting for the implimation date and changes in progress are in this status. | This status is never selected, it is generated by workflow |
| Status of | Evaluate | The Status you select when you have completed your change. RFCs in this state appear on the completed RFC report. | Auto‑escalates to a status of closed after several days |
| Status of | Rejected | ||
| Status of | Canceled | If after entry your RFC is not going to be implemented select this status. | |
| Status of | Closed | The Status of an RFC after the services affected have been evaluated for unintended outcomes due to the change. RFCs in this state appear on the completed RFC report for 7 days after the last edit. | |
| Assignees | none in this section | Assignees appears in the "RFC ### in UNL ITS Change Management" section but is configured in the "Assignees and Notifications" section |
| Field name | Input type | Information to enter | notes | |
|---|---|---|---|---|
| all | - | The person listed in this section should be the person who internal staff can contact about this change. Supervisor voting is based on this field. | ||
| Last Name | text | Contact's last name (LDAP sn) | Required to save RFC | |
| First Name | text | Contact's first name (LDAP givenName) | Required to save RFC | |
| Email address | text | Contact's email address (LDAP mail), if an address other than the directory listing is prefered then update this field after autofilling the rest of the fields. | Required to save RFC | |
| User ID | text | Contact's MyUNL username (LDAP UID), not nessessary but a usful field for doing autofill. | ||
| Phone Number | text | Contact's phone number, if an phone other than the directory listing is prefered then update this field after autofilling the rest of the fields. Please use the person's mobile or direct number if the contact has a front desk number in the directory. | Required to save RFC | |
| Pressing enter with your cursor in any field in ths section executes a search and autofill from directory information (LDAP). Only one partial field is required for a lookup, if there is only one match it autofills the fields, if more than one macth it gives a selection list. The default search is a starts with search (search is and if data in more than one field), if you want to do a more advanced search use the Select Requestor button. |
||||
| Field name | Input type | Information to enter | notes | |
|---|---|---|---|---|
| Request Type | Select one | Normal and Emergency are the to defined types of changes in policy. See the approval work flow PDF. |
Changes which fields are displayed and which are required | |
| Request Classification of | Emergency | An emergency change in ITIL. A change that falls out side the policy of a normal change, generally caused by an unexpected outage or an urgent security update. | ||
| Request Classification of | Normal | A normal change in ITIL. | ||
| Campus Impacted | Multi Select |
|||
| Organization of | UNL,UNO,UNK, Central Administration, State Colleges | Select all that apply, enterpise services like Firefly/Sap, PeopleSoft and EMS should select all | ||
| Organization of | Other | Select if this change effects services like extention offices, ESUs or off campus research sites. | ||
| Change Codes | Multi Select |
|||
| Change code of | Security | |||
| Change code of | Preventive Maintenance | |||
| Change code of | DR Mitigation | |||
| Change code of | Enhancemant | |||
| Change code of | Break Fix | |||
| Change code of | Third Sunday Maintenance | Select for this change to appear on the Third Sunday Report. | All ITS‑ES changes occurring during the Third Sunday maintenance window need this status. | |
| Change code of | Vendor Maintenance | |||
| Change code of | Network Nebraska | |||
| Change code of | ES Outsite Window | Select for this change to appear on the ES Outsite Window Report. | ||
| Closure Code | Select one | Only appears in Evaluate and Closed statuses | ||
| Closure Code of | Compleated as planned | |||
| Closure Code of | Compleated with issues | |||
| Closure Code of | Unsuccessful | |||
| Closure Code of | Rescheduled | |||
| Closure Code of | Canceled | |||
| Application(s)/System(s) to Change | text |
The system or process to be changed. Please include services effected. |
||
|
Description of Change |
text |
Detailed description of the change request. |
||
|
Target Implementation Date |
Date and time select |
Date and time when the change is starting to be implemented. |
||
|
Estimated Completion Date |
Date and time select | Date and time when the change is expected to be compleated. | ||
|
Reason For Change |
text |
Define as precisely as possible, the justification for the change. Indicate why the change is needed, including critical dependencies such as a new statutory requirement. |
||
|
Business Units or Processes affected by the change |
text | Describe the business units, business processes, and process owners affected by the change. | ||
|
Resources required for implementing the change |
text |
Describe any dependencies for the operational implementation of this change or business solution (e.g. people, skills, roles, tools, systems, processes, organization, and technology). |
||
|
Communication Method |
Multi Select |
|||
|
Communication Method of |
IS Alert | |||
|
Communication Method of |
ITS Newsletter | |||
|
Communication Method of |
Service Team | |||
|
Communication Method of |
Tac Team presentation | |||
| Communication Method of | Targeted users list | |||
| Communication Method of | Tech Info | |||
| Communication Method of | UNL Today | |||
|
Implementation plan |
text |
This should invariably require that an attachment of a checklist, project plan or a link to the implementation plan depending on the change be included here. Otherwise, describe the steps that will be used to complete the change. |
||
|
Testing |
text |
Explain the testing method, environment and status of any ongoing testing for this change. |
||
|
Risk Assessment |
text |
Describe the risks that could affect the implementation of the change, indicating its probability of occurrence, the impact, and the action to be taking if facing the risk. Does the change jeopardize security, backups or require the modification of the business continuity and contingency plans? If so, describe here specific changes that need to be reflected on documentation and testing procedures to maintain security, ensure the integrity of backups and keep the continuity and contingency plans accurate. |
||
|
Rollback/Back out plan |
text |
An exit strategy must exist to reduce risk to the production environment in case the change doesn’t work. Describe your trigger for rolling back your changes. Provide the link to the location of your plan or attach your checklist/back-out plan. Some changes do not have a viable rollback, when this is the case please indicate why rollback will not be an option. |
||
|
Other Comments/Special Considerations |
text |
This section offers some flexibility in adding any comments. |
| Field name | Input type | Information to enter | notes |
|---|---|---|---|
| Description* | diary text | This is the system field where you (the approving manager and the implementation team) enter notes about your progress (before, during and after the change). As a diary field the contents of this field are time and date stamped each time you save. | Required to save RFC |
| Field name | Input type | Information to enter | notes | |
|---|---|---|---|---|
| Assignees | member select | Please select the people directly working on this change. If your change requires a DNS change at implementation time please coordinate with the DNS team and add a member of that team. | While there are teams listed under workspace members please do not select them. They are used for automated workflow only! | |
|
Send Email To |
check boxes | By default the system only sends emails at 2 points; to approvers when an approval is requested and to assignees when approvals have been meet. If you want someone to get notified when you save your RFC please check the appropriate box. (the requester box refers to the person in the contact section) |