Provide a constant and rigorous framework for evaluating the service capability and risk profile before a fresh or changed service is released or deployed
Establish and keep maintaining the integrity of most recognized service assets and configurations as they evolve through the Service Transition stage
Provide good-quality knowledge and information so that change, Release and Deployment Management can expedite effective decisions about promoting a release through the test environments and into production
Provide efficient repeatable build and installation mechanisms you can use to deploy releases to the test and production environments and become rebuilt if necessary to restore service
Ensure that the service can be managed, operated and supported in accordance with the requirements and constraints specified within the Service Design.
(Service Transition 2. 4. 1)
Objectives Of Service Transition
Manage resources to allow the transition of a service into production within the predicted cost, quality and time estimates
Ensure that there is minimal unpredicted effect on the production services, operations, and support organization
Increase the client, user and service management staff satisfaction with the service transition practices, including deployment of the new or changed service, communications, release documentation, training and knowledge transfer
Increase proper use of the services and underlying applications and technology solutions
Provide clear and comprehensive plans that enable the client and business change projects to align their activities with the service transition plans
(Service Transition 2. 4. 1)
Business Value Of Service Transition
Service Transition also adds value to the business enterprise by improving:
The ability to adapt quickly to new requirements and market developments (competitive edge)
Transition management of mergers, de-mergers, acquisitions and transfer of services
The success rate of Changes and Releases for the business
The predictions of service levels and warranties for new and changed services
Confidence in the degree of compliance with business and governance requirements during change
The variation of actual against estimated and approved resource plans / budgets
The productivity of business and Customer staff because of better planning and use of new and changed services
Timely cancellation or changes to maintenance contracts for both hardware and software when components are removed or de-commissioned
Understanding the amount of risk during and after change; for example, service outage, disruption or re-work
(Service Transition 2. 4. 3)
Basic SACM Concepts
Configuration Item (CI)
A Configuration Item (CI) is an asset, service component or other item that is, or will be, under the control of Configuration Management.
CI Types include:
Service Lifecycle CIs (e. g. : Business cases; service management plans; service lifecycle plans; Service Design Packages (SDPs); release and change plans; test plans)
Service CIs (e. g. : Service capability assets: management, organization, processes, knowledge, people; service resource assets: financial capital, systems, applications, information, data, infrastructure and facilities, people; service models; service packages; release packages; service acceptance criteria)
Organization CIs (e. g. : Business strategy; policies; regulatory or statutory requirements; products shared by several group; internal CIs: tangible and intangible assets that must deliver and keep maintaining the service and infrastructure)
External CIs (e. g. : External customer requirements and agreements; releases from suppliers or sub-contractors and external services)
Configuration Model
Configuration Management gives a required logical model of the services, assets and the infrastructure by recording the relationships between CIs.
Relationships
A relationship is a connection between two CIs that identifies a dependency or connection between them. For example, applications may be linked to the servers they run on; IT services have many links to all or any the CIs that donate to them.
Configuration Management Database (CMDB)
A database used to manage configuration records throughout their lifecycle. The CMDB records the attributes of every CI, and relationships with other CIs. A CMDB could also contain other information linked to CIs, for example incident, problem or change records. The CMDB is maintained by Configuration Management and is utilized by all IT Service Management processes.
Configuration Management System (CMS)
The CMS holds every one of the information for CIs within the designated scope. The CMS maintains the relationships between all service components and any related service management records / documentation. Typically, the CMS will also hold data about employees, suppliers, locations and sections, customers and users.
(Service Transition 4. 3. 4. 2)
Definitive Media Library (DML)
The exact configuration of the DML is defined through the planning activities. The definition includes:
Medium, physical location, hardware and software to be used, if kept online. Some Configuration Management support tools incorporate software libraries, which can be seen as a logical part of a DML
Naming conventions for file store areas and physical media
Environments supported (e. g. : Test and live environments)
Security arrangements for submitting Changes and issuing software, plus backup and recovery procedures
The scope of the DML (e. g. : Source code, object code from managed builds and associated documentation)
Retention period
Capacity plans for the DML and procedures for monitoring growth in size
Audit procedures
Procedures to ensure that the DML is protected from erroneous or unauthorized Change (e. g. : Entry and exit requirements for items)
(Service Transition 4. 3. 4. 3)
The Configuration Management System (CMS) holds everything for CIs within the designated scope. Some of these items will have related specifications or files that contain the contents of the item (e. g. : software, document). For example, a service CI includes the facts such as supplier, cost, purchase date and renewal date for licenses and maintenance contracts and the related documentation such as SLAs and underpinning contracts.
The CMS is also used for a wide range of purposes, for example asset data in a CMS (CMDB data) may be produced available to external financial asset management systems to perform specific asset management process reporting outside of Configuration Management. The CMS maintains the relationships between all service components and any related incidents, problems, Known Errors, change and release documentation and may also contain corporate data about employees, suppliers, locations and sections, customers and users.
(Service Transition 4. 3. 4. 3)
SACM Activities
There is no standard template for deciding the optimum approach for SACM. The management team and configuration management should decide what degree of Configuration Management is necessary for the selected service or project that is delivering changes and how this level will be achieved. This is documented in a configuration management plan.
Configuration Identification
Define and document standards for selecting Configuration Items (CIs)and the components that compose them
Select the CIs and the components that compose them predicated on documented criteria
Assign unique identifiers to CIs
Specify the relevant attributes of every CI
Specify when each CI is put under Configuration Management
Identify the owner responsible for each and every CI
Configuration Control
Configuration control ensures that there are enough control mechanisms over CIs while maintaining an archive of changes to status, approvals, location and custodianship/ ownership. Without control of the physical or electronic assets and components, the configuration data and information there will be a mismatch with the physical world.
Each asset or CI will have one or more discrete states by which it can progress. The importance of every state should be defined in conditions of what use can be produced of the asset or CI. There will typically be considered a selection of states highly relevant to the individual asset or CIs.
The activities include a group of reviews or audits to ensure:
There is conformity between your documented baselines (e. g. : agreements, interface control documents) and the actual business environment to which they refer
To verify the physical existence of CIs in the business or in the DML and spares stores, the functional and operational characteristics of CIs and also to be sure the records in the Configuration Management System (CMS) match the physical infrastructure
Checking that release and configuration documentation is present before making a release
(Service Transition 4. 3. 5)
Updates to asset and configuration information are triggered by change requests, purchase orders, acquisitions and service requests. Some of the more noteworthy interfaces are:
Change Management - identifying the impact of proposed changes
Financial management - capturing key financial information such as cost, depreciation methods, owner and user (for budgeting and cost allocation), maintenance and repair costs
ITSCM - knowing of assets the business enterprise services be based upon, control of key spares and software
Incident/problem/error - providing and maintaining key diagnostic information; maintenance and provision of data to the Service Desk
Availability management - detection of points of failure
Audit your PCs to see if what you actually have is exactly what has been recorded. Will there be more than one PC per person? Can this be justified? Are there any extras which could be disposed of?
Define those service components which can be truly critical - they are most likely your CIs - and start tracking them and their relationships.
Discover where configuration information is already being maintained, and leverage any information of value in creating a single virtual repository. Is there relationships between components in one repository and those in another? These should be tracked.
place text
Basic Change Management Concepts
Service Change
A Service Change is a big change to a preexisting service or the introduction of a new service. It is the addition, modification or removal of authorized, planned or supported service or service component and its own associated documentation.
Normal Change
Any change that follows the normal change process is known as a normal change. Normal changes can include changes to services, the service portfolio, service improvement projects, etc.
Standard Change
A pre-approved change that is low risk is relatively common and follows an operation or work instruction; for example, provision of standard equipment to a fresh employee. They may be logged and tracked using a different mechanism, such as a Service Request.
Emergency Change
An emergency change is a big change that must be introduced as soon as possible; for example, to resolve a significant incident or implement a security patch. The Change Management process will as a rule have a specific procedure for handling Emergency Changes.
Remediation planning
No change should be approved without having explicitly addressed the question of how to proceed if it's not successful. Ideally, there will be a back-out plan, which will restore the organization to its initial situation, often through the reloading of a baselined set of CIs, especially software and data. However, not all changes are reversible, in which particular case an alternative method of remediation is necessary.
Change Advisory Board
The Change Advisory Board (CAB) is a body that exists to support the authorization of changes and also to assist Change Management in the assessment and prioritization of changes.
Emergency Change Advisory Board
Emergency changes are occasionally required and should be designed carefully and tested before use or the impact of the emergency change may be greater than the original incident. Emergency changes may document some details retrospectively. The number of emergency changes proposed should be kept to an absolute minimum, because they're generally more disruptive and susceptible to failure.
Emergency change authorization
Defined authorization levels will exist for a crisis change, and the levels of delegated authority must be clearly documented and understood. In an emergency it may well not be possible to convene a full CAB meeting. Where CAB approval is required, this will be provided by the Emergency CAB (ECAB).
Change Management - Practical Application
Create a CAB and get started holding meetings to evaluate changes.
Develop an alteration model that provides an authority model for assessing and authorizing changes based upon the change type.
Determine if there are any changes made without being assessed by the CAB. Did these lead to degradation or loss of service? Consider changing the categorization of these in the future to be included with those the CAB assesses.
Ensure timelines for change assessment are documented and agreed in SLAs, OLAs, and UCs.
Change model
A repeatable way of dealing with a specific group of change. A big change model defines specific pre-defined steps that will be followed for a change of the category. Change models may be very simple, with no requirement of approval, or is quite complex with many steps that want approval (e. g. : major software release).
Change process models and workflows
Organizations will see it beneficial to predefine change process models - and apply them to appropriate changes when they occur. A process model is a way of predefining the steps that needs to be taken to handle an activity (in cases like this an activity for dealing with a specific type of change) in an agreed way. Support tools may then be used to manage the mandatory process. This may ensure that such changes are handled in a predefined path also to predefined timescales.
Changes that require specialized handling could be treated in this manner, such as emergency changes which could have different authorization and could be documented retrospectively.
The change process model includes:
The steps that should be taken up to handle the change including handling issues and unexpected events
The chronological order these steps should be studied in, with any dependences or co-processing defined
Responsibilities: who should do what
Timescales and thresholds for completion of the actions
Escalation procedures; who should be contacted and when
These models are usually input to the Change Management support tools in use and the tools then automate the handling, management, reporting and escalation of the process.
Example of types of request by service lifecycle stage
Type of change with examples
Documented work procedures
SS
SD
ST
SO
CSI
Request for change to service portfolios
New portfolio line item
To predicted scope, Business Case, baseline
Service pipeline
Service change management
Request for Change to Service or service Definition
To existing or planned service attributes
Project change that impacts Service Design, e. g. forecasted warranties
Service improvement
Service change management
Project change proposal
Business change
No impact on service or design baseline
Project change management procedure
User access request
User access procedure
Operational activity
Tuning (within specification/constraints)
Re-boot hardware on failure if no effect on other services
Planned maintenance
Local procedure (often pre-authorized)
Seven Rs Of Change Management
Who RAISED the change?
It is important to really have the information on who is representing the Change in case further clarification about the Change is needed. There are also instances where the priority of the Change can be influenced by the position or department where the Change originated.
What is the REASON for the change?
It is important to learn why the change is being requested. A few examples could include:
Quality
Performance
Compliance
Maintenance
Defects
What is the RETURN required from the change?
What benefit can the organization, department, support personnel or customer expect from the change?
What will be the RISKS involved in the change?
All changes have a risk which could range anywhere from processing being delayed to the complete organization not having the ability to provide service to its customers. It's important to understand what the chance is so that appropriate precautions can be studied in the timing and execution of the change.
What RESOURCES must deliver the change?
In every change there are a variety of resources that need to be considered such as:
Human
Financial
External
Internal
Who is RESPONSIBLE for the build, test and implementation of the change?
It is important to recognize all the parties involved in bringing an alteration to realization and that the managers are informed regarding the role their people will play in implementing the change.
What is the RELATIONSHIP between this change and other changes?
The complication of the interaction, dependencies and relationships of changes can't be overemphasized. It isn't uncommon to possess parallel multiple changes that can affect the other person at any point in their critical paths. It is essential to comprehend this also to accommodate for it in order to avoid an increase in unplanned outages and failure in your change process.
(Service Transition 4. 2. 6. 4)
Change Management Activities
Record RFC
The change is raised by a request from the initiator - an individual or a group.
Review RFC
Change Management should briefly consider each request and filter based on:
Reasons To Accept
Reasons To Reject
Practical
Impractical
New RFC
Repeats of earlier RFCs:
Information complete
Already accepted
Information accurate
Rejected
Has the necessary budgetary approval
Still under consideration
Incomplete submissions:
Inadequate description
Without necessary budgetary approval
The problem of risk to the business of any change must be looked at before the authorization of any change. Many organizations use a simple matrix to categorize risk.
Authorize Change
Formal authorization is obtained for every change from a change authority that may be a role, person or several people.
Plan Updates
Careful planning of changes will ensure that there surely is no ambiguity about what tasks are contained in the Change Management process, what tasks are contained in other processes and how processes interface to any suppliers or projects that are providing a change or release.
Coordinate Change Implementation
Authorized RFCs should be passed to the relevant technical groups for building of the changes.
It is best practice to do this in a formal way that may be tracked.
On completion of the change:
Results are reported
Evaluation takes place
If successful, the record is closed
If failed, the record is closed
(Service Transition 4. 2. 6)
Change Management Relationships
Business Change Management
Changes to any business or project deliverables that do not impact IT services or components may be at the mercy of business or project change management procedures rather than the IT service Change Management procedures. However, care must be taken to ensure that changes to service configuration baselines and releases do follow the Change Management process. The Change Management team will, however, be expected to liaise closely with projects to ensure smooth implementation and consistency within the changing management environments.
Project Management
Project management must work in partnership to align all the processes and people involved in service change initiatives. The closer they are simply aligned, the higher the probability that the change effort will be moved forward for as long as it takes to complete. Change Management representatives may attend relevant Project Board meetings.
Supplier Management
Effective Change Management practices and principles must be put into place, in conjunction with Supplier Management, to manage supplier relationships effectively to ensure smooth delivery of service. Effort also should be placed into finding out how well the partners themselves manage change and choose partner and sourcing relationships accordingly.
The Configuration Management System provides reliable, quick and easy usage of accurate configuration information to allow stakeholders and staff to assess the impact of proposed changes and track changes work flow. This information enables the right asset and service component versions to be released to the appropriate party or into the correct environment. As changes are implemented, the Configuration Management information is updated.
Problem Management
Problem Management is another key process as changes tend to be necessary to implement workarounds and fix known errors. Problem Management is one of the major resources of RFCs and also often a major contributor to CAB discussion.
IT Service Continuity
IT Service Continuity has many procedures and plans that needs to be updated via Change Management to ensure they are accurate, up to date and that stakeholders are aware of changes.
Security Management
Security Management interfaces with Change Management since changes required by security will go via the Change Management process and security is a key contributor to CAB discussion on many services. Every significant change will be assessed because of its potential effect on the security plan.
Capacity and Demand Management are critical aspects of Change Management. Poorly managed demand is a source of costs and risk for service providers since there is always a level of uncertainty from the demand for services. Capacity Management has an important role in assessing proposed changes - not only the individual changes but the total impact of changes on service capacity. Changes due to Capacity Management, including those lay out in the capability plan, will be initiated as RFCs through the change process.
(Service Transition 4. 2. 7. 3 and 4. 2. 7. 4)
NOTES:
The goal of Release and Deployment Management is to deploy releases into production and establish effective use of the service to be able to provide value to the customer and also handover to service operations.
Release and Deployment Management aims to build, ensure that you deliver the ability to supply the services specified by Service Design and that will accomplish the stakeholders' requirements and deliver the intended objectives.
The following objectives are also important for the Release and Deployment Management process:
Ensure knowledge transfer to allow the clients and users to optimize their use of the service to aid their business activities
Ensure that skills and knowledge are used in functions and support staff
Ensure minimal unpredicted effect on the production services, businesses and support organization
Ensure that customers, users and service management staff are satisfied with the service transition practices and outputs
(Service Transition 4. 4. 1)
Basic RDM Concepts
Release Policy
Includes the unique identification, numbering and naming conventions, roles, responsibilities, time tables, frequency and other requirements regarding how releases will be handled.
Release Unit
Identifies the portion of the service or infrastructure that is normally released together in accordance with an organization's release policy. The unit may vary, with regards to the type or item of software and hardware.
Release Package
The package may contain multiple release units such as hardware, software, applications and documentation.
Release Design Options
Service Design will define the method of transitioning from the existing service to the new or changed service or service offering. Common options are:
Big bang vs. phased
'Big bang' option - the new or changed service is deployed to all user areas in one operation.
Phased approach - the service is deployed to a part of an individual base initially, and then this operation is repeated for subsequent elements of the user base with a scheduled rollout plan.
Push and pull
A push approach is employed where in fact the service component is deployed from the centre and pushed out to the prospective locations.
A pull approach is used for software releases where in fact the software is made available in a central location but users are free to pull the software right down to their own location at the same time of these choosing or whenever a user workstation restarts.
Automation vs. manual
Automation will ensure repeatability and consistency. In case a manual mechanism can be used it is important to monitor and measure the impact of many repeated manual activities as they are apt to be inefficient and error-prone.
Release and Deployment Models
Models permit consistency and repeatability while preparing releases for deployment and will incorporate a variety of conditions and guidelines.
DIKW represents the hierarchical progression from data to wisdom.
Data is a couple of discrete facts about events
Information originates from providing context to data
Knowledge is composed of the tacit experiences, ideas, insights, values and judgments of individuals
Wisdom provides ultimate discernment of the material and having the application and contextual awareness to provide a strong good sense judgment
Service Analytics is useful to model existing infrastructure components and support services to the higher-level business services. This model is built on dependencies rather than topology - causality rather than correlation. Infrastructure events are then linked with corresponding business processes. This is as far over the DIKW hierarchy as modern technologies allow. It really is well understood that no computer-based technology provides wisdom. It needs people to provide evaluated understanding, to answer and appreciate the 'Why?' questions.
(Service Transition 4. 7. 4)
Specifically within ITSM, Knowledge Management will be focused within the Service Knowledge Management System (SKMS) concerned, as its name implies, with knowledge. Underpinning this knowledge is a considerable quantity of data, held in a central logical repository or Configuration Management System (CMS) and Configuration Management Database (CMDB). However, clearly the SKMS is a broader concept that covers a much wider base of knowledge, for example:
The connection with staff
Records of peripheral matters (e. g. : Weather, user numbers and behavior, organization's performance figures
Suppliers' and partners' requirements, capabilities and expectations
Typical and anticipated user skill levels
