FitSM-3 Role Model

Part 3: Recommended role model
Edition 2016 – Version 2.2
This work is licensed under a Creative Commons

Attribution 4.0 International License.
http://www.fitsm.eu/
Document control
Document Title Part 3: Recommended role model
Document version 2.2
Release date 2016-06-14
Table of Contents
1. Foreword ............................................................................................................................................. 1
2. Introduction ........................................................................................................................................ 1
3. Scope and applicability ....................................................................................................................... 2
4. Terms and definitions ......................................................................................................................... 2
5. Important concepts............................................................................................................................. 3
5.1 Generic and specific roles ................................................................................................................. 3
5.2 RACI matrix........................................................................................................................................ 3
6. Generic ITSM roles .............................................................................................................................. 5
6.1 SMS owner ........................................................................................................................................ 5
6.2 SMS manager .................................................................................................................................... 6
6.3 Service owner.................................................................................................................................... 7
6.4 Process owner ................................................................................................................................... 8
6.5 Process manager ............................................................................................................................... 9
6.6 Case owner...................................................................................................................................... 10
6.7 Member of process staff ................................................................................................................. 10
6.8 Summary and visualisation of the role model ............................................................................... 11
7. Process-specific ITSM roles ............................................................................................................... 12
7.1 Context: Service Portfolio Management (SPM) .............................................................................. 12
7.2 Context: Service Level Management (SLM) .................................................................................... 13
7.3 Context: Service Reporting Management (SRM) ............................................................................ 15
7.4 Context: Service Availability & Continuity Management (SACM)................................................... 16
7.5 Context: Capacity Management (CAPM) ........................................................................................ 18
7.6 Context: Information Security Management (ISM) ........................................................................ 19
7.7 Context: Customer Relationship Management (CRM) ................................................................... 21
7.8 Context: Supplier Relationship Management (SUPPM) .................................................................. 22
7.9 Context: Incident & Service Request Management (ISRM) ............................................................ 23
7.10 Context: Problem Management (PM)........................................................................................... 24
7.11 Context: Configuration Management (CONFM) ........................................................................... 25
7.12 Context: Change Management (CHM) .......................................................................................... 26
7.13 Context: Release & Deployment Management (RDM) ................................................................. 28
FitSM was co-funded by the European Commission under contract number 312851.
7.14 Context: Continual Service Improvement Management (CSI) ...................................................... 29

8. Roles and federations ....................................................................................................................... 30
FitSM was co-funded by the European Commission under contract number 312851.
1. Foreword
FitSM is a lightweight standards family aimed at facilitating service management in IT service
provision, including federated scenarios. The main goal of the FitSM family is to maintain a clear,
pragmatic, lightweight and achievable standard that allows for effective IT service management
(ITSM).
FitSM is and will remain free for everybody. This covers all parts of the standard, including the core
parts and implementation aids. All parts of the FitSM standard and related material published by the
FitSM working group are licensed under a Creative Commons International License.
The development of FitSM was supported by the European Commission as part of the Seventh
Framework Programme. FitSM is owned and maintained by ITEMO e.V., a non-profit partnership of
specialists in the field of IT management, including experts from industry and science.
FitSM is designed to be compatible with the International Standard ISO/IEC 20000-1 (requirements
for a service management system) and the IT Infrastructure Library (ITIL). Although the FitSM
process model, requirements, recommended activities and role model target a lightweight
implementation, it can act as a first step to introducing “full” ITSM, i.e. applying ITIL good practices
and / or achieving compliance against ISO/IEC 20000-1. The FitSM family is made up of several
documents, providing guidance and input on different aspects of ITSM in federated ICT
infrastructures:
 FitSM-0: Overview and vocabulary

 FitSM-1: Requirements
 FitSM-2: Objectives and activities
 FitSM-3: Role model (this document)
 FitSM-4: Selected templates and samples (set of documents under continual development)
 FitSM-5: Selected implementation guides (set of documents under continual development)
 FitSM-6: Maturity and capability assessment scheme
