User manual | MBA thesis Final 06042016

How outsourcing affects ICT-Service Maturity
Tor Bergholm
Master’s Thesis
Degree Programme in
Information Systems Management
2016
Abstract
Päiväys
Date 06.04.2016
Author(s)
Tor Bergholm
Degree programme
Master’s Degree Programme in Information Systems Management
Report/thesis title
Number of pages
How outsourcing affects ICT-Service Maturity
and appendix pages
69 + 32
The objective of this thesis is to explore how outsourcing affects IT Service Maturity. The thesis
provides the answer by analysing the results of a series of IT Services Maturity Reviews performed at a large corporation during the first half year of 2014. The focus of the study is
to show in detail the answers of what scenarios was taken into account while building the
assessment survey. The author of the thesis works for Microsoft Finland as an IT Service Management and Program Management Consultant, specialising in IT Strategy and Process analysis.
The purpose of the Services Maturity Reviews was to do an assessment of the current IT
Services operational maturity or the large corporation, identifying areas which had suffered
from the recent changes like the outsourcing of major IT functions operational parts, restructuring of the IT services organisation and so forth, so to find the changes, in maturity, if any. While
the changes in maturity also could be issues and risks for further operations, the aim was also to
provide recommendations of what to improve and how. In addition, maturity reviews were
also used to help the customer define the future desired state of maturity.
Keywords
Outsourcing, ITIL, MOF, Enterprise Application Model, Infrastructure Optimization Model,
Change Management
Table of contents
1 Introduction .................................................................................................................... 1
1.1
Background of the thesis ........................................................................................... 1
1.2
Aim and purpose ...................................................................................................... 1
1.3
Research problem, question, and time-perspective ......................................................... 2
1.4
Scope of the Study .................................................................................................... 3
1.5
Structure of the thesis ............................................................................................... 3
1.6
Author’s role and contribution.................................................................................... 4
2 Theoretical framework ...................................................................................................... 5
2.1
Information Technology Infrastructure Library V3.0 revision 2011 by Axelos & Cabinet of
Commerce....................................................................................................................... 6
2.1.1
What is the Information Technology Infrastructure Library (ITIL)? ....................... 6
2.1.2
The Main Idea: The Service Lifecycle ................................................................ 6
2.1.3
The Strategy of aligning business with IT: ITIL Service Strategy. ........................... 7
2.1.4
The Delivery of good ITIL Service Management: Service Design........................... 7
2.1.5
The Delivery of good ITIL Service Management: Service Transition. ..................... 7
2.1.6
The Core of ITIL Service Management: Service Operation. .................................. 8
2.1.7
Service Operation: Event Management ............................................................. 9
2.1.8
Service Operation: Incident Management ........................................................ 10
2.1.9
Service Operation: Request Fulfillment ........................................................... 12
2.1.10 Service Operation: Problem Management ........................................................ 13
2.1.11 Service Operation: Access Management .......................................................... 15
2.1.12 Continual Service Improvement ..................................................................... 16
2.1.13 Continual Service Improvement, Total Quality Management and PDCA .............. 16
2.2
2.3
Microsoft Operations Framework version 4.0 by Microsoft ........................................... 18
2.2.1
What is MOF? ............................................................................................ 18
2.2.2
The IT Service Lifecycle ............................................................................... 18
2.2.3
The Plan Phase ........................................................................................... 21
2.2.4
The Deliver Phase ....................................................................................... 22
2.2.5
The Operate Phase ...................................................................................... 23
2.2.6
The Manage layer ........................................................................................ 24
The Core Infrastructure Optimization Capability Model (IOM) by Microsoft ................... 25
2.3.1
What is the Infrastructure Optimization Concept? ............................................ 25
2.3.2
Basic Infrastructure level maturity in the IO Model ........................................... 26
2.3.3
Standard Infrastructure level maturity in the IO Model ...................................... 27
2.3.4
Rationalized Infrastructure level maturity in the IO Model ................................. 28
2.3.5
Dynamic Infrastructure level maturity in the IO Model ...................................... 29
2.4 The Enterprise architecture Model ............................................................................ 30
2.4.1
2.5
What is the Enterprise architecture as strategy model? ....................................... 30
The Synthesis of frameworks and models in the study .................................................. 32
2.5.1
Why use so many tools and frameworks? ......................................................... 32
3 Research Methods mix .................................................................................................... 34
3.1
Sample width ......................................................................................................... 34
3.2
Research time-schedule ........................................................................................... 35
4 How to eat an elephant, or how to understand how a Corporation IT is doing? ........................ 36
4.1
The target Corporation of the Research ..................................................................... 36
4.2
Using Microsoft Operations Framework as the main framework .................................... 37
4.3
4.2.1
Best past, current, and desired maturity levels ................................................... 38
4.2.2
IO-Core maturity levels ................................................................................ 38
4.2.3
Commenting outside of the predefined question-answer units ............................. 39
4.2.4
The assessment questions theoretical basis ....................................................... 39
The Analysis of handling Services in The Plan Phase of IT Services ................................ 40
4.3.1
Strategy and IT............................................................................................ 41
4.3.2
Supporting Business with IT ......................................................................... 41
4.3.3
How does business know what services are available? ........................................ 42
4.3.4
How is capacity management of IT services currently done? ............................... 43
4.3.5
How should Disaster Recovery (DR) and Business Continuity (BC) be taken into
account in planning? ............................................................................................... 44
4.4
4.3.6
How well does the strategic planning plan security and IT service reliability? ......... 44
4.3.7
How are IT policies planned and used? ........................................................... 45
4.3.8
How is IT funded: Yearly, monthly, upon consumption? ................................... 45
The Analysis of handling Services in the Deliver Phase ................................................. 47
4.4.1
How well is the IT Services organization initiating projects? ............................... 48
4.4.2
How have the solution requirements been created? ........................................... 48
4.4.3
Is measuring, that planning before a project is started, sufficient? ........................ 49
4.4.4
What kind of operational requirements was taken into account in project planning? 49
4.4.5
What kind of testing is done and what about pilot testing?.................................. 50
4.4.6
What kind of a release process is used for changes when a service is mature? ......... 50
4.4.7
Is a process which includes a formal signoff utilized? ......................................... 50
4.4.8
How should the transition of new solutions from development to operations happen
in a mature organization? ......................................................................................... 51
4.5
The Analysis of handling the Services in the Operate Phase of Services ........................... 51
4.5.1
How is the service able to handle day-to-day operations?.................................... 52
4.5.2
Is information, like operation recommendations, provided by vendors, used? ........ 52
4.5.3
What is monitored in Operations? .................................................................. 53
4.5.4
How is monitoring tools utilized for monitoring SLA and OLA targets? ............... 53
4.5.5
How well defined is the Incident Management Process? ..................................... 54
4.5.6
How well have incident escalations been defined? ............................................. 54
4.5.7
How has knowledge management been done at Operations? .............................. 54
4.5.8
How is the staff trained to be able to do what is required from them? .................. 55
4.5.9
What does the Problem Management process for the services look like? ............... 55
4.5.10 How much was the service using defined Key Performance Indicators (KPIs) and
taking into account Critical Success Factors (CSFs)? ..................................................... 56
4.6
The analysis of the Manage Layer of Services .............................................................. 57
4.6.1
What kind of Change Management strategy was the Service using? ...................... 58
4.6.2
Was the Service making differences between how different kind of changes were
handled? ............................................................................................................... 58
4.6.3
What did services think about standard changes? .............................................. 59
4.6.4
What do the Services do with emergency changes? ............................................ 59
4.6.5
How much are the Services utilizing change and configuration management tools?. 59
4.6.6
How had Problem Management been defined and what was done? ...................... 60
4.6.7
Did the Service use the best practices by using Knowledge Management and the
Corporation Service Request Catalogue structure?........................................................ 60
4.6.8
Was the Service using the Corporation concept of best practices for Support? ....... 61
4.6.9
Was the Service using an Asset & Configuration Management Process? ................ 61
5 Summary ....................................................................................................................... 62
5.1
The questions ........................................................................................................ 62
5.2
The scaling ............................................................................................................ 63
5.2.1
The level 1 or the Silo-type maturity ............................................................... 63
5.2.2
The level 2 or Standardized technology maturity level. ....................................... 63
5.2.3
The level 3 or Optimization of solutions maturity level ...................................... 64
5.2.4
The level 4 or the Service Oriented Approach of maturity .................................. 64
5.2.5
What was missing ........................................................................................ 64
6 Discussion..................................................................................................................... 66
6.1
Future discussion above all grades: The Customer Centric Approach .............................. 66
6.2
Afterthought ......................................................................................................... 66
References ......................................................................................................................... 67
Appendix 1. Company internal result spreadsheet (Confidential) ................................................. 70
Appendix 2. Company internal report draft (confidential) .......................................................... 70
1
1.1
Introduction
Background of the thesis
In 2014 Microsoft Finland was contacted by a customer due to their problems in measuring
their current IT Services. The customer, the target organization in this MBA-study, is the IT
Services organisation of a multinational corporation. The corporation, which is a major player in its own market. had earlier, in year 2013, decided to organize a competitive tendering
where major parts of the ICT would be outsourced to a partner.
The Customer IT organization had already earlier done major outsourcing efforts, but this
time the emphasis was on gaining major savings. whereas earlier outsourcing had also had a
strong quality focus. The organization had at the point of contacting reached a point where
the tendering and changing the responsibilities of the operations of services to the outsourcing
partner was finalized. Now the challenges for the remaining in-house ICT organization was,
about regaining control of the ICT Services and, to be able to recognize how the services were
doing. As the target organization of the study already earlier had used an ITIL-based service
management type of ICT administration, a large part of the service managers had been kept as
in-house employees to assure continued services at the levels agreed with business in Operating Level Agreements. Service Level Agreements with vendors had been structured according
to ITIL recommendations as Orand and Villareal express (2011).
The challenge for the new organization was two folded: first to be able to re-organize the own
modus operandi to the new situation, and secondly, to know what the status of the outsourced
services was. As a result of this unclear situation, it was agreed with the author of this study,
that a series of maturity assessments should be organized.
1.2
Aim and purpose
The IT Services transition to outsourcing partners, during the years 2012 and 2013, including
proper planning of agreements with Key Performance Indicators and Critical Success Factors,
had not been implemented in the Corporation in an organised way. As a result, the maturity of
the IT Services was unclear. This MBA-study, conducted during the year 2014, evaluates the
maturity of those IT Services at that point. The objective for this study was to do research and
report how mature the IT services of the Corporation had been in the past, what was the current status, and to get building blocks to pinpoint which areas should be targeted as improvement areas, for setting strategic targets for the next foreseeable planning period. The objectives of the assessments which are the basis for this research, as agreed with the Corporate
1
customer, was to get a comprehensive sample and hence assessment of the situation of the
customers’ IT Services. The research would provide answers of the IT Services health in all
the phases of a service lifecycle according to the best practices view on Services according to
IT Infrastructure Library (ITIL) V.3.0 rev. 2011 and Microsoft Operations Framework ver.
4.0. (MOF). The scale of the maturity assessment would be adopted from the Microsoft Infrastructure Optimization (IO) Model, which in essence is based on the Enterprise Architecture
Strategy Maturity(EAM) Model from Sloan School of Management at Massachusetts Institute
of Technology (Ross et al. 2006). These frameworks divide the Services lifecycle into several
different areas: Management-Strategy, Planning-Design, Deployment-Transition, and Operations (MOF 4.0, ITIL 3.0). ITIL also separates one additional area to be structured: Continual
Service Improvement, whereas MOF handles this area as one part of the Management Layer.
(Microsoft Corporation. 2009. MOF – Cross Reference ITIL ® V3 and MOF 4.0. Seattle.).
IT Service Management as change in services is a constant. To simplify the target for IT to
exist, there are only two reasons, the flipsides of the same coin, namely producing added value, or producing savings. What is an IT Service then? According to the Information Technology Infrastructure Library version 3.0 (ITIL), “A means of delivering value to customers
by facilitating outcomes that customers want to achieve, without ownership of specific costs
or risks” (Orand and Villareal, 2011).
The IT services maturity research done at this customer was focused on analysing the status of
the IT services after the optimizing efforts executed by the corporation to decrease their IT
spending. The research raised the awareness of their current IT operational maturity, and at
the same identified possible issues and risks. The target was to provide some recommendations of what to improve and how. A research like this allows customers to define their desired state of IT Services maturity. This research aimed at helping the customer focus scarce
resources during a recession where they matter most. The aim of the study was to recognize
the most effective and efficient changes needed to the IT service management with none or
minimum amount of additional resources.
1.3
Research problem, question, and time-perspective
IT Service management as a process was something that had been done by the customer since
2005, when ITIL v. 2.0 was largely introduced to the customer IT. The continuous reorgani2
zations due to recession, but also due to the need of new solutions, has made the organization
unclear, and the maturity of the IT Services was not known, at least for the entity.
The effectiveness and efficiency of service management. in this study is measured by its ability to handle reactive non-planned activities as incident management, incident escalation management, problem management, change & configuration management, but also proactive processes for pre-emptive work.
The research questions were as follows:
Q1: How has service management been done at the customer in the past?
Q2: How is service management been done at the customer currently?
Q2: How should service management be done at the customer in the future?
Q4: How should the maturity of service management be measured in the aforementioned time
perspective?
1.4
Scope of the Study
The Customer IT handles 468 different IT Services which could be verified by business to be
active, and as such, trying to get a holistic view of the IT Services by interviewing all representatives for each IT service was not doable. To be able to get a representative view of the
entity, a select amount of 40 major Services was chosen to represent the majority. Of the 40
Services chosen 32 was able to participate in the set timeframe. Research of the customer corporation IT Service would not extend to the Customer business representatives (internal customers). The study would produce an internal report to IT of the maturity, and propose a
limited one-time solution, with improvement points. Actual changes were left for the customer to implement.
1.5
Structure of the thesis
The thesis is divided into six chapters. An overview of the chapters is summarized in this subchapter.
Chapter 1 presents the background of the study, the aim and purpose, and the scope of the
study and the research questions that the study aims to answer.
Chapter 2 present the theoretical frameworks for this study.
3
Chapter 3 focuses on research methods, the thinking for the choice of research methods,
ways of measurement, and description of the ways data was gathered.
Chapter 4 illustrates the empirical part of the study and analyses the results of each part of the
study.
Chapter 5 summarizes the findings of the study, offers the conclusions,
Chapter 6 provides some possible direction for development and afterthought.
1.6
Author’s role and contribution
The author is a full time employee of Microsoft, working in the area of IT Service Management assessments of customer IT-related processes and strategies. In the case of this thesis
the author that was asked by the customer corporation representative to do the aforementioned research of the customer IT maturity. To satisfy the customer needs, the author created the model how to use methodologies developed by Microsoft to be able to analyse the situation, agreed the scope with the customer, held the planning workshops, created a SharePoint
site together with a SharePoint-expert to be able to do offsite-evaluations, did a series of interviews with Service Manager representatives for the Services, and finally analysed and reported the results of the assessment to the customer. This study was not part of the project,
but was agreed to happen and to be delivered to be read and accepted by the customer.
4
2
Theoretical framework
To do the research successfully in the allotted timeframe and in the width according to
customer wishes, a fundamental understanding of the following frameworks was necessary to
implement at the IT organization. This required some basic introductions to customer
representatives to be performed to have the same initial level for evaluation. The following IT
Service Management Frameworks and models were used to do the analysis of the customer
situation:
Microsoft Operations Framework version 4.0(MOF).
ITIL version 3. revision 2011
Infrastructure Optimization Model (IOM).
Deming’s Plan-Do-Check-Act management cycle
Enterprise Architecture Model
The synthesis of the frameworks in this study
The ADKAR model, developed by the ProSci Learning Center, and the SECI model developed by Nonaka & Takeuchi are mentioned in the summary. These models could have been
used in further studies, but were not used during this research, and hence are not further explained in the study methodology chapter.
5
2.1
Information Technology Infrastructure Library V3.0 revision 2011 by Axelos &
Cabinet of Commerce
2.1.1
What is the Information Technology Infrastructure Library (ITIL)?
The Information Technology Infrastructure Library (ITIL) offers a governing approach to the
delivery of quality IT services. In this study ITIL is comprehensively used as a reference
framework, and due to that the main parts of the framework need to be explained.
ITIL was created in the 1980's by the UK governments CCTA (Central Computer and
Telecommunications Agency) with the objective of ensuring better use of IT services and
resources. (http://itsm.fwtk.org/History.htm 2015) The current name for the administering
party is now the Cabinet Office, part of HM Government. For a period of time it was
referred to as Office of Government Commerce (OGC). Since 2013 Axelos, a join operation
between HM Cabinet Office, and a private Company called Capita Plc. ITIL has been the de
facto standard for the IT industry in Service Management, and has provided good practices as
a framework.
As the introduction to the ITIL by Cabinet Office (Cabinet Office 2011) expresses, ITIL is
the most widely recognized framework for ITSM in the world. In the now already 25 years
since it was created, ITIL has evolved and changed its breadth and depth as technologies and
business practices have developed. ISO/IEC 20000 provides a formal and universal standard
for organizations seeking to have their service management capabilities audited and certified.
While ISO/IEC 20000 is a standard to be achieved and maintained, ITIL offers a body of
knowledge useful for achieving the standard (Cabinet Office 2011).
2.1.2
The Main Idea: The Service Lifecycle
ITIL Version 3 (2011) is a minor upgrade to the version 2007, and approaches IT service
management from the lifecycle perspective of a service. The older version 2.0 of ITIL did only
cover practices for the Operations phase. The IT Service lifecycle organization model (Figure
1) that ITIL 3.0 brings, provides structured thinking in how IT service management can be
managed, the way the various lifecycle components can be linked to each other, and hence, a
way grab the structure of the entire lifecycle system.
6
The ITIL Service lifecycle consists of five areas. The five volumes of the ITIL V3 core books
describe these five components:

Service Strategy

Service Design

Service Transition

Service Operation

Continual Service Improvement
As ITIL is a large framework, not all, but only the parts interesting for this study will be presented
2.1.3
The Strategy of aligning business with IT: ITIL Service Strategy.
ITIL expresses that the service strategy stage purpose of the service lifecycle is to define the
perspective, position, plans and patterns that a service provider, should it then be an internal
service provider or an external service provider, needs to be able to execute to meet an organization’s business outcomes (ITIL Service Strategy 2011, p.17).
For the purpose of this study, measuring Service Strategy implementation is crucial for understanding the maturity of the services.
2.1.4
The Delivery of good ITIL Service Management: Service Design.
ITIL expresses the primary purpose of the service design stage of the service lifecycle to be
taking care of that service solutions are designed to meet the current and future needs of the
business. Requirement handling in its all phases: from identification, to detailed description to
agreement with customer of priorities are fundamental to the production of good service solution designs (ITIL Service Design 2011, p.10).
2.1.5
The Delivery of good ITIL Service Management: Service Transition.
One can express, that the most common thing for IT to happen, is change. The Service Transition stage of the service lifecycle aims at ensuring that any modifications or transitions to the
live operational environment – is it then a new service, a modification to a service, a retiring
service or retired services – do not at least intentionally harm business, and do meet the agreed
7
expectations of the business, customers and users. For this to happen, all modifications to
operational environments should be managed, planned and coordinated through service transition processes. With the transition steps and processes recommended in the Service Transition, IT is facilitating the smooth transitions of changes to live operation (ITIL, Service Transition, 2011, p.10).
2.1.6
The Core of ITIL Service Management: Service Operation.
As expressed earlier ITIL V 3.0(2011 edition) is an upgrade to an earlier ITIL Framework.
The core part of the new ITIL is in the Service Operation part, which was constructed already
in the version 2.0 of ITIL. Service Operation is according to ITIL Service Operation phase
the critical stage of the service lifecycle. It is the stage of the lifecycle where the service really
starts to deliver benefit and value to the business, customers and users. (ITIL Service Operation, 2011, p.10). Within Service Operation are the processes to ensure that the added-value
can be provided effectively, and efficiently (Orand and Villareal, 2011)..
The most important processes in ITIL Service Operation are:
Event Management
Incident Management
Request Fulfillment
Problem Management
Access Management
Basically these processes are the de-facto standard to Service Desks, globally. However, how
the quality of services is measured, varies largely in Service Desks due to the varieties and challenges of Service Management as defined in Service Integration and Management (SIAM,
2015).
8
Figure 1: ITIL version 3.0, 2011 Enhanced.
2.1.7
Service Operation: Event Management
The Event Management purpose according to ITIL can be defined to be a process where
events are detected, the events are analyzed and made sense of, and deciding what control
should be provided or what the appropriate control action is (Orand and Villareal2011, p.229).
Event Management is according to ITIL the basis for Operational Management. Controls
defined in Event Management are used for automating Operations Management activities.
Some key Concepts work as a basis for Operations Management. Conceptualizing an event
ITIL describes an event as a change of state which has significance for the management of a
Configuration Item or IT Service. The event in this concept is related to the service, and
should be significant to the service, but it may be of no importance to us. (Ibid, 2011:229).
When the Event Management identifies an event, it should notify appropriate resources,
though some means, typically through alerts. The alert is defined as a warning that a something has changed, it might be a pre-defined threshold, that has been reached, or a failure of
Service component has occurred
9
2.1.8
Service Operation: Incident Management
According to ITIL the purpose of the Incident Management process restores normal service
operation as quickly as possible and minimizes the adverse impact on business operations,
thus ensuring that the best possible levels of service quality and availability are maintained.
Incident Management should not focus on fixing the underlying problem. Instead, Incident
Management should restore service as quickly as possible. This rapid restoration of service can
be done by the use of workarounds and other solutions like fast boot etc. The aim for Incident Management is to minimize the negative impact to business and maintain customer and
user satisfaction according to agreed standards. Incident Management is guided by the Service
Level Agreements (SLA), and due to that SLAs are of interest for any research of Service Operations (ITIL – Service Operation 2011, p.73).
According to Orand and Villareal (2011) the SLAs are the written statements that document
the expected levels of service for response targets for Incident Management. SLAs are also
beneficial in that they express the priorities and relative value of different Incidents. In an organization defined according to ITIL, the Service Desk should initiate the Incident Management process based on calls, emails or other contacts made. In scenarios where the incidents
can be resolved by the Service Desk, the Service Desk handles the entire Incident Management Process of the incident from recording to closure. In scenarios where incidents are beyond the technical ability of the Service Desk or that are multifaceted or complex, other resources are utilized, typically by an escalation. The Service Desk, is by using the Incident Management Process according to specification, helping to ensure that correct resources are utilized only when needed. by using specialized staff only for the incidents that cannot be resolved by the Service Desk. (Orand and Villareal 2011, p. 235)
The Incident Management process should record every incident that occurs for the environment which Service Desk is responsible for. Tracking the incidents should be done to ensure
that no incident is lost, forgotten, or ignored. The incidents should also be managed to see
that they are handled according to the Service Level Agreements. (Orand and Villareal 2011,
p.235)
Incident Management is one of the most visible processes to the business and due to that
business values the Incident Management process. Incident Management creates or restores
value to business through the ability to detect and resolve incidents. It is done according to
SLAs results in reduced downtime to the business which, in turn, means higher availability of
the service. The key to maintained business value is the proper prioritization of incidents that
can provide understanding to Service Desk and alignment between IT and real-time business
10
priorities. This requires that the Incident Management process has been built including the
knowledge about the business processes and any changes to those processes. This information should be included in the Service Level Agreements.
The ability to identify potential improvements to services. This happens as a result of understanding what constitutes an incident and also from being in contact with the activities of
business operational staff.
An incident can basically be reported from any source – by users, technicians, administrators
monitoring tools and so forth. An incident is always handled regardless of the source, as an
incident: an incident is an incident. The channel for the incoming incident or the role of the
one reporting something to the Service Desk does not make it a problem, but an incident.
As a part of the Incident Management there is a need to define Key Performance Indicators
(KPIs). By focusing on specific targets, KPIs for Incident Management aim at improving the
Incident Management process to ensure that incidents are resolved in the best interest for the
Business.
The most typical KPIs measured according to Orand and Villareal (2011) are:

Total number of incidents

Breakdown of incidents at each stage of the lifecycle

Size of current incident backlog

Number and percentage of major incidents

Mean elapsed time to resolve

Percentage of incidents handled within agreed response times

Average cost per incident

Number and percentage of incidents reopened

Number and percentage of incidents incorrectly assigned

Number and percentage of incidents incorrectly categorized

Percentage of incidents closed by the Service Desk without referring to other groups

Number and percentage of incidents processed per Service Desk agent

Number and percentage of incidents resolved remotely without requiring a visit

Number of incidents handled by each incident model

Breakdown of incidents by time of day to help pinpoint peaks and ensure matching of
resources
11
(Orand and Villareal 2011, p. 241)
2.1.9
Service Operation: Request Fulfillment
According to ITIL, the term ‘service request’ is used as a generic description for many different types of demands that are placed upon the IT organization by the users. Many of these are
typically requests from a user for information or advice or for a Standard Change or access to
an IT service. Requests are typically for small changes that are low risk, frequently performed,
low cost etc. (e.g. a request to change a password, a request to install an additional software
application onto a particular workstation, a request to relocate some items of desktop equipment) or may be just a request for information (ITIL Service Operations 2011, p.99).
The Service requests typically occur on a regular basis, such as adding software to a computer,
requesting toner for a printer, or requesting a cell phone or pager, along with many other types
of requests. Most Service Requests are based on services that are documented in the Service
Catalog. (Orand and Villareal2011, p.245)
Typically, the objectives of the Request Fulfillment Process (Figure 2) are about providing a
channel for users to request and receive standard services. Standard Services in this context
are services for which a predefined approval and qualification process exists.
Shortly put, the purpose of Request Fulfillment is to handle requests from users. The requests
might at this point be about what say not. The Request Process is responsible to verify what
kind of request type is in question. Often standardization as a part of the request process
means that many, if not all, service requests are initiated according to the presence of a product or service published in a Service Catalog. The Request Process typically does state which
team should provide the service requested, but services can be supplied by an internal support
team, or, and often are, supplied through external support teams. The model to use a Request
Process is established to automate responses to commonly occurring requests. The process,
once recognized to be needed to fulfil a request, might vary depending upon exactly what is
being requested, but can usually be broken down into a set of activities that have to be performed (ITIL Service Operation 2011, p.87)
12
Figure 2: Request Fulfillment Process.
2.1.10 Service Operation: Problem Management
According to Orand a problem in ITIL is defined as the unknown cause of one or more incidents. Problems, again once diagnosed and the root cause is found, result in the Problem
Management process (Figure 3) enforcing the documentation of a Known Error. A Known
Error is defined as a fault in the infrastructure for which a permanent solution or temporary
workaround has been found (Orand and Villareal 2011, p.250).
ITIL states that the purpose of problem management is to manage the lifecycle of problems.
According to ITIL problems should be handled in an organized way from the first identification of a problem existing, through further investigation, documentation of the problems and
13
in the end handling the solving of the problem. Problem management handles underlying
errors in a managed way and seeks to minimize the adverse impact of incidents and problems
on the business. Problem management also strives to proactively prevent recurrence of incidents related to these errors. In Problem Management the Problem Manager seeks to find the
root cause of incidents, documenting the behavior, and communicating the then known errors. In the end Problem Management aims at initiating actions to improve or correct the
problems found (ITIL Service Operation 2011, p. 97).
According to Orand &Villarreal the value for Business in Problem Management comes from
the reduction of Known Errors (KE) in the Service Environment, and thus prevents problems from happening before they occur, resulting in improved resource availability and fewer
incidents. Through this reduction in Known Errors, IT services can establish higher availability, increase productivity for users of IT, and gain reductions in the costs of Incident Management by reducing the amount of incidents due to problems (ITIL Service Operation 2011,
p.98).
14
Figure 3: Problem Management Process.
2.1.11 Service Operation: Access Management
The Access Management (AM) is one of the processes related to security. Access Management
is a wide Service Management area that according to Orand and Villareal (2011) has overall
responsibility for maintaining the access of services through ensuring that access is granted to
only the people who require access for legitimate reasons. The decision who is granted access
is not done in the Access Management process, but instead operates according to the policies
developed for access. Access policies are according to ITIL developed during the Service Design stage of the service lifecycle (Orand and Villareal 2011, p.127). In Service Design the emphasis is on security management and availability. When these processes are defined and executed one can determine what kind of access should be provided and to whom it should be
provided. Simply put, the purpose of Access Management is to provide access for services
that users are entitled to while preventing access to users that are not entitled. From a business
15
perspective, Access Management is regulating the access to confidential information to the
appropriate persons. Another important aspect is the regulatory requirements, like the Payment Card Industry standard (PCI), which might be audited for compliance, and if security
has been breached, might mean serious repercussions to business.
2.1.12 Continual Service Improvement
A core question for Services reliability is the amount of work which is used to do Continual
Service Improvement. How well does IT understand what reliability is, how is it measured,
and does IT aim at doing Continual Service improvement? ITIL has seen Continual Service
Improvement (CSI) so crucial for maintaining IT Services health, that ITIL ver. 3.0 has a separate book handling everything what comes to CSI. According to ITIL, Continual Service
Improvement must penetrate and become woven into every stage of the service lifecycle and
into every process, function, activity, tool, supplier and member of staff (ITIL Continual Service Improvement 2011:10).
ITIL lists functions that are needed to maintain or update IT services according to specifications. The functions include monitoring, measurement, analysis and reporting. At the same
time ITIL recommends actions to ensure processes also are under CSI. According to ITIL the
CSI should even ensure that the overall IT strategy itself is updated continuously. At the same
time ITIL now pinpoints that the Personnel and its knowledge, skills, qualifications and experience equally should be updated and maintained (ITIL Continual Service Improvement 2011,
p.10)
2.1.13 Continual Service Improvement, Total Quality Management and PDCA
Both MOF and ITIL in their current versions recognize continual improvement as an underlying paradigm. According to MOF, at the highest level, both lifecycles are illustrations of the
Plan-Do-Check (PDCA) concept. The PDCA can easily be recognized in the structures of
these lifecycles. (MOF, Cross Reference 2008, p.31)
According to ITIL Service improvements are governed by the improvement lifecycle, which is
modelled on the PDCA cycle. The PDCA model establishes a clear pattern for continual improvement efforts. (ITIL Continual Service Improvement 2011, p.78)
16
The PDCA-model (plan-do-check-act, sometimes seen as plan-do-check-adjust) is a repetitive
four-stage model for improving the quality of repetitive functions. PDCA-model is the core
of the Continual Service improvement (CSI) strategy in ITIL version 3.0 lifecycle thinking and
also more generally modern business process management. The PDCA model is also known
as the Deming circle/cycle/wheel. Other popular names for this model is Shewhart cycle,
control circle/cycle, or plan–do–study–act (PDSA). (What is PDCA 2016)
PDCA, as an old concept, was brought to larger public attention by Dr. W. Edwards Deming,
a management consultant, who also is often considered the father of modern quality control.
Deming's work is seen forming the basis for Total Quality Management (TQM) and ISO 9001
quality standards. Deming himself did not credit himself as the creator of the PDCA cycle, but
expressed Walter Andrew Shewhart as the creator. Shewhart who is not as largely known as
Deming, was a physicist, engineer and statistician who however is often considered the father
of statistical quality control. (What is PDCA 2016)
The PDCA-model is divided into the four sequential categories as a lifecycle: plan, do, check,
and act.

Plan: The phase where one defines the problem to be addressed, collect problem
data, and verify the problem's root cause.

Do: The phase when the solution is developed and implemented; the appropriate
methods of measurement to explore the solutions effectiveness are also decided at
this phase.

Check: Verify that the results strived for have been achieved by comparison of before-and-after data.

Act: The phase where documentation of the solution results is done. Process
changes are informed to stakeholders and the initiation of the next PDCA cycle is
started by giving recommendations for the remaining found problems to be addressed.
17
2.2
2.2.1
Microsoft Operations Framework version 4.0 by Microsoft
What is MOF?
Microsoft released the first version of Microsoft Operation Framework (MOF) in 1999. In
this study MOF together with ITIL is used as a reference framework, and due to that the main
parts of the framework need to be explained in the same way ITIL has been described.
Microsoft Operations Framework is an attempt, to with a structured approach, give IT
professionals knowledge and processes of good practices, and help its customers achieve
operational maturity through the entire IT service lifecycle.
The Microsoft Operations Framework is a framework based on development work to align a
practical operations framework or the how to do things, in a compliant manner with the
methods listed by the developers of the Information Technology Infrastructure Library (ITIL
v 3.0). Where ITIL is a framework of explaining good or best practise, so is MOF. Both
concentrate on good practice, rather than process as such. The main difference could be
epxressed as that where ITIL focuses more on the “what” or descriptive ways to express good
practises, MOF aims at giving more answers to the “how” or a prescriptive way to implement
good practises.
Microsoft Operations Framework (MOF) is a collection of good practices, principles, and
concrete activities. In the MOF (Figure 4) the developers have developed practical guidelines
for services and solutions to achieve consistent reliable entities. MOF is using an approach
of leading the discussion with question-based guidance that allows the organization
implementing MOF to find actual improvement activities, to increase maturity and do
continual service improvement. With this approach Microsoft provides organizations a way
to better their services reliability through the service lifecycle to assure that activities that will
keep the IT organization in function are done efficiently and effectively for the future.
2.2.2
The IT Service Lifecycle
As is the thought of Service lifecycle in the ITIL Framework, it is also the thought of the
lifecycle structured in MOF. The thought construct of a IT service lifecycle describes the
complete lifespan of an IT service. MOF uses a waterfall project model approach, advancing
in phases from planning the IT service to aligning it with the business strategy. Then by the
design, and delivery of the IT service, MOF assumes the advancement to create a draft service
which should reflect customer requirements. While transferring it into ongoing operation
one should according to MOF make final reviews and, hence, make the support organization
18
able to support it, delivering it to the user community. The major foundation of this model
lies upon strict IT governance, including risk management, compliance, change management
and other Service Management Functions (SMF) done in the Management layer.
The IT service lifecycle of MOF is comprising of three ongoing phases, Plan, Deliver, Operate
and one foundational Manager layer that operates throughout all of the other phases:

Plan phase: planning and optimization of an IT service, including operational strategy in
order to support business goals and objectives.

Deliver phase: ensure that IT the services are developed effectively, deployed successfully
by reviewing results, and are ready for Operations.

Operate phase: ensuring operational, maintainable, and supportable IT services, in a way
that meets business needs and expectations.

Manage layer: the construct which is present in all phases of the IT service lifecycle. The
Manager layer is comprising of IT governance, risk, compliance, roles and responsibilities,
change management, and configuration. Reviews of Continual Service Improvement is also a responsibility listed in the Manage layer. Processes in this layer must be applied to all
phases of the lifecycle.
According to MOF, the activities and processes are organized into Service Management
Functions (SMFs). The material in the Microsoft Operations Framework includes all the
major activities and processes involved in managing an IT service during its lifecycle. The
major phases are divided into conception of the service, development of the service, operation
of the service, maintenance, and also retirement. For all these major activities and processes
MOF recognizes different Service Management Functions (SMFs). The SMFs are grouped
together in phases that are following the IT Service lifecycle phases. The SMF: s in the
lifecycle phases are providing a view through goals and outcomes supporting the objectives of
that phase.
Readiness of each IT service to move from one phase to the next phase is assessed by
management reviews, where a review is done that goals are achieved and that goals of IT are
aligned with the goals of the customer organization (MOF overview 2008, p.12).
19
Figure 4: MOF.
20
2.2.3
The Plan Phase
The Plan Phase (Figure 5), is where business and IT do the biggest joint effort in determining
how IT should be focused to deliver the value add services that enable the business to
succeed.
Why would business be interested in using IT? What is IT needed for? All businesses, might
it then be companies, public organizations or other forms organized operations, there is
always a value in the efforts done in that area. To be interesting for these efforts that also
could be called functions, IT must be able to provide means to provide addition to that value.
In services that means being able to the right things when needed which is the same as
reliability, doing it according to the rules and practices of the society doing things in a
Compliant manner. Naturally cost-effectiveness is a major driver: there must be a value add
and benefits from the resources used to provide the Service. To not become obsolete IT
must also be able to adapt to the ever- changing needs of the business (MOF Plan overview
2011, p. 5).
Doing that requires:

Strategy and requirements understanding

Understanding how well the current IT services support the business.

Understanding what reliability is, but also what value it may be to this organization

Understanding the policies and requirements derived from the IT strategy.

Providing the prioritization structure and a IT Service Portfolio to be able to do the right
things in IT and drive the right planning decisions.

Creating and maintaining an IT strategy aligning it with the business strategy.
According to MOF, the IT strategy is the plan that aligns the organization’s objectives,
policies, and procedures into an overarching approach to deliver the desired set of services
that support the business strategy.
Good enough quality, cost efficiency, and reliability for the functions needed the most,
should be balanced in order to achieve the business and overall organization’s desired outcomes. The IT strategy is the result of the work done in the Plan phase. The IT strategy
should also according to MOF continually evolve and improve as business refocus and
21
practice its optimizing skills and ability to adapt to business changes (MOF Plan overview
2011, p.5).
Figure 5: Plan Phase.
2.2.4
The Deliver Phase
The Deliver Phase is the part of the service lifecycle where the service projects or infrastructure projects are functionally planned, designed according to requirements, built by developers, and deployed together with Operations. The Deliver Phase is also the part of the lifecycle
process through which any change must go, large or small. The degree of change priority,
change process and methodology will depend on the nature and size of the change. Often,
22
also, changes which are known and tested i.e. standard changes will be moved directly through
the Deliver Process without separate handling in the Change Advisory Board. Other typical
types with more emphasis in the deliver phase are minor, significant, or major change (MOF
Deliver Overview 2011, p.5).
2.2.5
The Operate Phase
The Operate Phase (Figure 6), is the part of the service lifecycle where Business should get
its return on investment. and it represents the culmination of the work done in planning
and delivery phases that precede it. The Operate Phase shortly put focuses on how to
handle the service after the services are in place and operational (MOF Operate Overview
2011, p.5).
Microsoft Operations Framework has published separate practice overviews called Service
Managment Functions(SMFs) per phase. For the Operate Phase MOF contains the
following SMFs: Operations SMF, Service Monitoring and Control SMF, Customer Service
SMF, and Problem Management SMF. From the Study perspective this phase is essential,
including handling of service requests and incident management in the Customer Service
SMF. and Problem Management SMFh, which is self expalanatory named.
Figure 6: The Operate Phase.
23
2.2.6
The Manage layer
The Manage layer (Figure 7), is the part of the service lifecycle where Business and IT is
focused on setting the management in place for the service, using controls, processes, and
activities (MOF Manage overview 2011, p.5). As the meaning for IT is added value or savings
i.e. additional business value, the better managed layer is handled, the lesser the risk, the
clearer the accountabilities are and better value business gets.
Figure 7: The Manage Layer.
24
2.3
2.3.1
The Core Infrastructure Optimization Capability Model (IOM) by Microsoft
What is the Infrastructure Optimization Concept?
The Microsoft Infrastructure Optimization (IO) Concept was developed by Jeanne Ross and
Patrick Weill to Microsoft, based upon the Enterprise Architecture as Strategy Model developed at the Center for Information Systems Research at MIT Sloan, Massachusetts Institute
of Technology. The Infrastructure Optimization Concept is structured around three information technology models: Core Infrastructure Optimization, Application Platform Infrastructure Optimization, and Business Productivity Infrastructure Optimization.
The process
maturity in the IO models contains four levels, and also capability classifications as groupings
of requirements for each level of maturity. The different areas of the IO concept are divided
into
1. Core IO, which focuses on the foundational elements of IT services and components,
2. Application Platform IO, which focuses on good practices for software development
3. Business Productivity IO, which focuses on the infrastructure requirements.
(Technet.microsoft.com, 2015)
Core Infrastructure Optimization Capability Model
In Figure 8 the requirements for different maturity levels according to the Core IO are presented related to capability in the different optimization levels.
25
Figure 8: Core IO Model.
2.3.2
Basic Infrastructure level maturity in the IO Model
The basic infrastructure (IT) and platform is typically characterized by work done in silos.
From a work perspective this is the lonely guy sitting in the corner behind the wall of computing books. Work tasks are performed manually instead of using automatic scripts for monitoring and other tasks. Processes, if they have been discovered, are performed in a local
mode, and the central control is minimal or non-existent. One typical signal of lacking maturity is also the poor governance of licenses and overlapping applications, where different departments may have competing applications to perform the same task. Each department
26
claim to have so special needs that standardization is not possible. Data, developed with the
applications, can be found on personal drives and personal shares, but poorly in centralized
shared storage. The need for sharing storage has typically been recognized, but the means to
solve the need have not been put in place on a general level. A weak Service Management
Maturity typically also shows as weak enforcement strategies for standardization, which is the
next level of maturity (Technet.microsoft.com, 2015).
2.3.3
Standard Infrastructure level maturity in the IO Model
Being able to move to the standardized level of maturity from the silos clearly benefits the ITorganizations, and their customers. Costs can be substantially reduced by using standardized
ways of working, standard processes, and controlling the entity, instead of working each and
everybody separately. Overlapping processes, applications, workstation and server purchases
and can be diminished, and a centralized management can be introduced. Typically, this also
means that directory services, like Microsoft Active Directory are taken into use, so that the
users can get access to right resources, like network segments and Common Server-based applications, and other shared resources.
IT-organizations that have been able to reach the standardized state, normally have realized
the value of standardization, and have implemented some policies. At this point however,
there is still not a proactive way of handling the patches, hardware and software assets, but
most cases are handled only when something occur i.e. reactively.
The afore mentioned reactive handling still means that there already is an inventory of hardware and software, desktop services have been standardized and license management has been
understood to be needed. There also already is a basic security process implemented at least
for perimeters, but internal security issues have not necessarily been understood. Hence, there
are savings that have been achieved by the measures typically done in the standardization
state, but mostly with mediocre savings, due to large amount of manual labor and manual
methods. Content is typically exposed to users through basic search capabilities in consolidated storage solutions, with content retention build in (Technet.microsoft.com, 2015).
27
2.3.4
Rationalized Infrastructure level maturity in the IO Model
At the standardized state the Customers of the IT organization typically become cost aware,
which leads to attempts to do rationalization. While it might be that this is just a natural development of understanding, often it is a sign of poorly done cost control of the standardization. Searching for cost benefit the IT organizations start looking for means of optimization
and rationalization. By proactive policies and processes, typical for optimization, that express
the most common usage scenarios with a scale from opportunity to business case to end of
lifecycle to eventual catastrophe and disaster recovery, the IT organization, if it succeeds, can
show it is a recognized counterpart to business, and it can produce services as intended.
When the optimization of the infrastructure and platform is actively handled, costs of managing desktops and servers are typically at their lowest. Processes and policies have also matured
enough to begin playing a large role in supporting and expanding the business, and business
has started to rely on IT as a crucial part of business.
Additionally, security is handled in a holistic way, with an ability to respond to threats, and a
proactive approach, where updates, and patches to environments are done in a well-controlled
manner.
As Ross, Weill, and Robertson (2006) expresses, automation plays a pivotal role in optimization, and manual deployments are avoided as much as possible. With this approach to deployments, the IT organization minimizes costs, the time from ready to deploy, and technical
challenges due to human mistakes.
Organizations that are in a rationalized level of Service Management maturity have a clear inventory of hardware and software, mostly as a Configuration Management Database (CMDB),
and are able to maintain a license database to only purchase licenses at real need. Information
stored in the IT Storage, as documents, data records etc. are seen as part of the Corporate IP,
and as such strategic explicit enablers for the business. Due to the importance, the information is handled in ways that ensure easy access, retention, accurate privacy, and search ability. In the rationalized level investments are normally based on business process thinking enabling line-of-business applications. These investments are also often integrated with business
productivity infrastructure investments, and IT has defined processes and procedures for the
holistic view on information to provision search integration. With these new Business Case
aware- Information integration aware line-of-business applications. Customers can get the
28
benefits from this rationalized state, and even aim at working at a dynamic state (Technet.microsoft.com, 2015).
2.3.5
Dynamic Infrastructure level maturity in the IO Model
In a well measured IT organization, the well-defined scorecard tools enable active business
case evaluation. With a continuous business case awareness, the benefits of implementing
new or alternative technologies can be evaluated. This level of awareness helps is taking on
such business challenges or opportunities that otherwise without proper information could be
deemed as risks where benefits are bigger than the incremental cost.
IT organizations who have been able to achieve a dynamic infrastructure and platform are
fully aware of the strategic business value their infrastructure provides.
The value realization can be measured in business cases and can be seen in the customers of
the IT organization being able to run their business efficiently and staying ahead of competitors. The Rationalization level is also recognized by that costs can be fully controlled. With
integration between users, applications and data, desktops, networks and servers, Cooperation and productivity is increased. Collaboration tools are common and pervasive
communication tools are enabling the users to work almost regardless of time and space.
Automation tools that are integrated with the larger environment enable business process
management.
IT uses technology to automate processes, and the target is to align IT, as much as possible
with business, and manage IT leveraging what business needs. The business case is taken into
account when investing in new technology, but only after a re-evaluation of the processes to
be automated. All new investments are measured against the business case to be able to provide measurable benefits. For the customers using dynamic infrastructure, a new level of flexibility can be reached, bringing easily exploitable high maturity services, thus enabling competitive and comparative advantage. The modularity and scalability enables the business flexibility which supports business expansion and scaling business risks. To be able to provide
dynamin infrastructure, all critical services which are to be dynamic, should be well steered
including service level agreements and recurring operational reviews. This level of IT maturity
is not easy to reach, and is often not even aimed to be reached (Technet.microsoft.com, 2015).
29
2.4 The Enterprise architecture Model
2.4.1
What is the Enterprise architecture as strategy model?
The Enterprise Architecture Model (EAM) was developed by Jeanne Ross, Patrick Weill, and
David C. Robertson at the Center for Information Systems Research (CISR) at MIT Sloan,
Massachusetts Institute of Technology. The model was published in 2006 in the book ‘Enterprise Architecture as Strategy, creating a business for business execution’, and has been used
as a basis for the IO Core model. The Enterprise Architecture model (Figure 9) was the result
of 200 studies of enterprise architecture in different companies (Ross, Weill, and Robertson
2006, p.IX). Additionally, ‘The Enterprise Architecture as strategy foundation’-concept, which
is presented in the book, is based on earlier surveys done to more than 100 U.S. and European
companies.
The key findings of the studies and surveys revealed that those companies (1/3 of all companies studied), who at the time of the study had digitized their core processes, had higher profitability, could do faster time to market efforts, and still had 25 % lower IT costs. (Ross, Weill,
and Robertson 2006, p. 1) As these results were remarkable, the material was used as a basis
for research to create a model which could explain the success of these successful companies.
The differentiators were found to be on a high level, namely the companies’ ability to create
an architectural view IT, and of how to perform operations, and hence the Enterprise architecture model was born. While this study is not directly based upon the EAM, but on the
derivate model, namely IOM used by Microsoft, the maturity stages of the EAM model are
not explained here, but the study references to the IOM, and the IOM is explained in detail.
The core thought, the grading and the structure of the EAM and the IOM are still the same.
The core idea of the EAM is that Enterprise Architecture should be the organizing logic for
business process and IT infrastructure capabilities. This logic should directly reflect the integration and standardization requirements of the firm’s operating model. This naturally means
that the operating model should also be understood. By being able to mature the IT environment handling structure, the EAM should be able to provide clear benefits (Figure 10).
30
Figure 9: Enterprise Architecture Model.
31
Figure 10: EAM Benefits.
2.5
2.5.1
The Synthesis of frameworks and models in the study
Why use so many tools and frameworks?
The agreed scope of the assessment and this study was to analyze the maturity of the IT services. IT services typically are matured by implementing ITIL good practices. ITIL does not
offer readymade assessment models, but suggests the use of either Capability Maturity Model
Integration (CMMI), Control Objectives of IT (COBIT) or ISO/ IEC 20 000. (ITIL Continual Service Improvement 2011, p.75). According to ITIL, a well-designed maturity assessment
framework should evaluate the all aspects of the process environment including the people,
process and technology. The framework should also evaluate factors affecting overall process
effectiveness within and close to the business – grade culture of acceptance, and be able assess existing processes, strategies and vision. Additionally, the assessment framework should
be able to assess the process organization, process governance, business/IT alignment, process reporting/metrics and decision-making. (ITIL Continual Service Improvement 2011,
p.75).
32
ITIL as a descriptive type of framework was not enough to be able to analyze the maturity of
the customer services without starting to build an assessment model from scratch, Microsoft
Operations Framework (MOF) as a more prescriptive operations framework was offering
example scenarios which could be used in the grading of the maturity. Microsoft (MS) could
offer an assessment model-template based upon MOF scenarios, and while MOF is ITIL ver.
3.0 2011 edition compliant, the customer agreed to use the MS template and working methods
from the MS maturity review as a base for developing a customized questionnaire. However,
MOF did not offer a scale for maturity as did not ITIL, but the template developed by MS
had solved this bringing in another dimension, by using the Core Infrastructure Optimization
Model (IOM). The IOM offers a measurement scale for maturity of Services, ranging from 1
to 4. This scale was better suited to be used instead of the ITIL suggested CMMI, which
would have measured repetitive actions variances, whereas IOM measures the service maturity.
The target in using these aforementioned frameworks was reflected in the final version of the
questionnaire. The questions were based upon ITIL, like incident management related questions, problem management questions etc. The answers were given according to the prescriptive scenarios provided by MOF, and the scaling and maturity analysis was adapted from the
IOM.
33
3
Research Methods mix
The way the study used methods was a mixture of qualitative methods and quantitative methods. This was agreed upon to be able to not only express a hypothesis for the quality of the
Service, but there was also a need for collecting expressed opinions. At the same time there
was also a need for quantitative methods, since the answers should be measurable on a preset
scale. The structured questions with predefined answers steered the participants to answer
the questions with close-ended answers on structured questions. Only when the participants
had already answered with a close-ended answer, did they additionally have the possibility to
clarify their thinking by expressing their opinion in free form. The way the methods are used
are more closely explained in the empirical part, where the questions and predefined answers
are presented.
A couple of words for those not that familiar with the differences between qualitative research
and quantitative research is needed. A qualitative research mainly tries to answer to questions
like why, what kind of, and how. Qualitative research helps to understand the target setting,
and the corresponding phenomena. The results of qualitative research aim at presenting a holistic view of the study object, and showing cause and effect relationships. At its most general
form qualitative research might be only a non-numeral way of description. (Tilastokeskus,
2015)
The way of working with qualitative research may vary largely, like doing interviews, or simply
observing the study target. The results are not quantifiable, but more relying on interpretation.
Quantitative research relies upon verifiable data. Often quantitative research is bases upon
large quantities that are analyzed. The structure of the data is well defined and typically based
upon a theory or like in this study frameworks. High level of reliability is a requirement, and
the hypothesis can be tested. (Tilastokeskus, 2015).
3.1
Sample width
To get a comprehensive sample to the research, representatives for 32 different IT Services
participated. The questionnaire consisted of altogether forty questions representing, the three
lifecycle phases of IT Services with ten (10) questions each, and additionally ten (10) questions
about the Management of Services. The answers were given as numerical values of maturity
34
on a scale from one (1) to four (4) as set for maturity levels of the Infrastructure Operating
(IO) Model. Each question represented a specific scenario, which could or could not be typical in the target organization. To get a comprehensive sample of the IT Services participating
in the research the target organization was agreed to be the customer’s complete IT organization. At the starting point of the research the customer had 476 different active IT Services,
and because of this amount it has been agreed that the Customer would assign one business
representative who would choose the most important services that should participate
3.2
Research time-schedule
The research for the customer was agreed upon during December 2013. Planning and Development of the assessment material was done during January and February 2014. The actual
research interviews were held during the first half of the Year 2014 after the development of
the assessment methodology, assessment website, and assessment time schedule were finished
in the end of February. The final results of the assessment were presented in August 2014.
The study is based upon the results of the assessment, and is a post-mortem deep analysis of
the outcomes of the assessment project.
35
4
4.1
How to eat an elephant, or how to understand how a Corporation IT is doing?
The target Corporation of the Research
The target Corporation is a major multinational player in its field. The IT Department of the
Corporation has evolved, from originally being a silo approach with local IT personnel working on local solutions, towards a centralized well defined added value driven separate organization. The IT in the Corporation has in the past been seen as a core enabler of competitive
advantage. This has resulted in IT solutions having widely been used for solving various
problems, resulting in a high level of automation, including a highly developed DemandSupply chain, from sub-suppliers, through hub-suppliers all the way to the automated tools for
sales forecasting of resellers. Due to various changes in the market for the products of the
Corporation, major changes in Corporation Strategy, the sales of an entire division due to the
strategy change, and general recession, the Corporation in 2013 did a decision to cut costs for
IT. The cost savings were done by competitive tendering of the current outsourced services
with current vendors against other vendors, but also by implementing the new aggressive costcutting outsourcing strategy to services which earlier had not been outsourced.
As a result of the new strategy the IT Department worked heavily with outsourcing efforts
during the end of year 2012, but also largely during the year 2013. After these efforts, especially the outsourcing of services which earlier not had been outsourced, the team responsible
for IT Service Management, felt the quality of services was endangered, and the management
of the IT Service Management Team decided to try to get done an audit or at least an assessment of the current quality of IT Services provided to business. After some negotiations with
some partners and other vendors, the IT department realized there was already existing
agreements with Microsoft Premier Services that could be utilized, for the purpose and an
assessment project was scoped.
The assessment project would produce the needed input for maturing the services provided.
The biggest areas of interest were the operational phase of the lifecycle, while the outsourcing
efforts were targeted at finding savings in support and maintenance costs of services.
The core structure created for the research was the survey. The survey was based on a survey
originally developed by Microsoft, namely a Proactive Services Maturity Review (PSMR). This
survey template was refurbished and altered to suit the needs of the customer. Due to the
36
geographically divided structure of the customer organization, the survey was done using two
different techniques. The main method was a structured interview with formal 40 questions
divided according to Service Management areas. The survey was divided into four areas,
to evaluate the use of best practices at the customer for IT Service Management. T h e
s u r v e y w a s structured to handle all the phases of an IT service lifecycle, with an emphasis
on the operations phase. The main framework to evaluate the maturity of the customer
ITSM was the Microsoft Operations Framework (MOF) with its phase-structure. Each of
the MOF phases describe industry good practices taking into consideration
(ITIL/MOF/ISO20000), how the good practises for management of an IT service throughout its lifecycle had been implemented. The maturity levels for these phases was evaluated
using the maturity levels defined in the Microsoft Infrastructure Optimization (IO) Maturity
Model (see Figure 11 for maturity definitions).
Infrastructure Optimization (IO) Levels
Basic
Standardized
Rationalized
Dynamic
Non-existent or
Processes are
IT Processes are
IT is strategic
unforced, manual and
centralized and are
persistent.
partner of Business.
localized IT
enforced. More
Organization is
Business is involved
processes. Overall
insight in health and
focused on IT
in the IT processes.
health of IT is
costs of IT
Services. Business is
IT Services are part
unknown/unclear or
infrastructures.
clearly represented by
of Business Services.
IT Staff (e.g. Service
IT is strategic Asset.
information.
Manager). There is
alignment between
IT Services and
Business Services.
Figure 11: Infrastructure Optimization (IO) Levels.
4.2
Using Microsoft Operations Framework as the main framework
Working for Microsoft, MOF was readily available, and free of cost to use, and hence was the
preferred framework structure for the research questionnaire. Still the main purpose was not
to have the discussion be about MOF or any other framework. The questions of the
37
questionnaire were not supposed to steer towards a theoretical discussion around frameworks,
but instead be a tool to be used to facilitate a discussion around how the customer different
services were running their IT and Service Management functions.
Facilitating the assessment discussions
At the pre-engagement meetings one of the important decision concerning participants, was
that the value of the assessment discussions was seen to increase if many of the recommended
attendees attended the session at the same time. As a result of this the most important
stakeholders for each service to be assessed were decided to be interviewed, and so core
stakeholders for each evaluated service were asked to participate in the engagement sessions to
answer to the survey. By having as many as possible of the stakeholders’ present, the
assessment was able to develop an educated comprehensive opinion of the maturity of the
services. At the same time a common understanding of what the possible issues were, and
what should be done to solve the issues, was typically discussed. As a result, the survey often
pinpointed improvement points, by expressing them as alternatives answers.
4.2.1
Best past, current, and desired maturity levels
To be able to get a better perspective to the services maturity, some changes in the Assessment method was needed. The MS developed method of asking for evaluations of the current
status and what would be the desired level of maturity was by the customer not seen as good
enough. Consequently, the assessment model was enhanced with a third question of what had
been the maturity in the foreseeable past. The expression foreseeable was used, since continuous changes had created many different places in time which could have affected the maturity. The outer limits of foreseeable were defined as three years, so either three years in the past
or three years in the future. The IT department had in the past used a rolling fifteen-month
planning model, and so most service representatives used 15 months as the time period for
foreseeable past or future.
4.2.2
IO-Core maturity levels
The maturity assessment was using the IO-Core maturity level scale: Basic, Standardized,
Rationalized and Dynamic. Current and desired maturity levels are determined based on how
the customer responds to the survey questions.
38
Microsoft Operating Framework is according to Microsoft encompassing all of the activities
and processes involved in managing an IT service through the entire lifecycle: its conception,
development, operation, maintenance, and—ultimately—its retirement. To analyze the
Services holistically, not only the Operational phase, but also getting a grip of the surrounding
reality of the services, using MOF was seen as beneficial.
Figure 12: Maturity levels and questions in the Maturity Review.
However, to be able to have the participants in the assessment sessions to focus the discussion
on the scenarios presented, in the past, in current time, and in the preferable future, the
maturity levels were not specifically called out.
4.2.3
Commenting outside of the predefined question-answer units
For some areas, the customer service representatives were not expected to feel any one of
the four possible responses to the survey questions sufficiently describing their situation. For
those scenarios the service representatives were told that a roughly right answer was the right
one, where’s a precise answer lacking something was wrong, and asked to choose the response
that best described their situation and then comment in free form to the response using the
Comments field.
4.2.4
The assessment questions theoretical basis
The questions were divided into four areas according to the phases of the MOF Framework,
including the management layer. In each phase questions were pinpointing at some specific
39
work sub process, with an aim to show what has been, what is now, and where should the
customer IT be.
4.3
The Analysis of handling Services in The Plan Phase of IT Services
According to Microsoft Operations Framework, planning is the key to a successful implementation of Services. The planning success is constructed by defining Service Management
Functions (SMF), that define the good practice for this phase. The key structure for the
study in planning, was about analysing how well planning of IT functions was performed together with business
According to MOF (MOF Plan overview, 2008) Business should get IT Services from IT that
are reliable, compliant, and cost-effective and that continuously adapt to the constantly
changing needs of the business. The Plan Phase is where business and IT should work as
partners to determine how IT will be focused to deliver added-value services that enable the
organization to succeed. For the target corporation, due to the outsourcing and
reorganization efforts done, the functionality of planning was not clear, and needed to be
measured.
In the study, the following things were measured:

How well was IT Services understanding the business strategy and requirements?

How did the current IT services support the business?

How does business know what services are available?

How does IT plan prioritizations and take pre-emptive actions by using Portfolio Management?

What best describes how capacity management of IT service currently is done?

How is Disaster recovery and Business Continuity taken into account in planning?

How well does the strategy plan security and IT service reliability?

How well does IT understand what policy requirements exist and how they impact the IT
strategy?
40

How is IT funded: Yearly, monthly, upon consumption?
4.3.1
Strategy and IT
Analyzing the co-operation between business and IT, by asking for the business strategy and
requirements, gives a good picture of the perceived maturity of the IT. If IT is showing a
clear own strategy, which is aligned with the Business Strategy, the co-operation model exists.
If the IT Organization does not have a formal documented IT strategy, and the IT strategy
and the goals for IT is not aligned with Business, this is a clear indication of that the service
maturity is low.
In the other extreme, assessing the existence of Strategy, is that a clear strategy is defined, metrics for measurement of the IT initiatives have been defined and the benefits realization of the
business objectives and business case are defined. That is according to MOF a mature organization what comes to planning (MOF Overview, 2008).
The answer revealed that the current status was perceived as 1.85 on the scale from 1 to 4.
The situation for planning and co-operation had not been better during the last three years,
showing a slight increase in co-operation when the best past state in average was 1.78. The
difference was small, in comparison to the expressed wish of what the situation should be if
the alignment would be done according to the Stakeholder wishes: The desired level of Cooperation was a clear 3, which means a clear 1.15 level discrepancy between current and desired. On the IO Maturity ladder, 1.85 equals to ability to grasp the entity and providing an
almost standardized service, whereas level 3 equals to organizational maturity which by clear
communication and know-how is able to do optimization of the services and hence effectively
provide better added value for the money spent.
4.3.2
Supporting Business with IT
The question which is essential for any existence of IT is if it is able to provide added value by
providing IT services that really are aligned with business needs? IT Organizations which are
not mature do provide only basic technology according to basic local wishes, where a mature
IT organization provides the users with a maintained catalog of all services which is fully up to
date. This catalog is integrated with the Service Desk software solutions and regular catalog
41
maintenance and addition of new services is defined. By defining a clear Service Catalog, the
IT Organization is handling expectation management. Service Level Management is also automated where possible, and all Services service level measurement can be read from real time
dashboards.
The answers for business alignment were in line with the answers for the strategy alignment.
The difference between current and desired state were 0.9 levels with a current level of 2.5 and
desired level of 3.4. This time there was a slight difference between the current and the best
past in favor of the current: The best past in business support had been 0.1 levels higher in the
past.
4.3.3
How does business know what services are available?
Both MOF and ITIL describe the usage of Service Catalogues as crucial for expectation management. Measuring how the stakeholder communications is done what comes to services
measures the ratio between IT Tactics (Parts of organization) and real IT Strategy (Organization wide). At its lowest some areas might be run with only operational tasks planned. The
interesting question is how the stakeholders see their service published to customers via a Service Portfolio, and is it expressing not only current services, but also planned services, as well
as services that are in development or have been retired? Organizations do need to prioritize
their actions due to scarce resources. During the assessments several time the same question
was presented: If users do not know a service exist, does the service then actually exist?
Planning of the functions through a centralized Portfolio Management function is according
to ITIL and MOF good practice. The assessment needed to analyze how the IT plan, handle
projects and prepare prioritizations and take pre-emptive actions where needed? The immature level in the assessment assumed that services existed independently in silos with no integration to the larger entity whereas the mature solution in the assessment was assuming that
an up to date service portfolio exists and is integrated with the current Service Catalogue. In
the mature level the Portfolio was assumed to offer a view to the whole lifecycle of services
describing new services planned, starting with ideas, through projects phase, to services in
their end of lifecycle. A Service Portfolio is this context should be used by the IT Management, and giving a full picture of the current IT being provided. A holistic Service Catalogue
and Portfolio Management also should reduce the risk for reduces duplication of similar IT
services, and lead to adoption of larger integration of common technologies.
42
The assessment results showed that the Portfolio Management process had been working
better in the past, with a 10% level drop to 2,3 from 2.55 best past. Also the information was
said not to be accurate, since some of the services expressed that the answer only could be a
guestimate, due to not having new updated information since last organizational change,
which had happened one year back. Again, the desired level showed a clear wish from service
representatives to be able to produce better management with a desired level Portfolio Management of 3.3.
4.3.4
How is capacity management of IT services currently done?
The mature level of capacity and performance requirements shows a process which identifies
current needs but also plans for future needs. This level of maturity at the organization also
should show consistent requirement handling, which should be documented in a capacity
plan. The capacity usage should be monitored; pre-emptive automation should be in place
with automatically triggered warnings before capacity shortcomings. Capacity issues should be
remediated proactively based on monitoring trends and future capacity should be planned and
adjusted in alignment with the IT strategy and portfolio plan.
Looking at the results, the comment expressed by several services stakeholders whose services
had outsourced hosting was that capacity planning in the current situation after the reorganization was difficult to do. The biggest obstacle was according the stakeholders that the current
Indian partner providing the hosting services did not provide accurate information of the status of the hosted environment. Business was giving requirements for Servers, mainly about
reactive measures, at least what came to the outsourcing partner, but the IT Service Management responsible for the service got little answers from the hosting partner. Many answered;
A strong -1 current. Still looking at the numbers, according to answers, capacity planning had
matured a lot before the outsourcing, so the current situation was 2.37 whereas the past had
been only 1.77 three years back. The desired state again, was no surprise, showed a desire to
mature a complete level to 3.4.
43
4.3.5
How should Disaster Recovery (DR) and Business Continuity (BC) be taken into account in planning?
The question in the assessment was trying to find an answer to the way the IT Department
was doing disaster recovery planning for IT services. A mature solution was agreed to include
that a disaster recovery plan has been defined, and also the overall business continuity plan has
been defined. This plan should be approved by IT and the business, and it should be supporting the IT Strategy. The critical system backups should be stored off-site; and it should be
clear what services need to be restored in the 1st 24, 48 and 72 hours if a disaster happens.
The plan should also include alternate work locations; alternate procedures should be documented, and disaster recovery procedures should be reviewed and tested.
In the assessment it was discovered that there was a large discrepancy between services. At
some services disaster recovery procedures were not known by the Service Managers. The
Service Managers were expressing that they should be informed of what they can do: At least
something! In other cases, the services representatives did know exactly what should happen,
and explained that All tests are not done, but all procedures are anyhow in place. Looking at
the numbers, the awareness of what DS meant, had increased slightly from the past being at a
level 2.46, whereas in the best past it had been 2.27. This equals to an increase of roughly 10%
in implementation of DS and BC.
4.3.6
How well does the strategic planning plan security and IT service reliability?
A well-defined strategy includes automated functions, where unauthorized access/security
breaches trigger response procedures. The services security should be audited within set repetitive intervals. In case of a security breach or file corruption one should be able restore critical
files or have them safely located. Security related patching should be done according to vendor
recommendations taking into consideration protection against vulnerabilities and confidentiality should be planned according to business and regulatory requirements.
Looking at the answers from the stakeholders of some services, expressed that there is not
quality reporting in place, so evaluation of the current situation is unclear. What is missing, is
that prioritizing has been so heavy that patching is not currently functioning. There is not
enough of resources to guarantee that there are necessary steps taken. The numbers of the
44
assessment do not support the expressed opinion for the entity with a current level 2.59 and
best past as 2.44. Still, you cannot say the services are safe, because security is only as functioning as the weakest spot and if some services are not patched according to recommendations, security breaches can actualize. This a clear risk for all services.
4.3.7
How are IT policies planned and used?
An immature environment could in the study alternative answers be recognised from that
there might be some IT policies but users and support staff are not necessary aware of them
due to missing communications, or the policies are implemented in a decentralized way in
silos. Clear ownership is typically missing. In a mature environment again the study was expecting that IT policies are handled in a centralized way. Communication is done according to
set intervals, the policies also have clear ownership and are based on co-operation with business expressing regulatory and business guidelines. The free form answers expressed that
business should decide to promote centralization. Centralization of policies does not currently
exist, knowledge may exist, but it is not centralized and if a level change is to be done, centralization needs to be done. The corporation IT policies, according to another service were said
to be 5 years old, and after the last reorganization a half year back, the service representatives
did not know what policies were to be used. This was seen as a business Action Point.
Looking at the numbers there was not any significant difference between current and best
past, with a current at 2.47. Desired level, as also expressed in free form answers was at a one
complete level higher with 3.4. As policies ensure that IT and business users are clear on
what is and is not acceptable use, this again is an action point for the IT Department of the
Corporation assessed.
4.3.8
How is IT funded: Yearly, monthly, upon consumption?
Typical for a mature IT department is that financial Management is done. The Business Cases
are evaluated well in advance, during the deliver phase while project work is done, and finally
the business benefits are evaluated against the knowledge of how much IT costs to run.
Financial Management is simply put that IT knows the cost of provision of services. Typically, there are two main ways of funding IT: One where the business pays a percentage of total
budget for IT, or secondly a more active full or part Financial Management, where services are
45
charged upon consumption. Knowing the Business Case and the cost of IT delivering e service, means that IT can provide added value creation back to the business.
The IT Department answers showed that the level of maturity varied a lot, and in general was
seen as immature. One service answered that the actual level is 0. After the last reorganization
the services themselves could not get the cost information for DBs HW, Backups. The service
only knew the cost of licenses. There also was a clear drop in financial management maturity
according to numbers. The current level was a 2.1, where it in the past had been 2.55. That
result equals to a full 20 % drop in financial management maturity. Naturally the service representatives did want the situation to get better and expressed the desired state to be 2.9.
46
4.4
The Analysis of handling Services in the Deliver Phase
One can think of the IT service lifecycle as a continuum that begins with the efforts of IT to
understand the services that the business needs and ends with those services operating in a
production environment. As MOF describes the Deliver phase, in this continuum, the Deliver
Phase is the part where the services are planned, designed, built, and deployed. In the target
corporation, the deliver phase has often been handled by external third party vendors, integrators etc. For this reason, analyzing the steering of the deliver phase was seen as extremely
important. As the IT Department used a standard lifecycle approach to implement projects,
releases, changes in general and so forth, the change management process was of large interest. Also, projects, done by external resources, cannot succeed if the initiation of projects is
not done with proper requirements, scheduling and scoping. Therefore, some emphasis was
put on analyzing how requirements handling is done. In general, the Deliver Phase is a crucial
step where various kinds of functions, like infrastructure projects, software projects or deployment of packaged products are planned, designed, built, and deployed. And to repeat the
most important, the Deliver Phase is the process through which any change must go, standard, large or small (Deliver overview, 2008, p.6).
The questions in the assessment that were used to be able to analyze the maturity of the steps
done at the customer were looking at:

How well is the IT Services organization able to initiate projects?

How have the solution requirements been created?

How does the organization measure that the planning before a project is started is sufficient?

What kind of operational requirements are taken into account in project planning?

What kind of testing is done of changes before actual deployment into production?

Does the organization see pilot testing as beneficial?

What kind of a release process is used for changes?

How are major releases approvals handled before deployment?

Does the Service use a process which includes a formal signoff?

How does the transition of new solutions from development to operations happen?
47
The foundation for functioning services is according to MOF done in the Deliver phase.
4.4.1
How well is the IT Services organization initiating projects?
The scale for immaturity versus maturity of initiating projects was in the assessment set to
variants from the scenario where projects might be initiated from almost any starting point
and there in practice is no initiation process to the other extreme, where projects are based on
well-defined requirements handling and projects cannot be initiated without being a part of
the strategic planning process for the business.
The average answer for the question was 2.5, but remarkable was the huge dispersion between
answers. I think it is too embarrassing to say, but -1, was the comment from one service
stakeholder group, whereas some services reported that their planning is fully strategically
aligned and, hence, valued as 4. Also some clear resistance to processes could be recognized,
where the answer for one stakeholder group was: If we create processes, each hour that we
use for some process, means increased time before the customer gets the advance out of the
product. This is a typical answer from an immature organization, so within the IT Department there could be found all levels of maturity.
The desired state was however clearly stated to be a reassuring whole level higher being 3.53.
That there still where services where stakeholders did not want any process improvements and
no increased maturity tells that there is a need to implement a IT Department wide reinforcement of compulsory processes in project delivery and trainings for those processes, because it
also was expressed by one service that in the current situation it was difficult to initiate a project when there was no clear information of what was expected.
4.4.2
How have the solution requirements been created?
The solution requirements maturity, preceding initiation of a project, was seen to be on level
2.15, with no clear difference from best past (2.1). Again a clear statement from the services
representatives was that the desired level should be more than one level higher with desired
level as 3.3. Remarkable was though that 20 % of the services evaluated the requirement handling to be only of basic level: Scope Creep was evaluated to be common, and requirement
handling was evaluated to not be done in a very systematic way.
48
4.4.3
Is measuring, that planning before a project is started, sufficient?
Measurement of project planning maturity sufficiency was measured on a scale where basic
level was the situation where projects just seemed to progress on their own, to the other extreme, where well planned model where advancement was reviewed against the agreed project
charter at each corporate widely agreed predefined process milestone. The requirements evaluation criteria in the mature organization was seen coming out of a portfolio management
review and the strategic plan. Resources at a high maturity level should be committed only to
strategic projects that are functioning according to set KPIs. Reviews should also be performed consistently to ensure alignment of resources, schedules and requirements across the
portfolio of projects. The maturity of projects requirements was evaluated to be 2.3 with no
clear change in the results from the past. The desired state was again a complete level higher
ending at 3.3. The answers by Service Managers expressed that the amount of resources for
this kind of work was very limited, so practice was lagging due to lacking resources. Also there
was a clear difference between projects operating in an agile model. and traditional waterfall
projects. Agile projects referred to the Agile methodology, which bases resource commitment
on priority of task list (product backlog), whereas older services projects expressed that the
first point for checking the requirement maturity situation was in meetings that was held only
after the project had started.
4.4.4
What kind of operational requirements was taken into account in project
planning?
The mature solution was expected to be one where operational requirements were based on
SLA targets and standard operations plan that existed were updated and included in the project. The immature version of operational requirements was as one respondent explained it:
Business simply says: Use enough hardware. The results revealed that the maturity of the operational requirements were of a level of 2.25. The situation had been even worse before, but
still was seen as inadequate, and the desired level was 3.21. According to answering Service
Managers, there was a clear problem in trying to influence this maturity, since the new operator of the Operational Services was withholding information needed and the adequate information needed could due to this not be acquired.
49
4.4.5
What kind of testing is done and what about pilot testing?
What kind of testing is done of changes before actual deployment into production and is pilot
testing seen as beneficial? For a project to show a mature level of functionality testing of all
changes before being deployed to production was seen as compulsory. Integrated, operational
and performance testing was all seen to be necessary either in a test environment modelling
the production environment or an equivalent. The test environment was expected to be maintained under change control and automation was supposed to be built into testing as much as
possible. At a current level of 2.47 the testing was seen as being at an “OK”- level, as one
respondent expressed. The trend was expressed to be that small changes was developed by
development, and if basic testing was successful, instead of larger testing, roll-back possibility
was secured, and so new features were not tested in QA, but were directly implemented in
production. Pilot testing again had been implemented only in select projects, when there had
been major technical questions which could be tested by piloting.
4.4.6
What kind of a release process is used for changes when a service is mature?
Assessing the release process is one of the milestone values for any project management
methodology. In a well-defined IT organization, it was seen that releases of projects should be
consistently and formally managed using an established process. Risk should be avoided by
bundling changes to minimize the rate of change in the operational environment. At the same
time a sign of a mature operation was seen to be how proactively reviews of the overall IT
plan was done and how other sources of upcoming changes was identified. The results were
showing that the IT Services were able to receive changes at a well standardized level of 2.56
and in major releases the level was 2.68. The trend was upwards, with best past at 2.3 and desired state at 3.4.
4.4.7
Is a process which includes a formal signoff utilized?
In the study the maturity was evaluated also by looking how a formal signoff was acquired
from business. In a mature environment the value of a formal acceptance signoff is understood. The signoff should be consistently obtained when a new IT service is deployed and by
that the IT organization gets a validation of that the project has delivered the requirements of
50
the functional specification. Good practice is also to do a post mortem review and capture the
learnings from the project. The results of the assessment again showed the general maturity
level of the delivery phase maturity as being of standardized level, and no clear changes in
maturity during the last years with best past and current level being 2.2, whereas desired state
was 3.4.
4.4.8
How should the transition of new solutions from development to operations happen in a mature organization?
A well-defined IT Organization uses a formal process for transitioning the solution from the
project team to the organization responsible of doing the operations. This process should be
well established and consistently followed. The results, once expressed that the IT Organization was not very successful operating even at a standardized level. The best past results had
been 1.88, and current was at level 1.96. The desired level showed a huge discrepancy in being
3.4. The reason for the IT Organizations not being able to produce high maturity handovers
was explained by the assessment participants by expressing that the Change Advisory Board
function (CAB) was functioning well, but the formal handover was not being used because
everybody was constantly in a hurry. As this also is the phase when the solution should be
stabilized the services representatives expressed a need to work on this area.
4.5
The Analysis of handling the Services in the Operate Phase of Services
According to MOF, the Operate Phase of the IT service lifecycle represents the culmination
of the two phases preceding it. The Operate Phase is in the center of this study, showing the
IT department output and maturity. It focuses on what to managing the services after the
services are in place. While the Plan Phase focuses on how to determine the business’s needs
for IT services, and the Deliver Phase focuses on how to design, plan, build, and deploy those
services, the Operate phase is, in effect, the state for the IT environment in which IT services
prove their Business Case (Operate overview 2008, p.5)
The following areas were analyzed as a part of the Operate phase assessment:

How is the service able to handle day-to-day operations?
51

Is information, like operation recommendations, provided by vendors, used?

What is monitored in Operations?

How is monitoring tools utilized for monitoring SLA and OLA targets?

How well defined is the Incident Management Process?

How well have incident escalations been defined?

How have knowledge management been done at Operations?

How is the staff trained to be able to do what is required from them?

What does the Problem Management process for the service look like?

How much was the service using defined KPIs and taking into account Critical Success
Factors?
4.5.1
How is the service able to handle day-to-day operations?
The IT Operations must understand what tasks should be performed, and how, to successfully maintain and operate an IT service. This covers all activities might they be daily, weekly,
monthly or ad-hoc. The mature Operations organization identifies all tasks imposed by SLAs
and OLAs. The organization is also able to do tracking of task execution and aims at continuous optimization and seeing for opportunities to automate. According to the respondents the
current situation is far from optimal. There is a day to day problem with the new Operator
doing the stuff, not reporting adequately so some of the respondents had no visibility whatsoever to how the Services were doing, and that was combined with that there was a day to day
problem when it has not been expressed what the new Operator really was responsible for.
Due to the problems with the new Operator some of the most critical services have been internalized back to the original internal service owner, which could be from the results of this
question current being 2.5 best past being more than 10 % lower (2.27), and the comments
from respondents being critical.
4.5.2
Is information, like operation recommendations, provided by vendors,
used?
Vendors typically provide recommendations and best practices that should be followed to
maintain the reliability and security of critical IT services. Regular IT Software Updates Management (SUM) and service maintenance maximises service stability, reliability and availability.
52
In a mature environment regular SUM activities are taken into account and needed changes to
follow the SUM process are reviewed and consulted with vendor before implementation. Also
Risk Assessment Program (RAP) assessments or similar are regularly done. Again, no surprises, current situation is 2.25, best past state has been even worse being 2, and the desired state
is above 3. Remarkable was that six services evaluated that no recommendations or best practises were used by their service. Partly the evaluations also are guestimates, based on agreements, due to that the respondents did express that it was difficult to get information from the
current environment hosting provider, even though there was an expressed wish to get information. The SUM Process was seen as important, but the current situation was expressed as
complicated as the update handling, monitoring and backup-handling was among the outsourced functions, and the possibility to influence the process was perceived to be small.
4.5.3
What is monitored in Operations?
A mature organization understands that monitoring is a backbone of all functions. For service
to be able to understand and react the best services have a correlated automated monitoring
solution. The Service can then use the established monitoring function in real time with realtime service dashboards. The answers expressed that there was no proof on functionality in
current situation. The services did not currently know: The visibility to the new hosting provider was missing! The answers, which were evaluated as 2.9 for the entity for current were
based on agreements, not proof of functionality.
4.5.4
How is monitoring tools utilized for monitoring SLA and OLA targets?
For IT to serve Business according to what is beneficial it is of outmost importance to align
IT service monitoring with relevant OLA & SLA targets. Otherwise there is no way to prove
that services are provide according to customer expectations. A mature solution was seen as
an online dashboard solution. The results of the assessments were according to the respondents an educated guess, since they did not get a holistic report of current monitoring. There
was also a gap between Hosting supplier and IT, and a gap created by a tool which was not
calculating according to SLA: s and OLA: s. There was also no information available what
happens to the tickets that had been issued. The numeral result for this evaluation as a guestimate was 2.09, but reality was thought to be worse. According to the original maturity review
developed by Microsoft a scenario where information is not known is automatically concluded
as a result 1, or no maturity at all.
53
4.5.5
How well defined is the Incident Management Process?
Incident Management is simply put the backbone of all Help Desk activities together with
Service Requests. A well-functioning Service Desk (SD) should be the Single Point of Contact
(SPOC). The SD should consistently log all incidents; use defined models for support for all
services and prioritized incidents resolution according to SLA targets. Not surprising, while
there was no information available from the hosting vendor of ticket resolution times the current situation was evaluated as 2.43, best past as 2.33, and desired level above three with the
result 3.18. However, some services representatives also answered that SD usage is not consistent, and incidents are handled bypassing SD, the maturity level cannot be evaluated to be
higher than basic level 2.
4.5.6
How well have incident escalations been defined?
The true measurement of a SD is the ability to escalate incidents in a timely accurate manner.
The ability to escalate shows the readiness of Continual Service improvement. Case escalation
and severity should in a mature environment be reviewed with the business in relation to
agreed SLAs. The findings for several services was that there was no 1st-3rd ties support
structure: All incidents were handled by the same team, and same person were handling incidents, escalations and even problems. For the better organised services, the case escalations
were automatically triggered when cases reached an agreed age or when cases changed severity. This still equalled to a low maturity and so was the average for answers for current situation: 1.90. Again the best past was still not seen as better than the current situation, so best
past was evaluated to 1.83.
4.5.7
How has knowledge management been done at Operations?
In a mature organization the SD can rely upon a knowledge base which is indexed and searchable. The knowledge is constantly upgraded by users, and the knowledge base owner oversees
the process to improve quality, accuracy and relevance of the answers. In a mature environment business and IT work together to define and review the knowledge and have developed
a common strategy for each supported service. In a well-developed SD Knowledge management solution self-service capabilities for customers are consistently being developed. For the
IT Organization studied the current situation was evaluated as really low 1.78, the best past
had been a bit better 1.88, and finally the desired situation was evaluated as 2.78, so even as
low, still one complete level higher.
54
4.5.8
How is the staff trained to be able to do what is required from them?
Nothing in IT is as persistent as change is. IT justifies itself during change, and to be able to
do so training for IT staff needs to be frequent, and a priority Human Resource (HR) task of
an efficient company. These trainings do not necessarily need to be formal training accreditations, but HR and IT should ensure that trainings are aligned to new services needs as well as
maintaining the skills required to ensure optimal customer service outcomes. To assure a successful end result, the changes caused by the outsourcing should have been supported by appropriate trainings for that part of the personnel that was reallocated. According to the answers given, training had been on level 2 in the past, had dropped to 1.85, but was eagerly
awaited by people expressing the desired level to be at level 3. A drop in the level of trainings,
provided by Management to personnel during change, is a clear sign of bad change management know-how. Failure to train people during larger changes, causes uncertainty and brain
drain, and in the long run escalates a dissolving knowledge creation spiral. According to the
ADKAR model (Hiatt, 2006, Kindle Locations 478-479). There are four factors that should be
taken into account while implementing change:

The current knowledge base of an individual

The capacity or capability of this person to gain additional knowledge

The resources available for education and training

The access to, or existence of, the required knowledge
The study reveals that the change management had not been done in a way that would support long term targets, since the outsourcing efforts, did not provide the needed trainings to
maintain the old level of knowhow.
4.5.9
What does the Problem Management process for the services look like?
Problem Management is according to ITIL (Service Operation 2011, p.97) making sure that
IT Problem management takes care of the activities required to diagnose the root cause of
incidents and to determine the resolution to those problems. Problem Management is also
responsible for ensuring that the problem resolution is implemented according to appropriate
control procedures. The most important continuation of Problem Management is the change
management and release and deployment management for the problem resolution. Problem
Management should take a deeper look at recurring incident issues, and repeat problems to
ensure that underlying root cause is addressed and remediated against.
55
The resolution should according to ITIL (Service Operation 2011, p.97) also take care of that
the information about problems and the appropriate workarounds and resolutions is maintained, so that the IT organization is able not only recognise, but also reduce the number and
impact of incidents over time. In this area, problem management needs to influence
knowledge management routines and processes. Tools such as the Known Error Database
(KEDB) should be used for both. In a mature operation one should also understand that even
though incident and problem management are separate Service Operation phase processes,
they are closely related and will typically support each other by using a similar kind of parts of
the process like incident/problem categorization, incident/problem impact and incident/problem priority. The aligned processes would help to achieve larger common understanding when communicating about related incidents and problems.
A mature problem management process is also divided into reactive and proactive aspects.
Reactive problem management is a continuation of by trying to solve problems in response to
incidents. Proactive problem management is closely related to Continual Service Improvement
trying to identify and solve problems and known errors before further incidents related occur
again. This kind of activity can be planned compared to incident driven impulse driven actions. The study showed that the IT Organization best past to have been low 1,83, current
situation had improved to 2,03, which is a 10% increase in problem management maturity,
and finally the desired state showed a clear understanding for the need of increased efforts in
the area of problem management with a desired level maturity of full one degree higher to
3,06.
4.5.10 How much was the service using defined Key Performance Indicators
(KPIs) and taking into account Critical Success Factors (CSFs)?
For the Services to become more mature, IT needs to prioritize its own Continual Service
Improvement (CSI)Program. If this is not done, the quality of the service will not become
better, it might even deteriorate over time due to updates and other change operations. An
Operations Management Review is a good indicator of service maturity, and needs to be
scheduled regularly. Reviews ensure that IT is business aligned and is delivering what it needs
to deliver in the most efficient manner. Therefore, reviews should periodically be performed
to capture learnings and translate them into improvement suggestions, and in the end change
56
management tasks. The study showed all too little interest in using well defined KPIs and
CSFs with an average of only 1,61 in the past, a slight increase to the current situation with a
still low 1,78, and an understanding for that it would be beneficial with huge increase desire of
1.3 maturity step levels to the state of 3,09. If services are not able to provide well measured
services, they also cannot prove that they are beneficial, so the study shows a clear area for
improvement.
4.6
The analysis of the Manage Layer of Services
The biggest overall question for ICT Governance is how the IT activity is coordinated and
governed? According to MOF one should look at what ultimately determines the way IT gets
work done.
At the IT Department studied, management was not sure how well services were managed,
which already put emphasis on this area of the study. Using the MOF Manage Layer structure,
the study could do research about how well the different parts of management functioned.
Special interest was laid upon how well decision making, risk management, and change
management processes were integrated and influencing each other. These processes occur
throughout the IT service lifecycle, and give the Service Management tact. Using the Manage
Layer view, the study, also did research in how consistent planning and delivering IT services
was at the IT Department, and could give some input as a basis for development and
operations of the IT services. (Manage Overview 2008:5).
The following areas were analyzed as a part of the Manage layer assessment:

What kind of Change Management strategy was the Service using?

Was the Service making differences between how different kind of changes were handled?

What did services think about standard changes?

What did the Service do with emergency changes?

How much was the Services utilizing change and configuration management tools?

How had Problem Management been defined and what was done?

Did the Service use the best practices by using the Corporation Service Request Catalogue
structure?
57

Was the Service using the Corporation concept of best practices for Support?

Was the Service using an Asset & Configuration Management Process?
4.6.1
What kind of Change Management strategy was the Service using?
As a continuance of the IT maintenance of services it is important that IT has defined and
uses a formal change control process, as unplanned changes are often the underlying reason
for downtime. ITIL (ITIL Service Operation 2011, p.227) expresses that personnel in service
operations should be involved in the assessment of all changes to ensure that operational issues are fully taken into account. ITIL continues the description of a good change management practise, by explaining that in a mature environment, the involvement of Operations
personnel should start as soon as possible, not just at the later stages of change just before
deployment to production.
Change Management is the process that should cover all changes done to production environments, and it is the process that should succeed any work done in the Problem Management process, and it is crucial for the Continual Service Improvement process. To the IT services of the Corporation studied, the Change Management Strategy was evaluated to in the
past have been pretty good: 2.44, the current situation even a lot better with 2,9 and a high
desired state of 3.59. Clearly there was an understanding of the importance of change management.
4.6.2
Was the Service making differences between how different kind of changes
were handled?
The operations teams or teams together with a Change Advisory Board (CAB) in mature services environment should provide look into the impact of changes before its implementation
in order to minimize the adverse impact of changes. It is crucial for changes to be assessed
against risk, impact, and also cost before approval. At this point before deployment at its latest
all relevant parties should be aware of the change decision and participating in the approval.
The study showed that different changes were handled on a best past level of 2,5, a better
current level of 2,62 and a desire to do it at a level of 3, 15. In the free answers it was however expressed that descriptions for what is the categorization of different cases (critical, major
etc.) was missing for some services. The Infrastructure CAB was in this case the only one existing CAB. A decision of when to use CAB had not been clearly stated. It was also stated
58
that the new outsourcing partner had even made changes to production without asking anybody. So the actual level of maturity varied largely in between services.
4.6.3
What did services think about standard changes?
Using a process model which includes “Standard Changes" as defined by ITIL predefined,
means that each new change may not necessarily have to go through the CAB process, as it is
pre-assessed. This will enable faster throughput of minor changes and will save resources. By
giving the authority to users like administrators and senior operators to making low level
changes that have predefined or acceptable levels of risk the organization can be more flexible.
The answers showed that the method of using standard changes to speed up functions was
not largely used with a best past or 1,72 a current with 1,93, but a wish to develop this way of
working with a desired level of 2,9.
4.6.4
What do the Services do with emergency changes?
To be able to recover rapidly it is important that IT has a baseline configuration. Emergency
changes can then be done and in case failure a failback to an earlier implementation can be
done. IT should always have a baseline where one can identify the desired state of services,
setup model or patching level. Change Control can then be applied in a controlled manner
managing all variances away from this baseline so that it is clear what the configuration should
be. The same methodology should in a mature environment be used both for server environments and desktops including desktop-images for fast implementation in case of need for
failover. The baseline should be counted as a CSF, and be monitored for divergence and CSI.
The services reported a best past to be 2,61, current to be 2,93 and the desired state to be a
high 3.51.
4.6.5
How much are the Services utilizing change and configuration management tools?
There are many reasons for utilizing Configuration Managements Systems (CMS). It should
however be a centralized effort planned in Service Transition as ITIL expresses it (ITIL Service Operation 2011, p. 229) since many ITSM tools, discovery functions and event monitoring tools, may require changes in the environments, like client/agent software deployments,
before they can be used. These efforts are environment intrusive and should be carefully
59
planned before any execution. It is also a recommendation of ITIL that implementation efforts of CMS to environments should be handled through formal release and deployment
management. Change Management toolsets for managing change (and therefore configuration) will still assist in saving time, increase consistency and can provide records of how requests for change have been handled and how Configuration Items (CIs) have changed over
time. In the study the Service representatives were pointing out that the IT needed to be able
to maintain also app information components, not only infra information as was the current
situation. It was also stated that the structure was not ideal with a 3rd party supplier, which
went outside of the SAAS idea to have integrated tools. The past maturity in this question was
seen as 2,44, current with a slight decrease with the 3r party supplier to 2,37, and a desire level
of 3,34.
4.6.6
How had Problem Management been defined and what was done?
Problem Management as a continuance of Incident Management escalations is an important
Service Management area, as discussed in the Operations Phase. From management point of
view, it was stated by some services that Problem Management process did not work in practice in the new environment with the new outsourcing partner, even though there was an old
process existing. However, on a maturity scale it was still stated that the best past had been
2.11 and current was better with 2,43, so the average perception by the service representatives
was that the situation was better than before. The desired state was expressed to be 3,34.
4.6.7
Did the Service use the best practices by using Knowledge Management
and the Corporation Service Request Catalogue structure?
In the study definition phase, the customer representatives wanted to define the Knowledge
Management (KM) Purpose according to following: The primary objective of the
“Knowledge Management" Process is to improve the quality of decision-making by enabling
reliable and relevant information availability during the service lifecycle. The KM should identify key knowledge capital for reuse within service. It also should submit knowledge capital
contribution to the knowledge management shared repository. Furthermore, the KM part
should do the review for new contribution content for active, archival, or delete mode. In
addition, KM work was to communicate new content upload to appropriate resources and
manage knowledge transfer. The service representatives saw the best past in the KM area to
60
have been 2,05, current to be 2,25, and desired level 3. It was stated that the new CMDB and
ticketing SAAS based tool (Service NOW), should be used for IT personnel but not necessarily for the end-user requests. The integrations to the internal systems were still not done, and
could prove a major problem for a deeper usage.
4.6.8
Was the Service using the Corporation concept of best practices for Support?
The Corporation had developed a Global Support Concept (GSC), which was in the implantation phase. The question was measuring how much service representatives did find the GSC
in use. The answers revealed that there was a problem using the concept, since the local Service Desk did not provide support for the GSC service, and so there was no support for end
customer for this service. The best past, which was defined as one year earlier when the service implantation had started was from the beginning at level 2, the current level was 2,4 and
the desired level 2,84.
4.6.9
Was the Service using an Asset & Configuration Management Process?
The question set was measuring how well the implantation of the Service NOW SAAS tool
had been done. According to the answers, there were some implantation problems. One major
issue was that the there was a need for enhancement in CMDB quality in general. The Configuration Items state was also poor: the Service representatives did know their CIs, and what
was right or wrong with them, but many of the CIs were currently incorrect, which was difficult to solve due to problems with the Service NOW tool. The evaluation of the usage told
that the best past state was 2,16, the current state had been improving to 2,68, and the desired
state was once more clearly higher at 3,46.
61
5
5.1
Summary
The questions
Taking a holistic three dimensional view, including the satisfaction, scope and also the time
perspective, of a Corporation level IT, is a major task. The methods defined by IT Governance Frameworks do help, but the realization and the value adding function of this work is up
to the individuals performing the work. In this study the goal was to answer the following
questions:
Q1: How had the service management been done at the customer in the past?
Q2: How was service management done at the customer currently?
Q2: How should service management be done at the customer in the future?
Q4: How should the maturity of service management be measured in the aforementioned time
perspective?
Answering the first two questions revealed that Service Management in general in the past had
been on a standardized level with an average of 2.21. Current level of maturity was also on a
standardized level with an average of 2.35. The Service Representatives showed a clear wish to
develop and mature the Service Management work, and so the average for all future lifecycle
phases was 3.27 when combining all the lifecycle areas in the confidential result-spreadsheet
(Appendix 2). The actual answers to question 3 and 4 for how service management should be
done and measured in the future was embedded in the prescriptive answer-suggestions given
during the assessment. The confidential report also provided a list of suggestions to the customer (Appendix 1) for improvement, including issues and risks, to be evaluated for further
measures.
Well, what did this all mean? The average level shown by the answers of this study show that
there had been no clear decrease in IT Service Maturity due to the outsourcing efforts, actually
the contrary, the Services came out as more mature in the Service Management perspective
after the outsourcing had been done. There was no average decrease in the Services in the
overall lifecycle, nor the field of Operations, which was the area where the outsourcing was
most remarkable. An average result does however not tell the real story, but “The Devil lays in
the details”. The impact on maturity when measured with a quantitative method, was not as
62
big, as the perception of the change in maturity, when discussing with people who had been
involved with the outsourcing efforts. As a result, from the business perspective, one could
say that the outsourcing seemed to had been successful, since there was tangible savings in the
costs of IT services and the maturity entity did not seem to had been adversely affected.
5.2
The scaling
To understand the results of the research, and possible needed actions, it is necessary to explain more what the numbers in the evaluation grade from 1 to 4 indicate. How would one
easily be able to recognise what level an organization is at, and what are those levels?
5.2.1
The level 1 or the Silo-type maturity
In some parts of the IT department the research found very unorganized ways of running the
IT services, equaling level 1 in Service maturity. What is this level then?
If you can use one expression which would make the observer recognize basic maturity in
smaller entities, it would be finding the “Shy IT guy in the corner, hiding in his cubicle behind
his IT Manuals”. At the same time as this is our departments “own guy” who knows everything we need, he is a considerable risk for the business. The solutions might be based on
whatever and the solution maturity is solely dependent on his skillset. The next shy guy at the
next department works in a similar way, and so there might be no standards uniting the departments. This also means cooperation in between the departments and the organization as
an entity is difficult.
5.2.2
The level 2 or Standardized technology maturity level.
Major part of the answers given about the maturity of the IT Services current situation were at
this level of maturity in the research.
Simplified, one could say that this is the level of maturity where the IT specialists run the
House. IT has been standardized, people understand the benefits of common solutions, and
have taken care of that the IT Department is run in a technically well-defined way. At the
same time as standardization is well understood the work roles are defined according to IT
Application Know-how, not by a service centric thinking. On this level there easily is a mismatch between business and IT created due to that when the IT specialist run the IT show,
easily the business case and the customer is forgotten. When costs are rising due to misplaced
sources of interest and priorities, business might feel alienated from IT and badly served.
63
5.2.3
The level 3 or Optimization of solutions maturity level
If the IT Department is able to evolve and react by starting to think solution centric instead of
application centric, the maturity starts to steer the decisions towards more effective solutions
and continuous optimizations, which in turns if done right and not decreasing the servicequality to business, will increase business satisfaction. The Service representatives, interviewed
for the assessment representing the IT Department, in their choices for desired state, showed
a clear wish to develop the IT Services and Service Management in general to this level, but
the business strategy for IT had been changed not to exist, or as it had been expressed IT
should only support the Business strategy, not develop any own strategy or as was expressed:
“There is no direct IT Strategy, everything is based directly on the Business Requirements. All
applications are handled by business and all development was done as Scrum/Agile”. As
shown also in this Corporation hunting for savings optimization had made the company outsource their IT. The result, as typically is, was a minor saving, but a huge drop in know-how.
5.2.4
The level 4 or the Service Oriented Approach of maturity
This is the level where traditional Service Management reaches its optimal results and Service
Management based thinking is in the center. Clear signs of functioning 4-lvel maturity is well
defined SLAs, OLAs and UC-contracts. The personnel working with IT understand what a
Service centric approach means, and can operate according to that thinking contrary to IT
centric thinking and approach. Services are continuously evaluated, clear service portfolios
exist, and the whole lifecycle of services is aligned with business targets. Another clear signal
of the Service centric thinking is the scalability of services, increasing and decreasing services
are built into the service-structure, so capacity considerations are a breeze.
5.2.5
What was missing
The dissatisfaction amongst the Service representatives, and the expressed worries for the
future of the Services, revealed that the change management part including people in their
transit from technology centric work roles to service centric management roles had not been
supported. Decreasing possibilities to get trainings at the same time as new roles were imposed to many people was telling that there was lacking knowhow in how to do successful
Change Management for organizations like this. The failure could clearly be recognised in the
atmosphere and even though the Services as such were able to function as before, the trust
between parties had been eradicated. In the free discussion afterwards, several Service repre64
sentatives expressed their intention of leaving the company. One of the Service representatives even left at the end of the research period for an indeterminate period of time on a sick
leave due to a burnout.
The perception of trust, the change management efforts done while outsourcing, and the understanding of the meaning of knowledge creation as expressed by Nonaka & Takeuchi (1995)
in their SECI-model was not an agreed target to be studied in this study, but study of these
areas would have been extremely useful as there were clear signals of mistrust and a negative
SECI-spiral, with knowledge losses through employees leaving.
65
6
6.1
Discussion
Future discussion above all grades: The Customer Centric Approach
This is the level which has not been established in the models used, but which is coming more
and more apparent in the new Customer centric world. In this future partnership between IT,
business and partners has been established through mutual trust. The customer centric approach differs from the Service centric approach or SOA by the level of automation: The IT
environment is highly automated. This also means that top level automation Know-how is
needed, but those roles are located at the third party or partner. The IT organization is the
orchestrator of services needed by the internal customers. IT is divided into commodities, and
added value-areas and the commodities are bought from outside. In some scenarios the combinatory combining different basic level services, like metadata for databases, and thus providing added value to the customers. At the same time, IT is not discussing services details anymore with the customers, but concentrating on the customer experience. This level of maturity is coming, due to customer demand. Simply put the IT Department of the future and people in IT concentrate partly on Service Management, buying service components, but more
importantly concentrating on value design combining these service components together with
business.
6.2
Afterthought
At the point of finalizing the research, many of the Services of the IT Department depicted in
this study are been merged to a larger entity, and will cease to exist. The signals that were recognizable in the lack of interest of business to provide trainings to the IT people changing
roles and the lack of the IT Strategy, was a clear signal of the upcoming change. Also the representatives that ordered this assessment have since resigned, and so the benefits of this study
are not going to benefit the customer IT Organization anymore. Still, participating in the process without doubt benefitted the participants of the assessment, by the thought put into describing future requirements for IT professionals. The change hunting the added value is the
only thing that persists in IT.
66
References
Cabinet Office. 2011 edition. ITIL – Service Design. TSO London.
Cabinet Office. 2011 edition. ITIL – Continual Service Improvement. TSO London.
Cabinet Office. 2011 edition. ITIL – Service Operation. TSO London.
Cabinet Office. 2011 edition. ITIL – Service Strategy. TSO London.
Cabinet Office. 2011 edition. ITIL – Service Transition. TSO London.
CMMI History 2015. Available at: http://hciitil.com/CMMI/references/CMMI_publication.html [Accessed 09.12.2015].
Figure 1: ITIL version 3.0, 2011 Enhanced. Available at:
https://s3.amazonaws.com/marketing-blogs/cw-blog/uploads/090814_ITIL.png [Accessed
15.03.2016].
Figure 2: Request Fulfillment Process. Source: ITIL Service Operation 2011).
Figure 3: Problem Management Process. (Source: Orand and Villareal 2011).
Figure 4: MOF. Available at: https://technet.microsoft.com/enus/solutionaccelerators/dd320379.aspx [Accessed 15.03.2016].
Figure 5: Plan Phase. Source: MOF: Plan Overview (2008).
Figure 6: The Operate Phase. Source: (MOF Operate Overview 2011).
Figure 7: The Manage Layer. Source: (MOF Manage Overview 2011).
Figure 8: Core IO Model. Available at: https://technet.microsoft.com/enus/library/bb821255.aspx [Accessed 15.03.2016].
67
Figure 9: Enterprise Architecture Model. Available at: CISR
http://cisr.mit.edu/files/2009/12/Topic-EA_slide2_lg.png [Accessed 15.03.2016].
Figure 10: EAM Benefits. Source: Ross, J, W., Weill, P.; and Robertson, D, C., Enterprise
Architecture as Strategy 2006
Figure 11 – Infrastructure Optimization (IO) Source: Appendix 2, Company Internal report 2016
Figure 12: Maturity levels and questions in the Maturity Review. Source: MS Maturity Review
Delivery Guide 2014
Hiatt, J., 2006. ADKAR: A Model for Change in Business, Government and our Community.
Prosci Learning Center Publications. Kindle Edition.
History of ITIL 2015. Available at:
http://itsm.fwtk.org/History.htm [Accessed 20.12.2015].
History of ISACA 2015. Available at: http://www.isaca.org/AboutISACA/History/Pages/default.aspx [Accessed 18.12.2015].
Nonaka, I., and Takeuchi H., 1996. The Knowledge Creating Company, How Japanese Companies Create the Dynamics of Innovation, Oxford University Press, New York, USA
Orand, B., and Villareal J., 2011. Foundations of IT Service Management, ITILYaBrady.com,
Proactive IT Solutions, LLCPro, USA
Ross, J, W., Weill, P., and Robertson, D, C., 2006. Enterprise Architecture as Strategy, Creating a foundation for business execution. Harvard Business Press, USA
USC Libraries 2016. Available at: http://libguides.usc.edu/writingguide/quantitative [Accessed 05.04.2016].
Service Integration and Management 2015. Available at: https://www.gov.uk/servicemanual/technology/service-integration.html [Accessed 19.12.2015].
68
Technet.microsoft.com 2015. IO Model, Available at:
http://social.technet.microsoft.com/wiki/contents/articles/12122.infrastructureoptimization.aspx [Accessed 05.04.2016].
Tilastokeskus 2015. Available at: https://tilastokeskus.fi/virsta/tkeruu/01/07/ [Accessed
04.11.2015].
Software Engineering Institute 2012. CMMI. CMMI_DEV_vs1_2.pdf Available at:
http://hci-itil.com/ITIL_v3/references/CMMI_DEV_vs1_2.pdf [Accessed 1.12.2015].
Soy, S, K., 1997. The case study as a research method. Available at:
http://www.ischool.utexas.edu/~ssoy/usesusers/l391d1b.htm [Accessed 29.03.2015].
What is PDCA? 2015. Available at: http://whatis.techtarget.com/definition/PDCA-plan-
do-check-act [Accessed 15.03.2016].
69
Appendix 1. Company internal result spreadsheet (Confidential)
Appendix 2. Company internal report draft (confidential)
70

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project