Вы находитесь на странице: 1из 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

Moog Industrial Group


Information Technology Department

Implementing ITIL Service Transition


Project Research Report

Author:

Jimmy Hill

Course:
ID:

ITM4

R00092466

Recipients: Jim ODwyer & Ed Crosbi

Due Date:

5th January 2013

Presentation Date:

8th January 2013

Revision 1

Page 1 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

Contents
1.

Purpose----------------------------------------------------------------------------------------------4
1.1 The Purpose of the research----------------------------------------------------------------4
1.2 The Scope of the Research-----------------------------------------------------------------6

2.

Introduction----------------------------------------------------------------------------------------6
2.1 The Moog Industrial Group-----------------------------------------------------------------6
2.2 Moog Industrial information Technology Group--------------------------------------7
2.2.1 Business Partners------------------------------------------------------------------------7
2.2.2 Applications and Solutions------------------------------------------------------------8
2.2.3 Service and Support---------------------------------------------------------------------8
2.2.4 Infrastructure-----------------------------------------------------------------------------9
2.2.4 Moog IT Structural Alignment with ITIL:---------------------------------------------9

3.

ITIL An Overview------------------------------------------------------------------------------10
3.1 The Five Phases of the ITIL Service Lifecycle---------------------------------------11
3.1.1 Service Strategy------------------------------------------------------------------------11
3.1.2 Service Design--------------------------------------------------------------------------12
3.1.3 Service transition----------------------------------------------------------------------12
3.1.4 Service Operation----------------------------------------------------------------------13
3.1.5 Continual Service Improvement---------------------------------------------------14
3.1.6 Inputs and Outputs of the Service Lifecycle phases------------------------15
3.2 The Benefits of ITIL------------------------------------------------------------------------15

4.0 Service Transition------------------------------------------------------------------------------16


4.1 An Overview----------------------------------------------------------------------------------16
4.2 The main concepts of Service Transition--------------------------------------------17
4.3 The core activities of Service Transition----------------------------------------------18
4.4 Benefits of Service Transition------------------------------------------------------------19
4.5 Service Transition Processes-------------------------------------------------------------20
4.5.1 Change Management-----------------------------------------------------------------20
4.5.2 Service Asset and Configuration Management - SACM--------------------25
4.5.3 Release and Deployment Management----------------------------------------27
4.6 Other key parts of the Service Transition Phase----------------------------------30
4.6.1 Knowledge Management-----------------------------------------------------------30
4.6.2

Service validation & testing------------------------------------------------------30

4.6.3 Transition Planning and support--------------------------------------------------31

Page 2 of 59

Date: 5th Jan 2012


5.0

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

Framework Comparisons-------------------------------------------------------------------32

5.1 Microsoft Operations Framework (MOF)---------------------------------------------32


5.1.1 An Overview----------------------------------------------------------------------------32
5.1.2 Comparing ITIL & MOF---------------------------------------------------------------34
5.1.3 The Strategic Alignment Model Enhanced (SAME).-------------------------35
5.1.4 ITIL Service Transition compared MOF 4.0 Delivery Phase---------------35
5.2 ISO20000 Certification Standard------------------------------------------------------36
5.2.1 An Overview----------------------------------------------------------------------------36
5.2.2 ISO20000 Clause 5 compared to ITIL Service transition------------------37
5.2.3 Audit Areas------------------------------------------------------------------------------38
6.0 Conclusion and Recommendation--------------------------------------------------------39
6.1 Conclusion------------------------------------------------------------------------------------39
6.2 Recommendation---------------------------------------------------------------------------40
6.2.1 Benefits----------------------------------------------------------------------------------40
6.2.2 Issues-------------------------------------------------------------------------------------40
6.2.3 Recommended next steps----------------------------------------------------------40
6.3 Observation-----------------------------------------------------------------------------------41
7.0 Referenced material--------------------------------------------------------------------------42
8.0 Appendices--------------------------------------------------------------------------------------43
8.1 Appendix 1 - The ITIL V3 2011 Reference Wall Chart----------------------------43
8.2 Appendix 2 - ITIL IT Service Management Overview-----------------------------44
8.3 Appendix 3 ISO Management systems comparison---------------------------45
8.4 Appendix 4 - A Service Transition project plan - for a blanket approach.--46
9.0 Citations------------------------------------------------------------------------------------------48

Page 3 of 59

Date: 5th Jan 2012

1.

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

Purpose

1.1 The Purpose of the research


In Moog Industrial IT, we have become only too well aware of
the place that information holds in most organisations.
Information is the power that guides, defines and supports an
organisations decision making and future. The information
technology that we are entrusted with to collect, store, secure,
develop and transmit this information is now more than ever at
the centre of most all organisations. No longer are poor IT
services acceptable; no longer is downtime acceptable and no
longer can we in IT hide behind what were considered the
black arts of IT. No longer can we stand by while Shadow IT
grows around us because we havent delivered. We and our
processes must become transparent to the business and
accountable to the business for its successes and failures with
IT services, we must be the owners or the brokers to all IT
services.
No longer can IT just do and then send a bill at the end
of the month
It is clear that service design, delivery and support and not just
the technology that underpins the services is what is most
important to the user and the business. That is it does not
really matter to them where the services are coming from as
long as they do as required, when required and a cost that is
justifiable to the business,

Page 4 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

A service is a means of delivering value to a customer


by facilitating outcomes customers want to achieve
without the ownership of the specific costs and risks i

We must be able to define an Moog IT strategy that is clearly


aligned to the organisations business strategy, for managing
and support IT services for all the users in Moog, this must
include a strategy for insourcing, outsourcing and smart
sourcing of IT services. We must develop business and IT
partnerships and relationships. We must ensure that we have
standardisation of all common IT services across all our thirty
sites globally and that all users have access to all services and
support for those services that they require to support the
businesses strategic goals and objectives. We need to have
standard and consistent IT processes and controls across
multiple sites, we must work in collaborative teams to ensure
that service value and quality are achieved and maintained. It
is also clear that as services are introduced and improved we
must be aware that it will affect how the organisation and users
work; we must be cognisant of this fact and proactively manage
organisational change.
We have sites in many countries, in Europe, Asia Pacific and the
Americas, this presents us with some cultural differences; we
think differently, we approach tasks differently, while the
common business language tends to be English there are many
misunderstandings and we must be aware and learn to check
and confirm all assumptions. We also have many inter-site
process differences, but are using one application to manage,
some of these differences are real and some are imagined to
strengthen site identity, we must work to breakdown these
differences and ensure sites will not lose their identity, but will

Page 5 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

have better quality services and more inter site support for
their process improvement projects.
The IT budget is a key area where we must centralise and show
each user and each site what it cost to have the right service,
the right quantity of service, the right quality of service
available to meet their needs and the business needs. IT must
show the business value of IT and be able to demonstrate the
TCO (total cost of ownership) of a service or services for the
group. We must also be able to demonstrate the ROI (return on
investment) on services we develop and deploy.
Continuous improvement is a key component of all business
process and of all IT processes and must be implemented as
part of any framework that we will implement.
At the end of the day we in IT must face in one direction and
follow one vision for the good of IT and for the good of the
organisation as a whole. To this end we need a management
framework that connects us all to one another through
standard best practise processes, policies and procedures that
allows communication, collaboration and sharing knowledge
and learning.

1.2 The Scope of the Research


The research phase will look at and understand if ITIL Service
Transition is right for Moog Industrial IT. The research is not
required to look at any of the other ITIL phases and will only
give an outline of them so that the relationships between them
and the Service Transition phase may be more easily
understood. This research will look at other frameworks, MOF
4.0 and ISO20000 to confirm that ITIL service transition is a
correct fit for Moog.

Page 6 of 59

Date: 5th Jan 2012

2.

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

