A Business Value Of Service Transition Information Technology Essay
Plan and manage the capacity and resources required to package, build, test and deploy a release into production and establish the service specified in the customer and stakeholder requirements
Provide a consistent and rigorous framework for evaluating the service capability and risk profile before a new or changed service is released or deployed
Establish and maintain the integrity of all identified 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 that can be used to deploy releases to the test and production environments and be rebuilt if required 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 enable the transition of a service into production within the predicted cost, quality and time estimates
Ensure that there is minimal unpredicted impact on the production services, operations, and support organization
Increase the customer, 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 customer 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 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 disposed of or de-commissioned
Understanding the level 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 more than one group; internal CIs: tangible and intangible assets that are required to deliver and maintain 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 delivers a required logical model of the services, assets and the infrastructure by recording the relationships between CIs.
Relationships
A relationship is a link 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 the CIs that contribute to them.
Configuration Management Database (CMDB)
A database used to manage configuration records throughout their lifecycle. The CMDB records the attributes of each CI, and relationships with other CIs. A CMDB may also contain other information linked to CIs, for example incident, problem or change records. The CMDB is maintained by Configuration Management and is used by all IT Service Management processes.
Configuration Management System (CMS)
The CMS holds all 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 business units, customers and users.
(Service Transition 4.3.4.2)
Definitive Media Library (DML)
The exact configuration of the DML is defined during 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 regarded 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 controlled 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 criteria for items)
(Service Transition 4.3.4.3)
The Configuration Management System (CMS) holds all the information 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 will include the details 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 held in a CMS (CMDB data) may be made 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 business units, customers and users.
(Service Transition 4.3.4.3)
SACM Activities
Management & Planning
There is no standard template for determining the optimum approach for SACM. The management team and configuration management should decide what level of Configuration Management is required 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 criteria for selecting Configuration Items (CIs)and the components that compose them
Select the CIs and the components that compose them based on documented criteria
Assign unique identifiers to CIs
Specify the relevant attributes of each CI
Specify when each CI is placed under Configuration Management
Identify the owner responsible for each CI
Configuration Control
Configuration control ensures that there are adequate control mechanisms over CIs while maintaining a record 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.
Status Accounting & Reporting
Each asset or CI will have one or more discrete states through which it can progress. The significance of each state should be defined in terms of what use can be made of the asset or CI. There will typically be a range of states relevant to the individual asset or CIs.
Verification & Audit
The activities include a series of reviews or audits to ensure:
There is conformity between the 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 organization or in the DML and spares stores, the functional and operational characteristics of CIs and to check that 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 – awareness of assets the business services depend on, 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
Service Asset & Configuration Management – Practical Application
Audit your PCs to see if what you actually have is what has been recorded. Is there more than one PC per person? Can this be justified? Are there any extras which could be disposed of?
Define those service components which are truly critical – these 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. Are 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 change to an existing 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 associated documentation.
Normal Change
Any change that follows the normal change process is considered 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 a procedure or work instruction; for example, provision of standard equipment to a new employee. They are logged and tracked using a different mechanism, such as a Service Request.
Emergency Change
An emergency change is a change that must be introduced as soon as possible; for example, to resolve a major incident or implement a security patch. The Change Management process will normally have a specific procedure for handling Emergency Changes.
Remediation planning
No change should be approved without having explicitly addressed the question of what to do if it is 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 case an alternative approach to remediation is required.
Change Advisory Board
The Change Advisory Board (CAB) is a body that exists to support the authorization of changes and to assist Change Management in the assessment and prioritization of changes.
Emergency Change Advisory Board
Emergency changes are sometimes 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 are generally more disruptive and prone to failure.
Emergency change authorization
Defined authorization levels will exist for an emergency change, and the levels of delegated authority must be clearly documented and understood. In an emergency it may 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 begin holding meetings to assess changes.
Develop a change 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 any of these result in 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 particular category of change. A change model defines specific pre-defined steps that will be followed for a change of this category. Change models may be very simple, with no requirement for approval, or may be very complex with many steps that require approval (e.g.: major software release).
Change process models and workflows
Organizations will find it helpful 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 should be taken to handle a process (in this case a process for dealing with a particular type of change) in an agreed way. Support tools can then be used to manage the required process. This will ensure that such changes are handled in a predefined path and to predefined timescales.
Changes that require specialized handling could be treated in this way, such as emergency changes that may have different authorization and may be documented retrospectively.
The change process model includes:
The steps that should be taken to handle the change including handling issues and unexpected events
The chronological order these steps should be taken 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 impact on other services
Planned maintenance
Local procedure (often pre-authorized)
ƒ¼
Seven Rs Of Change Management
Who RAISED the change?
It is important to 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 a Change can be affected by the position or department where the Change originated.
What is the REASON for the change?
It is important to know why the change is being requested. Some 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 are the RISKS involved in the change?
All changes have a risk which could range anywhere from processing being delayed to the entire organization not being able to provide service to its customers. It is important to understand what the risk is so that appropriate precautions can be taken in the timing and execution of the change.
What RESOURCES are required to deliver the change?
In every change there are a number 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 identify all the parties involved in bringing a change to realization and that the managers are informed as to 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 cannot be overemphasized. It is not uncommon to have parallel multiple changes that can affect each other at any point in their critical paths. It is essential to understand this and 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
Assess & Evaluate Change
The issue of risk to the business of any change must be considered prior to the authorization of any change. Many organizations use a simple matrix to categorize risk.
Authorize Change
Formal authorization is obtained for each change from a change authority that may be a role, person or a group of people.
Plan Updates
Careful planning of changes will ensure that there is no ambiguity about what tasks are included in the Change Management process, what tasks are included 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 can be tracked.
Review & Close Record
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 subject to 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 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 put into finding out how well the partners themselves manage change and choose partner and sourcing relationships accordingly.
Service Asset & Configuration Management
The Configuration Management System provides reliable, quick and easy access to accurate configuration information to enable stakeholders and staff to assess the impact of proposed changes and to track changes work flow. This information enables the correct 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 are often required to implement workarounds and to fix known errors. Problem Management is one of the major sources of RFCs and also often a major contributor to CAB discussion.
IT Service Continuity
IT Service Continuity has many procedures and plans that should be updated via Change Management to ensure that 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 will be a key contributor to CAB discussion on many services. Every significant change will be assessed for its potential impact on the security plan.
Capacity & Demand Management
Capacity and Demand Management are critical aspects of Change Management. Poorly managed demand is a source of costs and risk for service providers because there is always a level of uncertainty associated with 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 arising from Capacity Management, including those set out in the capacity 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 in order to deliver value to the customer and be able to handover to service operations.
Release and Deployment Management aims to build, test and deliver the capability to provide 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 enable the customers and users to optimize their use of the service to support their business activities
Ensure that skills and knowledge are transferred to operations and support staff
Ensure minimal unpredicted impact on the production services, operations 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 pertaining to 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, depending on 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 approach to transitioning from the current 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 the user base initially, and then this operation is repeated for subsequent parts of the user base via a scheduled rollout plan.
Push and pull
A push approach is used where the service component is deployed from the centre and pushed out to the target locations.
A pull approach is used for software releases where the software is made available in a central location but users are free to pull the software down to their own location at a time of their choosing or when a user workstation restarts.
Automation vs. manual
Automation will help to ensure repeatability and consistency. If a manual mechanism is used it is important to monitor and measure the impact of many repeated manual activities as they are likely to be inefficient and error-prone.
Release and Deployment Models
Models enable consistency and repeatability when preparing releases for deployment and will incorporate a variety of criteria and guidelines.
DIKW represents the hierarchical progression from data to wisdom.
Data is a set of discrete facts about events
Information comes from providing context to data
Knowledge is composed of the tacit experiences, ideas, insights, values and judgments of individuals
Wisdom gives the ultimate discernment of the material and having the application and contextual awareness to provide a strong common sense judgment
Service Analytics & Instrumentation
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 tied to corresponding business processes. This is as far along the DIKW hierarchy as modern technologies allow. It is well understood that no computer-based technology can provide wisdom. It requires 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 will be 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 experience of staff
Records of peripheral matters (e.g.: Weather, user numbers and behavior, organization’s performance figures
Suppliers’ and partners’ requirements, abilities and expectations
Typical and anticipated user skill levels
Order Now