Reading...
Play button
Play button
Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
25 Cards in this Set
- Front
- Back
- 3rd side (hint)
|
Service Transition: Theory
|
- Once a service has been designed, it must be transitioned into the live environment.
- Ensures that new, modified or retired services meet business expectations as documented during Service Strategy and Service Design |
2 |
|
|
Service Transition: Scope
|
- Process should lead to development and improvement of organization's capabilities for getting new and changed services into the live environment, and retiring services from the live environment.
|
1 |
|
|
Service Transition: Communication Plan
|
All statements released as part of a transition should be assessed with the following questions:
-When will the information be delivered? One shot, or over a set period? -How should the info be delivered? Tone and style? -What actions must be taken prior to communication to "clear the ground" -How and when will groups be involved in cascadign information? -Are the communications successful in overcoming barriers? -Has there been any consideration of the communication needs of any of the other stakeholders in the process? |
6 |
|
|
Service Transition: Stakeholder Management
|
Stakeholders can be customers, users, support staff, developers, third-party suppliers, etc.
Failure to manage stakeholders can result in missed deliverables, poor communcation and failure to gain value from a transitioned service, as well as failure to identify requirements, which leaves stakeholders feeling excluded and potentially resistant to the change. |
|
|
|
Service Transition: Stakeholder Management Strategy Should identify:
|
-Stakeholders
-Likely interests and influences of stakeholders -Project or program and how it will engage with stakeholders -Information to be communicated -How stakeholder feedback will be processed **Once stakeholders are understood, they can be provided with the information they require to support the change.** |
|
|
|
Service Transition: Change Management:
Sources of Changes |
Numerous, including:
-Customer requirements -Legislative or external business changes -Internal improvements and fixes -New Services |
|
|
|
Service Transition: Change Management:
Purpose |
To control the lifecycle of all changes, so that beneficial changes can be made with minimal disruption to services. Smoothly transition new and changed services to production environment.
|
|
|
|
Service Transition: Change Management:
Objectives |
To:
-Respond to changing business requirements while minimizing disruptions -Manage and implement Changes to ensure that services remain aligned with business requirements -Ensure that Changes are recorded (CMS) and managed from inception through implementation and review. -Optimize business risk--business may be prepared to accept a riskto get a change they need, but must understand the risk before they can accept it. |
|
|
|
Service Transition: Change Management:
Scope |
Change Management covers the management of changes to all CIs across the service lifecycle. Anything that contributes to the delivery of a service can fall within the scope of Change Management.
-Business Changes, such as a building move or relocation are OUTSIDE the scope of ChM, although IT ChM may support them. -Coordination of the ITSM Processes involved in a Change is OUTSIDE the scope of ChM. No change is risk-free. The smallest, simplest changes may constitute the greatest threats when introduced to the production environment. Ask: -What changes must be managed? -What kinds of changes do we deal with regularly? -What kind of changes are threats to our production environment? |
|
|
|
Service Transition: Change Management:
Input Sources: |
-Service Strategy (specifically Service Portfolio Management)--Initiates strategic changes)
-Service Design, CSI, SLM and Service Catalog Management--Initiate Service changes -Service Operation--Corrective changes (to address and incident or problem) |
|
|
|
Service Transition: Change Management:
Value |
Customer confidence that they will get what they need, when they need it, and in a working state.
Minimizes the time that IT staff spends tring to fix issues related to Changes, and reduces re-work (implementing the same changes over and over until they are successful) |
|
|
|
Service Transition: Change Management:
Change Proposal |
" A document that includes a high-level description of a potential service introduction or significant change, along with a corresponding business case and an expected implementation schedule."
|
|
|
|
Service Transition: Change Management:
Change Request (RFC) |
A formal proposal for a change to be made.
|
|
|
|
Service Transition: Change Management:
Change |
The act of adding, modifying or removing anything that could have an effect on IT services
|
|
|
|
Service Transition: Change Management:
Change Record |
"A record containing details of a change" throughtout its lifecycle. Records are created for ALL RFCs, even if they are rejected. the Change REcord contains information from the RFC, and updates from ChM as the Change lifecycle progresses
|
|
|
|
Service Transition: Change Management:
Change Classification |
Based on impact (high, medium or low) and the level of risk.
Different classifications of Changes are treated differently. |
|
|
|
Service Transition: Change Management:
Standard Changes: |
A change to a service or the infrastructure for which an approach has been agreed and pre-authorized by ChM. No need for individual assessment.
A procedure will be defined and accepted within the organization for these low-risk, low-impact changes. Standard changes have defined triggers, are low-risk, and must be carried out using a proven, documented procedure. ChM is initially involved in defining and pre-authorizing these low-impact, low-risk Changes. |
|
|
|
Service Transition: Change Management:
Normal Changes |
Normal Changes are triggered by an RFC from a change initiator. Normal Changes may be higher risk than Standard changes, or they may be novel.
The process for a Normal change allows relevant stakeholders to fully assess the Change, identify any potential difficulties, and make recommendations for how to address them prior to implementation of a Change. Normal Change examples might be: Installation of an organization-wide upgrade to an existing application, introduction of a new application, upgrades to hardware, or the release of a new piece of hardware. |
|
|
|
Service Transition: Change Management:
Emergency Change |
-Much less frequent than Normal or Standard Changes.
Still must be designed, managed and tested as much as possible in the available timeframe to minimize negative impact on the organization. Details of an emergency change may be recorded retrospectively--all details must still be recorded. Carefully defined levels of authority must be in place within the organization for management of emergency changes. A small group of people should be able to analyze the situation quickly and provide a well-reasoned response. |
|
|
|
Service Transition: Change Management:
Change Model |
Used by organizations to document and define the specific steps required to manage a particular type of Change and provide a repeatable way of doing so. Used by ChM and Incident Management primarily
Typically include: -Details of the steps to be taken -Timescales for each step, and chronological order (including dependencies) for each step -Roles and responsibilities of the people involved -Limitations on each role? -Dependencies or actions that must occur sequentially -Thresholds -How escalations should be managed, including escalation points and procedures |
|
|
|
Service Transition: Change Management:
Remediation Planning |
Plan B: What to do if things go wrong during Change implementation.
Every Change must have a remediation plan. Remediation plans include triggers and decision points. (e.g. if a step isn't completed in the agreed time, the remediation plan will be invoked) -Back out plan -IT Service Continuity Plan initiation -Other actions to protect the affected business process |
|
|
|
Service Transition: Change Management:
CAB |
The CAB is a group of stakeholders and SMEs that meet to review and support ChM during the assessment, prioritization and scheduling of Changes. The CAB meets regularly, and the schedule of meetings is dictated by the volume of Changes. CAB membership may vary depending on requirements. An immature process may require more frequent meetings of the CAB. ChManager is usually the CAB chair, and members are frequently customers, users, developers, third-parties and SMEs
|
|
|
|
Service Transition: Change Management:
E-CAB |
An Emergency Change Advisory Board is a subset of the CAB, and consists of a few senior, select people who can be quickly convened and have the authority to make a decision about an emergency change.
Emergency changes should still be designed and tested to the degree possible, and must be reviewed by the full CAB following implementation. |
|
|
|
Service Transition: Change Management:
Business Process Interfaces |
Program and Project Management (ChM needs to be involved in projects as early as possible, and identify any possible impact)
Organizational and Stakeholder Change Management (Need to evaluate whether Changes will affect the overall organizational structure/staff) Sourcing and Partnering (ChM needs to work with internal and external vendors and partners, integrating with their ChM processe if required.) |
|
|
|
Processes : ITIL Service Transition |
- Transition Planning & Support - Application Development |
8 |
