LP3: Build new or changed services: Difference between revisions

From YaSM Service Management Wiki
No edit summary
No edit summary
Line 71: Line 71:


<p><i><u>Compatibility</u>: The YaSM service build process is <a href="/wiki/en/index.php/YaSM_and_ISO_20000#ISO_20000_requirements_and_related_service_management_processes" title="YaSM und ISO 20000">aligned with ISO 20000</a>, the international standard for service management (see ISO/IEC 20000-1:2018, sections <a href="/wiki/en/index.php/YaSM_and_ISO_20000#Service-design-build-and-transition" title="ISO 20000, section 8.5: Service design, build and transition">8.5</a> and <a href="/wiki/en/index.php/YaSM_and_ISO_20000#Service-assurance" title="ISO 20000 section 8.7: Service assurance">8.7</a>), and it corresponds to various ITIL practices, such as '<a href="/wiki/en/index.php/YaSM_and_ITIL#ITIL-4-Release-management" title="ITIL 4 practices and YaSM processes: ITIL 4 release management">ITIL 4 release management</a>' and '<a href="/wiki/en/index.php/YaSM_and_ITIL#ITIL-4-Service-validation-and-testing" title="ITIL 4 practices and YaSM processes: ITIL 4 service validation and testing">ITIL 4 service validation and testing</a>'.</i></html>
<p><i><u>Compatibility</u>: The YaSM service build process is <a href="/wiki/en/index.php/YaSM_and_ISO_20000#ISO_20000_requirements_and_related_service_management_processes" title="YaSM und ISO 20000">aligned with ISO 20000</a>, the international standard for service management (see ISO/IEC 20000-1:2018, sections <a href="/wiki/en/index.php/YaSM_and_ISO_20000#Service-design-build-and-transition" title="ISO 20000, section 8.5: Service design, build and transition">8.5</a> and <a href="/wiki/en/index.php/YaSM_and_ISO_20000#Service-assurance" title="ISO 20000 section 8.7: Service assurance">8.7</a>), and it corresponds to various ITIL practices, such as '<a href="/wiki/en/index.php/YaSM_and_ITIL#ITIL-4-Release-management" title="ITIL 4 practices and YaSM processes: ITIL 4 release management">ITIL 4 release management</a>' and '<a href="/wiki/en/index.php/YaSM_and_ITIL#ITIL-4-Service-validation-and-testing" title="ITIL 4 practices and YaSM processes: ITIL 4 service validation and testing">ITIL 4 service validation and testing</a>'.</i></html>
<p>&nbsp;</p>


==Sub-processes==
==Sub-processes==


<html>YaSM's service build process has the following sub-processes:</p>
<html>YaSM's service build process has the following sub-processes:</p>
<p>&#160;</p>