Introduction

2.1 The Moog Industrial Group


Moog Industrial group designs and manufactures highperformance and high reliability motion control solutions for a
variety of industrial applications including plastics, metal
forming, power generation, steel production, test and
simulation, wind energy, motorsport and others.

WE MOVE YOUR
WORLD

With over 30 operations in more than 26 countries, Moog


Industrial delivers a high level of service, support and
collaborative expertise tailored to the requirements of machine
builders and design engineers worldwide.
(From - http://www.moog.com)
The group had Sales of $629M in FY11 and was the second
biggest group contributor to revenue at 27% after Aircraft
group at 37%. Global economic difficulties aside, the
projections are for the group sales to grow to greater than
Page 7 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

$1Bill inside five years. To this end IT is seen as a major


contributor in supporting this growth through effective IT
service delivery and IT support.

2.2 Moog Industrial information Technology


Group
The task for the IT group is to effectively use all the skills,
knowledge and experience of its global IT staff for the benefit of
all global IT users rather than the model of local IT staff for local
site users.
Under the current difficult economic conditions, we need to
introduce and maintain a wide range of IT Services at the right
cost, in the right place and at the right time to over thirty
geographically dispersed sites across Europe, Asia Pacific and
the Americas to support the business in achieving it goals and
objectives.
In an attempt to achieve this the IT group has been going
through a global restructuring of its IT resources, moving away
from the site focused IT resources to a more centrally focused
Global IT team.
The general structure is based on four main pillars.
Infra

2.2.1 Business Partners


There are three business partners, one for Europe, one for Asia
Pacific and one for the Americas.
Business partners will build very close relationships with the
business operations managers and their staffs to ascertain
what are the business service requirements in terms of IT
services and the demand for those services over the next five

Page 8 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

years and beyond. They are tasked with bringing an IT strategy


to the IT executive committee. They are also responsible for
bringing a portfolio of service projects which are aligned to
business needs, roughly costed in terms of finance, time and
resources (internal or external). These will also be prioritised in
terms of their returns to the business either by savings through
automation, through standardisation, through centralisation
and economy of scale or through increased sales and/or user
satisfaction. The executive committee will include the group IT
manager, Senior VPs and the Group Financial controller. Also at
these reviews will be each of the managers from the other
Pillars of IT.
2.2.2 Applications and Solutions
Applications and solutions group are responsible for the
development of the software applications and solutions agreed
by the business strategy. They will gather the detailed
requirements for the service (application or solution) from the
business. Develop the detailed design proposal and confirm its
business alignment with original strategy during design review
with the business partners. They will develop a project plan
including a strategy for the service, whether it is to be
developed internally, externally or whether a purchased third
party solution is better option. They will manage this project
and it required resources, and deliver the service for testing,
release and deployment.
2.2.3 Service and Support
Service and Support is truly a global multicultural team and has
staff members on all sites which have their own IT teams. Some
of these people will perform a dual role, one of service support
at level one or service desk (Incident Management, Access
Management) or as level two Desk side support (more hands on
technical support, Event Management and Problem
Management ) and two they will still be responsible for the local
infrastructure of Servers, Storage, Networks, Desktops and
printers.

Page 9 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

This team is responsible for the efficient and effective transition


of services into production environment and operation and
continuity of these services in production.
2.2.4 Infrastructure
The infrastructure group will be responsible for the
development and delivery of the hardware (including operating
system) and its configuration to the support the delivery and
operations of the services of IT. They will work to OLAs
(Operation Level Agreements). The hardware will include all
servers, storage devices and network. They will also be
responsible for delivering all test environments. They will
monitor and report on the complete distributed infrastructure to
ensure that IT can deliver on the SLAs set down for the
services provided.

2.2.4 Moog IT Structural Alignment with


ITIL:

Above is how I understand the newly announced Moog


Industrial IT organisational structure roughly aligns with the
processes of ITIL V3. The restructuring is still in process and will
continue to evolve over time as we research, understand and
implement the ITIL processes.
Note: This structure may pose risks to an implementation of ITIL
as some of the ITIL roles and responsibilities may be difficult to
place in this structure, as it hasnt been made completely clear
Page 10 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

what the responsibilities are for each of the pillars in the


structure. This will have to be done as part of an organisational
review before we begin the project planning proper in 2013.
The challenge with such distributed or site based teams in a
culture like Moogs is that everyone wants to and is encouraged
to innovate for the better of Moog locally and as a whole, so it
is most important that we adopt and have a standard
framework(s) and sets of guidelines to wrap around this
innovation to ensure we know how to and are consistent in
delivery and management of IT services design and delivery
across Moog Industrial. One of our main aims is to reduce
duplication of effort and expenditure in the same areas on
different sites and to pool our expertise for the good of all
users. To this end I will explain generally what ITIL is and outline
my research for implementing ITILs Service Transition
processes into Moog Industrial IT Group.

3.

ITIL An Overview

ITIL (The Information Technology Infrastructure Library) is


probably the most widely adopted framework approach for IT
Service Management in the world. It provides a practical, nononsense framework for identifying, planning, delivering and
supporting IT services to the business. ITIL advocates that IT
services must be aligned to the needs of the business and
underpin the core business processes. It provides guidance to
organisations on how to use IT as a tool to facilitate business
change, transformation and growth. ITIL was published between
1989 and 1995 by Her Majestys Stationery Office (HMSO) in
the UK on behalf of the Central Communications and
Telecommunications Agency (CCTA) which is now part of the
Office of Government Commerce (OGC). Its early use was really
only in the United Kingdom and in the Netherlands. Version two
of ITIL was published as a set of revised books between 2000
and 2004. The initial version of ITIL consisted of a library of 31
Page 11 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

associated books covering all aspects of IT service provision.


This initial version was then revised and replaced by seven,
more closely connected and consistent books (ITIL V2)
consolidated within an overall framework. This second version
became universally accepted and is now used in many
countries by thousands of organisations as the basis for
effective IT service provision. In 2007, ITIL V2 was superseded
by an enhanced and consolidated third version of ITIL V3,
consisting of a core of five books covering all the service
lifecycle.
The ITIL best practices currently
details five core processes,
Service Strategy, Service Design,
Service Transition, Service
Operation and Continual Service
Improvement which provide a
systematic, professional and best
practise approach to the
management of IT services,
enabling organisations to deliver
appropriate services and
continually ensure they are
meeting business goals and
delivering benefits. The five core
processes map the entire ITIL
Figure 1 - ITIL Service Lifecycle
Service Lifecycle, beginning with
the identification of customer needs and drivers of IT
requirements, through to the design and implementation of the
service into operation and finally, on to the monitoring and
improvement phase of the service.

Page 12 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

3.1 The Five Phases of the ITIL Service


Lifecycle
3.1.1 Service Strategy
Service Strategy activities include defining the market or what
services are required or we will offer, developing the services
that will be offered, developing the strategic IT assets that will
allows us to supply these services and preparation for the
execution of the service strategy. Service strategy has three
main processes, service portfolio management which is
responsible for managing investment across the lifecycle of all
active and retired services and also those in the concept,
design and transition pipeline. It must validate the business
case for a service, maximise the portfolio value and business
alignment and prioritise and balance supply and demand for
services. Demand management which is responsible for
forecasting the demand requirements for the services provided
and ensuring the right capacity is available, based on analysis
of business demand patterns. Financial management looks at
the IT budgeting, accounting and charge back for IT services,
and the value of the services and assets that underlie them.
3.1.2 Service Design
Service Design is required to deliver a service design package
(SDP) for handover to service transition. This includes a service
design to meet business needs, develop and maintain
processes, policies, standards, frameworks and documents to
support service design and the service lifecycle, technology
architectures and management systems, design of
measurement systems and metrics, develop the capabilities
and skill sets within the IT group, and give input to continued
service quality improvement. The key processes are Service
catalogue management (SCM) gives an accurate and consistent
list of available IT services and their details and status for
business to view. Service level management (SLM) agrees and
documents service targets with the business for both internally
and externally supplied services and monitors and reports
Page 13 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

against agreed levels of service. The outputs of the process are


service level agreements (SLAs), operational level agreements
(OLAs), underpinning contracts (UCs) for managing external
service providers, and service improvement plans (SIPs).
Capacity Management provides focus for managing all capacity
and performance related issues of service or resources to
match IT capacity to agreed business demands. Availability
management of services has both reactive and proactive
activities, the reactive activities of monitoring, measuring,
analysis and management of events, incidents and problems
affecting service availability, and the proactive activities of
planning, design, recommendation and improvement of the
availability of services. IT Service continuity management
(ITSCM) is the process of introducing policies and strategies for
business aligned risk reduction measures and service recovery
options to ensure continuity of service to the business.
Information Security management (ISM) purpose is to ensure
that information is available and usable when required; is kept
confidential, only available to those authorised to see it;
information integrity is maintained, is complete and accurate;
information is authentic, that is, business transactions and data
exchanges can be trusted.
3.1.3 Service transition
Note: This is the next process in the lifecycle and I will discuss
in detail later as it is the main purpose of this research report.
3.1.4 Service Operation
Service operation is the service value delivery phase and has
the purpose of delivering agreed levels of service to users and
customers, and is responsible for managing and monitoring the
applications, technology and infrastructure that support
delivery of the services. To maintain high quality of service,
service operation must balance the internal IT view against the
external business view of service delivery; stability of IT
services delivered versus the need to respond to changing
business requirements; the quality of the service provided
against the cost of the service that the business is willing to
Page 14 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

pay and being proactive in improving processes and service


delivery and quality against reacting all the time to requests,
events, incidents and problems. The key processes/functions
include; Event Management detects events normally from
notifications sent by a configuration item (CI) or a management
tool that shows all is not well and an incident record may be
created, all is normal or some intervention is required that is
notified to the IT support staff. Incident managements purpose
is to have the affected service back available as soon as is
possible to minimise the negative impact on the business.
Incidents get categorised to identify who should work on them
and for trend analysis, and they are prioritized according to
their urgency and business impact, and will be escalated if it
cannot be resolved quickly. Request Fulfilment process, possibly
an automated system, enables users to request and receive
standard services from the service catalogue, provides
information to users and customers about the services and
procedures for obtaining them and feedback forum general
information, complaints and comments. Access management is
concerned with giving access to authorised users to services,
while denying access to unauthorised users. Problem
Management is concerned with preventing problems and the
resulting incidents from happening, to get rid of recurring
incidents and to mitigate the impact of incidents that cant be
prevented. It includes diagnosing causes of incidents,
determining the resolution, and ensuring that the resolution is
implemented and maintains information about appropriate
workarounds and resolutions. The Service desk function
provides a central point of contact to IT users; service desk will
log, categorise and prioritise all incidents, service requests and
access requests and will act as first line of investigation and
diagnosis and will manage the entire incident or request
lifecycle. Service desk also acts as an interface for all other IT
service operation processes and activities. Technical
Management function supports planning, implementing and
maintenance of a stable technical infrastructure and ensures
that right resources and expertise are available to design, build,
Page 15 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

transition, operate and improve the IT services and supporting


technology. IT Operations Management is responsible for the
management and maintenance of the IT infrastructure. It
includes the IT Operations Control function staffed by shifts of
operators doing routine operational tasks, providing centralised
monitoring and control, and the Facilities Management function
responsible data centres, computer rooms and recovery sites.

3.1.5 Continual Service Improvement


Continual Service Improvement (CSI) is concerned with the
maintenance of service value to the customer through the
continual evaluation and improvement of the quality of services
and the overall quality and maturity of the IT service
management lifecycle processes.
The three key processes include; 7-Step improvement process;
1) Define what should be measures, 2) Define what can be
measured, 3) Gather data, 4) Process the data, 5) Analyse the
data, 6) Present & use data and 7) Implement corrective action.
Service monitoring and measurement process which looks to
validate previous decisions made, to direct activities to ensure
agreed targets are met, justify with fact that a course of action
is required and to ensure intervention at appropriate time to
take corrective action. Service Reporting process reports the
information of interest and importance to the business.
Business in most concerned with reporting historical events
that may continue to be a threat going forward, and how IT is
going to mitigate against such threats.