All documents are available and published in their most recent version through the website
www.fitsm.eu. Enquiries about the standard and its applicability should be directed by e-mail to
[email protected].
2. Introduction
Wherever ITSM is implemented and related ITSM processes are defined, clearly defined roles are
vital to ensure that people involved in these processes are aware of their authorities and
responsibilities. FitSM-3 defines these roles.
Page 1 Version 2.2

3. Scope and applicability

FitSM-3 sets out a schema for the roles recommended to effectively manage services. The purpose
of the role model is to establish the set of basic roles that need to be assigned in order to effectively
perform ITSM. This framework of generic and specific roles will serve as a guideline when
establishing a service management system (SMS). While not all roles are required under all
circumstances, it is important to assign individuals to roles necessary for a service provider’s
individual level of maturity. This supports FitSM’s goal to support lightweight ITSM.
FitSM-3 supports FitSM-1 (requirements) and FitSM-2 (objectives and activities) in seeking to
achieve an achievable level of capability for the ITSM processes considered. The role model defined
in FitSM-3 is not intended to be exhaustive or the only valid role model that can be used to meet the
requirements, but it gives some initial guidance on setting up a landscape of roles and
responsibilities in support of meeting the FitSM-1 requirements.
This standard is applicable to all types of organisation (e.g. commercial enterprises, government
agencies, non-profit organizations) from which IT services are provided, regardless of type, size and
the nature of the services delivered. It is especially suitable for groups new to service management,
or for federated scenarios.
4. Terms and definitions

For the purpose of this standard, the terms and definitions according to FitSM-0: Overview and
vocabulary apply.
Page 2 Version 2.2

5. Important concepts
Prior to presenting the FitSM role model, the idea of generic and specific roles as well as the concept
of a RACI matrix is explained.
5.1 Generic and specific roles

FitSM considers two kinds of roles: generic and specific roles. Generic roles are role types that
generally exist in all service provision scenarios. These must then be interpreted as a part of the
service management processes into specific roles for the respective service provider. For an
example, and as shown in the table below, Flight captain is a generic role within an airline. However,
flight captain for flight XX123 from Munich to Brussels is a specific role needed by that airline based
on the generic role.
The FitSM role map provides both a generic role model (section 6) and advice on how to translate
this into specific roles (section 7).
Description ITSM example Non-ITSM example
Generic role A conceptual class of role which is Process manager Flight captain
instantiated in a specific context to
create a specific role
Specific role A concrete role which can be assigned Process manager Flight captain for
to a person or team in order to give for the incident and flight XX123 from
this person or team the responsibility service request Munich to Brussels
for something management
process of an IT
service provider
(process manager
ISRM)
5.2 RACI matrix

The RACI matrix is a tool to describe roles and responsibilities within a specific context in a simplified
and easy to grasp manner. The four letters R, A, C and I stand for the various generic forms of
responsibility or participation:
 Responsible: A person or role actually executing / performing / carrying out a process or

activity
 Accountable: The person or role governing a process or activity by defining and approving
goals and providing or acquiring resources and capabilities required so that the process or
activity can be carried out effectively
 Consulted: A person or role whose expertise or other kind of contribution is needed to carry
out a process or activity without this person being responsible for the process or activity
him-/herself
 Informed: A person or role who needs to be kept informed about the status and/or results of
a process or activity
Page 3 Version 2.2

In the context of the role model, it is important to understand that different individuals and their
roles imply different levels of involvement in a process or activity. A RACI matrix shows these
relationships and can be a helpful way of describing the contributions of different roles in the
context of the regarded process or activity. For example:
Role 1 Role 2 Role 3 …
Activity 1 A R I
Activity 2 AI C R
Activity 3 AC R C
To produce a valid RACI matrix, the following set of simple rules should be followed:
 Every row should contain exactly one “A”. The rationale behind this rule is that there should