<!-- define schema.org/CreativeWork -->
<!-- define schema.org/CreativeWork -->
Line 85: Line 83:
<dd itemprop="description">Process objective: To initiate and coordinate the activities for developing or procuring the infrastructure components and other capabilities required for a new or changed service.</dd></dl>
<dd itemprop="description">Process objective: To initiate and coordinate the activities for developing or procuring the infrastructure components and other capabilities required for a new or changed service.</dd></dl>
</div>
</div>
<p><br /></p>
<div itemid="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#LP3.2" itemscope itemtype="https://schema.org/CreativeWork" itemref="md-type-subProcess">
<div itemid="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#LP3.2" itemscope itemtype="https://schema.org/CreativeWork" itemref="md-type-subProcess">
<meta itemprop="alternateName" content="YaSM service build process LP3.2" />
<meta itemprop="alternateName" content="YaSM service build process LP3.2" />
Line 91: Line 88:
<dd itemprop="description">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.</dd></dl>
<dd itemprop="description">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.</dd></dl>
</div>
</div>
<p><br /></p>
<div itemid="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#LP3.3" itemscope itemtype="https://schema.org/CreativeWork" itemref="md-type-subProcess">
<div itemid="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#LP3.3" itemscope itemtype="https://schema.org/CreativeWork" itemref="md-type-subProcess">
<meta itemprop="alternateName" content="YaSM service build process LP3.3" />
<meta itemprop="alternateName" content="YaSM service build process LP3.3" />
Line 97: Line 93:
<dd itemprop="description">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.</dd></dl>
<dd itemprop="description">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.</dd></dl>
</div>
</div>
<p><br /></p>
<div itemid="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#LP3.4" itemscope itemtype="https://schema.org/CreativeWork" itemref="md-type-subProcess">
<div itemid="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#LP3.4" itemscope itemtype="https://schema.org/CreativeWork" itemref="md-type-subProcess">
<meta itemprop="alternateName" content="YaSM service build process LP3.4" />
<meta itemprop="alternateName" content="YaSM service build process LP3.4" />
Line 103: Line 98:
<dd itemprop="description">Process objective: To provide guidance for operating the new service, for example by creating or updating service operation manuals and standard operating procedures.</dd></dl>
<dd itemprop="description">Process objective: To provide guidance for operating the new service, for example by creating or updating service operation manuals and standard operating procedures.</dd></dl>
</div>
</div>
<p><br /></p>
<div itemid="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#LP3.5" itemscope itemtype="https://schema.org/CreativeWork" itemref="md-type-subProcess">
<div itemid="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#LP3.5" itemscope itemtype="https://schema.org/CreativeWork" itemref="md-type-subProcess">
<meta itemprop="alternateName" content="YaSM service build process LP3.5" />
<meta itemprop="alternateName" content="YaSM service build process LP3.5" />
Line 109: Line 103:
<dd itemprop="description">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.</dd></dl>
<dd itemprop="description">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.</dd></dl>
</div>
</div>
<p><br /></p>
<div itemid="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#LP3.6" itemscope itemtype="https://schema.org/CreativeWork" itemref="md-type-subProcess">
<div itemid="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#LP3.6" itemscope itemtype="https://schema.org/CreativeWork" itemref="md-type-subProcess">
<meta itemprop="alternateName" content="YaSM service build process LP3.6" />
<meta itemprop="alternateName" content="YaSM service build process LP3.6" />
Line 115: Line 108:
<dd itemprop="description">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.</dd></dl>
<dd itemprop="description">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.</dd></dl>
</div>
</div>
<p><br /></p>
<div itemid="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#LP3.7" itemscope itemtype="https://schema.org/CreativeWork" itemref="md-type-subProcess">
<div itemid="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#LP3.7" itemscope itemtype="https://schema.org/CreativeWork" itemref="md-type-subProcess">
<meta itemprop="alternateName" content="YaSM service build process LP3.7" />
<meta itemprop="alternateName" content="YaSM service build process LP3.7" />
Line 122: Line 114:
</div>
</div>
<!-- end of schema.org/CreativeWork --><p></html>
<!-- end of schema.org/CreativeWork --><p></html>
<p>&nbsp;</p>


==Process outputs==
==Process outputs==
Line 134: Line 124:
<meta itemprop="alternateName" content="Service build data objects" />
<meta itemprop="alternateName" content="Service build data objects" />
<p><span itemprop="description">This section lists the documents and records produced by the service build process.</span> YaSM data objects <a href="#ydo" title="YaSM data object">[*]</a> are marked with an asterisk, while other objects are displayed in gray.</p>
<p><span itemprop="description">This section lists the documents and records produced by the service build process.</span> YaSM data objects <a href="#ydo" title="YaSM data object">[*]</a> are marked with an asterisk, while other objects are displayed in gray.</p>
<p>&#160;</p>