Page 16 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

3.1.6 Inputs and Outputs of the Service Lifecycle


phases

Figure 2 - Key Links, inputs & outputs of the service lifecycle


phases.

3.2

The Benefits of ITIL

Adopting ITIL can give you a huge range of benefits that


include:
You will have improved standardised IT services for all users no
matter what site they are on and irrelevant of the size of the
site and budgets available.
You will improve our IT Service alignment with business needs
and requirements, business will decide what services they
require, what budget they are willing to spend and what service
levels are required of the services and of IT. IT will then work to
develop, test and ensure that these services can be delivered
on-time and on budget to meet the service level agreement.
With pooled resources and standard managed processes of
business aligned service delivery you will be able to reduce the
costs of delivery and management of your services.
Page 17 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

You will have improved customer satisfaction through a more


standardised professional approach to service delivery. Users
will be able to see what services are available, the level of
service offered and the costs of that service up front.
There will be improved productivity for business and IT,
because IT resources will be working and focusing on what the
most important services to the business are, based on the
priorities set by the business and the service levels agreed. It
will also be able to show its worth through reporting its success
against these agreed service levels.
You can expect to have an improved customer experience due
to users getting the services and service levels they agreed.
Through access to services through a self-service portal and
through a service desk that is customer and incident
management focused.
Through pooling of your resources into expert collaborative
teams around a standard framework, irrelevant of their
location, you would expect to improve your use of the IT skills
and experience at your disposal and to ensure you only
outsource those skills where you either dont have any or dont
have enough.
With a standardised process for the delivery of external
services or outsourcing and through under-pinning contracts,
you would improve delivery and management of third party
services.

4.0 Service Transition


4.1 An Overview
Aligning the new or changed service with the
organisational requirements and organisational
operations ii

Page 18 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

Service transitions role is to take the service design package


from the service design stage and bring together all the
necessary elements to deliver and support the services
required by the business into the operations stage, its
processes and activities help to maximize the business value of
the IT services we provide. It helps to actively manage and
mitigate risk, and manage knowledge to support better
decision making. It enables management of necessary changes
in the IT service environment. It provides information that
allows changes to be made with an awareness of their potential
impact on the other IT services and on the business. Service
transition considers more than just one project; it supports all
services that are currently in transition and maintains
relationships between them to minimise the effects they might
have on each other. It also provides support for these projects
beyond initial implementation through early life support.
Service transition also defines requirements for understanding
what the business value of the service is, who will use the
service and who the main stakeholders are.

4.2 The main concepts of Service


Transition
The definition and implementation of common frameworks, a
set of standards, a set of policies, a set of procedures and
templates for the transition of all services and processes, new
or changed into the production or operations phase.
Develop a culture of change management across the
organisation where all changes to services or processes are
implemented through service transition and service change
management process.
Creation of processes that will re-use existing systems and
processes which work, and reduce the effort by not recreating
the wheel every time a new requirement or a process change is
required.
Page 19 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

Create a process that works with the business to coordinate the