be clear accountability for every activity; at the same time, it might lead to confusion and
lack of individual commitment or enforceability, if two or more persons or roles are
accountable at the same point in time.
 Every row should contain at least one “R”. This is an obvious constraint, since it requires that
there are no activities for which the responsibilities of executing them are undefined.
 It should be avoided that the same person or role is accountable and responsible at the
same time, i.e. for the same activity.
Page 4 Version 2.2

6. Generic ITSM roles

The following generic roles build the core of the FitSM role model:
 SMS owner
 SMS manager
 Service owner
 Process owner
 Process manager
 Case owner
 Member of process staff (process practitioner)
These roles are specified in the subsequent sections. Please note that in practice, and as the
achieved level of maturity increases, there may be additional generic roles, such as “internal
consultant” or “internal auditor”.
6.1 SMS owner

The SMS owner (also referred to as the senior responsible owner of the SMS) is the role that has the
overall accountability for the establishment and maintenance of the service management system. By
means of effective governance, he or she sets the key goals and provides overall direction for the
SMS. Consequently, a person with sufficient authority, usually a person on the top management
level, should take on this role.
Role Tasks Ca. number of persons

performing this role
SMS owner • Senior accountable owner of the entire 1 for the overall SMS
service management system (SMS)
Often, the person
• Overall accountability for all ITSM-related taking over the SMS
activities owner role may also
take over the process
• Act as the primary contact point for concerns
owner role (see next
in the context of governing the entire SMS
slide) for the entirety
• Define and approve goals and policies for the or a subset of the ITSM
entire SMS processes.
• Nominate the process owners and/or

managers, and ensure they are competent to
fulfil their roles
• Approve changes to the overall SMS
• Decide on the provision of resources

dedicated to ITSM
• Based on monitoring and reviews, decide on

necessary changes in the goals, policies and
provided resources for the SMS
Page 5 Version 2.2

6.2 SMS manager

The SMS manager is the role often regarded as the “project manager” of implementing IT service
management in an organisation or federation. However, different from a real project manager, the
SMS manager is not released from his or her duties after the SMS has been successfully
implemented to some extent, since a management system will always require continuing efforts of
maintenance, development and improvement. The SMS manager coordinates all efforts in planning,
implementing, reviewing and further improving the SMS.

SMS manager • Act as the primary contact point for all 1 for the overall SMS
tactical concerns (including planning and
development) in the context of the entire
SMS
• Maintain the service management plan and

ensure it is available to relevant stakeholders
• Ensure IT service management processes are

implemented according to approved goals
and policies
• Maintain an adequate level of awareness and

competence of the people involved in the
SMS, in particular the process managers
• Monitor and keep track of the suitability,

effectiveness and maturity of the entire SMS
• Report and, if necessary, escalate to the SMS

owner
• Identify opportunities for improving the

effectiveness and efficiency of the SMS
Page 6 Version 2.2

6.3 Service owner

The service owner is the responsible person for a specific (IT) service offered by the service provider.
This role is typically taken on by individuals with management experience. Service owner is unusual
in that it cuts across processes, only touching on parts of each process.

Service owner • Overall responsibility for one specific service 1 per service in the
which is part of the service portfolio service portfolio
• Act as the primary contact point for all One person may take
(process-independent) concerns in the over the service owner
context of that specific service role for one or more
(or even all) services.
• Act as an “expert” for the service in technical
and non-technical concerns
• Maintain the core service documentation,

such as the service specification / description
• Be kept informed of every event, situation or

change connected to the service
• Be involved in tasks significantly related to

the service as part of selected ITSM
processes, in particular SPM and SLM (see:
process-specific role models)
• Report on the service to the SMS owner
Page 7 Version 2.2

6.4 Process owner

The process owner has overall accountability for the operation of an ITSM process.

