LP2: Design new or changed services
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
The service design process in YaSM (fig. 1) is about defining the required service properties, determining the infrastructure and other capabilities which are needed to provide the service. The process is also responsible for developing 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.
Compatibility: The YaSM design process is aligned with ISO 20000, the international standard for service management (see ISO/IEC 20000-1:2018, sections 5, 8 and 9), and it corresponds to the practice of 'ITIL 4 service design'.
Sub-processes
YaSM's service design process 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 service and SMS components
- 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 'service design'. 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 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.
- 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. See also: Checklist / document template 'Service definition'. [*]
- 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 document template 'Service definition' 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 design process.
Roles and responsibilities
Process owner: 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 service and SMS components | 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
Is based on: The service design process from the YaSM Process Map.
By: Stefan Kempter 
and Andrea Kempter , IT Process Maps.
Related articles
All popular service management frameworks and standards cover the topic of service design.
ITIL® 4 refers to service design as a practice. In addition, the current ITIL edition introduces service design as a key activity of the service value chain:
[ ... Read more ]
Nobody would dispute that service capacity and performance must be managed. But does that mean we need a capacity management process?
[ ... Read more ]
Process description › Sub-processes › Process outputs › Metrics › Roles