planning and scheduling of IT with the planning and scheduling
of the business and including all stakeholders to ensure the
least amount of disruption to business functions.
Develop a process that identifies who the stakeholders are in
the services(s) that are being transitioned, and that creates a
relationship with them and involves them throughout the
transition phase.
Creating an effective control process that defines and manages
how assets are to be identified, logged and their configuration
details captured and maintained. How the roles and
responsibilities during the service transition phase are to be
defined and managed. How the activities of Service Transition
with be managed.
Creation of a process for knowledge collection, knowledge
transfer and decision support systems.
Create a process that plans the release, packaging and
deployment of services into production.
Create a process that drives continual improvement and quality
assurance of a service through the service transition phase.

4.3 The core activities of Service Transition


Service transition phase has the very important responsibility
for managing communication and commitment across all the
phases of the IT service management for all transition projects
on new or changed services or processes.
Service transition looks at the effects a new or changed service
will have on processes and business functions and the people
involved and helps manage organisation change.
Service transition looks to identify, understand and manage the
key service stakeholders, and their expectations for IT services.

Page 20 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

So they clearly understand what the service is that they will be


receiving and the level of service proposed.
Service transition takes responsibility for the project planning
and project management of the capacity and resources
required to package, build, test, and deploy a released
service(s) into production on time, on budget and to right
quality standard.
Service transition provides a standardised framework for the
logging, assessing, authorising, scheduling and reporting on all
changes to IT Assets, configuration items, services or their
components.
Service transition provides a consistent and rigorous framework
for evaluating, validating and testing the Service capability and
risk profile in a test environment before it is released into
production environment.
Service transition is responsible for the establishment,
maintenance and the integrity of verified and audited records
of all the identified Service Assets, including all configurations
and all license management.
Service transition is responsible for the provision of a goodquality service knowledge management system (SKMS), which
identifies knowledge, approves, stores and maintains as
relevant over time.
Service transition provides for efficient, consistent, tested,
piloted and repeatable build and installation and retirement
mechanisms for the delivery of services.
Service transition ensures that the Service can be managed,
operated, and supported according to the requirements and
constraints specified within the Service Design package.

Page 21 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

4.4 Benefits of Service Transition


Service transition brings a greater ability to quickly adapt to
new service requirements and business needs due to its well
documented and repeatable processes.
A higher success rate of changes and releases due the use of
tried and tested processes. Due to the use of knowledge and
learning gathered and shared from previous service transitions.
Better predictions of service levels and warranties for new and
changed services due to the use of standardised service
validation and testing, and through proper piloting.
A higher level of compliance with requirements during change
is expected due to the detailed service design package
received be validated and tested, all changes being processes
through change management and change evaluation process.
With standard integrated planning a greater level of clarity in
plans will be achieved that will allow business to link
organisational change to service transitions plans.

4.5 Service Transition Processes


First, Ill cover what I think are the three major process aspects
of Service Transition are: Change Management (CM), Service
Asset and Configuration Management (SACM), and
Release and Deployment Management (RDM). Each of
these principles is essential to effective Service Transition and
each has a specific set of requirements and measures.

4.5.1 Change Management


Change management is responsible for controlling the Lifecycle
of all Changes. The primary objective of Change Management is
to have a predictable process for managing changes to the
production environment to improve reliability and customer
satisfaction. This process is to enable beneficial Changes to be
made, with as little disruption to IT Services as is possible. It is

Page 22 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

responsible for the adding, changing or removing of any


service, configuration item or associated documents including
the strategic or directing level, the tactical or design/control
level and operational level changes unless it is otherwise stated
that a service or process is outside of its control.
4.5.1.1 Change Lifecycle
The change lifecycle normally consists of the following phases;
Initiating or recording and Logging the change through a
Request for Change (RFC) including the service or configuration
item being changed, the reason for the change, who you
believe is affected by the change, justification for the change in
monetary, time or quality terms.
Filtering changes; all changes with the exception of those that
can be dealt with by a standard change or by a change model
for which operating procedure already exists are filtered and
assessed by the Change Manager to ensure that they are
appropriate before they are accepted.
Prioritisation & Categorisation; when a change has been
deemed acceptable by the change manager, it needs to be
prioritised as either Emergency - for immediate action due to
loss of service or service unusable for a large number of
people, High action need in 48 hours due to severe impact on
some users or some impact on a large number of users,
Medium action needed in next 5 days because change cant
wait for next release of service or Low needs doing by a
specified date and can wait for the next release or upgrade of
the service. Categorisation of each change is also done under
the headings of; Standard change, Normal change and
Emergency Change which are discussed in a little later.
Assessing & Authorising a change; Assessing a change based
on its impact to the business will define what level of
authorisation is required to sign-off the change. Some standard
changes with little risk or impact that have procedures drawn
up for them can be pre-authorised or may need the sign-off of
Page 23 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

say, the shift supervisor, other changes of that have low impact
and low risk can be authorised by the change manager, and
changes of medium to high impact and risk would go to the
Change Advisory Board (CAB) or even senior management for
sign-off.
Planning & scheduling a change; only after the change has
been authorised can the change manager start planning and
scheduling, as this stage the change manager will identify who
will build and test the change and the timeline to completion.
Measuring & Reporting on change and change process; The
change manager is responsible for measuring and reporting on
the effectiveness of the change process.
4.5.1.2 Types of Change
Normal change - A change that follows all of the steps of the
change process.
Standard change - A pre-approved change that is low risk,
relatively common and follows a procedure or work instruction,
e.g. password reset
Emergency change - A change that must be introduced as
soon as possible. e.g. to resolve a major incident or implement
a security patch.
4.5.1.3 The benefits of change management (CM)
Change management gives us a more consistent way of
prioritising and responding to organisation and customer/user
request for change (RFC).
The process reviews all changes and assesses, categorises and
prioritises them, so that changes are implemented that meet
the customers agreed service requirements while optimising
costs by understanding the relationship between changes and
through economy of scale by grouping and building, testing and
implementing changes together.

Page 24 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

The process helps us meet our governance, legal, contractual


and regulatory requirements by reviewing and managing all
changes in line with these requirements.
Through proper review and risk assessment of all changes this
process helps to reduce the number of failed changes and
therefore the number of service disruption, defects and the
amount of rework required.
The process allows us to deliver change promptly to meet
business timescales because it sets a standard approach to
managing the change lifecycle, that categorises and prioritises
change based on impact and risk to the business, thereby put
the resources where they are needed most.
The process allows us to track all changes through the
complete lifecycle of a service.
The process gathers relevant data that allows us to create
better estimations of the quality, time and cost of change to
the organisation.
The process aids productivity of staff through minimising
disruptions due to high levels of unplanned or emergency
change and hence maximising the availability of services.
The process supports the reduction of the Mean Time to Restore
Service (MTRS), due to quicker and more successful
implementations of corrective changes.

Page 25 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

4.5.1.4 The change Process

Figure 3 - The Change Process

4.5.1.5

Roles in Change management

4.5.1.5.1 The Change Manager


The change manager is responsible for the complete change
management process. Their role is to authorise or approve
minor and low risk changes. The change manager will also call
the CAB meetings to discuss the higher risk and significant
changes, where this is appropriate, and make the decision
either to implement or reject the change. They will also ensure
that all of the activities required to build, to test and to
implement the change are scheduled and undertaken in an
appropriate manner and that they are documented and
reviewed and reported to management when completed.
Page 26 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

4.5.1.5.2 The Change initiator


