SP2: Maintain the service portfolio

From YaSM Service Management Wiki
Revision as of 14:00, 30 May 2024 by Andrea (talk | contribs)

auf Deutsch


 

Process name: Maintain the service portfolio - Part of: Supporting processes

Previous process: Set up and maintain the service management system

Next process: Manage customer relationships

 

Process description

The service portfolio management process in YaSM (fig. 1) is responsible for controlling all changes to the service portfolio. The process makes sure that the information in the service portfolio and the related service definitions are an accurate representation of the range of services managed by the service provider.

Fig. 1: Maintain the service portfolio. - YaSM service portfolio management process SP2. - Related with: Practices of ITIL 4 portfolio management and ITIL 4 service catalogue management.
Fig. 1: 'Maintain the service portfolio'
YaSM service portfolio management process ('SP2').


Changes to the service portfolio are usually the result of new services being proposed or built, or existing services being modified.

The service portfolio and the service definitions are an important input for most YaSM processes. For example, the definitions of customer services are the basis for setting up customer service agreements. Since the service definitions specify the service quality to be delivered, they are also a crucial input for service operation.

YaSM's service portfolio process also maintains the operational service agreements. As a rule, whenever a new or changed supporting service is ready to be activated in the service portfolio, the service portfolio manager will ensure that an operational service agreement is signed with the responsible service owner.

Note: Customer service agreements are managed by the customer relationship manager role (as soon as a customer service is activated in the service portfolio, customers may sign up for it).

 

Compatibility: The YaSM portfolio management process is aligned with ISO 20000, the international standard for service management (see ISO/IEC 20000-1:2018, sections 7 and 8.2), and it corresponds to the practices of 'ITIL 4 portfolio management' and 'ITIL 4 service catalogue management'.

Sub-processes

YaSM's service portfolio management process has the following sub-processes:

SP2.1: Add new or changed services to the service portfolio
Process objective: To add information about (planned) new or significantly changed services to the service portfolio.
SP2.2: Update the service portfolio
Process objective: To update information in the service portfolio, for example after the completion of a service improvement initiative.
SP2.3: Activate new or changed services
Process objective: To verify that new or significantly changed services are ready to go operational, and to obtain formal approval for service activation.
SP2.4: Review the service portfolio
Process objective: To submit the service portfolio to regular reviews, in order to detect errors in the service portfolio or inconsistencies between service definitions and/ or service agreements.

Process outputs

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

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). [*]
Operational service agreement
An agreement between a service provider and a part of the same organization for supplying a supporting service as specified in the service definition. A signed operational service agreement represents a commitment by an organizational unit within the service provider to supply a supporting service in line with the agreed quality, at a specified cost. A single agreement may cover multiple services. [*]
Request to change the configuration model
A request from a service management process to change the configuration model. This request is sent to the configuration manager if new CIs or CI attributes must be documented in the CMS but the CMS's structure is not adequate for holding the new data.
Request to update customer service agreements
A request to the business relationship manager to update one or several customer service agreements, for example following the modification of a service.
Service definition
A service definition specifies the service properties, in particular the offered functionality and the guaranteed service levels. Service definitions also describe how the organization's resources are used in order to provide the service. A service can be provided using one or several other (internal or external) supporting services. See also: Service definition checklist. [*]
Service portfolio
The service portfolio represents a complete list of all services managed by the service provider. Some of these services are visible to the customers (customer services), while others are not (supporting services, which can be provided with internal or external resources). See also: Service portfolio checklist. [*]
Service portfolio review report
A service portfolio review report records the details and findings from a service portfolio review. In particular, this report will highlight any detected inconsistencies within the service portfolio. [*]
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.

 


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 'Service definition' template or 'Service portfolio' 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 the service portfolio maintenance process.

Roles and responsibilities

Process owner: The service portfolio manager is responsible for managing the service provider's range of services. This includes making sure that the information in the service portfolio and any service definitions are accurate and up-to-date. The service portfolio manager will also support the steering group during strategic assessments of the service portfolio.

 

Responsibility matrix: 'SP2: Maintain the service portfolio'
YaSM role / sub-process Service owner Service portfolio manager
SP2.1 Add new or changed services to the service portfolio - AR
SP2.2 Update the service portfolio R AR
SP2.3 Activate new or changed services R AR
SP2.4 Review the service portfolio R AR

 

Notes

Is based on: The Service portfolio management 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