1. release and deployment
1.1. DEFINITIVE MEDIA LIBRARY
1.1.1. controls
1.1.1.1. master copies of controlled software
1.1.1.2. physical store for all media CIs
1.1.1.3. versions that meet quality standards
1.1.2. procedures
1.1.2.1. security
1.1.2.2. retention
1.1.2.3. audit
1.1.2.4. archive
1.1.2.5. protection from changes
1.1.2.6. back up procedures for library
1.1.3. only authorized media in DML
1.1.3.1. controlled by SACM
1.1.4. secure physical location
1.1.5. electronic assets in DML held in
1.1.5.1. SKMS?
1.2. RELEASE POLICY
1.2.1. Milestones
1.2.2. roles and resp
1.2.3. group changes into releases
1.2.4. automation techniques
1.2.5. baseline
1.2.6. authorization & acceptance
1.2.7. exit and entry criteria
1.3. OBJECTIVES
1.3.1. create, test, verify & deploy releases
1.3.2. manage org and stakeholder change
1.3.3. ensure deliver utility & warranty
1.3.4. mge deviations, risk, issues
1.3.5. knowledge transfer to optimise use of services
1.3.5.1. inc training
1.3.6. est and maintain integrity of service assets
1.3.7. provide efficient repeatable mechanisms for
1.3.7.1. building
1.3.7.2. testing
1.3.7.3. and deploying services & releases
1.4. SCOPE
1.4.1. CI items
1.4.1.1. virtual and physical
1.4.1.2. apps and software
1.4.1.3. training
1.4.1.4. contracts and agreements
1.4.2. excl.
1.4.2.1. testing
1.4.2.2. authorising changes
1.4.3. managing complexity associated with changes to services and service mgt processes
1.4.4. allowing for innovation while minimizing the uninteded consequences of change
1.4.5. new services & changes to existing
1.4.6. decommission and discontinuation of services
1.4.7. transferring services to and from other service providers
1.5. phases
1.5.1. release & deployment planning
1.5.2. release build and test
1.5.3. deployment
1.5.4. review and close
2. service asset & config mgt
2.1. CI
2.1.1. characteristics
2.1.1.1. unique
2.1.1.2. deliver services
2.1.1.3. managed
2.1.1.4. configurable
2.1.2. examples
2.1.2.1. Hardware
2.1.2.2. software
2.1.2.3. people
2.1.2.4. documentation
2.2. assets are controlled, accurate & reliable
2.3. maintain details about how assets have been configured
2.4. provide details on relationships betw assets
2.5. difference service asset & config
2.5.1. asset
2.5.2. config
2.5.2.1. relationships
2.6. objectives
2.6.1. maintain a config mgt system
2.6.1.1. identify & control access
2.7. scope
2.7.1. include
2.7.1.1. lifecycle CIs
2.7.1.2. service assets that need to be managed
2.7.1.3. virtual assets
2.7.1.4. interfaces to internal & external service providers
2.7.2. excludes
2.7.2.1. service assets that are not CIs
2.8. goal
2.8.1. support agreed IT service provision by managing, storing & providing info about CIs & service assets
3. knowledge mgt
3.1. SKMS
3.1.1. service knowledge mgt system
3.1.2. sum total off all knowledge within service mgt
3.1.3. cms >
3.1.3.1. cmdb >
3.1.3.1.1. can be more than 1
3.1.3.2. only one CMS (logically)
3.1.3.2.1. could consist of multiple actual db
3.1.3.2.2. but is logically 1
3.2. layers or levels
3.2.1. info integ layer
3.2.2. data layer
3.2.3. knowledge processing layer
3.2.4. presentation layer
3.3. DIKW
3.3.1. data
3.3.2. information
3.3.3. knowledge
3.3.4. wisdom
3.4. objectives
3.4.1. gather, analyze, store, share
4. guidance on
4.1. introducing new services
4.2. decommissioning services
4.3. transfer of services between service providers
5. Services are built, tested and released. knowledge is transferred to Users and Oprations. Transition planning and support oversees all the processes within Service Transition.
6. PURPOSE
6.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
7. Transition planning and support
7.1. Objectives
7.1.1. ensure all parties adopt common framework of standard re-usuable processes
7.1.2. identify manage and control risks
7.1.3. monitor and improve the performance of the service transition lifecycle stage
7.1.4. provide plans for customer & business change projects to align with service transition plans
7.1.5. plan and coordinate resources to ensure requirements of service strategy encoded in service design are effectively realised in service operation
7.1.6. new or change services, within cost, time and quality
7.2. scope
7.2.1. strictly applies in service transition
7.2.2. maintain policies, standard and models for service transition
7.2.3. maintain policies, standards and models for service transition activities
7.2.4. guide each change or new service through service transition
7.2.5. prioritise conflicting requirements
7.2.6. planning budget and resources needed
7.3. planning all service transition processes & coordinating the resources that they require
7.4. purpose
7.4.1. the transition planning and support process is to provide overall planning for service transitions and to coordinate the resource that they require
8. change management
8.1. what is a change
8.1.1. not talking about service change
8.1.2. service change driven by bus change
8.1.3. intro CI
8.1.3.1. config item
8.1.4. anything that changes a CI
8.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"
8.3. inc in service change
8.3.1. architecture
8.3.2. process
8.3.3. tools
8.3.4. metrics
8.3.5. documentation
8.4. CHANGE PROPOSAL
8.4.1. only applies to very high level changes
8.4.1.1. initiated by service portfolio mgt process
8.4.2. contains
8.4.2.1. high-level desc
8.4.2.2. bus outcomes
8.4.2.3. utility & warranty
8.4.3. doesn't authorise implementation, but allows the service to be chartered so that service design activity can commence.
8.5. CHANGE MODEL
8.5.1. how to handle a certain kind of change
8.5.2. contains
8.5.2.1. steps taken
8.5.2.2. order in which to take steps
8.5.2.3. responsibilities
8.5.2.4. timescales & thresholds
8.5.2.5. escalation procedures
8.5.3. streamline and minimise risk
8.5.4. use for
8.5.4.1. emergency changes
8.5.4.2. require specific sequence of events
8.5.4.3. security patch implementation
8.5.4.4. service requests
8.5.5. reduces risk
8.5.6. any tool should be able to do this
8.6. CAB
8.6.1. advise on changes
8.6.2. could be organised regionally
8.6.3. resp
8.6.3.1. assess
8.6.3.2. prioritise
8.6.3.3. schedule
8.6.4. include
8.6.4.1. capacity mgt process
8.6.4.2. availab mgt process
8.6.4.3. business members
8.6.4.4. change mgr
8.6.4.4.1. attendance at their descretion
8.6.4.5. application mgt
8.6.4.6. ops staff
8.6.4.7. BRMs
8.6.5. agenda
8.6.5.1. change proposals
8.6.5.2. change reviews
8.6.5.3. RFC to be assessed and assessed
8.7. emergency changes
8.7.1. handled by subset of CAB = ECAB
8.7.2. membership decided when meeting is called
8.8. types of changes
8.8.1. Normal
8.8.2. Standard
8.8.2.1. don't use CAB
8.8.2.2. low risk
8.8.2.3. example onboarding employee
8.8.2.4. approved in advance
8.8.2.4.1. only approval needed is financial
8.8.2.5. routine
8.8.2.6. trigger
8.8.2.6.1. service request usually
8.8.3. Emergency
8.8.3.1. highest risk
8.8.3.2. characteristics
8.8.3.2.1. testing reduced or limited
8.8.3.2.2. documentation may be deferred
8.8.4. should be able to manage change electronically
8.9. REMEDIATION PLAN
8.9.1. return to previous state
8.9.2. guidelines to when to back up plan
8.9.3. need to have plan and to have tested it
8.9.4. need to have criteria of when to use
8.10. objectives
8.10.1. balance risk and max value of changes
8.10.2. align service with business need
8.10.3. test all changes
8.11. SCOPE
8.11.1. CIs
8.11.2. 5 aspects of design
8.11.3. excludes
8.11.3.1. repairs
8.11.3.2. routine maintenance.
9. ensure
9.1. assure
9.1.1. GREEN FLAG terms