Process owner • Act as the primary contact point for concerns 1 per process
in the context of governing one specific ITSM
(optional, see In many situations in
process
comment in right practice, the SMS
column) • Define and approve goals and policies in the owner takes over the
context of the process according to the role of the process
overall SMS goals and policies owner for all ITSM
processes. If this is the
• Nominate the process manager, and ensure
case, it is not required
he / she is competent to fulfil this role
to establish the
• Approve changes / improvements to the process owner role as
operational process, such as (significant) a dedicated role at all,
changes to the process definition since it is merged with
the SMS owner role.
• Decide on the provision of resources
dedicated to the process and its activities
• Based on process monitoring and reviews,

decide on necessary changes in the process-
specific goals, policies and provided
resources
Page 8 Version 2.2

6.5 Process manager

The process manager has overall responsibility for the effective operation of an ITSM process.

Process manager • Act as the primary contact point for 1 per process
operational concerns in the context of the
One person may take
process
over the process
• Maintain the process definition / description manager role for one
and ensure it is available to relevant persons or more processes.
• Maintain an adequate level of awareness and

competence of the people involved in the
process
• Monitor and keep track of the process

execution and results (incl. process reviews)
• Report on process performance to the

process owner
• Escalate to the process owner, if necessary
• Identify opportunities for improving the

effectiveness and efficiency of the process
• Additional tasks – depending on the specific

process (see: process-specific role models)
Page 9 Version 2.2

6.6 Case owner

The case owner takes accountability for the advancement of a specific case, e.g. an incident or
change. They follow this case from start to finish ensuring it is correctly managed.
Note: The role of a case owner is usually required in a process, if occurrences (e.g. incidents, service
requests, problems, changes, releases, …) or logical entities / artefacts (e.g. different types of
agreements, reports or plans, …) are managed by the process, and the process manager him- /
herself does not take over specific responsibility for all of these occurrences or entities. If no specific
case owner is defined and assigned for an important occurrence or artefact belonging to a process,
the process manager will own it by default.

Case owner • Overall responsibility for one specific case 1 per case
occurring in a process context (e.g. one
There may be different
specific incident to be resolved)
cases per process at a
• Act as the primary contact point for all time. One person or
concerns in the context of that specific case group may be assigned
the case owner role for
• Coordinate all activities required to handle /
one or more (or even
resolve the specific case
all) concurrent cases.
• Escalate exceptions to the process manager,
where required

6.7 Member of process staff

Process staff are individuals involved in the execution one or more activities within a process, but
not taking a steering role (e.g. as process or case managers).

Member of • Carry out defined activities according to the 1 or more per process
process staff defined / established process and, as
One person may take
applicable, its procedures (e.g. the activity of
(sometimes also over the member of
prioritizing an incident)
referred to as process staff role for
process • Report to the case owner and / or process one or more processes.
practitioner) manager

Page 10 Version 2.2

6.8 Summary and visualisation of the role model

The following figure is a visual summary of the generic role model, enhanced by an exemplary view
on some specific roles as they are addressed in detail in the subsequent section.
Page 11 Version 2.2

7. Process-specific ITSM roles

The roles presented in subsequent sections build the specific role model of FitSM. Every specific role
is presented in the context of the ITSM process in which it appears. Please note that this role model
is not necessarily exhaustive in any situation and ITSM setup in practice.
7.1 Context: Service Portfolio Management (SPM)

In a lightweight service management system, the following roles should be defined and assigned in
the specific context of the SPM process:
 Process owner SPM

 Process manager SPM

Process owner Generic tasks of a process owner applied in the 1 in total

SPM context of SPM
Process manager Generic tasks of a process manager, plus: 1 in total

SPM
• Maintain the service portfolio
• Manage updates to the service portfolio
• Review the service portfolio at planned

intervals
• Ensure new or changed services are planned

and designed according to the SPM process,
and service design and transition packages
are created and maintained
Page 12 Version 2.2

