SP2: Maintain the service portfolio: Difference between revisions
No edit summary |
No edit summary |
||
Line 140: | Line 140: | ||
==Process metrics== | ==Process metrics== | ||
Process metrics are used, for example, to assess if the service management processes are running according to expectations. | |||
For suggestions of [[Service Management Metrics|suitable metrics]], please refer to the [[Service_Management_Metrics#Metrics_for_the_portfolio_maintenance_process|list of metrics for the service portfolio maintenance process]]. | |||
<p> </p> | <p> </p> |
Revision as of 19:03, 2 December 2018
Process name: Maintain the service portfolio - Part of: Supporting service management processes
Previous process: Set up and maintain the service management system
Next process: Manage customer relationships
Process description
Service portfolio management in YaSM 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.
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).
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. [*]
- 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). [*]
- 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 example) 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: Service portfolio manager
- 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.
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.
Process description › Sub-processes › Process outputs › Metrics › Roles