Please enable JavaScript.
Coggle requires JavaScript to display documents.
Service Transition (Change Management (Why Do Changes Fail? (• Wider…
Service Transition
Change Management
Addition, modification, or removal of anything that could have an effect on IT services
Purpose
To control the lifecycle of all changes, enabling beneficial changes to be made with a minimal disruption of IT services
control
Not just administration of change
Have a clear change policy and roles/responsibilities to allow for the control of change
lifecycle
Changes have their own lifecycle
Some are short and quick
Others take months or years to finish
beneficial changes
Don’t want to change for change sak
Need a beneficial reason to change
• Compliance
• Make more money
• Drive down costs
minimal disruption
Changes cause disruption
Change management focuses on creating the minimal impact to the service
Functions
Respond to change initiating triggers
New business requirements
Operational failures
Improvements and additions
Record, evaluate, authorize/reject, prioritize, plan, test, implement, document, and review changes
When Does Change Occur?
Changes happen at every stage
Changes happen to the Service Portfolio, Service Catalog, Service Level Agreements, and processes
Change management needs to be involved with all of these processes
3 Types of Changes
Emergency changes
Address unforeseen operational issues, such as failures, security threats, and vulnerabilities
Rapid change is required to continue the business operations
Emergency changes should still follow the documented procedures, but they just happen much quicker
Clearly define who can declare an emergency change
Emergency Change Advisory Board (ECAB) can be called in after hours for decisions
Testing may be modified or removed
RFC and documentation are often done after the issue is resolved
Normal changes
Change that has a uniqueness to them that represents a higher risk or uncertainty of outcome
Default type of change that occurs
Emergency and Standard are variations on Normal Change procedures
Standard changes
Typical day-to-day changes that are low-risk and well understood
Utilizes a shorter version of the Normal
Change procedures
Minimizes bureaucracy and quickly satisfies customer needs
Generally follow a predefined workflow controlled by automation
Usually an automated system checks initiator has permission to start the process and technicians just work the change ticket to resolution
Don’t need CAB approval since it is approved as part of normal service management (request fulfillment)
Why Do Changes Fail?
• Wider impact than originally thought
• Insufficient resources (time, money)
• Stakeholder disagreements on who can authorize the change
• Poorly planned or conducted testing
• Users were not ready for change
• Support organizations were not ready
• Change rolled out prematurely due to management pressures
• Two incompatible changes at once
Change Process Flow
process is a set of coordinated activities combining resources and capabilities to produce an outcome that creates value for the customer
Processes respond to a trigger, are measurable, produce specific results, and deliver the results to a defined customer
Initiation
Change is initiated by a trigger
Change priority must be determined
Initial Review
Determine if proposed change is realistic and check the priority
Record this step into CMS
Raise RFC
Formal Change Request or “Move,Add, Change” in some organizations
ITIL uses Request for Change (RFC)
The Seven (7) R’s of RFCs
Raised
Reason
Return
Risks
Resources
Responsible
Relationship
Assess and Evaluate
Analyze change and get recommendations from stakeholders
If your service is being changed, you get a veto!
Authorization to Proceed
Results of evaluation are presented to the Change Advisory Board (CAB) for approval or rejection of the change
Build and Test
Owner/Sponsor builds the service, then Service Validation and Testing will test it (CM only tracks progress)
Authorization to Implement
Initial test results are presented to the CAB then approval to implement can be obtained and scheduling occurs
Implementation
Release and Deployment are brought in to implement the change into the production environment
Remediation
Back out plan if the change release doesn’t work properly or a point of no return identified
Review
If implementation is considered successful then review occurs based upon accepted timeline after change
Closure
Results of review are recorded in change record, lessons learned identified, and change pushed to CSI
Authority for closure is the CAB
Change Advisory Board (CAB)
Focused on providing a go/no-go
decision for all changes
Meet on a regular basis
In large organizations there may be many smaller CABs, but one is always the final decision maker
CAB Members
Change Manager (Chairman)
Service Desk Manager
Capacity Manager
IT Security Manager
CAB Meeting Inputs
• Minutes of previous CAB 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 this CAB meeting
• Authorized new changes
• Rejected changes
• Updated change schedule
• Update PSO (Project Service Outage)
Change Authority
CAB is actually not the change authority but serves as an advisory body making recommendations
Change Authority comprise a role, a person, or a group/team
Change Authority is the stakeholder for a given change
Who is the Change Authority?
RFC documents the change authority for a given change
Change Management Team notates this during the “raising of an RFC” in the workflow activity
Change Authorities are often in the management level, executive board, or IT steering group
Delegation
Delegation of the Change Authority often occurs to the CAB or Change Manager
Routine changes can be delegated down to junior management such as during Standard Changes
Change Models
Predefined steps taken to handling a certain category of change
Numerous change models exist with one for each configuration item
Simple or Complex?
Change models can be simple or
complex
Standard Change Model
Detailed model covering all the technical details and angles of the proposed changes
Routine tasks can be covered by incorporation into the Standard Operating Procedures
Normal Change Model
Not as detailed because each change being proposed has unique qualities
Change models are useful when
emergency changes are proposed. Provides guidance and useful checklists
when limited time is available
Change Documents
• Request for Change RFC
• Change Record
Gives additional details to the RFC
• CAB Minutes
• Record of the CAB meetings
• Documentation of members present
• Documents what was discussed
• Documents reasoning used to make decisions
• Change Schedule
• States changes to be implemented
• Scheduled dates
• Projected Service Outage PSO
Notifies IT staff, users, Service Desk, and the customers of any changes to normal service availability
Service Asset and
Configuration Management
Ensures assets needed to deliver services are managed and accurate/reliable information is available for those assets
Service Asset and Configuration Management (SACM) is vital to knowledge management
SACM Considerations
Don’t start SACM until change control and change management are in place
Relationships between configuration items is what makes the SACM powerful instead of a simple asset list
Identify, control, record, report, audit, and verify services and configuration items (CIs) including their relationships to each other
Functions
Accurate information on configuration items is essential
Historical information on configuration items is necessary
SACM ensures only authorized components are utilized in architecture
SACM supports other processes in all
stages of the lifecycle
SACM may seem boring but it is crucial to your organizational success across various other processes
SACM Definitions
Configuration items
CIs are the individual records in your Configuration Management Database (CMDB)
CIs are components or service assets
that need to be identified and managed
Categories
Hardware
Software
People
Documentation
Physical locations
Levels
How detailed does your CIs need to be to support your service needs?
Do you need to know every CPU in every workstation or just how many workstations?
Depends on your organizations role and any outsourcing being conducted
Naming
Utilize a uniform naming convention
Do we call all mobile devices one thing, or break them into Laptops, Tablets, Smartphones, and PDAs?
Do we break them down based on their Operating Systems (Android, iOS, Windows)?
Labels
How are you going to label assets?
Workstations are easy
People and electronic software are
harder
Attributes
What information do you want to know about the Configuration Item (CI)?
Universal attributes: Description, Unique ID, Location
Other attributes can be customized based on the type of asset
CMDBs are relational databases
Configurations
Group of CIs to makeup a specific build or architecture
Created by linking several CIs in a relationship
KM system may be one configuration which is made up of numerous assets (servers, software, people) from various CIs
Baselines
Snapshot of a particular configuration at a moment in time
Starting point when equipment arrives
Must document any changes from the baseline to account for the difference between the design and operation
Most common baselines used are for workstations and servers
Configuration Management System
Essential set of tools, data, and information on configurations
Part of the Service Knowledge Management System (SKMS) and each SKMS can only have one CMS
Includes information on incidents, service requests, changes, problems, releases, errors, and more
Definitive Media Library (DML)
Secure storage area for authorized software versions for every CI
Includes the licensing information and documentation
Everything must be quality checked before being put into the DML
We will cover this more in the Release and Deployment Management lesson
SACM’s 5 Principles
Planning and Management
First major activity is planning
Must plan to introduce/develop SACM, including resources required, size of CI types, CI levels, and the management tools needed
Identification
Designate the CI types
Agree on naming conventions
Decide on unique identifiers for assets
Choose proper CI attributes
Control
Integrate SACM into the processes that produce changes to keep CI information up to date:
• Change Management
• Release and Deployment Management
• Incident Management
Status Accounting
Status of a CI changes over time
Create standard status codes
Verification and Audit
Verify and audit SACM to determine if it is effective
Are users and employees using it?
Is it up to date?
Don’t try to do 100% validation
Spot check it periodically and investigate when a problem is found
Objectives
To plan and manage service changes while managing the risks involved in the transition
To ensure the services meet the current and future needs of the business by creating value
Plan and manage service changes
efficiently and effectively
Utilizing the eight processes in Service Transition allows you to efficiently and effective plan, field, and manage new, changed, or retiring services
Manage risks
Change always involves some risk
Imperative that Service Transition team understands the “uncertainty of outcome” and provide oversight, mitigations, and management to minimize those risks
Successful deploy versions into supported environments
Team must ensure that extra resources, training, documentation, awareness, and understanding have been gained in order to successfully deploy new or changed services
Should include both the operators of
the service and the customers
Expectation management
Ensure that the customers are aware of the new or changed services and how the services are different
How are they faster, slower, cheaper, better?
Get the customer involved in pilots and acceptance testing
Creation of business value
Services must provide business value
Must ensure services have created the agreed-upon and documented business value before ending the Service Transition phase
Gain knowledge and understanding
Create an effective knowledge and information management system to ensure knowledge is gained and converted to understanding
Tools can help with this but so must the customer and service providers
Release & Deployment Process
Plan and Prepare
Check authorization on RFCs for
implementation
Check resource availability
Publish the plan for release
Ensure organization/users are ready to receive release (training)
In accordance with policy, determine
RFCs for the release candidate
Build and Test
Combine all components (even across multiple RFCs) that comprise release
Testing ensure no incompatibility in the mixture of the RFCs
Testing of the deployment mechanism should also occur in this phase
Service Testing and Pilots
Ensures that the release, as a whole, will provide the agreed upon utility and warranty
Often includes a Pilot test in the live environment across a limited number of live users such as a one department or single geographic region
Plan and Prepare Deployment
Usually uses automated deployment for software products
Software originates from the DML
Hardware requires physical deployment and coordination with the software deployment
Transfer, Deploy, Retire
It is time to put our plan into effect!
Service is transferred from one service provider to the next
Hardware/software are deployed
Redundant services, hardware, software are retired and their resources are made available to resource pool
Early Life Support
Additional highly skilled specialists may augment the operational teams during the initial roll out of the new or changed services
Review and Close
Once everything is “done”, it is time to review and close out the deployment
Includes a review to confirm success has been achieved and to collect the lessons learned
Knowledge Management
To share perspectives, ideas, experiences, and information
To ensure these are available at the right time to make correct decisions
To improve efficiency by reducing the
need to rediscover knowledge
Functions
Ensure that reliable and secure data, information, and knowledge are available to decision makers in order to improve quality and drive down cost
Ensure service management data, information, and knowledge are collected, analyzed, stored, used, shared, and maintained
Create and maintain an information management system to securely store data, information, and knowledge
Service Knowledge Management
System (SKMS)
KM’s Place in the Lifecycle
KM really must occur in all stages of
the ITIL lifecycle
Your KM program is only as good as your ability to get people to use it…
Data, Information, Knowledge, and Wisdom
Service Knowledge
Management System (SKMS)
Data comes from many sources (config DBs, service management tools, and even open-sources)
Contains all the data in a collection of
repositories and systems
Houses the Configuration Management System and in turn contains the Configuration Management Databases
Release & Deployment Management
Release
One or more changes to an IT service that are built, tested, and deployed together
Plans, schedules, and controls the build, test, and deployment of releases,as well as to deliver new functionality required by the business while protecting the integrity of existing services
Scope/Span of the Process
• Physical assets (servers, networks,…)
• Virtual assets (VMs, cloud)
• Application/System software
• Relevant documentation
• Training for users and IT staff
• Supporting services, including all related contracts and agreements
• Ensuring appropriate testing is completed (per Service Validation and Testing process)
Functions
• Produce\maintain R&D policy
• Produce\maintain individual R&D plans
• Define\create\test release packages
• Maintain integrity of live environment
• Deploy software from DML only
• Track progress of releases with SACM process
• Ensure each release has a test plan for backout
• Manage organizational and stakeholder change
• Ensure services deployed deliver agreed-upon utility and warranty
• Record and manage deviations, risks,
and issues
• Ensure successful transfer of skills and knowledge to users, customers, and Service Operation functions
Release & Deployment Assets
Secure Repositories
All assets being deployed (hardware or software) need to come from a trusted, quality-assured source
Change Evaluation Process
To assess the likely performance of the new or changed service
To compare predicted performance
against actual performance
To identify and manage risk and issues
Important Considerations
Helps to set stakeholder expectations
Valuable in providing guidance to the Change Management team on whether to allow a change to proceed to next phase of the change process workflow
Process is not covered by the ITIL Foundation exam, but it is necessary to fully understand the lifecycle
Outsourcing in Service Transition
If you have chosen to outsource services or parts of a service, now is the time to setup the appropriate contracts
If you do this, then have changed from being the provider to the customer
Outcomes are facilitated by the services without the specific detailed costs and risks
Many ways to outsource services
Traditional Outsourcing
You transfer services from internal
provisioning to an external supplier
Changing Outsourcing
You transfer services from one external
supplier to another external supplier
Re-Insourcing
You transfer services from an external supplier to your in-house team
Partnership or Co-Sourcing
You migrate to a partnership agreement where some pieces of the service are outsourced, but others remain in-house
Co-Sourcing/Multi-sourcing
Utilize multiple suppliers
Increases service level management and
supplier management challenges
Transition Planning & Support
Provide overall planning for the Service Transition stage and coordinate the required resources
Planning occurs for all related projects and programs during this stage
Functions
Plan and coordinate resources to ensure multiple concurrent transitions can occur seamlessly
Lead major changes through the transition stage
Migrate new or changed services to Service Operations within the agreed upon time, cost, and quality
Establish new or improved management systems and tools, technology and management architectures, processes, measurement methods, and metrics
Provide comprehensive transition plans to align business changes and the service transition
Identify, manage, and control risks across the other seven (7) Service Transition processes
Continually monitor and improve the Service Transition stage performance
Service Validation & Testing
Process
Ensures the service that has been built meets the specifications and will provide the agreed upon utility and warranty to the customer
Important Considerations
Testing is performed under both the Change Management process and the Release & Deployment process
Different testers than the Release & Deployment personnel conduct the testing to ensure compliance and proper validation
Process is not covered by the ITIL Foundation exam, but it is necessary to fully understand the lifecycle
Who Does The Planning?
It’s important to note that the Transition Planning and Support process doesn’t do the planning itself
It only ensures that planning is carried out per the service provider’s policies
Roles in Service Transition
ITIL does recommends roles:
• Service Owner
• Process Owner
• Process Manager