<dl>
<dl>
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name">Change status information</dt>
<dt itemprop="name">Change status information</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name">CI record</dt>
<dt itemprop="name">CI record</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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). <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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). <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name">Confirmation of successful deployment</dt>
<dt itemprop="name">Confirmation of successful deployment</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name">Data for project plan update</dt>
<dt itemprop="name">Data for project plan update</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name">Development QA documentation</dt>
<dt itemprop="name">Development QA documentation</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name">Incident model</dt>
<dt itemprop="name">Incident model</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name">Problem record</dt>
<dt itemprop="name">Problem record</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name">Purchase request</dt>
<dt itemprop="name">Purchase request</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name">Recovery plan</dt>
<dt itemprop="name">Recovery plan</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name">Request to add skills and human resources</dt>
<dt itemprop="name">Request to add skills and human resources</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name">Request to change the configuration model</dt>
<dt itemprop="name">Request to change the configuration model</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name">Request to develop applications or systems</dt>
<dt itemprop="name">Request to develop applications or systems</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name">Request to set up an external service</dt>
<dt itemprop="name">Request to set up an external service</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name">Request to update the service management processes</dt>
<dt itemprop="name">Request to update the service management processes</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name">Service definition</dt>
<dt itemprop="name">Service definition</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name" id="Service-operation-manual">Service operation manual</dt>
<dt itemprop="name" id="Service-operation-manual">Service operation manual</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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)'. <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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)'. <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name" id="Service-readiness-confirmation">Service readiness confirmation</dt>
<dt itemprop="name" id="Service-readiness-confirmation">Service readiness confirmation</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name">Service request model</dt>
<dt itemprop="name">Service request model</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name">Technical manual</dt>
<dt itemprop="name">Technical manual</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div>
<div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name" id="Test-report">Test report</dt>
<dt itemprop="name" id="Test-report">Test report</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name" id="Test-script">Test script</dt>
<dt itemprop="name" id="Test-script">Test script</dt>
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM data object">[*]</a></dd></div>
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm">
<div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name">User manual</dt>
<dt itemprop="name">User manual</dt>
<dd itemprop="description" style="margin-bottom: 1em;">A document for end-users, describing how to use a type of application or system.</dd></div>
<dd itemprop="description" style="margin-bottom: 1em;">A document for end-users, describing how to use a type of application or system.</dd></div>
Line 211: Line 200:
</p><p><span id="ydo"><strong>[*]</strong> <i>"YaSM data objects"</i> are those documents or records for which the YaSM model provides detailed recommendations: Every YaSM object has an associated checklist (see <a  href="https://yasm.com/wiki/en/index.php/Service_Management_Checklists" title="Example: YaSM checklists and document templates">example</a>) 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 <a href="https://yasm.com/wiki/en/img/yasm-project/Yasm-object-lifecycle-diagram.jpg" title="Example: YaSM object lifecycle diagram (.JPG)">example</a>).</span>
</p><p><span id="ydo"><strong>[*]</strong> <i>"YaSM data objects"</i> are those documents or records for which the YaSM model provides detailed recommendations: Every YaSM object has an associated checklist (see <a  href="https://yasm.com/wiki/en/index.php/Service_Management_Checklists" title="Example: YaSM checklists and document templates">example</a>) 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 <a href="https://yasm.com/wiki/en/img/yasm-project/Yasm-object-lifecycle-diagram.jpg" title="Example: YaSM object lifecycle diagram (.JPG)">example</a>).</span>
</p><p><i>"Other objects"</i> are mostly informal data or information where YaSM has less strong views about their contents. There are no associated lifecycle diagrams or checklists.</html>
</p><p><i>"Other objects"</i> are mostly informal data or information where YaSM has less strong views about their contents. There are no associated lifecycle diagrams or checklists.</html>
<p>&nbsp;</p>


==Process metrics==
==Process metrics==
Line 219: Line 206:


