SP1: Set up and maintain the service management system

From YaSM Service Management Wiki

auf Deutsch


 

Process name: Set up and maintain the service management system - Part of: Supporting processes

Next process: Maintain the service portfolio

 

Process description

One of the key principles in YaSM is that services should be managed through a service management system (SMS), in line with the requirements of ISO 20000, the leading service management standard (see ISO/IEC 20000-1:2018, sections 4 to 10).

Specifically, the YaSM process for maintaining the service management system (fig. 1) is responsible for designing, implementing, operating and continually improving the processes of the service provider organization, including the resources required to support the service management processes. It will also provide a complete set of service management policies which contain definitions and rules to direct the service provider's actions.

 

Fig. 1: Set up and maintain the service management system. - YaSM SMS maintenance process SP1.
Fig. 1: 'Set up and maintain the service management system (SMS)'
YaSM SMS maintenance process ('SP1').


The impetus for setting up or modifying service management processes often comes from service development projects, for example if the introduction of a new service requires an update to the incident resolution process.

It is also possible that a strategic review will lead to the conclusion that a process must be introduced or changed. Other than that, suggestions for process improvements may originate from anywhere in the service provider organization.

Note: If processes are operated by external parties, YaSM recommends treating such processes as external supporting services, to be managed through the service lifecycle processes.

Sub-processes

YaSM's process for setting up and maintaining the SMS has the following sub-processes:

SP1.1: Define process improvements
Process objective: To define the objectives of process improvement initiatives and the approach for their implementation. This includes creating business cases for the initiatives.
SP1.2: Start up process improvement initiatives
Process objective: To launch process improvement initiatives. This includes obtaining authorization by requesting a budget and submitting a request for change.
SP1.3: Design processes and policies
Process objective: To produce new or updated designs of service management processes, which are typically implemented through process improvement initiatives or as part of service development projects.
SP1.4: Implement process improvements
Process objective: To implement, test and deploy new service management processes or improvements to existing processes. This includes updating the related process documentation.
SP1.5: Monitor process improvement initiatives
Process objective: To assess if the process improvement initiatives are proceeding according to plan, and to introduce corrective measures where necessary.
SP1.6: Operate the processes
Process objective: To ensure the processes are operated effectively and efficiently, in line with the service provider's objectives. This includes managing the resources for operating the process, as well as reporting on process performance.
SP1.7: Perform process reviews
Process objective: To submit the service management processes to regular reviews or audits, and to identify potentials for improvement to be addressed by process improvement initiatives.

Process outputs

This section lists the documents and records produced by 'SMS maintenance'. YaSM data objects [*] are marked with an asterisk, while other objects are displayed in gray.