The change initiator, in theory, can be anyone in the
organisation, but normally consideration is given to who is
allowed to raise a request for change (RFC).
4.5.1.5.3 Change Advisory Board (CAB)
CAB, the Change Advisory Board, will be a dynamic group of
people, the board will include representatives from business
and IT who are relevant to the change, who understand the
stakeholder needs and who need to be consulted on a
particular change and this group will assess each change
request under the 7 Rs of change management, Who Raised
the request for change, what is the Reason for the change,
what is the Return expected from change, financial, quality or
otherwise, what Risks are involved to the service and the
business in making the change, what Resources, people,
finance etc. are required to make the change, who is
Responsible for the build, test and implementation of the
change, what is the Relationship between this and other
changes.
A CAB meetings called by the change manager may have an
agenda including the following items; a review of failed
changes, a review of backed out changes, a review of the
changes to be assessed by CAB, a review of the changes that
have been assessed and are a work in progress, a review of the
recently implemented changes, a review of the change
management process and any changes made to it and finally a
review of the successful changes and the business benefits
achieved for the period.
4.5.1.5.4 The change Builder, Tester and Implementer
The change builder and implementer will normally be the same
person, but not necessarily. The change tester should not be
the same person to ensure impartial testing and to avoid
segregation of duty issues, but all should be acknowledged
subject matter experts in the area of the change.

Page 27 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

4.5.1.5.5 The Change reviewers


This a group called together by the change manager to review
how a change has gone and to close out the change, this may
be the original CAB group the authorised the change.

4.5.2 Service Asset and Configuration Management SACM


SACM is a process that ensures the integrity of service assets
and their configurations in order to support the effective and
efficient management of the IT organisation.
The main reason for us doing configuration management is to
identify and label all authorised and identifiable configuration
items (CIs) / IT components (hardware, software, documents
{Service design package, release package etc} and SLAs) that
can go to make up a service. Then gather and maintain all that
information and documentation about these CIs and how they
relate to each other over the lifecycle of the CI in a
configuration management system (CMS) which is part of the
Service Knowledge management system (SKMS). The reason
for this is to ensure that the relevant information is available for
all the other service lifecycle processes to ensure that detailed
impact and risk analysis can take place to aid decision making
and resolve incidents and problems faster. This information also
provides a sound basis for incident management, problem
management, change management and release management.
This information will allow us to create a baseline configuration
record for audit purposes and correction of exceptions.
4.5.2.1

The roles in SACM

4.5.2.1.1 Service Asset Manager


The service asset manager is responsible for implementing the
service asset management policy and standards, the
evaluation, design and implementation of efficient and effective
asset management systems. Is responsible for defining what
Page 28 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

items are to be controlled and what details need to be


recorded, and the naming conventions and standards to be
used. They are also responsible for the interfaces to the other
processes, like change management, release management and
problem management etc.
4.5.2.1.2 Configuration Manager
The Configuration Manager is responsible for implementing the
configuration management policy and standards, evaluating
and implementing the configuration management system,
agreeing the scope of the configuration management
processes, defining the items that will be controlled, and the
relevant configuration information that is to be recorded about
these items. They plan for the population, integrity and
management of the configuration management system (CMS).
They will also develop configuration management methods and
procedures and ensure that changes to the configuration
management methods and processes are properly approved
and communicated. They will ensure that staff complies with
the identification standards. The will manage the interfaces to
the other processes and provide management reports.
4.5.2.1.3 Configuration Analyst
The configuration analyst will agree with the Asset and
Configuration Manager the CIs that will be uniquely identified
with naming conventions. They will ensure that the developers
and other configuration system users comply with identification
standards for object types, environments, processes, lifecycles,
documentation, versions, formats, baselines, releases and
templates. They will use the CMS for assessing the impact of
proposed changes and to ensure that implemented changes
comply. The Configuration Analyst is responsible for doing
regular audits and housekeeping to ensure that physical
inventory is consistent with the asset and the CMS.
4.5.2.1.4 Configuration Management System Manager
The CMS manager is responsible for the evaluation asset and
configuration management tools and recommends what is best
Page 29 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

in terms of organisational budget, technical requirements,


customisation and scalability. They monitor the performance
and capacity of the asset and configuration management
systems and advise on possible improvements and manage
housekeeping and fine tuning opportunities, always through the
change management process.
4.5.2.2 The Benefits of SACM
Optimising the performance of service assets and
configurations increases the overall service performance and
reduces the costs and risks caused by poorly managed assets,
e.g. service outages, fines for regulatory failures, only paying
the correct licence fees and avoiding failed audits.
The ready availability of accurate asset and configuration
information enables better forecasting and planning of
changes, as we have quick access to find all the affected
configuration items in the CMS.
The CMS information on assets and configuration showing what
items we have, their configuration and their location etc. makes
changes and release evaluation, planning and delivery much
more successful.
Through the use of the information available from SACM we can
resolve incidents and problems more quickly and easily within
the service level targets set.
The more we know about our service assets and their
configuration the better we can understand our capabilities to
deliver service levels and warranties to the customer.
Due to information collection and auditing we can better ensure
adherence to the agreed standards and our legal and
regulatory obligations.
SACM can give us access to more business opportunities as we
can demonstrate control of our assets and services to our
customers.

Page 30 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

SACM allows us to have traceability of changes back to the


requirements driving the change.

4.5.3 Release and Deployment Management


The job of release and deployment management is to deploy
new or changed services releases into production and enable
their effective use in line with what is stated in the service
design package and to deliver a service that is of value to the
customer. The objective of release and deployment
management is to build, test and deliver the capability to
provide the services specified by service design. This includes
the processes, systems and functions to package, build, test,
and deploy a release into production and prepare for service
operation.
4.5.3.1 The release and deployment management
activities
The process must proactively manage all risk from the
deployment of a new or changed service or upgrade and
minimise any negative impact and maximise any positive
impact on the business
The process must build, test and deliver the capability for
delivering the released services to the users as specified by
service design phase. This maybe automated through selfservice portals or batch-jobs at login or manual.
The process must develop and provide clear and
comprehensive deployment plans that enable change projects
to align their activities with the deployment schedule.
The process must ensure proper controls are in place to ensure
traceability of the hardware and software being changed and
that only correct, authorised and tested versions are available
to install.
The process must ensure that all master copies of software are
stored securely in the Definitive Media Library (DML).
Page 31 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

The process is responsible for the efficient and effective build,


installation, test and deployment of release packages.
The process is responsible for transferring service knowledge
and skills are transferred to the operations staff that will be
supporting the service.
The process must ensure that new or changed services are fit
for purpose (utility) that it does something useful or of value to
the customer, and that is Fit for use (warranty) that it is
available enough, has enough capacity, displays enough
continuity and is secure enough and thereby meets the service
levels agreed.
The process is responsible from communicating with the
customer throughout the planning and rollout and
understanding the expectations of the customer and managing
these expectations to avoid loss of confidence.

4.5.3.2 Release types


Major software releases and hardware upgrades,
normally containing large areas of new functionality, some of
which may make intervening fixes to problems redundant. A
major upgrade or release usually supersedes all preceding
minor upgrades, releases and emergency fixes.
Minor software releases and hardware upgrades,
normally containing small enhancements and fixes, some of
which may have already been issued as emergency fixes. A
minor upgrade or release usually supersedes all preceding
emergency fixes.
Emergency software and hardware fixes, normally
containing the corrections to a small number of known
problems

Page 32 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

4.5.3.3 Release and Deployment Options


Big bang The new or changed service is deployed all at once.
Beneficial when introducing an application change requiring
consistency across the organisation.
Phased The service is deployed piece by piece to a
scheduled rollout plan.
Push When the service component is deployed/ pushed out
from the centre.
Pull Used for software releases and updates, software is
made available in a central location, but users pull it down
when they want or at restart.
Automation Ensures repeatability and consistency. Tools and
scripts can be used to push changes.
Manual Completed by IT at location one at a time.
4.5.3.4 Benefits of Release and deployment
Management
Release and deployment management gives us the ability to
deliver change faster and more efficiently, it helps us to
effectively control costs and minimise risks from deploying new
or changed services.
Proper test and piloting in line with the requirements set out at
the design phase during this process gives assurance that
customers can use the new or changed service in a way that
supports the requirements and the organisations goals.
Through standardising in this process much improved
consistency in the implementation approach across the
organisation can be achieved.

Page 33 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