7.2 Context: Service Level Management (SLM)

the specific context of the SLM process:
 Process owner SLM

 Process manager SLM
 SLA / OLA / UA owner


SLM context of SLM

SLM
• Maintain the service catalogue
• Manage updates to the service catalogue
• Ensure the service catalogue is aligned with

the service portfolio
• Negotiate SLAs with customers
• Propose and negotiate OLAs with internal

groups or federation members
• Propose and negotiate UAs with external

suppliers
• Ensure that all SLAs, OLAs and UAs are

documented in a consistent manner
• Approve new or changed SLAs, OLAs and UAs
Ensure SLAs, OLAs and UAs are aligned to each other
SLA / OLA / UA • Maintain the SLA, OLA or UA under his/her 1 per SLA, OLA and UA
owner ownership and ensure it is specified and
documented according to relevant
specifications
• Evaluate the fulfillment of the SLA, OLA or UA
• Ensure that violations of the targets defined

in the SLA, OLA or UA are identified and
investigated to prevent future recurrence
• Perform regular reviews of the SLA, OLA or

UA
Page 13 Version 2.2

• Understand new or changed requirements on

the SLA, OLA or UA under his/her ownership,
and initiate necessary updates or other
follow-up actions
Page 14 Version 2.2

7.3 Context: Service Reporting Management (SRM)

the specific context of the SRM process:
 Process owner SRM

 Process manager SRM
 Service report owner


SRM context of SRM

SRM
• Maintain the list of service reports
• Review service report specifications in

regular intervals
• Monitor the production of accurate reports

according to specifications
Service report • Maintain the service report specification for 1 per service report
owner the report under his/her ownership
• Produce and deliver the service report

according to the specification
• Ensure that the input / contributions

required to produce the report is provided in
time
• Understand new or changed requirements on

the report under his/her ownership, and
update the report specification accordingly
Page 15 Version 2.2

7.4 Context: Service Availability & Continuity Management (SACM)

the specific context of the SACM process:
 Process owner SACM

 Process manager SACM
 Availability plan owner / continuity plan owner


SACM context of SACM

SACM
• Identify service availability and continuity
requirements

required to produce service availability and
continuity plans are provided by relevant
parties
• Produce, maintain and review all service

availability and continuity plans regularly
• Ensure that measures to increase service

availability and continuity (according to
plans) are planned and implemented under
the control of the change management
process
• Act as a contact point in case of questions

regarding service availability and continuity
requirements and measures
Availability plan • Create and maintain the availability or 1 per availability plan /
owner / continuity plan under his/her ownership continuity plan
continuity plan
• Ensure that relevant stakeholders in the
owner
context of the plan are consulted and
informed when creating, updating or
implementing the plan
• Ensure the plan and any updates to it are

approved according by relevant authorities
• Based on the contents of the final / approved

plan, raise requests for changes or trigger the
Page 16 Version 2.2

continual service improvement process as

required
• In case of a continuity plan: Ensure that the

needs for testing the plan are identified and
tests of preventive or reactive measures are
performed regularly
Page 17 Version 2.2

7.5 Context: Capacity Management (CAPM)

the specific context of the CAPM process:
 Process owner CAPM

 Process manager CAPM
 Capacity plan owner


CAPM context of CAPM

CAPM
• Identify service performance and capacity
requirements

required to produce capacity plans are
provided by relevant parties
• Produce, maintain and review capacity plans

regularly
• Ensure that measures to increase service

performance and capacity (according to
plans) are planned and implemented under
the control of the change management
process
• Act as a contact point in case of questions

regarding service performance and capacity
requirements and measures
Capacity plan • Create and maintain the capacity plan under 1 per capacity plan
owner his/her ownership
• Ensure that relevant stakeholders in the

context of the plan are consulted and
informed when creating, updating or
implementing the plan
• Ensure the plan and any updates to it are

