1 / 18

Introduction to the Change Process

Introduction to the Change Process. October 2010 Revised September 2013. Things needed to enter a Change. At least one Configuration Item (CI) for which this change will be applied A description of the work to be done An understanding of the Risk, Impact and Benefit of this Change.

alana-cervantes
Télécharger la présentation

Introduction to the Change Process

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introduction to theChange Process October 2010 Revised September 2013

  2. Things needed to enter a Change • At least one Configuration Item (CI) for which this change will be applied • A description of the work to be done • An understanding of the Risk, Impact and Benefit of this Change

  3. Opening a New Change From the Pegasus heading, hover over the Changes tab to display the dropdown list and select New Change.

  4. Required Fields to Register a New Change • Required Values are in BOLD to save for the current Phase. • Requested By - Lastname,First (no spaces), click on the name to populate the field. This person cannot be a member of the Assignment Group when a Critical CI is chosen, but should be typically a Line Of Business person (who is not part of Vanderbilt IT or associated groups, such as Informatics) • Assignment Group –Defaults to workgroup of the person opening the change. • Change Owner – must me a member of the Assignment Group • Lastname,First (no spaces) click on name to populate field • Title – High Level description of the work. • Click +ADD to create a REGISTERED change.

  5. Adding a CI Start typing the name of the CI and then click on the appropriate selection. Click the + to add the CI to the change. This can be done for any number of CIs as needed. Note: There is an X to the left of the CI should there be a need to delete one.

  6. Fields Required to Close Phase to TO BE APPROVED • Required fields are in BOLD. Click Close Phase to advance to the next Phase. • Impact/Risk assessment: Click the subtab to complete the assessment – Pay special attention to the Critical Applications list link on this tab. • Planned Start – Changes planned for within a 3 business-day window will require the Emergency Reason box to be valued • Planned End – can not be the same as Planned Start • Scheduled Downtime Start & End – Check the CI DOWN box if the CI will be unavailable. • Affected CI – + allows for adding multiple Cis. • Description – Laymans Detailed Description about the change.

  7. Adding Approvers Click on the APPROVALS Tab, then the APPROVERS SubTab– Start typing the approvers lastname. A display window below will start showing matches. The more you type, a more restricted list is presented. Highlight the name and click on the ADD APPROVER box. Note the X next to the approvers name once the approver is added, this X is to remove an approver added in error. The Change Owner ascertains what other services or configurations items might be impacted by the Change, and is responsible for identifying the correct subject matter experts (Technical Approvers) and garnering their approval. Top & Emergency changes require the Change Owner to secure their Director’s approval priortosending it to Change Management.

  8. Emailing your list of Approvers While still on the APPROVALS Tab, click the Email Approvers tab . This is where the email message is tailored to be sent to the approvers. Include a brief description and date. Clicking SAVE retains the content of tailored email message to the approvers. Click SEND EMAIL to send approval email to your selected approvers. Keep an eye on your Change. It is the Change Owner’s responsibility to procure these approvals. Pegasus will automatically send the approval email each day until the approver approves. Contact the approver directly if necessary.

  9. Closing Phase After Your Final Approval After all technical approvers approved in TO BE APPROVED, the Current Status will say APPROVED. If there are suggestions for Line Of Business Approvers, enter their names under the ADDITIONAL APPROVERS Tab. This is a free form text box. Click the CLOSE PHASE button to send the change to Change Management. NOTE: Pay close attention to the Planned Start Date and the current Date and Time before moving it to READY FOR CAB. A change that has a Planned Start Date that falls within 3 business day of the change being moved READY FOR CAB will get flagged by the system as an emergency. Emergency Changes are only processed if they are to either avoid downtime or recover from downtime. Change Mgmt will ask you to reschedule if they don’t meet that criteria.

  10. Approving a Change When listed as a required approver on a change, one option is to approve via Pegasus Web Tool. Navigate to the APPROVALS tab, then Current Approvers. TO APPROVE: Click the box under the APPROVE heading then click SUBMIT APPROVAL. TO DENY: Click the box under the DENY heading, then click SUBMIT. You must include in COMMENTS a reason for denying the work. TO RETRACT your APPROVAL or DENIAL: Click the box under the RETRACT heading, then click SUBMIT. You must include in COMMENTS a reason for retracting. Another option to approve is via a hand held device (iPhone, Droid, etc) Follow the link in the approval email that says VIEW IN MOBILE EDITION. There will be a prompt for VUNET credentials. PegasusMobile will launch displaying the Change Title and the APPROVE/ DENY boxes. Mark the appropriate choice , then click Submit.

  11. Conditional Approval CONDITIONAL APPROVAL: If this box is checked, either a technical or Line Of Business approver has attached conditions for their approval. Approvers that wish to attach a condition should check this box and enter the conditions in the COMMENTS box when they approve the Change. Change Management and the Change Owner should review the comments under the APPROVER LOG tab for conditions if this box is checked.

  12. SLIDING IMPLEMENTATION DATE SLIDING IMPLEMENTATION DATE: When this box is checked, it allows the Change to be implemented up to six days after the Planned Start Date/Time. The requirement here is that the Change Owner must notify Change Management at least 24 Hours in advance of when they plan to actually do the work. This means one business day, and does not include weekends and holidays. Failure to do so, will force the change to be completed as Unmanaged. The Change will remain in Ready for CAB phase until Change Management receives the notification from the Change Owner.

  13. READY FOR CAB A change that is in READY FOR CAB has all fields locked to the Change Owner. There is no action required by the Change Owner in this step. Approvers will have the APPROVAL tab open to vote on the change. Approvers can Approve, Deny and Retract their vote. Denying & Retracting votes will require the approver to provide a reason. CAB will review the Change and if approved, communication will be sent and the change will move it to “IMPLEMENTATION PENDING”. If the CAB has questions or requires additional information, the Change Owner will be contacted to provide the additional information. If the CAB did not approve, Change Mgmt will move it back to REGISTERED or TO BE APPROVED based on the reason for not approving and inform the Change Owner.

  14. IMPLEMENTATION PENDING The Change will remain in this phase until the work is ready to begin. At that point it should be the Planned Start date/time, the Change Owner or Implementer will move the change to “IMPLEMENTING”. The only field that is required to move a change from Implementation Pending to Implementing is Actual Start.

  15. COMPLETED • Once the work is completed , it’s time to close out the Change. • Required Info to move from IMPLEMENTING to COMPLETED: • Actual End – the date/time of completion and/or return to normal operation for this CI • Scheduled Downtime Start/End-If applicable. • Closure Code – Choose the code which best describes the success of this event • Closure Comments – Required when the change is completed with a closure code other than SUCCESSFUL or WITHDRAWN. Supply detailed comments regarding the event and what made it not successful. • Move phase to ‘COMPLETED’. • After the fields above are satisfied, Close the Phase moving it to COMPLETED

  16. EMERGENCY CHANGES The system automatically flags as an Emergency Change any Change that is moved to TO BE APPROVED or READY FOR CAB phase when the planned Start Date/Time is less than three business days from current system date/time. Emergency Changes are reserved for changes that need to be fast tracked to either avoid downtime or to recover from downtime. They require approval from the Change Owner’s Director and from the Administrator On Call. Emergency Reason will become required; the Change Owner must provide a valid reason describing why this event is an Emergency. Emergency Changes require the Change Owner to get their Director’s approval. Change Management will get the approval of the Administrator On Call. Poor Planning is not a valid reason for an Emergency Change.

  17. Rescheduling a Change Rescheduling a Change can only happen if the work has not yet physically begun. If a change has already begun and the Owner or Implementer has decided not see it through for one reason or another, the change must be completed with the appropriate non successful Closure Code (Withdrawn is inappropriate for a change where work has begun) Rescheduling a change requires the Change Owner/Implementer to contact Change Management and ask for the change to be moved back to Registered. This resets the Approvals and clears the Planned Dates/Times.) When changing the Scope, Date, Time, etc.of a previously approved change, the change owner is responsible for getting the technical approvers to reapprove. Change Management will get the Line of Business to reapprove.

  18. Conclusion Thank You! Change Management Change.Management@vanderbilt.edu

More Related