4.6 Other key parts of the Service


Transition Phase
Other Key areas of Service Transition are Knowledge
Management, Service validation & testing and Transition
Planning and support.
4.6.1 Knowledge Management
Knowledge Management is responsible for setting the data
requirements, for the capture, maintenance and management
of that data. It is responsible for the procedures for data
management and the evaluation and improvement of that data.
It must ensure that the knowledge is transferred to improve the
performance of IT service design and delivery. The use of this
knowledge in the service transition phase; helps us to identify
who our main stakeholders are, in a service being transitioned
into operations and building relationships and communications
strategies with them. Through the information gather in the
knowledge management from the design phase, the service
design package, it is possible for us to understand the risk
levels that were agreed and acceptable and the expectations
for performance of the service. It is also possible to understand
the timescales for delivery of the service to achieve maximum
value and the resources that are being made available to
achieve completion. The quality and relevance of the
knowledge rests in turn on the accessibility, quality and
continued relevance of the underpinning data and information
available to service staff.
It is clear that there is a lot of data being collected or that can
be collected throughout the phases and in many different
databases, it is the integration of these sources that will
achieve the greatest outcome in terms of the effectiveness of
the knowledge management system.

Page 34 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

4.6.2
Service validation & testing
This process or function is really part of the build and test cycle
of the release and deployment management process and its
main aim is to ensure that the service will provide value to the
organisation. Without proper testing, it may cause an increased
number of incidents to be recorded, overwhelming the service
desk. May lead to errors that are harder to diagnose in
production, may cause high levels of customer dissatisfaction,
drive higher costs, might create reputation damage and/or loss
of revenue.
4.6.2.1 The activities of service validation and testing
Prepare test environments; Service validation and testing is
responsible for preparing the test environments that mimics the
production environments into which it will be deployed, to test
a new or changed service in line with the test requirements set
out in the service design package developed in the service
design phase.
Perform Tests; the process is responsible for performing test in
accordance with the test requirements that were agreed at the
design phase and delivered in the service design package. This
will include testing to ensure that the service levels agreed can
be met before the services are deployed into production.
Produce Test Report; the process is responsible for producing
test reports that validate the service is okay to go ahead into
the pilot testing phase or to show that remediation is required
before it can move on to pilot and deployment.

4.6.2.2 Benefits of service validation and testing


It will give confidence that the new or changed service
outcomes will be achieved.
It gives validation that service is Fit for purpose (Service
Utility).

Page 35 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

It gives assurance that Service is Fit for use (Service


Warranty).

4.6.3 Transition Planning and support


The process is responsible for the integrated project planning
all service transition processes mentioned here and
coordinating the resources that they require to establish a new
or changed service into operations on time, on budget and to
quality requirements.
4.6.3.1 The activities of Transition planning and
support
This process plans and coordinates all the resources required to
operate the projects to establish successfully a new or changed
service into production with predicted cost, quality and time
estimates.
The process plans the changes required that ensures integrity
of all customer assets, service assets and configurations as
they evolve through service transition.
The process coordinates activities across all projects, all
suppliers and all service teams, thereby understanding the
relationships between the projects, the risks from one project to
another and possible impacts of one project on another.
Responsible for opening and maintaining communication
channels with customers, users and stakeholders throughout
the transition process.
4.6.3.2 The benefits of Transition planning and support
The Benefits will be the ability to handle a greater number of
changes, releases and deployments and retirements with less
work, less risk and a higher degree of success.

Page 36 of 59

Date: 5th Jan 2012

5.0

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

Framework Comparisons

5.1 Microsoft Operations Framework


(MOF)
5.1.1 An Overview
Microsoft Operations Framework (MOF), first produced in 1999,
is a structured approach aimed at helping its customers get to
IT operational excellence and was created to cover the entire IT
Service Lifecycle, in much the same way as ITIL, some say it is
based on the original ITIL V2. MOF was created to give IT
professionals the knowledge and processes they required to
manage their Microsoft platforms cost-effectively and to
achieve high levels of reliability and of security. Version 4.0 of
the MOF actually brings it closer to ITIL, as it was built to
respond to newer challenges in IT: how IT can demonstrate its
value to the business, how it can respond to the increasing
number of regulations and how it can improve organisational
capabilities.
The key to MOF they say is that it offers practical guidance for
everyday tasks and activities, and for all budget conscious IT
managers, its entire documentation is free for use, and even
free for reuse under the Creative Commons Attribution License
(CCAL).
As with most frameworks of the IT service lifecycle, MOF looks
to how to manage along the life of an IT service, from planning,
building and refining an IT service, to ensuring business
strategy alignment, right the way through to delivery in
accordance with the customers requirements, to operating the
service and supporting the service, and making it available to
the users. Also underpinning this, MOF offers a foundation for
how IT governance should operate, processes for managing
risks in the IT environment, how to become compliant and
maintain compliance, MOF offers help on IT organisational

Page 37 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

structure to support the service lifecycle, and a process for how


change should be managed.

The IT Service Lifecycle of MOF (see Figure 4) is composed of


three on-going phases and one foundational layer that operate
throughout all of the other phases:
Plan phase: plan and optimize an IT service strategy in order to
support business goals and objectives.

Deliver phase: ensure that IT


services are developed effectively,
deployed successfully, and ready
for Operations.

Operate phase: ensure that IT


services are operated, maintained
and supported in a way that meets
business needs and expectations.

Figure 4 - The MOF 4.0 Showing


Phases, Service Management Functions
& Management Reviews

Manage layer: the foundation of the IT Service Lifecycle. This


layer is concerned with IT governance, risk, compliance, roles
and responsibilities, change management, and configuration.
Processes in this layer apply to all phases of the lifecycle.
5.1.2 Comparing ITIL & MOF
Even though both ITIL and MOF are frameworks based on the
service lifecycle, they cannot be directly compared on a one-toone basis until you go down to the processes and functions. The
following chart (see Figure 5) shows how they overlay and while
they tend to blur the lines between what is a process and what
are functions and activities they do cover the same general
practises.

Page 38 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

While ITIL speaks about management processes, MOF speaks


about service management functions Example: ITILs Release
& Deployment Management process and MOFs Deploy Service
Management Function.
ITIL release and deployment management process speaks
about the planning, the preparation, the build, test and piloting,
the early life support and the release review.
MOF deploy service management function speaks of deploying
stable solution into production, customer acceptance and the
transfer from project team to operations and support team.
Portfoli
o

Service
Alignme
nt
Operational
Health
Review
Policy and
Control
Review

Project
Plans
Approve
Business
Readiness

Figure 5 - The Lifecycles comparison overlay from


cross_ref_itilv3_mof4.pdf

5.1.3 The Strategic Alignment Model Enhanced (SAME).


SAME is a blueprint or an approach to the management of
organisations that looks at them under the headings of Strategy
- Tactics - Operations. At a strategic level an organisation
manages its long-term objectives in terms of identity, value,
relations, choices and preconditions. At the tactical level these
objectives are translated into specific goals that are directed
and controlled. At the operational level these goals are then
translated into action plans and realised

Page 39 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

The following figure (see Figure 6) shows clearly how the five
ITIL V3 processes and the four MOF 4.0 service management
phases occupy virtually the same management space.

Figure 6 Positioning ITIL V3 and MOF 4.0 in the 3x3 SAME Matrix

5.1.4 ITIL Service Transition compared MOF 4.0