approved according by relevant authorities
• Based on the contents of the final / approved

plan, raise requests for changes or trigger the
CSI process as required
Page 18 Version 2.2

7.6 Context: Information Security Management (ISM)

the specific context of the ISM process:
 Process owner ISM

 Process manager ISM
 Information security risk manager
 Asset owner
 Information security control owner


ISM context of ISM

ISM
• Act as the primary contact of the service
(Information provider for all information security-related
security manager issues
/ officer)
• Monitor the status and progress of all
activities connected to the process of
information security management, in
particular the maintenance of the asset
inventory, information security risk
assessment and handling of information
security events and incidents
• Ensure that information security incidents

are detected and classified as such as quickly
as possible, and handled in an effective way
to minimise harm caused by them
• Ensure that all security-related

documentation is maintained ad up-to-date
Information • Ensure that the asset inventory is complete 1 in total

security risk and up-to-date
manager
• Ensure that the asset owners maintain the
descriptions and classifications of the assets
under their ownership and provide other
information relevant for identifying and
assessing information security risks
• Perform a solid risk assessment periodically,

based on available information on assets to
Page 19 Version 2.2

be protected, as well as up-to-date

information on vulnerabilities and threats
• Update the risk assessment, whenever

necessary – in particular, if a significant risk
factor has changed
• Together with other experts, identify, plan,

implement and document information
security controls to treat risks
Asset owner • Maintain and review the description and 1 per (information)
classification of a specific (information) asset asset
in the asset inventory
• Act as a primary contact point for the asset

under his/her ownership
• Support the identification and analysis of

information security risks connected to the
asset under his/her ownership by providing
information / input to the risk assessment
Information • Maintain and review the specification / 1 per security control

security control documentation of a specific information
owner security control
• Act as a primary contact point and expert for

the control under his/her ownership
Page 20 Version 2.2

7.7 Context: Customer Relationship Management (CRM)

the specific context of the CRM process:
 Process owner CRM

 Process manager CRM
 Customer relationship manager (account manager)


CRM context of CRM

CRM
• Maintain the customer database
• Ensure that customer complaints are handled

according to the process
• Coordinate customer satisfaction surveys
• Review the results from customer service

reviews
Customer • Act as the primary contact point for a specific 1 per identified
relationship customer customer
manager
• Maintain the relationship with that customer
(Account by regular communication
manager)
• Process formal customer complaints
• Conduct, moderate and record customer

service reviews
Page 21 Version 2.2

7.8 Context: Supplier Relationship Management (SUPPM)

the specific context of the SUPPM process:
 Process owner SUPPM

 Process manager SUPPM
 Supplier relationship manager


SUPPM context of SUPPM

SUPPM
• Maintain the supplier database
• Ensure that supplier performance is

monitored according to the process
Supplier • Act as the primary contact point for a specific 1 per identified
relationship supplier supplier
manager
• Maintain the relationship with that supplier
by regular communication
• Maintain mechanisms for monitoring the

performance of the supplier
Page 22 Version 2.2

7.9 Context: Incident & Service Request Management (ISRM)

the specific context of the ISRM process:
 Process owner ISRM

 Process manager ISRM
 Incident owner / service request owner


ISRM context of ISRM

ISRM
• Ensure that all incidents and service requests
are recorded, and that records are of
sufficient quality to enable traceability and
long-term analysis
• Monitor the overall progress of incident

resolution and service request fulfilment, and
identify potential violations of target
response and resolution times
Incident owner / • Coordinate and take over overall 1 per incident / service
service request responsibility for all activities in the lifecycle request
owner of a specific incident or service request
• Monitor the progress of incident resolution or

request fulfilment taking into account agreed
timeframes
• Trigger reminders to those involved in

incident resolution or request fulfilment and
escalate to the process manager as required
• In case of a (potential) SLA violation, trigger

communication and escalation as defined in
the SLM process
• Ensure an adequate level of documentation

