This is the stage when services are built.
- Coordination is key among stakeholders, customers, users, and support organizations.
- Create end-to-end testing.
Key takeaways
- Physical implementation of new service
- Tested in a live environment
- Configuration has been documented
- Operations has been trained
- To plan and manage service changes while managing transition risks.
- To ensure services meet the business's needs and create value.
- Plan and manage service changes efficiently and effectively using eight processes.
- Manage risks.
- Successfully deploy into environment.
- Manage expectations of new or changed services.
- Create business avlue.
- Create knowledge management system.
Set up appropriate contracts with outside services.
- Outcomes are facilitated by the services without the detailed costs and risks
- Traditional Outsourcing - transfer services from internal provisioning to an external provider.
- Changing Outsourcing - transfer services from one external supplier to another external supplier.
- Re-Insourcing - transfer services from ane xternal supplier to your in-hour team.
- Partnership or Co-Sourcing - Migrate to a partnership agreement where some of the service is outsourced and some is in-house.
- Co-Sourcing/Multi-sourcing - Using multiple suppliers (increasing service level management complexity)
Provide planning for Service Transition and coordinate resources
Functions
- Plan and coordinate resources for multiple concurrent transitions
- Lean major changes through the Transition stage
- Migrate new or change services to operations
- Establish new/improved management systems and tools
- 5 pieces of holistic Service Design
- Provide transition plans to align business changes and service transition
- Identify, manage, and control risks across the other processes
- Monitor and improve Service Transition stage
- Ensure that reliable and secure information are available to decision makers
- Ensure service management data is collected and maintained
- Create and maintina information management system
KM occurs in all stages of ITIL lifecycle.
| Wisdom | Decisionable |
| Knowledge | Analyzed in Context |
| Information | Context and Patterns |
| Data | Facts and Figures |
- Service Knowledge Management System (SKMS)
- Configuration Management System (CMS)
- Configuration Management Databases (CMDB)
- Configuration Management System (CMS)
Ensure required assets are managed and information is accurate/reliable.
- Don't start until change control and management are in place
- SACM is powerful because of relationship between configuration items.
Functions
- Keep accurate information on configuration items.
- Historical information is necessary.
- Ensures only authorized components are used.
- Ensures only authorized changes occur.
- Supports other processes across lifecycle.
- Configuration Items (CIs) - individual records in Configuration Management Database (CMDB) of assets that need to be managed.
- Hardware, software, people, documentation, physical locations
- Levels - Consider how detailed CIs should be.
- Naming - Determine uniform naming convention.
- Labels - How to assign labels to assets? Hardware? People? Software?
- Atributes - What do you want to know about the CI?
- Description, unique ID, location, etc.
- Configurations - Group of CIs to make up a specific build.
- Baselines - Snapshot of a configuration.
- Configuration Management System - Tools for tracking configruation information.
- Definitive Media Library (DML) - Secure storage area for all authorized software versions.
- Planning and Management - Make a plan.
- Identification - Designate CI types, agree on naming conventions, decide on unique IDs
- Control - Integrate SACM into the processes taht produce changes to keep CI up to date
- Change Management
- Release and Deployment Management
- Incident Management
- Status Accounting - Status of a CI's changes over time with standard status codes.
- Verification and Audit - Is it effective?
To control the lifecycle of all changes, maximizing benefit and minimizing disruption.
Functions
- Respond to change-initiating triggers
- New business requirements
- Operational failures
- Improvements and additions
- Manage changes at every stage in service lifecycle
Emergency Changes
- Address unforeseen issues
- Rapid change is required to continue business operations
- Should still follow documented procedures
- Clearly define who can declare an emergency change
- Emergency Change Advisory Board (ECAB) can be called after hours
- Testing may be modified or removed
- RFC and documentation are done after issue resolution
Normal Changes
- Are unique or have a higher risk than a standard change
- Default type of change that occurs; emergency and standard are variations on this.
Standard Changes
- Typical day-to-day changes, low-risk and well-understood
- Minimizes bureaucracy and quickly satisfies customers
- Use a shorter version of the Normal Change procedures
- Generally follow predefined, automated workflow
- Don't need CAB approval
Why do changes fail?
- Wider impact than imagined
- Insufficient resources
- Stakeholder disagreements about who can authorize
- Poorly planned/conducted testing
- Users not ready
- Support organizations not ready
- Rolled out prematurely due to management pressure
- Two incompatible changes at once
- Initiation
- Initiated by trigger
- Priority must be determined
- Initial Review
- Determine if change is realistic
- Must be documented in CMS
- Raise Request for Change (RFC)
- "Move, Add, Change" (MAC)
- Raised - Who requested it?
- Reason - Why is it needed?
- Return - ROI?
- Risks - What are the uncertainties?
- Resources - What does it cost?
- Responsible - Who's the owner?
- Relationship - with other changes
- Assess and Evaluate
- Analyze change and get recommendations
- Authorization to Proceed
- Get permission from Change Advisory Board (CAB)
- Build and Test
- Owner/Sponsor builds
- Service Validation and Testing tests it
- Authorization to Implement
- Test results presented to CAB for approval and scheduling
- Implementation
- Release and Deployment team implement the change in the production environment
- Remediation
- Back out plan if it doesn't work properly
- Is there a point of no return?
- Review
- If implementation is successful, review occurs on accepted timeline
- Closure
- Results of review are recorded
- Lessons learned identified
- Change pushed to CSI
- CAB authorizes closure.
- Makes major decisions for all changes
- Meet on regular basis
- One master CAB may oversee smaller CABs
Members
- Change Manager (Chariman)
- Service Desk Manager
- Capacity Manager
- IT Security Manager
- etc
CAB Meeting Inputs
- Minutes of previous meeting
- Any Emergency CAB activity
- New changes for decision
- Changes ready for implementation
- Change reviews completed since last meeting
- Any improvement initiatives
CAB Meeting Outputs
- Minutes of meeting
- Authorized new changes
- Rejected changes
- Updated change schedule
- Update Project Service Outage (PSO)
CAB Chairman's Role
- Enforces standards and processes
- Ensures all change authorities have approved the changes before he does
- Provides final approval on RFC
- CAB is an advisory board to make recommendations to the Change Authority, a stakeholder for any change.
- RFC documents Change Authority during "Raising of an RFC" in change workflow.
Simple or complex?
Standard Change Model
- Covers all the technical details and angles of the proposed change
- Detailed plan for routine tasks
Normal Change Model
- Not as detailed because they are new and unique
Models provide guidance and checklists when limited time is available in emergency situations.
- Request for Change
- Formal change proposal
- Manages change throughout the process
- Change Record
- Gives details to the RFC
- CAB Minutes
- Meeting minutes with details
- Change Schedule
- State changes to be implemented and when
- Project Service Outage
- Notifies everyone of any changes to normal service availability
A release is any change to an IT service.
Plan, schedule, and control the building, testing, and deployment of releases to dliver new functionality while protecting existing services.
- Physical assets
- Virtual assets
- Application/system software
- Relevant documentation
- Training for users and IT staff
- Supporting services, contracts, and agreements
- Ensure testing is completed
Functions
- Produce/maintain R&D policy and plans
- Define/create/test release packages
- Maintain live environment
- Deploy software from DML only
- Track progress of releases with SACM
- Ensure release has a test plan for backout
- Manage stakeholder change
- Ensure services deliver expectations
- Record/manage risks and issues
- Ensure successful transfer of skills and knowledge
Secure Repositories
- Definitive Media Library (DML)
- Secure storage of quality-checked master copies of all software
- Controlled access (physical, electronic, or both)
- Software remains here until it is no longer useful
- Many organizations keep licenses in DML
- Definitive Spares
- Unallocated items of hardware
- A float is unallocated but configured hardware ready to be swapped
- Controlled and quality-checked like the DML
Plan and Prepare
- Determine RFCs for the release candidate
- Check implementation authorization for RFCs
- Check resource availability
- Publish the plan for release
- Ensure organization/users are trained
Build and Test
- Combine components to comprise a release
- Testing ensures no incompatibility among RFCs
- Test deployment mechanism
Service Testing and Pilots
- Ensure the release works as a whole
- Includes a pilot group in the live environment
Plan and Prepare Deployment
- Use automated deployment for software from DML
- Hardware requires physical deployment and coordination with software
Transfer, Deploy, Retire
- Put the plan into effect
- Transfer service
- Deploy hardware and software
- Retire redundant services
Early Life Support
- Additional highly skilled specialists available during roll out of new services
- Bring operational staff up to speed and allow them to take over fully
Review and Close
- Once everything is done, review it to make sure it is done, and close out the deployment.
- Document successes achieved and lessons learned.
- Which role would be responsible for packaging, building, testing, and deploying new or changed services?
Release and Deployment manager - Which of the following statements regarding standard changes are NOT correct?
- They are approved by a delegated authority
- They take precedence over normal changes
- They are low risk
- They usually follow a change model
- Which of the following is TRUE regarding the configuration management system (CMS)?
- The CMS should contain project plans and the user skills register.
- There should not be more than one CMS.
- The service knowledge management system (SKMS) is an integram part of the CMS.
- There should not be more than one configuration management database (CMDB).
- Which types of changes would NOT normally be directly relevant to the Change Management process?
- Revision of existing service level agreements (SLAs)
- Changes to teh data center configuration *** Changes to corporate strategy**
- Retirement of a service
- What is the BEST source of accurate information concering the components of any given service?
Configuration management system - Which is TRUE with regard to the service knowledge management system (SKMS)?
- SKMS and Configuration management System (CMS) are the same thing
- CMS is part of the SKMS
- CMS is controlled and documented; the SKMS is purely conceptual
- If you ahve a CMS, there is no need for an SKMS
- Which of the following would NOT be found in the definitive media library?
- Release schedule for the software
- License documentation
- Software specifications
- Copies of proprietary software
- Which statement is NOT correct regarding a change model?
- A change model should not include escalation procedures
- Standard change almost always uses a change model
- A change model can be used for emergency purposes
- A change model provides the steps to be followed when handling a certain type of change
- Which is the CORRECT list of activities in Service Asset and Configuration Management (SACM)?
Planning, identification, control, status accounting, verification, and audit - What is NOT a Service Transition process?
- Service Level Management
- Service Asset and Configuration Management
- Change Evaluation
- Knowledge Management
- Which is NOT an element of the DIKW model?
- Design (Data)
- Information
- Knowledge
- Wisdom
- When can early life support be considered successfully completed?
When service targets are being met consistently and the new service is being supported by Service Operation teams - Which of the following are ouiputs from the change advisory board (CAB)?
Projected service outage (PSO) documentation, approved RFCs, meeting minutes, change schedule - Which roles could be members of the change advisory board (CAB)?
Capacity manager, service desk manager, service owner, change manager - What is the responsibility of the emergency change advisory board (ECAB)? To evaluate emergency changes and to decide whether they should be approved for implementation