Budget request
A budget request is typically issued to obtain funding for setting up, improving or operating a service or process. An approved budget request means that the required financial resources have been allocated by the financial manager. [*]
Change record
A change record contains all details of a change, documenting the lifecycle of a single change. In its initial state, a change record describes a request for change (RFC) which is to be assessed and authorized prior to implementing the change. Further information is added as the change progresses through its lifecycle. [*]
Change status information
Current status information related to the implementation of a change. This information is sent to the change manager from the various processes that implement authorized changes. It is used by the change manager to keep the change records and the change schedule up-to-date.
CI record
Configuration information is maintained in CI records for all configuration items (CIs) under the control of the configuration manager. In this context, CIs can be of various types: Applications, systems and other infrastructure components are treated as CIs, but often also services, policies, project documentation, employees, suppliers, etc. Configuration information is stored in the configuration management system (CMS). [*]
Data for project plan update
Current information related to project progress and resource consumption. This information is sent from various service management processes to the project manager as input for project control.
Process improvement plan - PIP
Items in the process improvement plan (PIP) are used to record and manage process improvement initiatives throughout their lifecycle. There may be one process improvement plan for all processes or dedicated plans for particular processes managed by the service provider. The addition of new items to the PIP is often triggered by process reviews, although suggestions to improve processes may also come from other sources. [*]
Process metric
Process metrics are used to help manage a process. They are often designed to measure if a process is running successfully. As such, they are an essential input for continual process improvement. Process metrics also play an important role in steering the service provider’s resources. [*]
Process model
The process model provides an overview of the service management processes. It typically contains high-level views to illustrate the structure and interdependencies of the processes, and more detailed views to describe the processes' inputs and outputs, activities and responsibilities. The process model is an important tool for ensuring that all processes within the service provider organization cooperate in a seamless way. [*]
Process operation manual
A process operation manual specifies the activities required for the operation of a process and its underlying infrastructure. The information in the process operation manual is meant to describe the day-to-day tasks in a way that is useful for operational staff. Some instructions related to the operation of particular applications, systems or other infrastructure components may be documented in separate technical manuals or 'standard operating procedures (SOPs)'. [*]
Process review plan
The process review plan is maintained by the SMS manager to ensure all relevant processes and areas of the service provider organization are subjected to regular management reviews, audits, benchmarkings or maturity assessments, as appropriate. [*]
Process review report
A process review report records the details and findings from a process review or audit. This report is an important input for the definition of process improvement initiatives. See also: Process review report checklist. [*]
Purchase request
A request to procure goods or services from an external supplier. Purchasing requests are typically sent to the supplier manager, for example if applications, systems or other infrastructure components are needed for setting up a new service, or if standard infrastructure components and consumables are required for service operation.
Request to add skills and human resources
A request to add skills and human resources to the service provider organization, for example issued during service implementation if new or changed skills and/ or additional human resources are needed for a new service.
Request to assess compliance implications
A request to assess which compliance requirements are relevant for a new or changed service, typically issued during service design.
Request to assess continuity risks
A request to assess risks associated with critical events, typically issued during service design if new or changed service continuity arrangements are likely to be needed for a new or improved service.
Request to assess security risks
A request to assess security risks, typically issued during service design if new or changed security controls and mechanisms are likely to be needed for a new or improved service.
Service management policies
The service management policies represent a key element of the service management system, defining principles and rules to be followed in the service provider organization. The set of service management policies includes a top-level service management policy which is supported by a number of specific policies for the various service management processes. [*]
Suggested service modification
A suggestion for modifying a service, for example to improve service quality or economics. Suggestions may originate from anywhere within or outside of the service provider organization.
Suggested strategic initiative
A suggestion to start up a strategic initiative. Such suggestions often originate from service or process reviews if issues are detected whose resolution is beyond the scope of 'ordinary' service or process improvements.

 


Notes:

[*] "YaSM data objects" are those documents or records for which the YaSM model provides detailed recommendations: Every YaSM object has an associated checklist (see 'Process review report' template and more examples) describing its typical contents, and an associated lifecycle diagram depicting how the status of the object changes as it is created, updated, read and archived by various YaSM processes (see example).

"Other objects" are mostly informal data or information where YaSM has less strong views about their contents. There are no associated lifecycle diagrams or checklists.

Process metrics

Process metrics are used, for example, to assess if the service management processes are running according to expectations.

For suggestions of suitable metrics, please refer to the list of metrics for YaSM's SMS maintenance process.

Roles and responsibilities

Process owner: The SMS manager is responsible for setting up and maintaining the service management system. This role plays a key part in managing the service management processes and policies, ensuring that all elements of the SMS cooperate in a seamless way to achieve the service provider's objectives.

 

Responsibility matrix: 'SP1: Set up and maintain the service management system'
YaSM role / sub-process Compli. mgr. Oper. Proc. owner Secur. mgr. Serv. cont. mgr. SMS mgr. Techn. domain expert
SP1.1 Define process improve­ments R - R R R AR R
SP1.2 Start up process improve­ment initiatives - - R - - AR R
SP1.3 Design processes & policies R - R R - AR -
SP1.4 Implement process improve­ments - R R - - AR R
SP1.5 Monitor process impro­vement initiatives - - - - - AR
SP1.6 Operate the processes - R R - - A -
SP1.7 Perform process reviews - - - - - AR -

 

Notes

The SMS maintenance process in YaSM establishes, operates and continually improve sthe service management system (SMS). In particular, this process is responsible for managing the service management policies and processes, including the resources required to support the service management processes.
SMS maintenance process: Objectives

Is based on: The SMS maintenance process from the YaSM Process Map.

By:  Stefan Kempter Author: Stefan Kempter, IT Process Maps GbR  and  Andrea Kempter Contributor: Andrea Kempter, IT Process Maps GbR, IT Process Maps.

 

Process description  › Sub-processes  › Process outputs  › Metrics  › Roles