FitSM-3 Role model

Part 3: Role model Version 3.0.1 This work is licensed under a Creative Commons Attribution 4.0 International License. www.fitsm.eu FitSM-3: Role model FitSM was co-funded by the European Commission under contract number 312851. Document control Document title FitSM-3: Role model Document version 3.0.1 Release date 2024-05-22 Contents 1. Foreword ........................................................................................................................................... 1 2. About this document ......................................................................................................................... 1 3. Basic Role Concepts ........................................................................................................................... 2 3.1 Anatomy of a Role ........................................................................................................................... 2 3.2 Assigning Roles and the RACI matrix ............................................................................................... 2 4. General roles in an SMS ..................................................................................................................... 3 4.1 SMS Owner ...................................................................................................................................... 3 4.2 SMS manager ................................................................................................................................... 4 4.3 Additional possible general roles ..................................................................................................... 5 5. Approach to process ownership, management and execution ......................................................... 5 6. Process-specific roles in an SMS ........................................................................................................ 7 6.1 Context: Service Portfolio Management (SPM) ............................................................................... 7 6.2 Context: Service Level Management (SLM) ..................................................................................... 8 6.3 Context: Service Reporting Management (SRM) ............................................................................. 9 6.4 Context: Service Availability & Continuity Management (SACM) .................................................. 10 6.5 Context: Capacity Management (CAPM) ....................................................................................... 11 6.6 Context: Information Security Management (ISM) ....................................................................... 12 6.7 Context: Customer Relationship Management (CRM) .................................................................. 13 6.8 Context: Supplier Relationship Management (SUPPM) ................................................................. 13 6.9 Context: Incident & Service Request Management (ISRM) ........................................................... 14 6.10 Context: Problem Management (PM) ......................................................................................... 15 6.11 Context: Configuration Management (CONFM) .......................................................................... 16 6.12 Context: Change Management (CHM) ......................................................................................... 17 6.13 Context: Release & Deployment Management (RDM) ................................................................ 18 6.14 Context: Continual Service Improvement Management (CSI) ..................................................... 19 7. Role Model Overview ...................................................................................................................... 20 FitSM-1: Requirements Page 1 Version 3.0 1. Foreword FitSM is a lightweight standards family aimed at supporting the implementation of IT service management (ITSM), including federated scenarios. The FitSM approach is built on four key principles: practicality, consistency, sufficiency and extendibility. 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 maintained by ITEMO e.V., a non-profit partnership of specialists in the field of IT management, including experts from industry and research. FitSM is designed to be compatible with other ITSM frameworks such as the International Standard ISO/IEC 20000 and ITIL good practices. However, the FitSM process model, requirements, recommended activities and role model target a lightweight and more achievable implementation. The FitSM family is made up of several documents, providing guidance and input on different aspects of ITSM: • FitSM-0: Overview and vocabulary • FitSM-1: Requirements • FitSM-2: Process activities and implementation • FitSM-3: Role model (this document) • FitSM-4: Templates and samples (set of documents under continual development) • FitSM-5: 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. 2. About this document 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 responsibilities. FitSM-3 provides the set of basic roles that need to be assigned in order to establish 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. FitSM-3 supports FitSM-1: Requirements and FitSM-2: Process activities and implementation, in structuring 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, but it gives 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 organisations (e.g. commercial enterprises, government agencies, academia, non-profit organizations) from which IT services are provided, regardless of type, size and the nature of the services delivered. For the purpose of this standard, the terms and definitions according to FitSM-0: Overview and Vocabulary apply. FitSM-1: Requirements Page 2 Version 3.0 3. Basic Role Concepts In order to understand the role model presented here, we provide some basic concepts about how roles are built up within an SMS. 3.1 Anatomy of a Role A role, according to FitSM-0, is a set of responsibilities and connected behaviours or actions collected into a logical unit that can be assigned to an individual or group. In more detail, we might say a role is made up in the following way: Figure 1: Anatomy of a role • Each role has a context where the role operates, this is typically the entity which the role deals with. In some situations, this is as wide as a whole SMS, in other situations, it might be with a specific process or even just a single incident. • Each role must then have a definition: the list of tasks to be completed or responsibilities to be held regarding the context of the role. • Finally, an individual must be assigned to the role, must be aware of the assignment and have sufficient experience to fulfil the role, or alternatively, be offered sufficient training to fulfil the role. If a role includes a context, a clear definition and an assignment, we can say that this role has been implemented. As we will see in the following sections, some roles will only be implemented once, while others will be implemented many times in parallel. 3.2 Assigning Roles and the RACI matrix The RACI matrix is a tool to describe roles and responsibilities within a specific context in a simplified and easy to understand manner. While the roles described in this document may assist in assigning responsibilities within an SMS, there are often multiple individuals involved in a single issue, and division of responsibility and accountability is not always clear. A RACI matrix assists in clarifying this and can be a useful tool. The four letters R, A, C and I in the RACI matrix stand for the various generic forms of responsibility or participation: FitSM-1: Requirements Page 3 Version 3.0 ● 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 themself. ● Informed: A person or role who needs to be kept informed about the status and/or results of a process or activity. 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 … Figure 4 Example of a RACI matrix 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. 4. General roles in an SMS General roles within an SMS are those that address the whole SMS. They are mainly related to the General Requirements (GR 1-7) in FitSM-1: Requirements. 4.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 SMS. By means of effective governance, the SMS owner sets the key goals and provides overall direction for the SMS. Consequently, a person with sufficient authority, usually a person at the top management level, should take on this role. FitSM-1: Requirements Page 4 Version 3.0 Role Tasks Number of implemented roles SMS owner • Senior accountable owner of the entire service management system (SMS). • Overall accountability for all ITSM-related activities. • Act as the primary contact point for concerns in the context of governing the entire SMS. • Define and approve goals and policies for the entire SMS. • 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. 1 for the overall SMS Often, the person taking over the SMS owner role may also take over the process owner for the entirety or a subset of the ITSM processes. 4.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 regular project manager, the SMS manager is not released from their 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. Role Tasks Number of implemented roles SMS manager • Act as the primary contact point for all operational 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, particularly the process managers. • Monitor and keep track of the suitability, effectiveness and maturity of the entire SMS 1 for the overall SMS FitSM-1: Requirements Page 5 Version 3.0 • Manage risks across the SMS (unless there is an SMS-level Risk Manager role defined for this SMS). • Report and, if necessary, escalate to the SMS owner. • Identify opportunities for improving the effectiveness and efficiency of the SMS. 4.3 Additional possible general roles The roles above provide a minimum set of general roles, but others can be imagined based on the general requirements GR1-GR7 or based on topics that arise in multiple processes. For example, from GR2 Documentation (DOC), an SMS-wide Documentation officer could be considered, charged with ensuring all documentation is consistent across an organisation. Equally, Internal Auditors mandated under GR6 Monitoring & Reviewing IT Service Management (CHECK) could be considered. Another example might be in the area of risk management. Risks are specifically identified in FitSM as part of PR4: Service Availability and Continuity management and also in PR6 Information Security Management (ISM). In some situations, it may make sense to consider a Risk manager spanning all processes. None of these are required by FitSM, but these and other general roles may be defined as needed in the specific context of the service provider. 5. Approach to process ownership, management and execution This document sets out a basic set of roles needed in order to implement service management processes and a service management system according to FitSM. Although most roles involve specific tasks tailored to their respective processes and contexts, there are recurring role patterns that consistently appear throughout the model. These are explained in this section. For each process, we have a ‘Process owner’ and a ‘Process manager’, analogous to the SMS owner and SMS manager seen in the previous section. In general, the ‘Process owner’ roles are more related to oversight than direct control of a process, analogous to the Accountability option on the RACI matrix presented in a previous section. In practice, the ‘Process owner’ roles are often combined with the SMS owner in practice, though this requires more engagement by the SMS owner. In general, ‘Process manager’ roles take operational control of a process and are the day-to-day leader of the process activities, their role being closer the ‘Responsible’ option in a RACI matrix. They oversee process activities and process staff and escalate issues to the ‘Process owner’ roles. Next, we have a common type in ‘case owner’ roles. Cases are entities that exist within processes repeatedly, and which occur multiple times, often in high numbers. Examples of cases are Incident records (tickets), SLAs, customers or even services. We cannot predict how many cases of each type will occur in advance, but certainly we expect many incident tickets over time, and hopefully many FitSM-1: Requirements Page 6 Version 3.0 customers. We cannot assume that assigning one role to cover all cases of one type will be effective, as each may need different skills. Rather, we assign an owner for each case, to handle it through its lifetime. This role may of course be reassigned over time, and one individual may handle multiple similar cases at once, but this ensures that all important entities within an SMS have some level of oversight. Case owners are often both responsible for a case, and accountable to some extent, however, it is more often accountable for the case being adequately managed and not being ignored, rather than making high level decisions about it. In this way, for instance, the owner of a proposed change may be required to ensure it is fairly discussed, and costs and benefits assessed in a timely manner, but are not themselves the one that makes a decision on whether it is ultimately implemented. Finally, we have process staff members. This role is given to anyone performing tasks in a process without performing one of the other role types described above. This is often for those with operational tasks such as following set procedures within the process. Often, those with more specific roles on one process may act as staff members in other processes at the same time. The following table gives the common tasks for these three common types of roles. These are referred to from the process specific roles in subsequent sections. Common role type Common tasks Process owners of the 14 processes • Act as the primary contact point for concerns in the context of governing one specific ITSM process. • Define and approve goals and policies in the context of the process according to the overall SMS goals and policies. • Nominate the process manager, and ensure they are competent to fulfil this role. • Approve changes / improvements to the operational process, such as (significant) changes to the process definition. • 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. Process managers of the 14 processes • Act as the primary contact point for operational concerns in the context of the process. • Maintain the process definition / description and ensure it is available to relevant persons. • 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). • Manage risks that involve this process (unless there is a processspecific role that manages risks in this context). • Report on process performance to the process owner. FitSM-1: Requirements Page 7 Version 3.0 • 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 processspecific role models). Case Owner • Overall responsibility for one specific case occurring in a process context (e.g. one specific incident to be resolved). • Act as the primary contact point for all concerns in the context of that specific case. • Coordinate all activities required to handle / resolve the specific case. • Escalate exceptions to the process manager, where required. • Additional tasks – depending on the specific process (see processspecific role models). Process staff member • Carry out tasks according to the defined / established process and, as applicable, its activities and procedures (e.g. the procedure of prioritizing an incident). • Report to case owners and / or process managers, as appropriate. • Contribute to the effectiveness and continual improvement of the process. 6. Process-specific roles in an SMS 6.1 Context: Service Portfolio Management (SPM) The following roles should be defined and assigned in the specific context of the SPM process: ● Process owner SPM ● Process manager SPM Role Tasks Number of implemented roles Process owner SPM Generic tasks of a process owner (see section 5) applied in the context of SPM. 1 in total Process manager SPM Generic tasks of a process manager (see section 5), plus: • Maintain the service portfolio. • Manage updates to the service portfolio. • Ensure the lifecycle of new or changed services are managed and appropriate plans are created and maintained. 1 in total FitSM-1: Requirements Page 14 Version 3.0 Role Tasks Number of implemented roles Process owner SUPPM Generic tasks of a process owner (see section 5) applied in the context of SUPPM 1 in total Process manager SUPPM Generic tasks of a process manager (see section 5), plus: • Maintain the supplier database. • Ensure that supplier performance is monitored according to the process. 1 in total Case owner: Supplier relationship manager • Act as the primary contact point for a specific supplier. • Maintain the relationship with that supplier by regular communication. • Maintain mechanisms for monitoring the performance of the supplier. 1 per identified supplier 6.9 Context: Incident & Service Request Management (ISRM) The following roles should be defined and assigned in the specific context of the ISRM process: ● Process owner ISRM ● Process manager ISRM ● Case owner: Incident owner / service request owner Role Tasks Number of implemented roles Process owner ISRM Generic tasks of a process owner (see section 5) applied in the context of ISRM 1 in total Process manager ISRM Generic tasks of a process manager (see section 5), plus: • 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. 1 in total FitSM-1: Requirements Page 15 Version 3.0 Case owner: Incident owner / service request owner • Coordinate and take over overall responsibility for all activities in the lifecycle 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. 1 per incident / service request 6.10 Context: Problem Management (PM) The following roles should be defined and assigned in the specific context of the PM process: ● Process owner PM ● Process manager PM ● Case owner: Problem owner Role Tasks Number of implemented roles Process owner PM Generic tasks of a process owner (see section 5) applied in the context of PM 1 in total Process manager PM Generic tasks of a process manager (see section 5), plus: • 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. 1 in total Case owner: Problem owner • Coordinate and take over overall responsibility for all activities in the lifecycle of a specific problem, including problem analysis and identification of options to handle the problem. 1 per problem FitSM-1: Requirements Page 16 Version 3.0 • 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. 6.11 Context: Configuration Management (CONFM) The following roles should be defined and assigned in the specific context of the CONFM process: ● Process owner CONFM ● Process manager CONFM ● Case owner: Configuration item (CI) owner Role Tasks Number of implemented roles Process owner CONFM Generic tasks of a process owner (see section 5) applied in the context of CONFM 1 in total Process manager CONFM Generic tasks of a process manager (see section 5), plus: • Maintain and periodically review the scope and granularity of the CMDB. • 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. 1 in total Case owner: CI owner • Ensure that the information on a specific CI in the CMDB is accurate and up to date. • Collaborate with the process manager and other CI owners to ensure that all information on the 1 per CI FitSM-1: Requirements Page 17 Version 3.0 relationships from / to a specific CI are accurate and up to date. 6.12 Context: Change Management (CHM) The following roles should be defined and assigned in the specific context of the CHM process: ● Process owner CHM ● Process manager CHM ● Case owner: Change owner ● Change advisory board (CAB) member Role Tasks Number of implemented roles Process owner CHM Generic tasks of a process owner (see section 5) applied in the context of CHM 1 in total Process manager CHM Generic tasks of a process manager (see section 5), plus: • 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. 1 in total Case owner: Change owner • Control and coordinate all activities in the 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 the request for change to completion of the post implementation review. • As applicable, communicate with the Release owner of the release containing this change. 1 per change FitSM-1: Requirements Page 18 Version 3.0 Change advisory board (CAB) • Evaluate non-standard changes, taking into account at least: o Benefits o Risks o Potential impact o Technical feasibility o Effort / cost • Decide on the approval of non-standard changes, based on the evaluation results. • Decide which changes can be considered preapproved in the future. 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 at regular intervals, although the specific composition of the CAB may / will vary. 1 board for a certain number of changes 6.13 Context: Release & Deployment Management (RDM) The following roles should be defined and assigned in the specific context of the RDM process: ● Process owner RDM ● Process manager RDM ● Case owner: Release owner Role Tasks Number of implemented roles Process owner RDM Generic tasks of a process owner (see section 5) applied in the context of RDM 1 in total Process manager RDM Generic tasks of a process manager (see section 5), plus: • Maintain the overall release planning, including release cycles. • Manage the release and deployment strategies defined for the SMS. • Apply the release and deployment strategies to defined groups of components, as appropriate. • Review deployed releases for success. 1 in total FitSM-1: Requirements Page 19 Version 3.0 Case owner: Release owner • Identify the appropriate release and deployment strategy for a specific release. • Control and coordinate the activities in the 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. 1 per release 6.14 Context: Continual Service Improvement Management (CSI) The following roles should be defined and assigned in the specific context of the CSI process: ● Process owner CSI ● Process manager CSI ● Case owner: Improvement owner Role Tasks Number of implemented roles Process owner CSI Generic tasks of a process owner (see section 5) applied in the context of CSI 1 in total Process manager CSI Generic tasks of a process manager (see section 5), plus: • Review the status and progress of ongoing improvements in regular intervals. 1 in total Case owner: Improvement owner • Maintain the improvement under their ownership. • Coordinate the activities to implement the improvement. 1 per improvement FitSM-1: Requirements Page 20 Version 3.0 7. Role Model Overview The main types of roles described in this role model, including the general and process specific roles, can be visualised as follows: . Figure 2: Visualisation of roles within the SMS We can also extend this visualisation with specific process and examples: Figure 3: Visualisation of roles within the SMS with examples