For suggestions of [[Service Management Metrics|suitable metrics]], please refer to the [[Service_Management_Metrics#Metrics_for_the_service_build_process|list of metrics for the service build process]].
For suggestions of [[Service Management Metrics|suitable metrics]], please refer to the [[Service_Management_Metrics#Metrics_for_the_service_build_process|list of metrics for the service build process]].
<p>&nbsp;</p>


==Roles and responsibilities==
==Roles and responsibilities==
Line 320: Line 305:
<html><div  itemid="https://yasm.com/wiki/en/img/yasm-process-definition/what-is-service-implementation-process.jpg" itemscope itemtype="https://schema.org/ImageObject">
<html><div  itemid="https://yasm.com/wiki/en/img/yasm-process-definition/what-is-service-implementation-process.jpg" itemscope itemtype="https://schema.org/ImageObject">
<a href="https://yasm.com/wiki/en/img/yasm-process-definition/what-is-service-implementation-process.jpg" title="Service build (service implementation): process definition (.pdf)" itemprop="contentUrl">
<a href="https://yasm.com/wiki/en/img/yasm-process-definition/what-is-service-implementation-process.jpg" title="Service build (service implementation): process definition (.pdf)" itemprop="contentUrl">
<img style="display: block; float: left; margin-right: 20px" src="https://yasm.com/wiki/en/img/yasm-process-definition/what-is-service-implementation-process.jpg" width="320" height="160" title="Service build (service implementation): process definition" alt="What is service implementation? Definition of the service build process from the YaSM framework." />
<img style="display: block; float: left; margin-left: 10px; margin-right: 20px" src="https://yasm.com/wiki/en/img/yasm-process-definition/what-is-service-implementation-process.jpg" width="320" height="180" title="Service build (service implementation): process definition" alt="What is service implementation? Definition of the service build process from the YaSM service management framework." />
<meta itemprop="caption" content="Build new or changed services | YaSM service implementation | Process definition LP3" />
<meta itemprop="caption" content="Build new or changed services | YaSM service implementation | Process definition LP3" />
<meta itemprop="width" content="1050" />
<meta itemprop="width" content="1200" />
<meta itemprop="height" content="525" /></a></div>
<meta itemprop="height" content="675" />
<div style="margin-left: 30%; color:#636363">
<meta itemprop="dateCreated" content="2017-06-30" />
<p style="margin-top: 0;">Is based on: The service build process from the <a href="https://yasm.com/en/products/yasm-process-map" title="YaSM Process Map">YaSM Process Map</a>.</p>
<meta itemprop="datePublished" content="2017-08-20" />
<meta itemprop="dateModified" content="2021-06-28" /></a></div>
<div style="margin-left: 5%; color:#636363">
<p style="margin-top: 0; word-wrap:normal;">Is&nbsp;based&nbsp;on: The service build process from the <a href="https://yasm.com/en/products/yasm-process-map" title="YaSM Process Map">YaSM Process Map</a>.</p>


<p>By:&#160;&#160;Stefan Kempter&#160;<a href="https://www.linkedin.com/in/stefankempter"><img style="margin:0px 0px 0px 0px;" src="/wiki/en/img/yasm-wiki/bookmarking/linkedin.jpg" width="16" height="16" title="By: Stefan Kempter | Profile on LinkedIn" alt="Author: Stefan Kempter, IT Process Maps GbR" /></a>&#160;&#160;and&#160;&#160;Andrea Kempter&#160;<a href="https://www.linkedin.com/in/andreakempter"><img style="margin:0px 0px 0px 0px;" src="/wiki/en/img/yasm-wiki/bookmarking/linkedin.jpg" width="16" height="16" title="By: Andrea Kempter | Profile on LinkedIn" alt="Contributor: Andrea Kempter, IT Process Maps GbR" /></a>, IT Process Maps.<br style="clear:both;"/></div><p></html>
<p>By:&#160;&#160;Stefan Kempter&#160;<a href="https://www.linkedin.com/in/stefankempter"><img style="margin:0px 0px 0px 0px;" src="/wiki/en/img/yasm-wiki/bookmarking/linkedin.jpg" width="16" height="16" title="By: Stefan Kempter | Profile on LinkedIn" alt="Author: Stefan Kempter, IT Process Maps GbR" /></a>&#160;&#160;and&#160;&#160;Andrea Kempter&#160;<a href="https://www.linkedin.com/in/andreakempter"><img style="margin:0px 0px 0px 0px;" src="/wiki/en/img/yasm-wiki/bookmarking/linkedin.jpg" width="16" height="16" title="By: Andrea Kempter | Profile on LinkedIn" alt="Contributor: Andrea Kempter, IT Process Maps GbR" /></a>, IT Process Maps.<br style="clear:both;"/></div><p></html>
<p>&nbsp;</p>


==Related articles==
==Related articles==


<html><a href="https://yasm.com/wiki/en/index.php/Service_Transition"><img src="https://yasm.com/wiki/en/img/yasm-service-management/service-transition-implementation.jpg" title="YaSM and the service transition stage" alt="Rather straightforward: The service implementation process ('service transition') in YaSM." style="display: block; float: left; margin-right: 20px" width="320" height="180"/></a>
<html><a href="https://yasm.com/wiki/en/index.php/Service_Transition"><img src="https://yasm.com/wiki/en/img/yasm-service-management/service-transition-implementation.jpg" title="YaSM and the service transition stage" alt="Rather straightforward: The service implementation process ('service transition') in YaSM." style="display: block; float: left; margin-left: 10px; margin-right: 20px" width="320" height="180"/></a>
<div style="margin-left: 30%; color:#636363">
<div style="margin-left: 5%; color:#636363">
<p style="margin-top: 0;"><a href="https://yasm.com/wiki/en/index.php/Service_Transition">YaSM and the service transition stage</a></p>
<p style="margin-top: 0; word-wrap:normal;"><a href="https://yasm.com/wiki/en/index.php/Service_Transition">YaSM and the service transition stage</a></p>
<p><small>by: Stefan Kempter</small></p>
<p><small>by: Stefan Kempter</small></p>
<p>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<sup><small>&#174;</small></sup> 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": <a href="https://yasm.com/wiki/en/index.php/Service_Transition">[...]</a></p></div><p>
<p>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<sup><small>&#174;</small></sup> 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": <a href="https://yasm.com/wiki/en/index.php/Service_Transition">[...]</a></p></div><p>
Line 343: Line 329:


<p><small>
<p><small>
<span itemprop="breadcrumb" itemscope itemtype="http://schema.org/BreadcrumbList">
<span itemprop="breadcrumb" itemscope itemtype="https://schema.org/BreadcrumbList">
<span itemprop="itemListElement" itemscope itemtype="http://schema.org/ListItem">
<span itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
<a itemprop="item" href="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#Process_description">
<a itemprop="item" href="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#Process_description">
<span itemprop="name">Process description</span></a>
<span itemprop="name">Process description</span></a>
<meta itemprop="position" content="1" /></span> ›
<meta itemprop="position" content="1" /></span> ›
<span itemprop="itemListElement" itemscope itemtype="http://schema.org/ListItem">
<span itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
<a itemprop="item" href="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#Sub-processes">
<a itemprop="item" href="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#Sub-processes">
<span itemprop="name">Sub-processes</span></a>
<span itemprop="name">Sub-processes</span></a>
<meta itemprop="position" content="2" /></span> ›
<meta itemprop="position" content="2" /></span> ›
<span itemprop="itemListElement" itemscope itemtype="http://schema.org/ListItem">
<span itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
<a itemprop="item" href="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#Process_outputs">
<a itemprop="item" href="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#Process_outputs">
<span itemprop="name">Process outputs</span></a>
<span itemprop="name">Process outputs</span></a>
<meta itemprop="position" content="3" /></span> ›
<meta itemprop="position" content="3" /></span> ›
<span itemprop="itemListElement" itemscope itemtype="http://schema.org/ListItem">
<span itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
<a itemprop="item" href="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#Process_metrics">
<a itemprop="item" href="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#Process_metrics">
<span itemprop="name">Metrics</span></a>
<span itemprop="name">Metrics</span></a>
<meta itemprop="position" content="4" /></span> ›
<meta itemprop="position" content="4" /></span> ›
<span itemprop="itemListElement" itemscope itemtype="http://schema.org/ListItem">
<span itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
<a itemprop="item" href="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#Roles_and_responsibilities">
<a itemprop="item" href="https://yasm.com/wiki/en/index.php/LP3:_Build_new_or_changed_services#Roles_and_responsibilities">
<span itemprop="name">Roles</span></a>
<span itemprop="name">Roles</span></a>
Line 409: Line 395:
[[Category:YaSM process]]
[[Category:YaSM process]]
<!-- --- -->
<!-- --- -->

Revision as of 15:27, 28 June 2021

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


 

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.

Fig. 1: Build new or changed services. - YaSM service build process LP3 (YaSM service implementation). - Related with various ITIL 4 service transition practices.
Fig. 1: 'Build new or changed services':
YaSM service build process LP3 ('service implementation').


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 or procuring the infrastructure components and other capabilities 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. [*]
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. [*]
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 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 build process.

Roles and responsibilities

Process owner: Service implementation manager

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

 

Responsibility matrix: "LP3: Build new or changed services"
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 Author: Stefan Kempter, IT Process Maps GbR  and  Andrea Kempter Contributor: Andrea Kempter, IT Process Maps GbR, IT Process Maps.

Related articles

Rather straightforward: The service implementation process ('service transition') in YaSM.

YaSM and the service transition stage

by: Stefan Kempter

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": [...]


 

Process description  › Sub-processes  › Process outputs  › Metrics  › Roles