1.
Event Management
2.
Incident Management
3.
Request Fullfillment
4.
Access Management
5.
Problem Management
6.
IT Operations Control
7.
Facilities Management
8.
Application Management
9.
Technical Management
Before getting started to examine Access Management and
Request Fulfilment it is better to understand the concept of ITSM. In
this introduction we will try to describe it and name its processes. Knowing
what it stands for is going to help us to undertand other detailed
explanations. Service Management is a customer-focused approach
to delivering information technology. Service Management provides a framework
to structure IT-related activities and the interactions of IT technical
personnel with customers and clients. Services allow customers to do business
without worrying about underlying technology or IT infrastructure. Services
must evolve in order to continue to meet the needs of the customer and respond
to technological changes and advances. The Service Lifecycle is the overall
framework used to identify, define, manage, and retire IT services.
IT Service Management (ITSM) is defined as a process-based practice intended
to align the delivery of information technology (IT) services with needs of the
business, which emphasizes benefits to customers. While the process at its core
concerns technology, this focus on the client is key.
The purpose of Service Operations can be summed as:
• To coordinate and deliver key activities and processes
required to provide and manage
• services at agreed levels to the business, users and
customers
• To manage the technology and toolsets that are used to
deliver and support services
• To manage, measure, control and feedback improvements in
the day to day operations
• To monitor performance, assess metrics and gather data to
input into the Continual Service Improvement Process Area
ITSM is often implemented through a set of frameworks.
There are many, some of which are complimentary to others, such as ITIL, COBIT, PMBOK, PRINCE, CMMI. IT
Services has selected to build its path on ITIL.
After all these general knowledge about ITSM we can say
that it is mainly about handling user requests, fixing services carrying
operation problem tasks. This view handles a service after is has been deployed
and is active to the customer.
Event Management
Let's look first at what an event can be request or
incident. If it is an incident , it can become a problem and problem
always triggers change. If it is a request , it can trigger change directly. And
every change requires some operations (eg : in the CMDB ) .An event can be
defined as any detectable or discernible occurrence that has significance for
the management of the IT Infrastructure or the delivery of IT service and
evaluation of the impact a deviation might cause to the services.
Event Management, as defined by ITIL, is the
process that monitors all events that occur through the IT infrastructure. It
allows for normal operation and also detects and escalates exception
conditions.
1.Purpose
The goal of Event Management is to detect and
analyze events and determine the appropriate process for dealing with the
events. This can include categorizing opened tickets, automating processes,
comparing performance/behavior against Service Level Agreements, and creating
the basis of service improvement and reporting. The ServiceNow platform tracks
these events in a number of System Logs, and can respond to them in automated
ways using specific policies.
System logs contains a number of logs in the
System Logs applications which can be viewed, reported on, or used as the basis
of automated policies (see below). These logs include:
- Transactions
- Emails
- Events
- Imports
- Warnings
- Errors
The platform also provides a log file browser,
as well as allowing a log file download.
Let's look at the form of the target list :
- The purpose is the ability to detect
events, investigate and determinate the correct control action
- The events (warnings and exceptions)
can be used to automate many routine activities
- Event Management can be applied to
any aspects of Service Management that can be controlled and can be automated
(Configuration Items)
- Provide mechanisms for early
detection of incidents.
- Some types of automated activities
can be monitored by exception, reducing downtime.
Incident Management
Objective
· Restore
unscheduled service interruption as quickly as possible
Definition
of Terms:
· An incident is a unscheduled interruption
or degradation of service.
Escalation
The process for getting more resources is
called escalation. There are two types of escalation:
· Functional escalation passes the incident
to another party within the same unit.
· Hierarchical escalation passes the incident to someone
higher in the hierarchy so more resources can be requested.
Incident
Management Activities
· The first step in incident management
is identifying the incident. Once the incident is identified, it is logged.
· The incident is
categorized and prioritized.
· Initial diagnosis is performed. At
this point, the person receiving the incident attempts to resolve the incident.
· If the incident is resolved, it is
closed. If the incident is not resolved, the incident is escalated to another
unit that will resolve it.
· Investigation will proceed and initial
diagnosis is done. The purpose at this point is to fix the incident as quickly
as possible. This is done through workarounds or quick fixes.
· Once a
resolution is determined, the resolution is implemented. Recovery can result if
the incident is caused by a newly implemented change.
· The incident is then classified and
initial support is given.
· When the
incident is confirmed as fixed, the incident is closed.
Request Fulfillment
ITIL uses the term service request as a
general description for the varying requests that users submit to the IT
department.
A service request is
a request from a user for information, advice, a standard change, or access to
a service. For example, a service
request can be a request for a password change or the additional installation
of a software application on a certain work station. Because these requests
occur on a regular basis and involve little risk, it is better that they
are handled in a separate process.
Request fulfillment (implementation of
requests) processes service requests from the users. The objectives of
the request fulfillment process are:
• to offer users a channel through which they
can request and receive services; to this effect an agreed approval and
qualification process must exist.
• to provide users and customers with
information about the availability of services and the procedure for obtaining
these services.
• to supply the components of standard
services (for instance, licenses and software media)
• to assist with general information,
complaints or comments
Request Fulfillment is to manage the
lifecycle of all Service Requests. A Service Request is a generic term that
describes the numerous and varied demands placed on the service and support
organization. Many are small changes, which are considered to be low risk,
frequently occurring and low cost in nature, such as change a password or
install a software application request. Alternatively, it may simply be a
Customer asking for information. It is the scale, frequency and low-risk nature
of the Service Requests that require that they be handled by the Request
Fulfillment process, and not Incident or Change Management.
The frequent recurrence of Service Requests
requires a predefined process Workflow be set with the support Technicians,
service targets and escalation paths in place. To cater for the diverse nature
of Service Requests, at minimum two Workflows should be customized for Request
Fulfillment, one to handle simple requests for information and the other to
deal with standard changes.
In the system, Service Requests are logged
against Service Items in the Service Catalog and follow Workflows that ensure
that each Request is handled with consistency. The Workflows define the actions
required to correctly implement any changes to the Service and define the
responsibilities, authorization and timeframe expected to manage the changes
that may result from a Service Request.
Once a Workflow is assigned to a Service
Request, it is routed to an appropriate Technician based on Service Request
Workflow State. After a Technician completes their assignment, the Request is
forwarded to the next User based on the configuration of the next State for a
standard change or closed, if it is a simple request for information.
When Service Requests are raised for Service Item
breakdowns, the system allows them to be easily associated with an Incident
within the Analysis tab of the Request. Or, if the Service Request results in a
change to an Item that is not in the Service Catalog, a Change Request can
easily be generated within the Service Request.
If a Service Request is related to an
Incident, Problem or Change Request and that related request in the other
Process is closed, the Service Request is automatically closed. The system
views the request hierarchy from low to high as Service Request, Incident,
Problem and Change Request, and if a related request of a higher type is
closed, all the lesser type requests are automatically closed, or if the
handshaking facility is enabled for the system, moved to the Pending-Approval
State.
The Service Strategy volume provides guidance
on how to design, develop, and implement service management not only as an
organizational capability but also as a strategic asset. Guidance is provided
on the principles underpinning the practice of service management that are
useful for developing service management policies, guidelines and processes
across the ITIL Service Lifecycle.
Access Management
People in IT Departments faces difficult challenges every
single day. For all the people work in IT departments providing an excellent
service is not an easy task. The information in your company must flow easily
throughout the organizations in a quick and secure way. So in all these
considerations, you must ensure its availability and have the necessary
resources to access it.
The question is: how can your IT department know what
information must be available to each user? And how can you control that every
user has access only to the information that is strictly necessary? The answer
is having a well organized Access Management organization.
People can come to you with questions like “I haven’t
been using this application for a long time so I just forgot my password. What
am I supposed to do?” or “I have a new position in this company so I need to be
able to Access new specific parts of the system. How can I get this
permissions?” etc. All these questions can be answered easily and quickly if
you have a well organized management system of accessing in the company.
The image above presents an example of accessing several
different points by different users with a not well- organized Access
management system. To make things even worse, if there is no IT Service
Catalogue defined, it’s almost impossible to maintain any form of Access
Management.
Well-organized Access Management relies on other parts of
Service Management to do their part as well, e.g. Change Management, Service
Desk, and Information Security.
Process activities of Access Management
The role of Access Management is to enable users (and
groups of users) with appropriate levels of access to the services presented in
the IT Service Catalogue. Access is the term that describes the level and
extent of the service functionality available to the user, and is related to
the user identity, which uniquely distinguishes one individual from another,
verifying / confirming their status within the organization. User rights (or
privileges) refer to actual settings within a service that are granted to the
user or user group, e.g. read, write, list, execute, delete, change, etc. With
all necessary basics covered, lets look at process activities of the Access
Management.
Policies
and principles of Access Management with basic concepts
Access Management is the process that enables users to
use the services that are documented in the Service Catalogue. It comprises the
following basic concepts:
Access refers to the level and extent of a service’s
functionality or data that a user is entitled to use.
Identity refers to the information about them that
distinguishes them as an individual and which verifies their status within the
organization. By definition, the Identity of a user is unique to that user.
Rights (also called privileges) refer to the actual
settings whereby a user is provided access to a service or group of services.
Typical rights, or levels of access, include read, write, execute, change,
delete.
Services or service groups: Most users do not use only
one service, and users performing a similar set of activities will use a
similar set of services. Instead of providing access to each service for each
user separately, it is more efficient to be able to grant each user – or group
of users – Access to the whole set of services that they are entitled to use at
the same time.
Directory Services refers to a specific type of tool that
is used to manage access and rights.
Problem Management
Problem Management Objective
· Provide long term fixes to existing or possible incidents
Definition of Terms:
· Problem - cause of an incident
· Error - design flaw or malfunction
· Known Error is created once the root cause is known
Problem Management Activities
·
The first step in problem management is to detect the problem. The problem
is identified through pro-active or re-active problem management. Most often,
information on problems come from Incident Management.
· After the problem has been
identified, the problem is logged.
· The problem is then categorized and
prioritized.
· If the problem is approved for
investigation, the group responsible for the problem investigates and diagnoses
the problem.
· Once the root cause is known or a
workaround is in place, a known error is raised.
· A resolution is determined. Management
may decide not to fix the problem. If the resolution is not approved, the error
is updated and the problem is closed.
· If the problem requires change, the
fix goes through Change Management and Release Management.
· Once the
change has been done, the problem is closed.