Delivery Phase
Now to look at how ITIL service transition and parts of MOF
Delivery phase line up. Well to begin MOF delivery phase
roughly covers both ITILs service design phase and service
transition phase as was seen in Figure 5 above.
Then looking at figure 6 above you will see that ITIL service
transition is more closely aligned with the operational part of IT
and takes the service design phase, which is at the tactical
planning level of SAME matrix, output in terms of the service
design package and manages the resources to develop the
solution, test the solution, validate the solution and its service
level agreements, release the accepted solution, deploy the
released and do early life support of a new or changed services.
Also included in service transition phase are change
management, service asset and configuration management,
and knowledge management.
The MOF 4.0 Delivery phase overlaps the tactical and
operational parts of the SAME matrix. It has the service
Page 40 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

management functions of Envision and project planning to


match ITILs service design phase in the tactical area. But as we
are interested in service transition; MOF 4.0 has the service
management functions of build, stabilise and deploy where ITIL
uses service transition phase processes of transitions planning
and support and release and deployment management in the
operational area. It differs in that ITIL service transition has
change management and service asset and configuration
management in its phase, whereas in MOF 4.0 these are rolled
up in the Manage phase that has the change and configuration
service management function. The Manage phase wraps
around all of the other MOF phases. This phase also includes
the service management function of Teams that is responsible
for all roles and responsibilities, where this is kept as part of
each of the processes in ITIL and the Governance, Risk and
compliance that aligns with more of ITIL Service Design.

5.2

ISO20000 Certification Standard

5.2.1 An Overview
ISO 20000 promotes the adoption of an integrated process
approach to effectively deliver managed services to meet the
business and customer requirements. The latest ISO20000
release is also more closely aligned with other management
system standards of ISO9001:2008 and ISO27001:2005.
IRCAs view is that publication of ISO/IEC 20000-1:2011
provides organizations implementing IT Service Management
Systems and organizations needing to conduct audits of IT
Service Management Systems an opportunity to re-assess their
own practices and identify improvement opportunities. iii
While ISO 20000 is very closely aligned with ITIL V3 and can
accredit ITIL processes, it does not prescribe that its
requirements must be met by following the ITIL
recommendations, so there are many possible ways to achieve
compliance. However it is mostly through introducing ITILs

Page 41 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

framework of processes that organisations obtain an ISO 20000


certificate for their IT service management.
A reason for the ITIL V3 update was to get a closer alignment
with the ISO 20000 standard. The principle of continual
improvement and Information security management were
added to ITIL, and thus the processes of ITIL V3 2007/ ITIL 2011
and ISO 20000 are very much in line.
As a result, ITIL offers a broad range of best practice
recommendations which are the perfect basis for developing
ISO 20000 compliant processes for the organization - the
implementation of ITIL is the best available route towards
ISO20000 certification.
5.2.2 ISO20000 Clause 5 compared to ITIL Service
transition
Clause 5: Design and transition of new of changed services
emphasises Change Management as a keep process as it is in
ITIL Service transition. It also defines requirements for predeployment service testing against service provider and
stakeholder agreed criteria, use of the release and deployment
control process to migrate the service into operations and a
post-deployment review process.
Service transition processes align with different processes of
the ISO 20000 standards processes, mainly with Control
processes and Release processes and I have shown these in
Figure 7.

Page 42 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

Figure 7 - ISO 20000 Processes and Service Transition Processes

5.2.3

Audit Areas

Requirements for a management system;


Planning and implementing service management;
Planning and implementing new or changed services;
Service delivery process;
Relationship processes;
Resolution processes;
Control processes; and
Release processes.

Page 43 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

However, a certification standard and not a framework for


implementation like ITIL V3 or MOF 4.0. Also there is not a lot of
freely available information on the web and I currently dont
have access to the ISO20000 standard myself, even though
Moog may have and does have access to the ISO9001
standard, Im not sure I can get access to other standards.

6.0

Conclusion and Recommendation

6.1

Conclusion

This conclusion is based on the going ahead as originally


planned with me working on a project to implement service
transition processes into Moog Industrial group but as already
discussed with project supervisor Jim ODwyer this is probably
now not going to be actually what happens due to a change of
mind lately from discussions with my boss in Moog and other
ITIL adopters.
I believe that implementing ITIL service transition and the
standardised integrated planning and support that it will bring
to managing IT resources, change and risk etc. across all of the
IT projects will benefit the Moog IT group and the Moog
Organisation as a whole through better more valuable services,
controlled costs, and controlled change, efficient and effective
delivery models for the user and overall a more transparent
service oriented IT group. The centralising nature of the
processes of service transition will help to turn site focused IT
teams to teams who act as a central team to support all users
across the thirty sites.
While other frameworks offer similar outcomes, ITIL is the most
widely adopted framework and offers a wealth of knowledge
and support through many groups and forums. I would however
advise you not to ignore the other frameworks who offer a large
amount of templates and resources that are transferable and
are free to download and use.

Page 44 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

When all is said and done, my conclusion is still that a


framework like ITIL certified to ISO20000 is the best approach
to delivering better IT services in Moog and creating that virtual
IT organisation that works as one entity while distributed all
over the globe.

6.2

Recommendation

I would recommend implementing ITIL service transition and


my original recommendation would have been to go ahead with
a blanket or big bang approach to implementing service
transition to Moog. This would be similar to the project plan
(see Appendix 3) I have written and would have meant first
drafting the policies and procedures, the roles and
responsibilities, and the document templates etc. and then
laying these over the organisation as a new system. This
however would have benefits and issues attached.
6.2.1 Benefits
A quicker implementation
Everything is prepared in advance of implementation
Everything is prepared offline and then transferred as one,
switch off switch on
Everything is written to match best practise standards
6.2.2 Issues
A lack of involvement of all the IT stakeholders
Possible rejection by IT stakeholders
More difficult to sell and embed
6.2.3 Recommended next steps
First, we need to create a vision with senior management for
how we want IT to deliver services in the organisation. We need
to communicate and sell this vision to all in IT Staff and
business managers.

Page 45 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

Then, we need analysing the organisation for what weve


already got, what we are already doing well and to test our
readiness to implement service transition processes.
Then, we can begin to start setting some goals and objectives
and developing a solid project plan with timelines, milestones,
resources and deliverables.
Then, we can begin implementing IT Service Transition
I have had a number of conversations with people at the IT
service management forum (itSMF) conference and have plans
to meet local members again. Coupled with this, as I said
earlier things have changed and my boss and I now want to
discuss a different approach, but still ITIL. We now want to look
at take a Step-by-Step approach of taking a service or small
group of services and building service management around
them. This will mean going right back to looking at service
portfolio and service catalogue management with service level
management development the processes as we take the
service(s) right through to Service operations. These
discussions will begin in mid-January when my boss returns to
the UK from a two year stint in Japan as Region IT Manager and
service and support manager. So, the research begins again,
but will run in parallel with the actual project as we step
through each of the processes.

6.3 Observation
IT Service management has a broad body of knowledge out
there and I found this research difficult to do and could have
written many more pages without feeling that I have covered it
adequately. But what I read is positive in terms of the benefits
for IT Service transition and ITIL in general to an organisation.

Page 46 of 59

Date: 5th Jan 2012

7.0

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

Referenced material

http://www.itil-officialsite.com/AboutITIL/WhatisITIL.aspx
http://books.google.ie/books?
id=a57syGFfEWkC&pg=PA199&lpg=PA199&dq=starting+servic
e+transition&source=bl&ots=swEYXyB19s&sig=FOX9xLIL9Xfiz
1vLnC4DwjfcV6M&hl=en&sa=X&ei=iriBUIrZOoyDhQff4IDYBA&s
qi=2&ved=0CDMQ6AEwBA#v=onepage&q=starting
%20service%20transition&f=false
http://www.slideshare.net/AxiosSystems/fy12-lead-nurtureitilv3
Focus on - ITIL Service Transition (Updated for ITIL 2011).pdf
by Anthony Orr. Orr is Director of Service Management and
works within the Office of the CTO at BMC Software. He is one
of the authors for the ITIL 2011 update and a senior ITIL
examiner for APMG.
http://www.governancetraining.com/service-transistion.htm
http://en.wikipedia.org/wiki/IT_service_management#Framewor
ks
http://en.it-processmaps.com/itil/iso-20000.html#ITIL-ISO20000
CIT Course notes IT Service Management Module.
http://www.microsoft.com/en-us/download/details.aspx?
id=17647 for MOF 4.0 downloads.
IRCA briefing note ISO IEC 20000-ENG.pdf(The International Register
of Certificated Auditors)

