LP2: Design new or changed services

From YaSM Wiki
Jump to: navigation, search

share this page on LinkedInshare this page on Twittershare this page
auf Deutsch

 

Process name: Design new or changed services - Part of: Service lifecycle processes

Previous process: Set the strategic direction

Next process: Build new or changed services

 

Process description

Fig. 1: Design new or changed services. - YaSM service design process LP2.
Figure 1: 'Design new or changed services'. - YaSM service lifecycle process LP2.

The main responsibilities of YaSM's service design process ("LP2: Design new or changed services") are to define the required service properties, to determine the infrastructure and other capabilities which are needed to provide the service, and to develop the approach for implementing new or changed services.

While the service design process carries out the service design activities, the project management process will typically be in charge of overall planning and coordination of the service development project.

 

Sub-processes

YaSM's service design process 'LP2: Design new or changed services' has the following sub-processes:

 

LP2.1: Define required service properties
Process objective: To define the expected outcome and the required properties of a new or changed service. This includes defining the properties of any supporting services which must be set up or modified in order to be able to deliver the new service.


LP2.2: Design required infrastructure
Process objective: To specify the required infrastructure and other capabilities which must be created before a new or changed service can be provided.


LP2.3: Outline the implementation approach
Process objective: To describe how the infrastructure and other capabilities required for providing a new or changed service will be created.


LP2.4: Prepare the service implementation
Process objective: To submit the service design documents to a final review and to decide if the service is ready for implementation. This includes submitting one or several RFCs to the change assessment process.

 

Process outputs

This section lists the documents and records produced by 'Design new or changed services'. 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.


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.


Pricing scheme
A pricing scheme is the basis for calculating the price a customer is expected to pay for using a service. Pricing schemes are maintained by the financial manager and may be simple or more complex, especially if the price to be paid is tied to actual service usage or service quality. A description of the applicable pricing scheme is also part of the service agreements.


Request to add services to the service portfolio
A request from a service management process to add new (versions of) services to the service portfolio. This request is sent to the service portfolio manager if new or significantly changed services are being created.


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 disaster 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.


Requirements specification
A requirements specification document contains a complete description of the behavior of an application, system or other infrastructure item that is to be developed or acquired. Requirements specifications typically include functional and non-functional requirements, such as performance requirements or design constraints. The contents and degree of detail will vary depending on the nature of the system specified and the purpose of the specification. [*]


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 implementation blueprint
The service implementation blueprint builds upon the specifications in the service definitions. It describes from a technical and organizational perspective what capabilities are required in order to be able to offer a new or changed service, and outlines the approach to creating the required service infrastructure and other capabilities. The service implementation blueprint is an important input for project planning and service implementation. [*]

 


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 design process.

 

Roles and responsibilities

Process owner: Service design manager

  • The service design manager is responsible for the detailed specification of the requirements for new or changed services, as well as identifying a suitable approach for their implementation.

 

Responsibility matrix: "LP2: Design new or changed services"
YaSM role / sub-process Compli. mgr. Financ. mgr. Proc. owner Secur. mgr. Serv. contin. mgr. Serv. design mgr. Serv. owner Serv. portf. mgr. Suppl. mgr. Techn. domain expert
LP2.1 Define required service properties R R - R R AR R R R -
LP2.2 Design required infrastructure R - R R R AR R - - R
LP2.3 Outline the implementation approach - - - - - AR R - - R
LP2.4 Prepare the service implementation - - - - - AR R - - R

 

Notes

YaSM LP2: Design new or changed services. - Thumbnail.

Is based on: The service design process from the YaSM Process Map.

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

 

Related blog posts

YaSM's service design process contains the activities to design new or substantially changed services.

YaSM and service design

by: Stefan Kempter

Many people find 'service design according to ITIL' a bit baffling while YaSM's service design process is quite straightforward: [...]

 

In ITIL®, capacity management is part of service design. Do we really need a capacity management process?

Where is capacity management?

by: Stefan Kempter

In ITIL®, there's a capacity management process as part of service design. Nobody would dispute that service capacity and performance must be managed. But does that mean we need a capacity management process? [...]

 

Process description Sub-processes Process outputs Metrics Roles