ITIL Service Transition

Get Started. It's Free
or sign up with your email address
ITIL Service Transition by Mind Map: ITIL Service Transition

1. Transition planning and support

1.1. Objectives

1.1.1. ensure all parties adopt common framework of standard re-usuable processes

1.1.2. identify manage and control risks

1.1.3. monitor and improve the performance of the service transition lifecycle stage

1.1.4. provide plans for customer & business change projects to align with service transition plans

1.1.5. plan and coordinate resources to ensure requirements of service strategy encoded in service design are effectively realised in service operation

1.1.6. new or change services, within cost, time and quality

1.2. scope

1.2.1. strictly applies in service transition

1.2.2. maintain policies, standard and models for service transition

1.2.3. maintain policies, standards and models for service transition activities

1.2.4. guide each change or new service through service transition

1.2.5. prioritise conflicting requirements

1.2.6. planning budget and resources needed

1.3. planning all service transition processes & coordinating the resources that they require

1.4. purpose

1.4.1. the transition planning and support process is to provide overall planning for service transitions and to coordinate the resource that they require

2. change management

2.1. what is a change

2.1.1. not talking about service change

2.1.2. service change driven by bus change

2.1.3. intro CI config item

2.1.4. anything that changes a CI

2.2. "the addition, modification or removal of anything that could have an effect on IT services. The scope should include changes to all architectures, processes, tools, metrics and documentation, as well as changes to IT services and other config items"

2.3. inc in service change

2.3.1. architecture

2.3.2. process

2.3.3. tools

2.3.4. metrics

2.3.5. documentation


2.4.1. only applies to very high level changes initiated by service portfolio mgt process

2.4.2. contains high-level desc bus outcomes utility & warranty

2.4.3. doesn't authorise implementation, but allows the service to be chartered so that service design activity can commence.


2.5.1. how to handle a certain kind of change

2.5.2. contains steps taken order in which to take steps responsibilities timescales & thresholds escalation procedures

2.5.3. streamline and minimise risk

2.5.4. use for emergency changes require specific sequence of events security patch implementation service requests

2.5.5. reduces risk

2.5.6. any tool should be able to do this

2.6. CAB

2.6.1. advise on changes

2.6.2. could be organised regionally

2.6.3. resp assess prioritise schedule

2.6.4. include capacity mgt process availab mgt process business members change mgr attendance at their descretion application mgt ops staff BRMs

2.6.5. agenda change proposals change reviews RFC to be assessed and assessed

2.7. emergency changes

2.7.1. handled by subset of CAB = ECAB

2.7.2. membership decided when meeting is called

2.8. types of changes

2.8.1. Normal

2.8.2. Standard don't use CAB low risk example onboarding employee approved in advance only approval needed is financial routine trigger service request usually

2.8.3. Emergency highest risk characteristics testing reduced or limited documentation may be deferred

2.8.4. should be able to manage change electronically


2.9.1. return to previous state

2.9.2. guidelines to when to back up plan

2.9.3. need to have plan and to have tested it

2.9.4. need to have criteria of when to use

2.10. objectives

2.10.1. balance risk and max value of changes

2.10.2. align service with business need

2.10.3. test all changes

2.11. SCOPE

2.11.1. CIs

2.11.2. 5 aspects of design

2.11.3. excludes repairs routine maintenance.

3. release and deployment


3.1.1. controls master copies of controlled software physical store for all media CIs versions that meet quality standards

3.1.2. procedures security retention audit archive protection from changes back up procedures for library

3.1.3. only authorized media in DML controlled by SACM

3.1.4. secure physical location

3.1.5. electronic assets in DML held in SKMS?


3.2.1. Milestones

3.2.2. roles and resp

3.2.3. group changes into releases

3.2.4. automation techniques

3.2.5. baseline

3.2.6. authorization & acceptance

3.2.7. exit and entry criteria


3.3.1. create, test, verify & deploy releases

3.3.2. manage org and stakeholder change

3.3.3. ensure deliver utility & warranty

3.3.4. mge deviations, risk, issues

3.3.5. knowledge transfer to optimise use of services inc training

3.3.6. est and maintain integrity of service assets

3.3.7. provide efficient repeatable mechanisms for building testing and deploying services & releases

3.4. SCOPE

3.4.1. CI items virtual and physical apps and software training contracts and agreements

3.4.2. excl. testing authorising changes

3.4.3. managing complexity associated with changes to services and service mgt processes

3.4.4. allowing for innovation while minimizing the uninteded consequences of change

3.4.5. new services & changes to existing

3.4.6. decommission and discontinuation of services

3.4.7. transferring services to and from other service providers

3.5. phases

3.5.1. release & deployment planning

3.5.2. release build and test

3.5.3. deployment

3.5.4. review and close

4. service asset & config mgt

4.1. CI

4.1.1. characteristics unique deliver services managed configurable

4.1.2. examples Hardware software people documentation

4.2. assets are controlled, accurate & reliable

4.3. maintain details about how assets have been configured

4.4. provide details on relationships betw assets

4.5. difference service asset & config

4.5.1. asset

4.5.2. config relationships

4.6. objectives

4.6.1. maintain a config mgt system identify & control access

4.7. scope

4.7.1. include lifecycle CIs service assets that need to be managed virtual assets interfaces to internal & external service providers

4.7.2. excludes service assets that are not CIs

4.8. goal

4.8.1. support agreed IT service provision by managing, storing & providing info about CIs & service assets

5. ensure

5.1. assure

5.1.1. GREEN FLAG terms

6. knowledge mgt

6.1. SKMS

6.1.1. service knowledge mgt system

6.1.2. sum total off all knowledge within service mgt

6.1.3. cms > cmdb > can be more than 1 only one CMS (logically) could consist of multiple actual db but is logically 1

6.2. layers or levels

6.2.1. info integ layer

6.2.2. data layer

6.2.3. knowledge processing layer

6.2.4. presentation layer

6.3. DIKW

6.3.1. data

6.3.2. information

6.3.3. knowledge

6.3.4. wisdom

6.4. objectives

6.4.1. gather, analyze, store, share

7. guidance on

7.1. introducing new services

7.2. decommissioning services

7.3. transfer of services between service providers

8. Services are built, tested and released. knowledge is transferred to Users and Oprations. Transition planning and support oversees all the processes within Service Transition.


9.1. to ensure that new, modified or retired services meet the expectations of the business as documented in the service strategy and service design stages of the lifecycle

10. automation

10.1. knowledge mgt tools

10.2. data mining

10.3. reporting

10.4. extract, transforrm, load

10.5. deployment

10.6. collaboration

10.7. workflow design

10.8. configuration mgt