http://www.google.ie/url?sa=t&rct=j&q=iso%20200001&source=web&cd=3&ved=0CD8QFjAC&url=http%3A%2F
%2Fwww.irca.org%2FDocuments%2Fpress%2F2012%2FIRCA
%2520briefing%2520note%2520ISO%2520IEC%2520200001%2520ENG.pdf&ei=wv_iUIP8OcYhQebwoGQBg&usg=AFQjCNGk8P7Td0bktqcFOXUnDm4H1cdTJ
A
Page 47 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

Page 48 of 59

Date: 5th Jan 2012

8.0

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

Appendices

8.1 Appendix 1 - The ITIL V3 2011 Reference


Wall Chart

Page 49 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

Page 50 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

8.2 Appendix 2 - ITIL IT Service Management


Overview
IT Service Management Synopsis

FormStrategy

Service Transition (ST)


Define & Implement
common Transition
frameworks, Standards
DesignService Solutions & procedures

Value Creation

DesignService Portfolio through ST

Service Strategy

Service Design

Service Operation

Continual Service
Improvement

Handlingconflict of
mantainingcurrent versus
reactingto change

Promote aCSI vision, with


asense of urgency&
empowerment to act

Activities

Processes

Concepts

Implement all Change Achieve abalance of Stability DemingCycle: Plan-Do-

Service Assets

DesignArchitecture

Service Providers

DesignProcesses

Service Portfolio

Financial Mgmt
DemandMgmt

Service catalogmgmt
CapacityMgmt

Portfolio Mgmt

AvailabilityMgmt
ContinuityMgmt
InfoSecMgmt
Supplier Mgmt

Reuse Existing
Processes& Systems
Coordinate Planswith
needsof business
Manitain Stakeholder
involvement &
relations
Effective control of
Assets, Responsiblities
& Activities
Deliver Knowledge
Transfer & Decision
Support systems
Plan Release &
Deloyment Packages
Continue to improve &
ensure service quality
during ST
Transition Planning&
Support
Change Mgmt
Service Asset & Config
Mgmt
Release & Deloyment
Mgmt
Service Testing &
Validation Mgmt
Evaluation Mgmt
Knowledge Mgmt
Communication

DefiningMarket

DevelopRequirements

DevelopOffering

Organisation change
Data& InformationMgmt Mgmt

DevelopStrategicAssets ApplicationMgmt

Stakeholder Mgmt

Prepare forExecution

to Responsivenessto change Check-Act


SetCSI Metricsfor
Achieve optimal balance of Technology, Processes&
cost & Value
Services
Achieve balance of Reactive
to proactive behaviour
SetCSFs& KPIs
Involvement withother
phases

Make Assesment /
DecisionswithDIKW
model

Effective Communications

Governance Drives&
Controls
Use CSI Policiesto capture
agreements

Event mgmt
Incident Mgmt
Problemmgmt
Request Fulfilment
AccessMgmt

Monitoring& Control
Day-to-DayITOperations
Facilities& DatacenterMgmt
Infrastructure Mgmt

Page 51 of 59

SettingDirection
Service Reporting

Service Measurement

Date: 5th Jan 2012

8.3

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

Appendix 3 ISO Management systems comparison

Page 52 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

Service management system ISO20000 compared to ISO/IEC 9001


& ISO/IEC 27001. (IRCA briefing note ISO IEC 20000-1 ENG.pdf)

Page 53 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

8.4 Appendix 4 - A Service Transition project plan - for


a blanket approach.
Note: This plan has been summarised from 9 pages by collapsing details
on processes after change management as they following similar
structures.
Task Name

Moog - Implementing Service Transition - Jimmy Hill Student No: R00092466

Project Proposal Phase


IT Management ITIL Service Transition Project Initiation Document Proposal Presentation
IT Management ITIL Service Transition Project Initiation Document Proposal Review
Business Management ITIL Service Transition Project Initiation Document Proposal Presenta
Business Management ITIL Service Transition Project Initiation Document Proposal Review
Business & IT Management sign-off / Sponsor confirmation
Project Planning & Preparation Phase
Define Project Mission
Draft Mission statement
Define the Project scope
Define whats in project scope
Define whats out of project scope
Define scope change management process
Plan Strategy for Organisational Change Management
Defining Project Roles and Responsibilities
Produce Project Organisation Chart
Project Manager
Define Role and Responsibility
Project Management administrator
Define Role and Responsibility
Consultant
Define Role and Responsibility
Service Transition Team Leader
Define Role and Responsibility
Service Operation Team Leader
Define Role and Responsibility
Other roles as process defined
Identify stakeholders and key influencers
Ensure their alignment with mission
Create strategy to manage expectations
Define Communications Strategy
Define Methods of communication (Email, newsletter etc)
Define Meeting schedules
Define Meeting Minutes & other document storage location and Access rights Matrix
Define a Risk Management Strategy
Create a risk management policy & procedure document
Create & maintain a Risk register
Define an Issue management strategy

Page 54 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

Create an issues log


Define the issue management policy
Project Kick-off Phase
Introduction to General IT
ITIL Presentation to IT Teams
ITIL Presentation to Business management
Introduce Consulting Team
Introduce the Mission Statement
Project Execution Phase
Training
ITIL Foundation Training for IT Team members
ITIL Service Transition Training for Implementation team members
Implementing Service Transition
Change Management
Review current change management process
Complete GAP analysis to ITIL change process
Document Processes for re-use
Schedule processes for retirement
Test & validate New Processes
Releases New Processes
Develop/Map Roles & Responsibilities to ITIL
Change Manager
Define the Role and Responsibilities
Change Administrator
Define the Role and Responsibilities
IT Functional Unit Manager
Define the Role and Responsibilities
Change Owner
Define the Role and Responsibilities
CAB & ECAB Members
Define the Procedures for CAB/ECAB member selection (Business, IT operational, IT
etc.
Development Activities
Create a Request for Change Template
Create instruction for template completion
Create a risk analysis process
Develop Standard Change Models
Define procedures for different Change types; Normal, Standard and Emergency
Create standard flow processes for change
Create procedures for change process

Page 55 of 59

Date: 5th Jan 2012

ITM4 Project Research


Student: Jimmy Hill
Implementing Service Transition in Moog ID #: R00092466

Define change management Role in Developing & maintaining Service portfolio; Servi
Retirement
Define change management Role in Developing Maintaining configuration Mgmt. Syst
ISIS;SCD; KEDB
Service Asset & Configuration Management - SACM
Knowledge Management
Release and Deployment management
Transition Planning and Support
Service Validation & Testing
Evaluation

9.0

Citations

Page 56 of 57

iAn Introductory Overview of ITIL V3 Written by: Alison Cartlidge Xansa Steria; Ashley Hanna
HP; Colin Rudd itEMS Ltd; Ivor Macfarlane IBM; John Windebank Sun; Stuart Rance HP and
Published by The UK Chapter of the itSMF. Website: http://www.itilofficialsite.com/AboutITIL/WhatisITIL.aspx.

ii Slide 5 CIT IT Service management Module Lecture 2 notes - Lecture 2 ITIL Service
Transition.pdf.

iii Page 3 - IRCA briefing note ISO IEC 20000-ENG.pdf (see reference material list.)(IRCA

- International Register of Certificated Auditors)

Вам также может понравиться