Information Technology Management and Standards Service Operations

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.