LP4: Operate the services: Difference between revisions
From YaSM Service Management Wiki
No edit summary |
No edit summary |
||
| Line 118: | Line 118: | ||
==Process outputs== | ==Process outputs== | ||
<html><div itemid="https://yasm.com/wiki/en/index.php/LP4:_Operate_the_services# | <html><!-- define schema.org/DefinedTermSet --> | ||
<div itemid="https://yasm.com/wiki/en/index.php/LP4:_Operate_the_services#process-inputs-outputs" itemscope="itemscope" itemtype="https://schema.org/DefinedTermSet"> | |||
<link itemprop="additionalType" href="http://www.productontology.org/id/Input/output" /> | |||
<meta itemprop="name" content="YaSM process LP4: documents and records" /> | <meta itemprop="name" content="YaSM process LP4: documents and records" /> | ||
<meta itemprop="alternateName" content="Service operation process outputs" /> | <meta itemprop="alternateName" content="Service operation process outputs" /> | ||
| Line 125: | Line 127: | ||
<p> </p> | <p> </p> | ||
<dl><dt>Budget request</dt> | <dl> | ||
<dd>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. <a href="#ydo" title="YaSM data object">[*]</a></dd></ | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Budget request</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM data object">[*]</a></dd></div> | |||
<dd>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. <a href="#ydo" title="YaSM data object">[*]</a></dd></ | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Change record</dt> | ||
< | <dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM data object">[*]</a></dd></div> | ||
<dd>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 style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <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>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 itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <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>A record containing the details of a customer complaint, including the actions taken to resolve the complaint. <a href="#ydo" title="YaSM data object">[*]</a></dd></ | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Complaint record</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">A record containing the details of a customer complaint, including the actions taken to resolve the complaint. <a href="#ydo" title="YaSM data object">[*]</a></dd></div> | |||
<dd>A customer survey is typically based on questionnaires, aimed at getting insight into overall customer satisfaction and customers' views on specific (aspects of) services. In many cases, answers are given using a scale, for example '1: Very dissatisfied', … , '10: Very satisfied'. <a href="#ydo" title="YaSM data object">[*]</a></dd></ | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Customer survey questionnaire</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">A customer survey is typically based on questionnaires, aimed at getting insight into overall customer satisfaction and customers' views on specific (aspects of) services. In many cases, answers are given using a scale, for example '1: Very dissatisfied', … , '10: Very satisfied'. <a href="#ydo" title="YaSM data object">[*]</a></dd></div> | |||
<dd>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 itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <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>A set of data with all details of a service incident, documenting the history of the incident from registration to closure. A service incident is defined as an unplanned interruption or reduction in quality of a service. Events that could potentially impair a service in the future are also treated as incidents (e.g. the failure of one hard-drive of a set of mirrored drives). <a href="#ydo" title="YaSM data object">[*]</a></dd></ | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Incident record</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">A set of data with all details of a service incident, documenting the history of the incident from registration to closure. A service incident is defined as an unplanned interruption or reduction in quality of a service. Events that could potentially impair a service in the future are also treated as incidents (e.g. the failure of one hard-drive of a set of mirrored drives). <a href="#ydo" title="YaSM data object">[*]</a></dd></div> | |||
<dd>A message containing the present status of an incident or service request sent to a user who earlier reported a service interruption or submitted a service request. Status information is typically provided to users at various points during an incident's or request's lifecycle. If the resolution time exceeds or is expected to exceed the agreed time frames, status notifications are especially important to keep the user informed.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Incident/ request status information</dt> | ||
< | <dd itemprop="description" style="margin-bottom: 1em;">A message containing the present status of an incident or service request sent to a user who earlier reported a service interruption or submitted a service request. Status information is typically provided to users at various points during an incident's or request's lifecycle. If the resolution time exceeds or is expected to exceed the agreed time frames, status notifications are especially important to keep the user informed.</dd></div> | ||
<dd>The planned service outages document or database lists any expected or planned deviations from normal service availability, such as outages due to maintenance work or the implementation of changes. <a href="#ydo" title="YaSM data object">[*]</a></dd></ | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name" id="Planned-service-outages">Planned service outages</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">The planned service outages document or database lists any expected or planned deviations from normal service availability, such as outages due to maintenance work or the implementation of changes. <a href="#ydo" title="YaSM data object">[*]</a></dd></div> | |||
<dd>A notification to users or clients of existing or potential service failures, so that users are in a position to prepare themselves for a period of service unavailability.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Pro-active user information</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">A notification to users or clients of existing or potential service failures, so that users are in a position to prepare themselves for a period of service unavailability.</dd></div> | |||
<dd>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 itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <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>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 style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <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>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 itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name" id="Recovery-plan">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>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 style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <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>Self-help information for users supplied by the service provider, for example as part of the support pages on the intranet.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Self-help information for users</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">Self-help information for users supplied by the service provider, for example as part of the support pages on the intranet.</dd></div> | |||
<dd | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Service access log</dt> | ||
< | <dd itemprop="description" style="margin-bottom: 1em;">The service access log contains data records gathered by access control systems as users request access to particular services. These data are used, for example, by the security manager, as a basis for improving the security mechanisms and controls.</dd></div> | ||
<dd | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <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 | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name" id="Service-quality-report">Service quality report</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">A service quality report gives insight into the service provider's ability to deliver the agreed service quality. Most importantly, it reports on the service levels achieved in relation to the agreed targets, as specified in the service definitions. Service quality reports will also highlight any breaches of contractual commitments and exceptional events. <a href="#ydo" title="YaSM data object">[*]</a></dd></div> | |||
<dd | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <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 | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Service request record</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">A record containing all details of a service request. Service requests are formal requests from a client or user for something to be provided within the framework of existing service agreements - for example, a request for information or advice; to reset a password; or to install a workstation for a new user. <a href="#ydo" title="YaSM data object">[*]</a></dd></div> | |||
<dd>Statistical data on service usage by clients/ users, as a basis for producing client invoices.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Service usage statistics</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">Statistical data on service usage by clients/ users, as a basis for producing client invoices.</dd></div> | |||
<dd>A suggestion to update self-help information for users supplied by the service provider, for example as part of the support pages on the intranet.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Suggested changes to self-help information</dt> | ||
< | <dd itemprop="description" style="margin-bottom: 1em;">A suggestion to update self-help information for users supplied by the service provider, for example as part of the support pages on the intranet.</dd></div> | ||
<dd>A suggestion for improving service security. Suggestions for security improvements may originate from anywhere within the organization.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Suggested improvement to continuity arrangements</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">A suggestion for improving service security. Suggestions for security improvements may originate from anywhere within the organization.</dd></div> | |||
<dd | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Suggested process modification</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">A suggestion for modifying one or several service management processes. Suggestions for process modifications or improvements may originate from anywhere within the organization.</dd></div> | |||
<dd>A suggestion for modifying a service, for example to improve service quality or economics. Suggestions may originate from anywhere within or outside of the service provider organization.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Suggested service modification</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">A suggestion for modifying a service, for example to improve service quality or economics. Suggestions may originate from anywhere within or outside of the service provider organization.</dd></div> | |||
<dd>A request to support the resolution of an incident or problem, usually issued from the incident or problem manager when further assistance is needed from technical experts or external suppliers.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Support request</dt> | ||
< | <dd itemprop="description" style="margin-bottom: 1em;">A request to support the resolution of an incident or problem, usually issued from the incident or problem manager when further assistance is needed from technical experts or external suppliers.</dd></div> | ||
<dd>The system event log contains data records generated by the monitoring systems which continually check the state of the technical infrastructure. Event records are used, for example, to detect current service interruptions that necessitate immediate action. Event records are also the basis for identifying conditions that require preventive action in order to sustain service quality, such as imminent capacity shortages.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">System event log</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">The system event log contains data records generated by the monitoring systems which continually check the state of the technical infrastructure. Event records are used, for example, to detect current service interruptions that necessitate immediate action. Event records are also the basis for identifying conditions that require preventive action in order to sustain service quality, such as imminent capacity shortages.</dd></div> | |||
<dd | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <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 | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">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 | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">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.</dd></div> | |||
<dd>A document for end-users, describing how to use a type of application or system. <a href="#ydo" title="YaSM data object">[*]</a></dd></dl> | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
</div><!-- end of schema.org/ | <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. <a href="#ydo" title="YaSM data object">[*]</a></dd></div> | |||
</dl> | |||
</div><!-- end of schema.org/DefinedTermSet --><p> | |||
<p> </p> | <p> </p> | ||
| Line 379: | Line 384: | ||
<link itemprop="hasPart" href="https://yasm.com/wiki/en/index.php/LP4.6:_Resolve_incidents_and_service_requests"> | <link itemprop="hasPart" href="https://yasm.com/wiki/en/index.php/LP4.6:_Resolve_incidents_and_service_requests"> | ||
<link itemprop="hasPart" href="https://yasm.com/wiki/en/index.php/LP4.7:_Resolve_problems"> | <link itemprop="hasPart" href="https://yasm.com/wiki/en/index.php/LP4.7:_Resolve_problems"> | ||
<link itemprop="hasPart" href="https://yasm.com/wiki/en/index.php/LP4:_Operate_the_services# | <link itemprop="hasPart" href="https://yasm.com/wiki/en/index.php/LP4:_Operate_the_services#process-inputs-outputs"> | ||
<link itemprop="image" href="https://yasm.com/wiki/en/img/yasm-process/Operate-the-services-yasm-lp4.jpg" /> | <link itemprop="image" href="https://yasm.com/wiki/en/img/yasm-process/Operate-the-services-yasm-lp4.jpg" /> | ||
<link itemprop="image" href="https://yasm.com/wiki/en/img/yasm-process-definition/what-is-service-operation-process.jpg" /> | <link itemprop="image" href="https://yasm.com/wiki/en/img/yasm-process-definition/what-is-service-operation-process.jpg" /> | ||
Revision as of 16:13, 25 January 2021
Process name: Operate the services - Part of: Service lifecycle processes
Previous process: Build new or changed services
Next process: Improve the services
Process description
The service operation process in YaSM (fig. 1) ensures that the services are delivered effectively and efficiently, in line with the contractual commitments. This includes fulfilling service requests, resolving incidents and problems, as well as carrying out routine operational tasks.
The achieved service quality is measured on a regular basis. The resulting service quality reports are an important input for the service improvement process.
Figure 1 above also highlights how three particular sub-processes from service operation (Monitor the services, Resolve incidents and service requests, Resolve problems) cooperate in order to detect and resolve actual or potential incidents and their underlying causes (problems).
Compatibility: The YaSM service operation process is aligned with ISO 20000, the international standard for service management (see ISO/IEC 20000-1:2018, sections 8.3, 8.4, 8.7 and 9) and it corresponds to various ITIL 4 practices, such as 'monitoring and event management', 'ITIL 4 incident management' and 'ITIL 4 problem management'.
Sub-processes
YaSM's service operation process has the following sub-processes:
- LP4.1: Support the service operation
- Process objective: To provide support for service operation, for example by ensuring that the required resources for operating the services are available, and by configuring and maintaining operational support systems.
- LP4.2: Provide guidance for service operation
- Process objective: To provide instructions for the activities to be carried out by operational staff. This includes, for example, the preparation of detailed guidance for regular maintenance tasks.
- LP4.3: Monitor the services
- Process objective: To make sure the service infrastructure and service usage are constantly monitored, and to decide on appropriate responses if any irregularities are detected.
- LP4.4: Produce service quality reports
- Process objective: To measure the achieved service quality on a regular basis and to identify areas where service quality must be improved.
- LP4.5: Perform routine operational tasks
- Process objective: To execute the routine operational tasks required to deliver the agreed service quality on a sustainable basis.
- LP4.6: Resolve incidents and service requests
- Process objective: To resolve service incidents (reports of suspected or actual service failures) or requests for service. In the case of service incidents, the primary objective of this process is to return the service to users as quickly as possible. In some cases this involves applying a workaround if the root cause cannot be readily identified and/ or resolved.
- LP4.7: Resolve problems
- Process objective: To manage the lifecycle of all problems, where a problem is the underlying cause of one or several (potential) incidents. The primary objective of this process is to prevent service incidents from happening, and to minimize the impact of incidents which cannot be prevented.
Process outputs
This section lists the documents and records produced by the operational process. 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.
- 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). [*]
- Complaint record
- A record containing the details of a customer complaint, including the actions taken to resolve the complaint. [*]
- Customer survey questionnaire
- A customer survey is typically based on questionnaires, aimed at getting insight into overall customer satisfaction and customers' views on specific (aspects of) services. In many cases, answers are given using a scale, for example '1: Very dissatisfied', … , '10: Very satisfied'. [*]
- 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. [*]
- Incident record
- A set of data with all details of a service incident, documenting the history of the incident from registration to closure. A service incident is defined as an unplanned interruption or reduction in quality of a service. Events that could potentially impair a service in the future are also treated as incidents (e.g. the failure of one hard-drive of a set of mirrored drives). [*]
- Incident/ request status information
- A message containing the present status of an incident or service request sent to a user who earlier reported a service interruption or submitted a service request. Status information is typically provided to users at various points during an incident's or request's lifecycle. If the resolution time exceeds or is expected to exceed the agreed time frames, status notifications are especially important to keep the user informed.
- Planned service outages
- The planned service outages document or database lists any expected or planned deviations from normal service availability, such as outages due to maintenance work or the implementation of changes. [*]
- Pro-active user information
- A notification to users or clients of existing or potential service failures, so that users are in a position to prepare themselves for a period of service unavailability.
- 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.
- Self-help information for users
- Self-help information for users supplied by the service provider, for example as part of the support pages on the intranet.
- Service access log
- The service access log contains data records gathered by access control systems as users request access to particular services. These data are used, for example, by the security manager, as a basis for improving the security mechanisms and controls.
- 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 quality report
- A service quality report gives insight into the service provider's ability to deliver the agreed service quality. Most importantly, it reports on the service levels achieved in relation to the agreed targets, as specified in the service definitions. Service quality reports will also highlight any breaches of contractual commitments and exceptional events. [*]
- 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. [*]
- Service request record
- A record containing all details of a service request. Service requests are formal requests from a client or user for something to be provided within the framework of existing service agreements - for example, a request for information or advice; to reset a password; or to install a workstation for a new user. [*]
- Service usage statistics
- Statistical data on service usage by clients/ users, as a basis for producing client invoices.
- Suggested changes to self-help information
- A suggestion to update self-help information for users supplied by the service provider, for example as part of the support pages on the intranet.
- Suggested improvement to continuity arrangements
- A suggestion for improving service security. Suggestions for security improvements may originate from anywhere within the organization.
- Suggested process modification
- A suggestion for modifying one or several service management processes. Suggestions for process modifications or improvements may originate from anywhere within the organization.
- Suggested service modification
- A suggestion for modifying a service, for example to improve service quality or economics. Suggestions may originate from anywhere within or outside of the service provider organization.
- Support request
- A request to support the resolution of an incident or problem, usually issued from the incident or problem manager when further assistance is needed from technical experts or external suppliers.
- System event log
- The system event log contains data records generated by the monitoring systems which continually check the state of the technical infrastructure. Event records are used, for example, to detect current service interruptions that necessitate immediate action. Event records are also the basis for identifying conditions that require preventive action in order to sustain service quality, such as imminent capacity shortages.
- 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 operation process.
Roles and responsibilities
Process owner: Operations manager
- An operations manager will be needed to take overall responsibility for operating a service. For instance, this role will ensure that all day-to-day operational activities are carried out in a timely and reliable way.
| YaSM role / sub-process | Operations manager | Oper. | Serv. owner | Techn. domain expert | |
|---|---|---|---|---|---|
| LP4.1 | Support the service operation | AR | R | R | R |
| LP4.2 | Provide guidance for service operation | AR | - | R | R |
| LP4.3 | Monitor the services | A | R | - | - |
| LP4.4 | Produce service quality reports | A | R | R | - |
| LP4.5 | Perform routine operational tasks | A | R | - | - |
| LP4.6 | Resolve incidents and service requests | see RACI matrix "LP4.6: Resolve incidents and service requests" | |||
| LP4.7 | Resolve problems | see RACI matrix "LP4.7: Resolve problems" | |||
Notes
Is based on: The service operation process from the YaSM Process Map.
By: Stefan Kempter 
and Andrea Kempter , IT Process Maps.
Related articles
Service operation according to YaSM
by: Stefan Kempter
Since the existing guidance on service operation is well established and generally accepted, the service operation process in YaSM is based on the guidance provided in ITIL® and other service management frameworks.
What's special about service operation in YaSM? [...]
Process description › Sub-processes › Process outputs › Metrics › Roles