for the specific incident or service request
Page 23 Version 2.2

7.10 Context: Problem Management (PM)

the specific context of the PM process:
 Process owner PM
 Process manager PM
 Problem owner


PM context of PM

PM
• Ensure that incident trends are regularly
analysed to identify problems
• Ensure that identified problems are recorded,

and that records are of sufficient quality
• Ensure that problems are analysed,

information on known errors recorded, and
problems brought to closure
Problem owner • Coordinate and take over overall 1 per problem

responsibility for all activities in the lifecycle
of a specific problem, including problem
analysis and identification of options to
handle the problem
• Monitor the progress of problem resolution

and ensure that the problem is escalated
effectively, if required
• Ensure the information in the KEDB on this

problem / known error are up-to-date,
including appropriate descriptions of
potential workarounds
• Communicate the problem / known error and

potential workarounds to relevant
stakeholders (e.g. ISRM staff and users)
• Depending on the selected option for dealing

with the problem / known error, raise
requests for changes or trigger the CSI
process as required
Page 24 Version 2.2

7.11 Context: Configuration Management (CONFM)

the specific context of the CONFM process:
 Process owner CONFM

 Process manager CONFM
 CI owner


CONFM context of CONFM

CONFM
• Maintain the definitions of all CI and
relationship types
• Plan regular verifications of the configuration

information held in the CMDB
• Ensure that configuration verifications are

conducted and identified nonconformities
addressed
• Take a configuration baseline when needed
CI owner • Ensure that the information on a specific CI in 1 per CI

the CMDB is accurate and up-to-date
• Collaborate with the process manager and

other CI owners to ensure that all
information on the relationships from / to a
specific CI are accurate and up-to-date
Page 25 Version 2.2

7.12 Context: Change Management (CHM)

the specific context of the CHM process:
 Process owner CHM

 Process manager CHM
 Change requester
 Change owner
 Change advisory board (CAB)


CHM context of CHM

CHM
• Plan, schedule, prepare and moderate
change advisory board (CAB) meetings
• Maintain the list and descriptions of standard

changes, together with relevant technical
experts
• Ensure that all requests for changes are

processed effectively, and in a timely manner
• Monitor the overall progress of change

evaluation, approval and implementation
• Review the change records in regular

intervals, to identify trends or
nonconformities or poor documentation /
traceability
Change • Raise a request for change 1 per request for

requester change
• If necessary, provide additional information
to the change manager and represent the
change during a CAB meeting
Change owner • Control and coordinate all activities in the 1 per change
lifecycle of a specific change
• Monitor the progress of change evaluation

and implementation for this change
• Ensure that the change record is complete

and up-to-date at any time from recording
Page 26 Version 2.2

the request for change to completion of the

post implementation review
• As applicable, communicate with the release

owner of the release containing this change
Change advisory • Evaluate non-standard changes, taking into 1 board for a certain
board (CAB) account at least: number of changes
• Benefits
• Risks
• Potential impact
• Technical feasibility
• Effort / cost
• Decide on the approval of non-standard

changes, based on the evaluation results
Important notes:
• The CAB should be composed of (all) relevant

stakeholders of the changes that are
currently subject to evaluation and approval.
• CAB meetings should take place in regular

intervals, although the specific composition of
the CAB may / will vary.
Page 27 Version 2.2

7.13 Context: Release & Deployment Management (RDM)

the specific context of the RDM process:
 Process owner RDM

 Process manager RDM
 Release owner


RDM context of RDM

RDM
• Maintain the overall release planning,
including release cycles
• Review deployed releases fur success
Release owner • Control and coordinate the activities in the 1 per release
lifecycle of a specific release, including
planning, building, testing and deploying
• Ensure that the required documentation of

the release (including release plans) is
complete and of adequate quality
• Act as a single point of contact for the release

for all stakeholders of this release, including
the change manager, affected change
owners, developers, problem manager and
customer representatives.
Page 28 Version 2.2

