LP2: Design new or changed services
Previous process: Set the strategic direction
Next process: Build new or changed services
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.
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.
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. [*]
[*] "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 are used, for example, to assess if the service management processes are running according to expectations.
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.
|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|
Is based on: The service design process from the YaSM Process Map.
Related blog posts
by: Stefan Kempter
Many people find 'service design according to ITIL' a bit baffling while YaSM's service design process is quite straightforward: [...]
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? [...]