This ITIL core foundation video explains about overview, purpose, objective and scope of service operation in this tutorial video along with the
important terms like incident, event, problem, alert, service request and work around.
Purpose of service operation
The purpose of service operations is to coordinate and carry out the activities and processes required to deliver and manage services at agreed levels to business users and customers. Service operation is also responsible for the on-going management of the technology that is used to deliver and support services.
Objectives of service operation
The objective of service operations is to maintain business satisfaction by delivering effective and efficient IT services, minimise the impact of service outage and to ensure access to IT services for only authorised users.
Scope of service operation
The services themselves – Activities that form part of a service is included in service operation, whether it is performed by the service provider, an external supplier or the user or customer of that service.
Service management processes – The on-going management and execution of the many service management processes that are performed in service operation.
Technology – All services require some form of technology to deliver them. Managing this technology is not a separate issue, but an integral part of the management of services themselves.
People – All processes and technology are managed, they are all about people. It is people who drive the demand for the organisation’s services and products and it is people who decide how this will be done.
Important terms in service operation.
First we will see the event.
Event can be defined as Change of state that has significance for the management of an IT service or other configuration item
Events are typically notifications created by an IT service, configuration item or a monitoring tool.
Event can be classified into three categories.
Informational
An event that does not require any action, regular operation
Warning
An event that is unusual but not an exception, requires closer monitoring.
Exception
An event signifying a service or a device is operating abnormally
Let's look at alert now.
A warning that a threshold has been reached, something has changed, or a failure has occurred.
Alerts are often created and managed by system management tools.
Alerts are managed by the event management process.
Objective is to notify the concerned stakeholders
Now we will see about incident.
incident can be defined as an unplanned interruption to an IT service.
A reduction in the quality of an IT service.
Failure of an IT component that has not yet affected service, but could likely disrupt service if left unchecked. This can be raised by IT support teams.
Example: Failure of a network component, failure to send email etc.
Also it is important to know the relationship between the event, alert and incident.
All alerts are events, but not all events trigger alerts
All incidents are events, but all events are not incidents
Now we will see what is a service request.
A generic description for many varying types of demands that are placed upon the IT department by the users.
Many of these requests are actually small changes which are low risk, frequently occurring, low cost, etc.
Their scale and frequency, low risk nature means that they are better handled by a separate process, rather than being allowed to congest and obstruct the normal incident and change management processes.
Let's look about problem now.
problem can be defined as the cause of one or more incidents.
The cause is not usually known at the time a problem record is created, and the problem management process is responsible for further investigation.
Prioritised in the same way and for same reasons as incidents.
Next is, workaround.
workaround can be defined as a temporary way to restore service failures to a usable level. For example, rebooting a server hang.
Used for reducing or eliminating the impact of an incident or problem for which a full resolution is not yet available.
Workarounds for incidents that do not have associated problem records are documented in the incident record.
Workarounds for problems are documented in known error records.