Page History

Services

A service is defined as a means of enabling value co-creation by facilitating outcomes that customers want to achieve, without the customer having to manage specific costs and risks.

In SimpleOne, services are used in each practice, not only in the Incident Management practice, for example; they are also used in Change Control practice, Request Fulfillment practice, so every ITSM/ESM object is clearly linked with a Service. In fact, service is a core element of the ITSM/ESM Solution, so Service Catalog Management and Knowledge Management practices are tightly interconnected in our system,

One of their purposes is requests classifying; also, services are used in the Knowledge Management practice to classify the articles in the Knowledge Base.

All services are usually stored in the core repository named Service Portfolio which is divided into three parts:

Service Pipeline

This part of the repository contains services that are not yet live. They may be just proposed, or under development or construction. 

Service PortfolioCatalog

This part of the repository contains active services offered to the customers; this is the only part visible to them.

Retired Services

Services here are out of business due to various reasons, for example, because of the loss of relevance.

As an SKMS (Service Knowledge Management System), SimpleOne uses service as a compulsory attribute to each knowledge base article so as to enable value tracking between the service consumer and service provider.

Service specifications

In SimpleOne, services are used in various practices, not only in the Incident Management practice; they are also used in Change Control practice, Request Fulfillment practice, so it's a common feature. One of their purposes is requests classifying.

Services specifications 

have external and internal specifications.

External specifications are for the end-user, and internal specifications are for the agent or the service owner.

External Specifications are:

• SLA:
• Service Description;
• Service Request Description;
• Self-Service How-tos.

SLA

Service Description

Service Request Description

Self-Service How-tos

Internal Specifications are:

, each service documentation has a set of specification which, in turn, are divided into external and internal ones; you can know the difference between them below.

External Specifications

Service external specifications are essential for the system consumer who is using it in the end-user role. These are:

• SLA
• Service Description
• Request Description
• User Self-Study.

SLA

This specification is for SLM-relevant parts related to this service (indicators, etc.). It describes various aspects of service quality, like maximum requests handling time, and others.

Service Description

This is a service description, informative and related to the company infrastructure.

Request Description

In there, request description should be added; on its basis, any articles may be found in Knowledge Management System for displaying as how-tos (see the next point).

User Self-Study

Here, some hints can be displayed to consumer, on the basis of the previous relevant tasks (Incidents, Requests, etc.).

Internal Specifications

Service internal specifications are available to the agent (who also may be called the service owner) who is responsible for the task handling. These are:

• Incident Model
• Request Model
• Contacts
• Incident Model;
• Service Request Model;
• Escalation Contacts;
• Escalation Rules.

Incident Model

This model defines specific agreed tasks or steps that need to be followed to fulfill this resolve this incident or any incident related to this category.

Request Model

This model defines specific agreed tasks or steps that need to be followed to fulfill this service request or any service request related to this category.

Contacts

In this part, the agent has the directory of the contacts of relevant persons and groups to whom he can escalate the incident or another kind of task if needed.

Escalation Rules

These rules clarify escalation rules, depending on the task type (is it Incident, Change Request, or other), its impact, urgency, and other factors. You can read some more about this in Incident Processing#EscalationRulesEscalationRules.