LP4: Operate the services

 

Process name: Operate the services - Part of: Service lifecycle processes

Previous process: Build new or changed services

Next process: Improve the services

 

Process description

Figure 1: "Operate the services". - YaSM service lifecycle process LP4.

YaSM's service operation process ("LP4: Operate the services") 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.

The figure 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).

 

Sub-processes

YaSM's service operation process 'LP4: Operate the services' 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 service

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 'Operate the services'. YaSM data objects [*] are marked with an asterisk, while other objects are displayed in gray.

 

Budget request

A budget request is typically issued to obtain funding for setting up, improving or operating a service or process. An approved budget request means that the required financial resources have been allocated by the financial manager. [*]

Change record

A change record contains all details of a change, documenting the lifecycle of a single change. In its initial state, a change record describes a request for change (RFC) which is to be assessed and authorized prior to implementing the change. Further information is added as the change progresses through its lifecycle. [*]

Change status information

Current status information related to the implementation of a change. This information is sent to the change manager from the various processes that implement authorized changes. It is used by the change manager to keep the change records and the change schedule up-to-date.

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.

 

Responsibility matrix: "LP4: Operate the services"

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 blog posts

Service operation according to YaSM

by: Stefan Kempter

Is the purpose of YaSM's operational process different from ITIL^® and what's special about service operation in YaSM? [...]

 

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