Disclaimer: This is an example of a student written essay.
Click here for sample essays written by our professional writers.

Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of UKEssays.com.

A Business Value Of Service Transition Information Technology Essay

Paper Type: Free Essay Subject: Information Technology
Wordcount: 4882 words Published: 1st Jan 2015

Reference this

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.


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

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

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.

Get Help With Your Essay

If you need assistance with writing your essay, our professional essay writing service is here to help!

Essay Writing Service

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

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






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:






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:





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

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




Repeats of earlier RFCs:

Information complete

Already accepted

Information accurate


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 and


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


Cite This Work

To export a reference to this article please select a referencing stye below:

Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.

Related Services

View all

DMCA / Removal Request

If you are the original writer of this essay and no longer wish to have your work published on UKEssays.com then please: