LP3: Build new or changed services
Process name: Build new or changed services - Part of: Service lifecycle processes
Previous process: Design new or changed services
Next process: Operate the services
Process description
Once service design has defined the implementation approach, the service build process in YaSM (fig. 1) will create, test and deploy the required infrastructure, supporting services, documentation and other service components.
Other processes may be called upon if specific capabilities must be upgraded due to the introduction of a new service. For example, it may be necessary to
- Modify service management processes.
- Adapt the security mechanisms and controls.
- Update the service continuity arrangements.
- Develop new skills..
During the service build activities, the project management process will typically be in charge of overall planning and coordination of the service development project.
Compatibility: The YaSM service build process is aligned with ISO 20000, the international standard for service management (see ISO/IEC 20000-1:2018, sections 8.5 and 8.7), and it corresponds to various ITIL practices, such as 'ITIL 4 release management' and 'ITIL 4 service validation and testing'.
Sub-processes
YaSM's service build process has the following sub-processes:
- LP3.1: Coordinate development and procurement activities
- Process objective: To initiate and coordinate the activities for developing and procuring the service components and service management system (SMS) components required for a new or changed service.
- LP3.2: Develop applications and systems
- Process objective: To develop or configure applications and systems which provide the required functionality for services. This process includes the development of custom applications and systems as well as the customization and configuration of products procured from external vendors.
- LP3.3: Accept delivery of the service components
- Process objective: To receive the required service components and submit them to an initial assessment. This process ensures that only components which meet stringent quality criteria are allowed to enter the main service testing stage.
- LP3.4: Create or update operational documentation
- Process objective: To provide guidance for operating the new service, for example by creating or updating service operation manuals and standard operating procedures.
- LP3.5: Test the service components
- Process objective: To test all service components as well as all tools and mechanisms required for deployment. This process ensures that only components which meet stringent quality criteria are deployed into the live productive environment.
- LP3.6: Deploy the service components
- Process objective: To deploy the service components into the live production environment. This process is also responsible for configuring operational systems and training end-users and operating staff.
- LP3.7: Prepare the service activation
- Process objective: To assess if all infrastructure and other capabilities are in place before authorizing activation of the new services.
Process outputs
This section lists the documents and records produced by the service build process. YaSM data objects [*] are marked with an asterisk, while other objects are displayed in gray.
- 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). [*]
- Confirmation of successful deployment
- A confirmation that the deployment of service components has been completed successfully, typically issued during service implementation if new or changed applications or systems must be deployed for a new service.
- 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.
- Development QA documentation
- A documentation of tests and quality assurance measures applied during the development or configuration of applications, systems and other infrastructure components. The QA documentation testifies that the required component-level QA measures were applied prior to admitting an infrastructure component into service testing.
- Incident model
- An incident model contains the pre-defined steps that should be taken for dealing with a particular type of incident. The aim of providing incident models is to ensure that recurring incidents are handled efficiently and effectively. [*]
- Problem record
- A set of data with all details of a problem, documenting the history of the problem from registration to closure. A problem is defined as the underlying cause of one or more (potential) incidents, although the cause may not be known at the time a problem record is created. Often, a workaround is provided for a problem while a full resolution is not yet available. See also: Problem record checklist. [*]
- Purchase request
- A request to procure goods or services from an external supplier. Purchasing requests are typically sent to the supplier manager, for example if applications, systems or other infrastructure components are needed for setting up a new service, or if standard infrastructure components and consumables are required for service operation.
- Recovery plan
- Recovery plans contain detailed instructions for returning specific services and/ or systems to a working state, which often includes recovering data to a defined consistent state. [*]
- Request to add skills and human resources
- A request to add skills and human resources to the service provider organization, for example issued during service implementation if new or changed skills and/ or additional human resources are needed for a new service.
- 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 develop applications or systems
- A request for the development or customization of an application or system, typically issued during service implementation if new or changed applications or systems are needed for a new service.
- Request to set up an external service
- A request to set up an external supporting service, typically issued during service implementation if new or changed external supporting services are needed for a new service.
- Request to update the service management processes
- A request to update the service provider's processes, typically issued during service implementation if new or changed processes are needed for a new 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: Checklist / document template 'Service definition'. [*]
- Service operation manual
- A service operation manual specifies the activities required for the operation of a service and its underlying infrastructure. The information in the service operation manual is meant to describe the day-to-day tasks in a way that is useful for operational staff. Some instructions related to the operation of particular applications, systems or other infrastructure components may be documented in separate technical manuals or 'standard operating procedures (SOPs)'. [*]
- Service readiness confirmation
- The service readiness confirmation documents the results of a service readiness assessment. A service is assessed for readiness before being allowed to go operational, using a set of criteria that relate, in particular, to the service provider’s ability to operate the service. Once it is confirmed that the service readiness criteria are fulfilled, a service can be marked as 'active' in the service portfolio. [*]
- Service request model
- Service request models contain the pre-defined steps that should be taken for dealing with a particular type of service request. The aim of providing service request models is to ensure that routinely occurring requests are handled efficiently and effectively. [*]
- Technical manual
- A document describing the procedures required to run and maintain a system or infrastructure component. Technical manuals are often provided by external product suppliers or internal development teams.
- Test report
- A test report provides a detailed account of testing activities. A test report is created for example during tests of new or changed service components, or during tests of security or service continuity mechanisms. [*]
- Test script
- A test script specifies a set of test cases including their expected outcomes. The nature of the test cases will vary depending on what is to be tested. [*]
- User manual
- A document for end-users, describing how to use a type of application or system.
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 'Problem record' 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 build process.
Roles and responsibilities
Process owner: The service implementation manager is responsible for coordinating the implementation of new or significantly changed services. In particular, the service implementation manager ensures that all service infrastructure and other required capabilities are properly tested and deployed.
| YaSM role / sub-process | Applic./ System devlp. | Cust. | Oper. | Service implmnt. mgr. | Serv. owner | Techn. domain expert | Test mgr. | |
|---|---|---|---|---|---|---|---|---|
| LP3.1 | Coordinate development and procurement activities | - | - | - | AR | - | - | - |
| LP3.2 | Develop applications and systems | AR | - | - | - | - | - | - |
| LP3.3 | Accept delivery of the service components | - | - | - | A | - | - | R |
| LP3.4 | Create or update operational documentation | - | - | - | AR | R | R | - |
| LP3.5 | Test the service components | - | R | R | A | - | - | R |
| LP3.6 | Deploy the service components | - | - | R | AR | - | - | - |
| LP3.7 | Prepare the service activation | - | - | - | AR | - | - | - |
Notes
Is based on: The service build process from the YaSM Process Map.
By: Stefan Kempter 
and Andrea Kempter , IT Process Maps.
Related articles
YaSM and the service transition stage
Service transition has been a prominent topic in service management since the advent of ITIL v3, where service transition is one of the five service lifecycle stages. ITIL® 4 has dropped the service lifecycle concept, but most familiar ITIL processes from the service transition stage have found their way into ITIL 4 as "practices":
[ ... Read more ]
Process description › Sub-processes › Process outputs › Metrics › Roles