7.14 Context: Continual Service Improvement Management (CSI)

the specific context of the CSI process:
 Process owner CSI

 Process manager CSI
 Improvement owner


CSI context of CSI

CSI
• Review the status and progress of ongoing
improvements in regular intervals
Improvement • Maintain the improvement under his/her 1 per improvement

owner ownership
• Coordinate the activities to implement the

improvement
Page 29 Version 2.2

8. Roles and federations

Federations vary widely, from very loose to tightly integrated. In order to effectively assign roles
across a federation it is important to understand the location of responsibility for each service
management process and its related activities. They may all reside within a single organisation that is
a fully integrated federator, or may be spread across organisations that cooperate to provide the
overall service(s).
In a tightly integrated situation, the model presented in the previous sections is straight-forward to
implement, but it is harder in looser federations. However, even if ITSM responsibility is spread
across multiple organisations, it still resembles a single-organisation service management system in
that there is a discrete hierarchy dealing with ITSM that is not the same as existing line
organisations. Thus, the three key factors, in all federation types are:
 An agreed upon SMS owner (see section 6.1) of sufficient seniority to oversee ITSM across
the whole federation;
 very clear communal understanding of the responsible organisation, unit or group for each
ITSM process;
 a joint agreement that the hierarchy within ITSM activities will be respected by other
hierarchies within the service provider or federation. Thus, process staff will follow
instructions and meet goals set by process owners and process managers, even if they are in
different legal organisations.
If these factors are considered, roles can be assigned in a federation just as they can within a single
organisation.
Page 30 Version 2.2

FitSM-3 Role Model

Uploaded by

Copyright:

Available Formats

FitSM-3 Role Model

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FitSM-3 Role Model

Uploaded by

Copyright:

Available Formats

Part 3: Recommended role model

Edition 2016 – Version 2.2

This work is licensed under a Creative Commons

7.14 Context: Continual Service Improvement Management (CSI) ...................................................... 29

 FitSM-0: Overview and vocabulary

Page 1 Version 2.2

3. Scope and applicability

4. Terms and definitions

Page 2 Version 2.2

5.1 Generic and specific roles

Description ITSM example Non-ITSM example

5.2 RACI matrix

 Responsible: A person or role actually executing / performing / carrying out a process or

Page 3 Version 2.2

Role 1 Role 2 Role 3 …

Page 4 Version 2.2

6. Generic ITSM roles

6.1 SMS owner

Role Tasks Ca. number of persons

• Nominate the process owners and/or

• Approve changes to the overall SMS

• Decide on the provision of resources

• Based on monitoring and reviews, decide on

Page 5 Version 2.2

6.2 SMS manager

Role Tasks Ca. number of persons

• Maintain the service management plan and

• Ensure IT service management processes are

• Maintain an adequate level of awareness and

• Monitor and keep track of the suitability,

• Report and, if necessary, escalate to the SMS

• Identify opportunities for improving the

Page 6 Version 2.2

6.3 Service owner

Role Tasks Ca. number of persons

• Maintain the core service documentation,

• Be kept informed of every event, situation or

• Be involved in tasks significantly related to

• Report on the service to the SMS owner

Page 7 Version 2.2

6.4 Process owner

Role Tasks Ca. number of persons

• Based on process monitoring and reviews,

Page 8 Version 2.2

6.5 Process manager

Role Tasks Ca. number of persons

• Maintain an adequate level of awareness and

• Monitor and keep track of the process

• Report on process performance to the

• Escalate to the process owner, if necessary

• Identify opportunities for improving the

• Additional tasks – depending on the specific

Page 9 Version 2.2

6.6 Case owner

Role Tasks Ca. number of persons

• Additional tasks – depending on the specific

6.7 Member of process staff

Role Tasks Ca. number of persons

• Additional tasks – depending on the specific

Page 10 Version 2.2