ITIL service operations

1 ITIL® is a (registered) Trade Mark of AXELOS Limited. All rights reserved.
IT Infrastructure Library® is a (registered) Trade Mark of AXELOS Limited. All rights reserved.
Service Operation

Agenda
Service operation principles
Service operation processes
Common service operation activities
Organizing for service operation
Technology considerations
Implementation of service operation

When considering service operation it is tempting to focus only on
managing day-to-day activities & technology as ends in themselves.
However, service operation exists within a far greater context. As part of the
service lifecycle, service operation is responsible for:
Executing & performing processes that optimize the cost & quality of
services
Enabling the business to meet its objectives. As part of the world of
technology, service operation is responsible for:
Effective functioning of components that support services
Execution of operation control activities to manage & deliver services.
As part of the overall business, service operation is responsible for:
Delivering services efficiently & at acceptable cost
Delivering services within prescribed service levels
Maintaining user satisfaction with IT services.

Service operation fundamentals
Providing business value through service operation
Optimizing service operation performance
Processes within service operation
Functions within service operation

Providing business value through service operation
Each stage in the service lifecycle provides value to business. The
operation of service is where these plans, designs & optimizations are
executed & measured. From a customer viewpoint, service operation is
where actual value is seen.
To achieve business value, service operation cannot solely focus on the
day-to-day operation & delivery of services. Other challenges exist outside
that focus that can put business value at risk
Few organisation plan effectively for the operating costs of a service.
It is difficult to secure funding to fix a service after the implementation
It is difficult to secure funding to obtain monitoring tools
Services are taken for granted & any action to optimize them is perceived
as ‘fixing services that are not broken’.

Optimizing service operation performance
Service operation is optimized in two ways:
Long-term incremental improvement This is based on evaluating the
performance & output of all service operation processes, technologies,
functions & outputs over time.
Short-term ongoing improvements These are the improvements made to
working practices within the processes, functions & technologies that
underpin service operation itself.

Processes within service operation
There are a number of key service operation processes that must link
together to provide an effective overall IT support structure. The overall
structure is briefly described here & then each of the processes is described
in more detail
Event management manages events throughout their lifecycle. This
lifecycle includes coordination activities to detect events, make sense of
them & determine the appropriate control action.
Incident management concentrates on restoring unexpectedly degraded
or disrupted services to users as quickly as possible & minimize business
impact
Request fulfilment is the process for managing the lifecycle of all service
requests.
Access management is the process of granting authorized users the
rights to use a service, while restricting access to non-authorized users.

Functions within service operation
Processes alone will not result in effective service operation. Service
operation relies on several functions to execute operational tasks. Functions
include groups of skilled people who carry out one or more service lifecycle
processes & activities. Within service operation, there are four main
functions, listed here & discussed in detail
The service desk is the single point of contact for users when there is a
service disruption & service Requests
Technical management provides detailed technical skills & resources
needed to support the ongoing operation of IT services & the
management of the IT infrastructure.
IT operations management executes the daily operational activities
needed to manage IT services & the supporting IT infrastructure.
Application management is responsible for managing applications
throughout their lifecycle.

Achieving balance in service
operation
Internal IT view versus external business view
Stability versus responsiveness
Quality of service versus cost of service
Reactive versus proactive

operation
The external view of IT is the way in which services are experienced by its
users & customers. They do not always understand, nor do they wish to
care about, the details of what technology is used to manage those
services. All they are concerned about is that the services are delivered as
required & agreed.
The internal view of IT is the way in which IT components & systems are
managed to deliver the services. Because IT systems are complex &
diverse, this often means that the technology is managed by several
different teams or departments – each of which is focused on achieving
good performance & availability of ‘its’ systems.

operation
.

operation
No matter how good the functionality of an IT service & no matter how well
it has been designed, it will be worth far less if the service components are
not available or if they perform inconsistently. This means that service
operation needs to ensure that the IT infrastructure is stable & available as
designed. At the same time, service operation needs to recognize that
business & IT requirements change. Some of these changes are
evolutionary. Many changes, though, happen very quickly & sometimes
under extreme pressure. The ability to respond to this type of change
without impacting other services is a significant challenge. Many IT
organizations are unable to achieve this balance & tend to focus on either
the stability of the IT infrastructure or the ability to respond to changes
quickly.

operation

operation
Service operation is required consistently to deliver the agreed level of IT
service to its customers & users, while at the same time keeping costs &
resource utilization at an optimal level. the investment made to deliver a
service at increasing levels of quality. an increase in the level of quality
usually results in an increase in the cost of that service, & vice versa

operation

operation
A reactive organization is one which does not act unless it is prompted to do
so by an external driver. The unfortunate irony of this approach is that
discouraging effort investment in proactive service management can
ultimately increase the effort & cost of reactive activities & further risk
stability & consistency in services.
A proactive organization is always looking for ways to improve the current
situation. It will continually scan the internal & external environments,
looking for changes that may have potential impact However, being too
proactive can be expensive & can result in staff being distracted. The need
for proper balance in reactive & proactive behaviour often achieves the
optimal result

operation
It is best practice to manage services proactively, but achieving this comes
with many challenges:
The maturity of the organization
The culture of the organization
Role of IT & the mandate
The level of integration of management processes & tools
The maturity & scope of knowledge management in the organization.

operation

Providing good service
All service operation staff must be fully aware that they are there to ‘provide
service’ to the business. They must provide a timely (rapid response &
speedy delivery of requirements), professional & courteous service to allow
the business to conduct its own activities – so that the commercial
customer’s needs are met & the business thrives. It is important that staff
are trained not only in how to deliver & support IT services, but also in the
manner in which that service should be provided. For example, staff that are
capable & deliver service effectively may still cause significant customer
dissatisfaction if they are insensitive or dismissive. Conversely, no amount
of being nice to a customer will help if the service is not being delivered.

Operation staff involvement in
other service lifecycle stages
It is extremely important that service operation staff are involved in activities
taking place with other service lifecycle stages where appropriate.
Resources must be made available for these activities & the time required
should be taken into account:
IT operation staff play an important assistance role in supporting service
strategy activities e.g. identifying operational risks.
One key to achieving balance in service operation is an effective set of
service design processes & service operation involvement in service design
activities should be strongly encouraged.
IT operations management staff should be involved during service transition
to ensure consistency & that both stated business & manageability
requirements are met.
Service operation staff should be involved in supporting CSI activities &
identifying improvement opportunities for inclusion in the CSI register

Operational health
Many organizations find it helpful to compare the monitoring & control of
service operation to health monitoring & control. In this sense, the IT
infrastructure is like an organism with vital life signs that can be monitored
to check whether it is functioning normally. This means that it is not
necessary to monitor continuously every component of every IT system to
ensure that it is functioning. Operational health can be determined by
isolating a few important ‘vital signs’ on devices or services that are defined
as critical for the successful execution of a vital business function.
Operational health is dependent on the ability to prevent incidents &
problems by investing in reliable & maintainable infrastructure. This is
achieved through good availability design & proactive problem
management. At the same time, operational health is also dependent on the
ability to identify faults & localize them effectively so that they have minimal
impact on the service

Communication
Good communication is needed with other IT teams & departments, with
users & internal customers, & between the service operation teams &
departments themselves. Issues can often be prevented or mitigated with
appropriate communication.
An important principle is that all communication must have an intended
purpose or a resultant action. Information should not be communicated
unless there is a clear audience. In addition, that audience should have
been actively involved in determining the need for that communication &
what they will do with the information. Further, there should be review of
ongoing communications on a periodic basis to validate that they are still
required by the audience.

Documentation
IT operations management & all of the technical & application management
teams & departments are involved in creating & maintaining a range of
documents that should be stored in the service knowledge management
system

Agenda

Event Management
Incident Management
Request Fulfilment
Problem Management
Access Management

Event management
Purpose
Objectives
Value to business
Policies & concepts
Process
Inputs & Outputs
CSFs & KPIs

Event management
Purpose
The purpose of event management is to manage events throughout their
lifecycle. This lifecycle of activities to detect events, make sense of them &
determine the appropriate control action is coordinated by the event
management process. The purpose of event management is to manage
events throughout their lifecycle. This lifecycle of activities to detect events,
make sense of them & determine the appropriate control action is
coordinated by the event management process.

Event management
Objectives
Detect all changes of state that have significance for the management of a
CI or IT service
Determine the appropriate control action for events & ensure these are
communicated to the appropriate functions
Provide the trigger, or entry point, for the execution of many service
operation processes & operations management activities
Provide the means to compare actual operating performance & behaviour
against design standards & SLAs
Provide a basis for service assurance & reporting; & service improvement.

Event management
Value to business
Event management provides mechanisms for early detection of incidents. In
many cases it is possible for the incident to be detected & assigned to the
appropriate group for action before any actual service outage occurs.
Event management makes it possible for some types of automated activity
to be monitored by exception – thus removing the need for expensive &
resource-intensive real-time monitoring, while reducing downtime.
When integrated into other service management processes (such as, for
example, availability or capacity management), event management can
signal status changes or exceptions that allow the appropriate person or
team to perform early response, thus improving the performance of the
process

Event management
Policies
Event notifications should only go to those responsible for the handling of
their further actions or decisions related to them.
Event management & support should be centralized as much as reasonably
possible.
All application events should utilize a common set of messaging & logging
standards & protocols wherever possible.
Event handling actions should be automated wherever possible.
A standard classification scheme should be in place that references
common handling & escalation processes.
All recognized events should be captured & logged.

Event managemennt
Principles & basic concepts
There are many different types of events,
Informational events
A scheduled workload has completed
A user has logged in to use an application
An email has reached its intended recipient.
Warning events
A server’s memory utilization reaches within 5% of its highest acceptable
performance level
The completion time of a transaction is 10%
Exceptional events
A user attempts to log on to an application with the incorrect password
A device’s CPU is above the acceptable utilization rate
A PC scan reveals the installation of unauthorized software

Event managemennt
Designing for event management
Effective event management is not designed once a service has been
deployed into operations. Because event management is the basis for
monitoring the performance & availability of a service, the exact targets &
mechanisms for monitoring should be specified & agreed during the
availability & capacity management processes. Testing & evaluation of
designed event mechanisms should be included with activities undertaken
during service transition.
Key considerations for designing event management can include:
What needs to be monitored?
What type of monitoring is required (active/passive; performance/output)?
When do we need to generate an event?
Who are the messages intended for?

Event managemennt
Designing for event management

Event managemennt
Use of event rule sets & correlation engines
A rule set consists of several rules that define how the event messages for
a particular event will be processed & evaluated.
Rules themselves are typically embedded into monitoring & event handling
technologies. They consist of Boolean kinds of algorithms to correlate
events that have been generated in order to create additional events that
need to be communicated. These algorithms can be codified into event
management software typically referred to as correlation engines.

Event management
Process

Event management
Process description
Event occurs
Events occur continuously, not all are significant, therefore care needs to be taken in
the designing events that need to be captured
Event notification
Devices are interrogated by a management tool, which collects targeted data. Most
Cis generate notifications standards such as SNMP.
Event detection
Once a notification has been generated, it will be detected by a system designed to
interpret the meaning of the event
Event logged
All events should be logged.

Event management
Process description
First level correlation & filtering
Significance of events
Second level event correlation
Further action required?
All events should be logged.

Event management
Process description
Response selection
Review actions
Close event
.

Event management
Inputs
Operational & service level requirements associated with events & their
actions
Alarms, alerts & thresholds for recognizing events
Event correlation tables, rules, event codes & automated response
solutions that will support event management activities
Outputs
Events that have been communicated & escalated to those responsible for
further action
Event logs describing what events took place & any escalation &
communication activities taken to support forensic, diagnosis or further CSI
activities
Events that indicate the potential breach of an SLA or OLA objective

Event management
CSFs & KPIs
CSF Detecting all changes of state that have significance for the
management of CIs & IT services
KPI Number & ratio of events compared with the number of incidents
CSF Provide the means to compare actual operating performance &
behaviour against design standards & SLAs
KPI Number & percentage of incidents that were resolved without impact
to the business (indicates the overall effectiveness
CSF Providing a basis for service assurance, reporting & service
improvement
KPI Number & percentage of repeated or duplicated events

Incident management
Purpose
Objectives
Value to business
Policies & concepts
Process
Inputs & Outputs
CSFs & KPIs

Incident management
Purpose
The purpose of incident management is to restore normal service operation
as quickly as possible & minimize the adverse impact on business
operations, thus ensuring that agreed levels of service quality are
maintained. ‘Normal service operation’ is defined as an operational state
where services & CIs are performing within their agreed service &
operational levels

Incident management
Objectives
Ensure that standardized methods & procedures are used for efficient &
prompt response, analysis, documentation, ongoing management &
reporting of incidents
Increase visibility & communication of incidents to business & IT support
staff
Enhance business perception of IT through use of a professional approach
in quickly resolving & communicating incidents when they occur

Incident management
Value to business
The ability to reduce unplanned labour & costs for both the business & IT
support staff caused by incidents.
The ability to detect & resolve incidents which results in lower downtime to
the business, which in turn means higher availability of the service. This
means that the business is able to exploit the functionality of the service as
designed.
The ability to align IT activity to real-time business priorities. This is
because incident management includes the capability to identify business
priorities & dynamically allocate resources as necessary.

Incident management
Policies & concepts
Many organizations will find it helpful to predefine ‘standard’ incident
models & apply them to appropriate incidents when they occur.
The incident model should include:
The steps that should be taken to handle the incident
The chronological order these steps should be taken in, with any
dependencies or co-processing defined
Responsibilities; who should do what
Timescales must be agreed for all incident handling stages (these will differ
depending upon the priority level of the incident), based upon the overall
incident response & resolution targets within SLAs, & captured as targets
within OLAs & UCs. All support groups should be made fully aware of these
timescales.

Incident management
Policies & concepts
Incidents should be tracked throughout their lifecycle to support proper
handling & reporting on the status of incidents. Within the incident
management system, status codes may be linked to incidents to indicate
where they are in relation to the lifecycle. Examples of these might include:
Open An incident has been recognized but not yet assigned to a support
resource for resolution
In progress The incident is in the process of being investigated & resolved
Resolved A resolution has been put in place for the incident but normal
state service operation has not yet been validated by the business or end
user

Incident management
Policies & concepts
A separate procedure, with shorter timescales & greater urgency, must be
used for ‘major’ incidents. A definition of what constitutes a major incident
must be agreed & ideally mapped onto the overall incident prioritization
scheme – such that they will be dealt with through this separate procedure.
incident prioritization scheme – such that they will be dealt with through this
separate procedure.

Incident management
Process

Incident management
Process description
Incident identification
While work cannot begin on dealing with an incident until it is known that an
incident has occurred, it is usually unacceptable, from a business
perspective, to wait until a user is impacted & contacts the service desk.
Incident logging
All incidents must be fully logged & date/time stamped, regardless of
whether they are raised through a service desk telephone call, automatically
detected via an event alert, or from any other source.
Incident categorization
Part of the initial logging must be to allocate suitable incident categorization
coding so that the exact type of incident is recorded.

Incident management
Process description
Incident prioritization
Another important aspect of logging every incident is to agree & allocate an
appropriate prioritization code, as this will determine how the incident is
handled both by support tools & support staff.
Initial diagnosis
If the incident has been routed via the service desk, the service desk
analyst must carry out initial diagnosis, typically while the user is still on the
telephone – if the call is raised in this way – to try to discover the full
symptoms of the incident & to determine exactly what has gone wrong &
how to correct it.

Incident management
Process description
Incident escalation - Functional escalation
As soon as it becomes clear that the service desk is unable to resolve the
incident itself, the incident must be immediately escalated for further
support.
Hierarchic escalation
If incidents are of a serious nature (for example, high-priority incidents) the
appropriate IT managers must be notified, for informational purposes at
least. Hierarchic escalation is also used if the ‘investigation & diagnosis’ &
‘resolution & recovery’ steps are taking too long or proving too difficult.

Incident management
Process description
Investigation & diagnosis
A reported incident is likely to require some degree of investigation &
diagnosis. Each of the support groups involved with the incident handling
will investigate & diagnose what has gone wrong – & all such activities
(including details of any actions taken to try to resolve or recreate the
incident) should be fully documented in the incident record so that a
complete historical record of all activities is maintained at all times.
Resolution & recovery
When a potential resolution has been identified, this should be applied &
tested. The specific actions to be undertaken & the people who will be
involved in taking the recovery actions may vary, depending upon the
nature of the fault

Incident management
Process description
Incident closure
The service desk should check that the incident is fully resolved & that the
users are satisfied & willing to agree the incident can be closed.

Incident management
Inputs
Information about CIs & their status
Information about known errors & their workarounds
Communication & feedback about incidents & their symptoms
Outputs
Resolved incidents & actions taken to achieve their resolution
Updated incident management records with accurate incident detail &
history
Updated classification of incidents to be used to support proactive problem
management activities

Incident management
CSFs & KPIs
CSF Resolve incidents as quickly as possible minimizing impacts to the
business
KPI Mean elapsed time to achieve incident resolution or circumvention,
broken down by Impact code
CSF Maintain quality of IT services
KPI Total numbers of incidents (as a control Measure)
CSF Maintain user satisfaction with IT services
KPI Average user/customer survey score (total & by question category)

Request fulfilment
Purpose
Objectives
Value to business
Policies & concepts
Process
Inputs & Outputs
CSFs & KPIs

Request fulfilment
Purpose
Request fulfilment is the process responsible for managing the lifecycle of
all service requests from the users. The term ‘service request’ is used as a
generic description for many different types of demands that are placed
upon the IT organization by the users. Many of these are typically requests
for small changes that are low risk, frequently performed, low cost etc. (e.g.
a request to change a password, a request to install an additional software
application onto a particular workstation, a request to relocate some items
of desktop equipment) or may be just a request for information.

Request fulfilment
Objectives
Maintain user & customer satisfaction through efficient & professional
handling of all service requests.
Provide a channel for users to request & receive standard services for
which a predefined authorization & qualification process exists.
Provide information to users & customers about the availability of services &
the procedure for obtaining them

Request fulfilment
Value to business
The ability to provide quick & effective access to standard services that
business staff can use to improve their productivity or the quality of
business services & products.
The ability to effectively reduce the bureaucracy involved in requesting &
receiving access to existing or new services, thus also reducing the cost of
providing these services.
The ability to increase the level of control over requested services through a
centralized fulfilment function. This in turn can help reduce costs through
centralized negotiation with suppliers, & can also help to reduce the cost of
support.

Request fulfilment
Policies & concepts
The activities used to fulfil a request should follow a predefined process
flow (a model) devised to include the stages needed to fulfil the request, the
individuals or support groups involved, target timescales & escalation paths.
This ensures that requests are fulfilled in a consistent & efficient manner. It
implies that all types of requests for any given service are identified in
advance & their fulfilment flows considered during service design. The
ownership of service requests should reside with a centralized function
such as the service desk, which monitors, escalates, despatches & often
fulfils the user request. This provides the benefit of a single point of contact
for requesting & receiving information about service requests & their status.
All requests should be logged, controlled, coordinated, promoted &
managed throughout their lifecycle via a single system. This supports a
consistent & repeatable approach for handling service requests & reduces
the potential for lost requests & conflicts that might arise during handling of
requests.

Request fulfilment
Request models : many organizations will wish to create predefined request
models, which typically include one or more standard changes in order to
complete fulfilment activities.
Menu Selection : Request fulfilment should offer self-help practices, where
users can generate a service request from a ‘menu’-type selection via a
request portal so that they can select & input details of service requests
from a predefined list. In this way, appropriate expectations can be set by
giving target delivery & /or implementation targets/dates (in line with SLA
targets).
Request status tracking : Requests should be tracked throughout their
lifecycle to support proper handling & reporting.
Prioritizing, escalating & Financial approval : Procedures must be in place
to deal with exceptional circumastances.

Request fulfilment
Process

Request fulfilment
Process Description
Receive Request
Standard forms & records should be used to capture request information so
that they can be more easily processed, with minimal need to go back to
requesters for more information. It must be determined whether the request
might actually be an incident or a request for new features.
Request logging & validation
All service requests must be fully logged & date/time stamped, regardless of
whether they are raised through a service desk, RFC, telephone call or
email. As further activities to fulfil a request occur, the request record should
be updated accordingly, with relevant information & details so that a full
history is maintained.
Request categorization
Logging must categorize so that the type of the request is recorded.

Request fulfilment
Process Description
Request prioritization
Another important aspect of logging every request is to agree & allocate an
appropriate prioritization code, as this will determine how the service
request is handled.
Request authorization
No work should take place to fulfil a request until it has been properly
authorized. Simple authorizations can take place via the service desk alone
or as pre-authorized requests based on the request type.
Request review
the request is reviewed to determine the proper function that will fulfil it. In
many cases, the service desk function may perform all needed fulfilment
activities. In other cases, the requests may be escalated to other functions
that perform specialized activities to fulfil them.

Request fulfilment
Process Description
Request model execution
As functions undertake activities to fulfil a request, a request model should
be used that documents a standard process flow, roles & responsibilities for
fulfilling it. This ensures that a repeatable & consistent set of actions are
always undertaken for each request type that minimize the risks for delays
or failures as requests are fulfilled.
Request closure
Once service request activities have been completed, the service desk
should be notified of the completion status. The service desk should then
check that the request has been fulfilled & that users are satisfied & willing
to agree that the request can be closed. Checks should be done to improve
the procedures.

Request fulfilment
Inputs
Work requests
Authorization forms
Service requests
Outputs
Authorized/rejected service requests
Request fulfilment status reports
Fulfilled service requests

Request fulfilment
CSFs & KPIs
CSF Requests must be fulfilled in an efficient & timely manner that is
aligned to agreed service level targets for each type of request
KPI The mean elapsed time for handling each type of service request
CSF Only authorized requests should be fulfilled
KPI Percentage of service requests fulfilled that were appropriately
authorized
CSF User satisfaction must be maintained
KPI Level of user satisfaction with the handling of service requests (as
measured in some form of satisfaction survey)

Problem management
Purpose
Objectives
Value to business
Policies & concepts
Process
Inputs & Outputs
CSFs & KPIs

Problem management
Purpose
The purpose of problem management is to manage the lifecycle of all
problems from first identification through further investigation,
documentation & eventual removal. Problem management seeks to
minimize the adverse impact of incidents & problems on the business that
are caused by underlying errors within the IT Infrastructure, & to proactively
prevent recurrence of incidents related to these errors. In order to achieve
this, problem management seeks to get to the root cause of incidents,
document & communicate known errors & initiate actions to improve or
correct the situation.

Problem management
Objectives
Prevent problems & resulting incidents from happening
Eliminate recurring incidents
Minimize the impact of incidents that cannot be prevented.

Problem management
Value to business
Higher availability of IT services by reducing the number & duration of
incidents that those services may incur. Problem management works
together with incident management & change management to ensure that
IT service availability & quality are increased. When incidents are resolved,
information about the resolution is recorded. Over time, this information is
used to speed up the resolution time & identify permanent solutions,
reducing the number & resolution time of incidents.
Higher productivity of IT staff by reducing unplanned labour caused by
incidents & creating the ability to resolve incidents more quickly through
recorded known errors & workarounds.
Reduced expenditure on workarounds or fixes that do not work.
Reduction in cost of effort in fire-fighting or resolving repeat incidents.

Problem management
Policies & concepts
Problems should be tracked separately from incidents. This will provide
clear separation between many problem management activities that are
proactive & incident management activities that are mostly reactive.
All problems should be stored & managed in a single management system.
This provides a definitive recognized source for problem information &
supports easier access for reporting & investigation efforts.
All problems should subscribe to a standard classification schema that is
consistent across the business enterprise. This provides for faster access to
problem & investigative information. It provides better support for problem
management diagnostic & proactive trending activities. It implies that a well
defined & communicated set of problem classification categories is in place.

Problem management
Reactive & proactive problem management activities: With reactive problem
management, process activities will typically be triggered in reaction to an
incident that has taken place. Reactive problem management complements
incident management activities by focusing on the underlying cause of an
incident to prevent its recurrence & identifying workarounds when
necessary.
With proactive problem management, process activities are triggered by
activities seeking to improve services. One example might be trend analysis
activities to find common underlying causes of historical incidents that took
place to prevent their recurrence. Proactive problem management
complements CSI activities by helping to identify workarounds &
improvement actions that can improve the quality of a service.

Problem management
Problem models: Many problems will be unique & will require handling in an
individual way – but it is conceivable that some incidents may recur
because of dormant or underlying problems.
As well as creating a known error record in the KEDB to ensure quicker
diagnosis, the creation of a problem model for handling such problems in
the future may be helpful. This is very similar in concept to the idea of
incident or request models described in previous chapters, but applied to
problems.
Incidents vs, Problems: An incident is an unplanned interruption to an IT
service or reduction in the quality of an IT service. A problem presents a
different view of an incident by understanding its underlying cause, which
may also be the cause of other incidents. Incidents do not ‘become’
problems. While incident management activities are focused on restoring
services to normal state operations, problem management activities are
focused on finding ways to prevent incidents from happening in the first

Problem management
Incidents vs, Problems: An incident is an unplanned interruption to an IT
service or reduction in the quality of an IT service. A problem presents a
different view of an incident by understanding its underlying cause, which
may also be the cause of other incidents. Incidents do not ‘become’
problems. While incident management activities are focused on restoring
services to normal state operations, problem management activities are
focused on finding ways to prevent incidents from happening in the first
place.
Problem Analysis techniques: There are many problem analysis, diagnosis
& solving techniques available & much research has been done in this area.
Chronological analysis, Pain value analysis, Kepner & Tregoe,
Brainstorming, 5-Whys, Fault isolation, Affinity mapping, Hypothesis testing,
Technical observation post, Ishikawa diagrams, Pareto analysis

Problem management
Process

Problem management
Process Description
Problem detection
It is likely that multiple ways of detecting problems will exist in all
organizations. These can include triggers for reactive & proactive problem
management
Problem logging
Regardless of the detection method, all the relevant details of the problem
must be recorded so that a full historic record exists. This must be date &
time stamped to allow suitable control & escalation.
Problem categorization
Problems should be categorized in the same way as incidents, so that the
true nature of the problem can be easily traced in the future & meaningful
management information can be obtained

Problem management
Process Description
Problem Prioritization
Problems should be prioritized the same way using the same reasons as
incidents. The frequency & impact of related incidents must also be taken
into account.
Problem investigation & diagnosis
An investigation should be conducted to try to diagnose the root cause of
the problem. The appropriate level of resources & expertise should be
applied to finding a resolution commensurate with the priority code
allocated & the service target in place for that priority level.
Workarounds
In some cases it may be possible to find a workaround to the incidents
caused by the problem – a temporary way of overcoming the difficulties.

Problem management
Process Description
Raising a known error record
A known error is defined as a problem with a documented root cause &
workaround. The known error record should identify the problem record it
relates to & document the status of actions being taken to resolve the
problem, its root cause & workaround. All known error records should be
stored in the KEDB.
Problem resolution
Once a root cause has been found & a solution to remove it has been
developed, it should be applied to resolve the problem. If any change in
functionality is required, an RFC should be raised & authorized before the
resolution can be applied. If the problem is very serious & an urgent fix is
needed for business reasons, then an emergency RFC should be raised.

Problem management
Process Description
Problem closure
When a final resolution has been applied, the problem record should be
formally closed – as should any related incident records that are still open.
A check should be performed at this time to ensure that the record contains
a full historical description of all events – & if not, the record should be
updated. The status of any related known error record should be updated to
show that the resolution has been applied.
Major Problem review
After every major problem (as determined by the organization’s priority
system), & while memories are still fresh, a review should be conducted to
learn any lessons for the future. Such reviews can be used as part of
training & awareness activities for support staff

Problem management
Inputs
Incident records for incidents that have triggered problem management
activities
Incident reports & histories that will be used to support proactive problem
trending
Information about CIs & their status
Outputs
Resolved problems & actions taken to achieve their resolution
Updated problem management records with accurate problem detail &
history
RFCs to remove infrastructure errors

Problem management
CSFs & KPIs
CSF Minimize the impact to the business of incidents that cannot be
prevented
KPI The number of known errors added to the KEDB
CSF Maintain quality of IT services through elimination of recurring
incidents
KPI Total numbers of problems (as a control measure)
CSF Provide overall quality & professionalism of problem handling activities
to maintain business confidence in IT capabilities
KPI The number of major problems (opened & closed & backlog)

Access management
Purpose
Objectives
Value to business
Policies & concepts
Process
Inputs & Outputs
CSFs & KPIs

Access management
Purpose
The purpose of access management is to provide the right for users to be
able to use a service or group of services. It is therefore the execution of
policies & actions defined in information security management.

Access management
Objectives
Manage access to services based on policies & actions defined in
information security management
Efficiently respond to requests for granting access to services, changing
access rights or restricting access, ensuring that the rights being provided
or changed are properly granted
Oversee access to services & ensure rights being provided are not
improperly used.

Access management
Value to business
Ensuring that controlled access to services will allow the organization to
maintain effective confidentiality of its information
Ensuring that employees have the right level of access to execute their jobs
effectively
Reducing errors made in data entry or in the use of a critical service by an
unskilled user (e.g. production control systems)
Providing capabilities to audit use of services & to trace the abuse of
services
Providing capabilities to revoke access rights when needed on a timely
basis – an important security consideration
Providing & demonstrating compliance with regulatory requirements (e.g.
SOX, HIPAA & COBIT).

Access management
Policies & concepts
Access management administration & associated activities should be
guided & directed by the policies & controls as defined in the information
security policy
Access management should log & track accesses to use of services &
ensure rights being provided are appropriately used. This implies that
appropriate access logging & tracking capabilities are in place with controls
to raise events for unauthorized access & abuse of services.
Access management should maintain access to services in alignment with
changes in personnel events such as transfers & terminations. This implies
that communications are in place with human resource functions to notify IT
about personnel events & changes on a timely basis

Access management
Access: the level & extent of a service’s functionality/data that a user is
entitled to use.
Identity: the information about them that distinguishes them as an individual
& which verifies their status within the organization. By definition, the
identity of a user is unique to that user.
Rights: the actual settings whereby a user is provided access to a service or
group of services, e.g. read, write, execute, change, delete.
Services or service groups. Most users do not use only one service, & 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/group of users – access to the
whole set of services that they are entitled to use at the same time.
Directory services: the specific tools used to manage access & rights.

Access management
Process

Access management
Process description
Request Access
Access (or restriction) can be requested using one of any number of
mechanisms. Rules for requesting access are normally documented as part
of the request fulfilment model associated with requests for access & may
also be described in the service catalogue.
Verification
Access management needs to verify every request for access to an IT
service from two perspectives:
That the user requesting access is who they say they are. achieved by
the user providing their user name
That they have a legitimate requirement for that service will require some
independent verification,

Access management
Process description
Provide rights
Access management does not decide who has access to which IT services.
Rather, access management executes the policies & regulations defined
during service strategy & service design. Access management enforces
decisions to restrict or provide access, rather than making the decision
Check & monitor identiy status
As users work in the organization, their roles change & so also do their
needs to access Services. Access management should understand &
document the typical user lifecycle for each type of user & use it to
automate the process.

Access management
Process description
Log & track access
Access management should not only respond to requests. It is also
responsible for ensuring that the rights they have provided are being
properly used. In this respect, access monitoring & control must be included
in the monitoring activities of all technical & application management
functions & all service operation processes
Remove or restrict rights
Just as access management provides rights to use a service, it is also
responsible for revoking those rights. Again, this is not a decision that it
makes on its own. Rather, it will execute the decisions & policies made
during service strategy & design & also decisions made by managers in the
organization.

Access management
Inputs
Information security policies (from service design)
Operational & service level requirements for granting access to services,
performing access management administrative activities & responding to
access management related events
Authorized RFCs to access rights
Authorized requests to grant or terminate access rights.
Outputs
Provision of access to IT services in accordance with information security
policies
Access management records & history of access granted to services
Access management records & history where access has been denied &
the reasons for the denial

Access management
CSFs & KPIs
CSF Ensuring that the confidentiality, integrity & availability of services are
protected in accordance with the information security policy
KPI Percentage of incidents that involved inappropriate security access or
attempts at access to services
CSF Provide appropriate access to services on a timely basis that meets
business needs
KPI Percentage of requests for access (service request, RFC etc.) that
were provided within established SLAs & OLAs
CSF Provide timely communications about improper access or abuse of
services on a timely basis
KPI Average duration of access-related incidents (from time of discovery
to escalation).

Agenda

Common service operation
activities
Monitoring & control
IT operations
Server & mainframe management & support
Network management
Storage & archive
Database administration
Directory services management
Desktop & mobile device support
Middleware management
Internet/web management
Facilities & data centre management
Improvement of operational activities

activities
The following section focuses on a number of operational activities that
ensure that technology is aligned with the overall service & process
objectives. These activities are sometimes described as processes, but in
reality they are sets of specialized technical activities all aimed at ensuring
that the technology required to deliver & support services is operating
effectively & efficiently.
These activities will usually be technical in nature – although the exact
technology will vary depending on the type of services being delivered

activities
The steps to mature from a technology-centric organization to an
organization that harnesses technology as part of its business strategy.

Monitoring & control
The measurement & control of services is based on a continual cycle of
monitoring, reporting & subsequent action. This cycle is discussed in detail
in this section because it is fundamental to the delivery, support &
improvement of services.
Monitoring refers to the activity of observing a situation to detect changes
that happen over time. In the context of service operation.
Reporting refers to the analysis, production & distribution of the output of
the monitoring activity.
Control refers to the process of managing the utilization or behaviour of a
device, system or service. Control requires three conditions
• The action must ensure that the outcome conforms to a defined standard
• The conditions prompting the action must be defined, understood & confirmed
• The action must be defined, approved & appropriate for these conditions

IT operations
Console management/operations bridge
Job scheduling
Backup & restore
Print & output management

IT operations
Console management/operations bridge
The console management/operations bridge function handles a structured
set of activities that centrally coordinate management of events, incidents,
routine operational activities, & reporting on the status or performance of
technology components.
The console management/operations bridge function handles a structured
set of activities that centrally coordinate management of events, incidents,
routine operational activities, & reporting on the status or performance of
technology components.

IT operations
Job scheduling
Job scheduling involves defining & initiating job scheduling software
packages to run batch & real-time work. This will normally involve daily,
weekly, monthly, annual & ad hoc schedules to meet business needs.
There are likely to be frequent amendments or adjustments to make during
which job dependencies have to be identified & accommodated. There will
also be a role to play in defining alerts & exception reports to be used for
monitoring/checking job schedules.

IT operations
Backup & restore
Backup & restore is essentially a component of good IT service continuity
planning. As such, service design should ensure that there are solid backup
strategies for each service & service transition should ensure that these are
properly tested.
Regulatory requirements specify that certain types of organization (such as
financial services or listed companies) must have a formal backup & restore
strategy in place & that this strategy is executed & audited.
The only point of taking backups is that they may need to be restored at
some point. For this reason it is not as important to define how to back a
system up as it is to define what components are at risk & how to effectively
mitigate that risk.

IT operations
Print & output management
Many services consist of generating & delivering information in printed or
electronic form. Ensuring the right information gets to the right people, with
full integrity, requires formal control & management.
Print (physical) & output (electronic) facilities & services need to be formally
managed because:
• They often represent the tangible output of a service. The ability to
measure that this output has reached the appropriate destination is
therefore very important
• Physical & electronic output often contains sensitive or confidential
information. It is vital that the appropriate levels of security are applied
to both the generation & the delivery of this output.
Where print & output services are delivered directly to the users, it is
important that the responsibility for maintaining the printers or storage
devices is clearly defined

Server & mainframe
management & support
Servers & mainframes are used in most organizations to provide flexible &
accessible services from hosting applications or databases, operating high-
volume transaction systems, running client/server services, storage, print &
file management. Successful management of servers & mainframes is
therefore essential for successful service operation
The procedures & activities that must be undertaken by mainframe & server
team(s) or department(s) include
Operating system support, Licence management for all server CIs, Third-
level support, Procurement advice, System security, Definition &
management of virtual servers, Capacity & performance:

Network management
As most IT services are dependent on connectivity, network management
will be essential to deliver services & also to enable service operation staff
to access & manage key service components.
Network management will have overall responsibility for all of the
organization’s own local area networks (LANs), metropolitan area networks
(MANs) & wide area networks (WANs), & will also be responsible for liaising
with third-party network suppliers.
Network management is also frequently responsible, often in conjunction
with desktop support, for remote connectivity issues such as dial-in, dial-
back & virtual private network facilities provided to home workers, remote
workers or suppliers.
Some network management teams or departments will also have
responsibility for voice/telephony, & for voice over internet protocol (VoIP),
quality of service & remote monitoring systems.

Storage & archive
Many services require the storage of data for a specific time & also for that
data to be available off-line for a certain period after it is no longer used.
This is often due to regulatory or legislative requirements, but also because
history & audit data are invaluable for a variety of purposes.
A separate team or department may be needed to manage the
organization’s data storage technology.
Regardless of what type of storage systems are being used, storage &
archiving will require management of the infrastructure components as well
as the policies related to where data is stored, for how long, in what form &
who may access it.

Database administration
Database administration must work closely with key application
management teams or departments – & in some organizations the functions
may be combined or linked under a single management structure.
Database administration works to ensure the optimal performance, security
& functionality of databases that they manage.

Directory services management
A directory service is a specialized software application that manages
information about the resources available on a network & which users have
access to. It is the basis for providing access to those resources & for
ensuring that unauthorized access is detected & prevented.
Directory services are usually based on the OSI’s X.500 standard &
commonly use protocols such as Lightweight Directory Access Protocol
(LDAP). LDAP is used to support user credentials for application login &
often includes internal & external user/customer data which is especially
good for extranet call logging. Because LDAP is a critical operational tool,
& generally kept up to date, it is also a good source of data & verification for
the CMS

Desktop & mobile device support
As most users access IT services using desktops, laptops & mobile
computing devices, it is key that these are supported to ensure the agreed
levels of availability & performance of services.
Desktop & mobile device support will have overall responsibility for all of the
organization’s desktop, laptop & mobile device hardware,software &
peripherals

Middleware management
Middleware is software that connects or integrates software components
across distributed or disparate applications & systems. Middleware enables
the effective transfer of data between applications, & is therefore key to
services that are dependent on multiple applications or data sources.
A variety of technologies are currently used to support program-to-program
communication, such as object request brokers, message-oriented
middleware, remote procedure calls & point-to-point web services.
Middleware management can be performed as part of an application
management function (where it is dedicated to a specific application) or as
part of a technical management function (where it is viewed as an extension
to the operating system of a specific platform).

Internet/web management
Many organizations conduct much of their business through the internet &
are therefore heavily dependent upon the availability & performance of their
websites. In such cases a separate internet/web support team or
department will be desirable & justified.

Facilities & data centre
management
Facilities management refers to the management of the physical
environment of IT operations, usually located in data centres or computer
rooms.
Managing a data centre is far more than hosting an open space where
technical groups install & manage equipment, using their own approaches
& procedures. It requires an integrated set of processes & procedures
involving all IT groups at every stage of the service lifecycle. Data centre
operations are governed by strategic & design decisions for management &
control & are executed by operators.
Key functions & policies refer to Data centre automation Specialized
automation systems that reduce the need for manual operators & which
monitor & track the status of the facility & all IT operations at all times.
Policy-based management Where the rules of automation & resource
allocation are managed by policy, rather than having to go through complex
change procedures every time processing is moved between resources

Improvement of operational
activities
All service operation staff should be constantly looking for areas in which
process improvements can be made to give higher IT service quality & /or
performed in a more cost-effective way. Opportunities for improvement will
be included in the CSI register for review & prioritization.

Agenda

Organizational development
Functions
Service desk function
Technical management function
IT operations management function
Application management function
Roles
Service operation organization structures

Organizational development
There is no single best way to organize, & best practices described in ITIL
need to be tailored to suit individual organizations & situations. Any
changes made will need to take into account resource constraints & the
size, nature & needs of the business & customers. The starting point for
organizational design is strategy.

Functions
A function is a team or group of people & the tools or other resources that
they use to carry out one or more processes or activities. In larger
organizations, a function may be broken out & performed by several
departments, teams & groups, or it may be embodied within a single
organizational unit (e.g. the service desk). In smaller organizations, one
person or group can perform multiple functions – e.g. a technical
management department could also incorporate the service desk function.
For service operations to be successful, an organization will need to clearly
define the roles & responsibilities required to undertake the processes &
activities for transition. These roles will need to be assigned to individuals,
& an appropriate organization structure of teams, groups or functions
established & managed.

Functions

Justification & role of the service desk
Service desk objectives
Service desk organizational structure
Service desk staffing
Measuring service desk performance
Outsourcing the service desk

A service desk is a functional unit made up of a dedicated number of staff
responsible for dealing with a variety of service activities, usually made via
telephone calls, web interface, or automatically reported infrastructure
events.
The service desk is a vitally important part of an IT organization & should be
the single point of contact for IT users on a day-by-day basis. It not only
handles incidents, escalates incidents to problem management staff,
manages service requests & answers questions, it may also provide an
interface for other activities such as customer change requests,
maintenance contracts, software licences, SLM, service asset &
configuration management, availability management, financial management
for IT services, & IT service continuity management.
An effective service desk should not be underestimated, a good service
desk can often compensate for deficiencies in IT Dept, but a poor one can
give a poor impression of an otherwise very effective IT Dept!

Justification & role of the service desk
Very little justification is needed today for a service desk, as many
organizations have become convinced that this is by far the best approach
for dealing with first-line IT support issues.
Users calling the service desk should be able to speak to someone who is
able to address their needs, & service desk analysts should not be burned
out in less than a year because of undue stress. Care should be taken to
select appropriately skilled individuals with a good understanding of the
business & to provide adequate training

Service desk objectives
The primary aim of the service desk is to provide a single point of contact
between the services being provided & the users. A typical service desk
manages incidents & service requests, & also handles communication with
the users. Service desk staff execute the incident management & request
fulfilment processes to restore the normal-state service operation to the
users as quickly as possible. In this context ‘restoration of service’ is meant
in the widest possible sense. While this could involve fixing a technical fault,
it could equally involve fulfilling a service request or answering a query –
anything that is needed to allow the users to return to working satisfactorily

Service desk organizational structure
There are many ways of structuring service desks & locating them – & the
correct solution will vary for different organizations. The primary options are
detailed over the next few slides, but in reality an organization may need to
implement a structure that combines a number of these options in order to
fully meet the business needs.

Service desk organizational structure – Local service desk

Service desk organizational structure – Centralized service
desk

Service desk organizational structure – Virtual service desk

An organization must ensure that the correct number of staff are available
at any given time to match the demand being placed upon the desk by the
business. Call rates can be very volatile & often in the same day the arrival
rate may go from very high to very low & back again. An organization
planning a new desk should attempt to predict the call arrival rate & profile,
& to staff accordingly.
An organization must decide on the level & range of skills it requires of its
service desk staff, & then ensure that these skills are available at the
appropriate times. A range of skill options are possible, starting from a call
logging service only – where staff need only very basic technical skills –
right through to a technical service desk where the organization’s most
technically skilled staff are used. In the case of the former, there will be a
high handling but low resolution rate, while in the latter case this will be
reversed.

It is vital that all service desk staff are adequately trained before they are
called upon to staff the service desk. A formal induction programme should
be undertaken by all new staff, the exact content of which will vary
depending upon the existing skill levels & experience of the new recruit.
Many organizations find it useful to appoint or designate a number of ‘super
users’ throughout the user community, to act as liaison points with IT in
general & the service desk in particular. Super users can be given some
additional training & awareness & used as a conduit for communications
flow in both directions. They can be asked to filter requests & issues raised
by the user community; this can help prevent ‘incident storms’ when a key
service or component fails, affecting many users.

It is very important that all IT managers recognize the importance of the
service desk & the staff who work on it, & give this special attention. Any
significant loss of staff can be disruptive & lead to inconsistency of service,
so efforts should be made to make the service desk an attractive place to
work.
Ways in which this can be done include proper recognition of the role, with
reward packages recognizing this, team-building exercises & staff rotation
onto other activities (projects, second-line support etc.).

Measuring service desk performance
Metrics should be established so that performance of the service desk can
be evaluated at regular intervals. This is important to assess the health,
maturity, efficiency, effectiveness & any opportunities to improve service
desk operations.
Metrics for service desk performance must be realistic & carefully chosen. It
is common to select those metrics that are easily available & that may seem
to be a possible indication of performance; however, this can be misleading.
For example, the total number of calls received by the service desk is not in
itself an indication of either good or bad performance & may in fact be
caused by events completely outside the control of the service desk, An
increase in the number of calls to the service desk can indicate less reliable
services over that period of time – but may also indicate increased user
confidence in a service desk that is maturing, resulting in a higher likelihood
that users will seek help rather than try to cope alone.

Outsourcing the service desk
it is vital that the organization retains accountability for the activities &
services provided by the service desk. The organization is ultimately
accountable for the outcomes of the decision & must therefore determine
what service the outsourcer provides, not the other way round.
If the outsourcing route is chosen, some safeguards are needed to ensure
that the outsourced service desk works effectively & efficiently with the
organization’s other IT teams & departments & that end-to-end service
management control is maintained Some of these safeguards are set out
below
Common tools & processes
SLA targets
Good communications
Ownership of data

Technical management role
Technical management objectives
Generic technical management activities
Technical management organization
Technical design & technical maintenance & support
Measuring technical management performance
Technical management documentation

Technical management role
Technical management plays a dual role:
It is the custodian of technical knowledge & expertise related to managing
the IT infrastructure. In this role, technical management ensures that the
knowledge required to design, test, manage & improve IT services is
identified, developed & refined.
It provides the actual resources to support the service lifecycle. In this role
technical management ensures that resources are effectively trained &
deployed to design, build, transition, operate & improve the technology
required to deliver & support IT services.
By performing these two roles, technical management is able to ensure that
the organization has access to the right type & level of human resources to
manage technology & thus to meet business objectives

Technical management objectives
The objectives of technical management are to help plan, implement &
maintain a stable technical infrastructure to support the organization’s
business processes through:
Well designed & highly resilient, cost-effective technical topology
The use of adequate technical skills to maintain the technical infrastructure
in optimum condition
Swift use of technical skills to speedily diagnose & resolve any technical
failures that do occur.

Generic technical management activities
Technical management is involved in two types of activity:
Activities that are generic to the technical management function as a whole.
Identifying the knowledge & expertise required to manage & operate the IT
infrastructure & to deliver IT services
Documenting the skills that exist in the organization, as well as those skills
that need to be developed
Procuring skills for specific activities where the required skills are not
available

Technical management organization
Technical management is not normally provided by a single department or
group. One or more technical support teams or departments will be needed
to provide technical management & support for the IT infrastructure.
Technical management consists of a number of technological areas. Each
of these requires a specific set of skills to manage & operate it. The primary
criterion of technical management organizational structure is that of
specialization or division of labour. The principle is that people are grouped
according to their technical skill sets, & that these skill sets are determined
by the technology that needs to be managed.

Technical design & technical maintenance & support
Technical management consists of specialist technical architects &
designers & specialist maintenance & support staff.
The problems that need to be overcome are similar to those faced in
managing the application lifecycle. The solution will include the following
elements:
Support staff should be involved during the design or architecture of a
solution. Design staff should be involved in setting maintenance objectives
& resolving support issues.
A change in how both design & support staff are measured. Designers
should be held accountable for their portion of the design flaws that create
operational outages. Support staff should be held accountable for
theircontribution to the technical architecture.

Measuring technical management performance
Performance metrics for technical management will largely depend on
which technology is being managed, but some generic metrics are:
Measurement of agreed metrics
Process metrics
Technology performance
Meantime between failures of specified equipment
Measurement of maintenance activity
Training & skils development

Technical management documentation
Technical documentations
Maintenance schedules
Skills inventory

IT operations management
function
IT operations management role
IT operations management objectives
IT operations management organization
Measuring IT operations management performance
IT operations management documentation

function
IT operations management role
The role of IT operations management is to execute the ongoing activities &
procedures required to manage & maintain the IT infrastructure so as to
deliver & support IT services at the agreed levels.
IT operations control oversees the execution & monitoring of the operational
activities & events in the IT infrastructure. This can be done with the help of
an operations bridge or network operations centre.
Facilities management refers to the management of the physical IT
environment, typically a data centre or computer rooms & recovery sites
together with all the power & cooling equipment. Facilities management
also includes the coordination of large-scale consolidation projects, e.g.
data centre consolidation or server consolidation projects. In some cases
the management of a data centre is outsourced, in which case facilities
management refers to the management of the outsourcing contract.

function
IT operations management objectives
Maintenance of the status quo to achieve stability of the organization’s day-
to-day processes & activities
Regular scrutiny & improvements to achieve improved service at reduced
costs, while maintaining stability
Swift application of operational skills to diagnose & resolve any IT
operations failures that occur.

function
IT operations management organization
IT operations management is seen as a function in its own right but that, in
many cases, staff from technical & application management groups form
part of this function.
This means that some technical & application management departments or
groups will manage & execute their own operational activities. Others will
delegate these activities to a dedicated IT operations department.

function
Measuring IT operations management performance
IT operations management performance is measured in terms of its
effective execution of specified activities & procedures, as well as its
execution of process activities. Examples of key metrics used to measure
the performance of the IT operations function can include:
Percentage of scheduled jobs completed successfully on time
Number of exceptions to scheduled activities & jobs
Number of data or system restores required
Equipment installation statistics, including number of items installed by type,
successful installations etc.
Process metrics. IT operations management executes many service
management process activities. Their ability to do so will be measured as
part of the process metrics where appropriate

function
IT operations management documentation
A number of documents are produced & used during IT operations
management. This list is a summary of some of the most important & does
not include reports that are produced by IT operations management on
behalf of other processes or functions.
Standard operating procedures
The SOPs are a set of documents containing detailed instructions & activity
schedules for every IT operations management team, department or group
Operations logs
Any activity that is conducted as part of IT operations should be recorded.
Shift schedules & reports
Shift schedules are documents that outline the exact activities that need to
be carried out during he shift.

Application management roles
Application management objectives
Application management principles
Application management lifecycle
Application management generic activities
Application management organization
Measuring application management performance
Application management documentation

Application management is to applications what technical management is to
the IT infrastructure. Application management activities are performed in all
applications, whether purchased or developed in-house. One of the key
decisions that they contribute to is the decision of whether to buy an
application or build it. Once that decision is made, application management
will have several roles:
It is the custodian of technical knowledge & expertise related to managing
applications. In this role application management, working together with
technical management, ensures that the knowledge required to design, test,
manage & improve IT services is identified, developed & refined.
It provides the actual resources to support the service lifecycle. In this role,
application management ensures that resources are effectively trained &
deployed to design, build, transition, operate & improve the technology
required to deliver & support IT services.

Application management objectives
Applications that are well designed, resilient & cost-effective
Ensuring that the required functionality is available to achieve the required
business outcome
The organization of adequate technical skills to maintain operational
applications in optimum condition
Swift use of technical skills to speedily diagnose & resolve any technical
failures that do occur.

Application management principles
One of the key decisions in application management is whether to buy an
application that supports the required functionality, or whether to build the
application specifically for the organization’s requirements.
Application management will assist in this decision during service design as
follows:
Application sizing & workload forecasts
Specification of manageability requirements
Identification of ongoing operational costs
If the decision is to build the application, a further decision needs to be
made on whether the development will be outsourced or built using
employees.
An operational model is the specification of the operational environment in
which the application will eventually run when it goes live.

Application management lifecycle

Application management lifecycle - Requirements
During this stage the requirements for a new application are gathered,
based on the business needs of the organization & is active during the
service design stage of the service lifecycle. There are six types
Functional requirements These are specifically required to support a
particular business function. Manageability requirements These
requirements address the need for a responsive, available & secure
service. Usability requirements These address the needs of the end user.
Architectural requirements These are needed if a change to existing
architecture standards is required. Interface requirements These are
needed where there are dependencies between existing applications or
tools & the new application. Service level requirements These specify
how the service should perform, the quality of its output & any other
qualitative aspects measured by the user or customer.

Application management lifecycle – Design
This is the stage during which requirements are translated into
specifications. Design includes the design of the application itself, & the
design of the environment, or operational model that the application has to
run on. Architectural considerations are the most important aspect of this
stage, because they can impact on the structure & content of both
application & operational model. Considerations for the application (design
of the application architecture) & for the operation model (design of the
system architecture) are strongly related & need to be aligned.
For purchased software, organizations will not be allowed direct input to the
design of the software However, it is important that application management
is able to provide feedback to the software vendor about the functionality,
manageability & performance of the software. Responsiveness of the
software vendor to the continual improvement of the software needs to be
evaluated

Application management lifecycle – Build
In the build stage, both the application & the operational model are made
ready for deployment. Application components are coded or acquired,
integrated & tested.
Please note that ‘test’ is not a separate stage in the lifecycle, even though it
is a discrete activity, & even though tests are conducted independently of
both the development & operational activities. Without the build & deploy
stages, there would be nothing to test & , without testing, there would be no
control over what is developed & deployed.
For purchased software, this will involve the actual purchase of the
application, any required middleware & the related hardware & networking
equipment. Any customization that is required will need to be done here.

Application management lifecycle – Deploy
In this stage, both the operational model & the application are deployed.
The operational model is incorporated in the existing IT environment & the
application is installed on top of the operational model.
Testing also takes place during this stage, although here the emphasis is on
ensuring that the deployment process & mechanisms work effectively, e.g.
testing whether the application still functions to specification after it has
been downloaded & installed.

Application management lifecycle – Operate
In the operate stage, the IT services organization operates the application
as part of delivering a service required by the business. The performance of
the application in relation to the overall service is measured continually
against the service levels & key business drivers.

Application management lifecycle – Optimize
In the optimize stage, the results of the service level performance
measurements are measured, analysed & acted upon. Possible
improvements are discussed & developments initiated if necessary.
One important thing to remember about the application management
lifecycle is that, because it is circular, the same application can reside in
different stages of the lifecycle at the same time.

Application management generic activities
Identifying the knowledge & expertise required to manage & operate
applications in the delivery of IT services.
Initiating training programmes to develop & refine the skills in the
appropriate application management resources & maintaining training
records for these resources.
Recruiting or contracting resources with skills that cannot be developed
internally, or where there are insufficient people to perform the required
application management activities

Application management organization
Although all application management departments, groups or teams
perform similar activities, each application or set of applications has a
different set of management & operational requirements. Examples of these
differences include:
The purpose of the application Each application was developed to meet a
specific set of objectives, usually business objectives. The functionality of
the application Each application is designed to work in a different way & to
perform different functions at different time. The platform on which the
application runs Each platform affects the way in which an application
needs to be managed & operated. The type or brand of technology used
Even applications that have similar functionality operate differently on
different databases or platforms

Measuring application management performance
Performance metrics for application management will largely depend on
which applications are being managed, but some generic metrics are
included here.
Percentage of users able to access the application & its functionality
Percentage of reports & files that are transmitted accurately & on time to the
users
Percentage availability for critical business transactions
Application management teams execute many service management
process activities. Their ability to do so will be measured as part of the
process m
Application performance metrics are based on service design specifications
& technical performance standards set by vendors & will typically be
contained in OLAs or SOPs.

Application management documentation
Application portfolio
Application requirements
Use cases
Design documentation
Manuals

Roles
A number of roles need to be performed in support of service operations. A
role is a set of responsibilities, activities & authorities granted to a person or
team. A role is defined in a process or function. One person or team may
have multiple roles; for example, the roles of configuration manager &
change manager may be carried out by a single person.
Roles are often confused with job titles, but it is important to realize that
they are not the same. Each organization will define appropriate job titles &
job descriptions that suit its needs, & individuals holding these job titles can
perform one or more of the required roles.
Roles fall into two main categories – generic roles such as process
manager & process owner, & specific roles that are involved within a
particular lifecycle stage or process such as a service desk analyst or IT
operator.

Roles
Incident management roles
Incident management process owner
Carrying out the generic process owner role for the incident management
process
Designing incident models & workflows
Working with other process owners to ensure there is an integrated
approach to the design & implementation of incident management,
problem management, event management, access management &
request fulfilment process owner
Incident management process owner
Carrying out the generic process manager role for the incident
management process
Planning & managing support for incident management tools & processes
Coordinating interfaces between incident management & other service
management processes

Roles
First-line analyst
Recording incidents
Routeing incidents to support specialist groups when needed
Analysing for correct prioritization, classification & providing initial support
Providing ownership, monitoring, tracking & communication of incidents
Providing resolution & recovery of incidents not assigned to support
specialist groups
Closing incidents
Monitoring the status & progress towards resolution of assigned incidents

Roles
Second-line analyst
Many organizations choose to have a second-line support group, made
up of staff with greater (though still general) technical skills than the
service desk – & with additional time to devote to incident diagnosis &
resolution without interference from telephone interruptions. Key
responsibilities would be similar to the first-line analyst role.
Such a group can handle many of the less complicated incidents, leaving
more specialist third-line) support groups to concentrate on dealing with
more deep-rooted incidents & /or new developments etc.
Third-line analyst
Third-line support will be provided by a number of internal technical
groups & /or third-party suppliers/maintainers
Voice support, Network support, Server support, Desktop support,
Application support, Database support, Hardware support

Roles
Problem management roles
Problem management process owner
Carrying out the generic process owner role for the problem management
process
Designing problem models & workflows Working with other process
owners to ensure there is an integrated approach to the design &
implementation of problem management, incident management, event
management, access management & request fulfilment
Problem management process manager
Carrying out the generic process manager role for the problem
management process
Planning & managing support for problem management tools &
processes
Coordinating interfaces between problem management & other service

Roles
Problem management roles
Problem analyst
Reviewing incident data to analyse assigned problems
Analysing problems for correct prioritization & classification
Investigating assigned problems through to resolution or root cause
Coordinating actions of others as necessary to assist with analysis &
resolution actions for problems & known errors
Raising RFCs to resolve problems
Monitoring progress on the resolution of known errors & advising incident
management staff on the best available workaround for incidents
Updating the KEDB with new or updated known errors & workarounds
Assisting with the handling of major incidents & identifying their root
causes.

Roles
Request fulfilment roles
Request fulfilment process owner
Carrying out the generic process owner role for the request fulfilment
process
Designing request fulfilment models & workflows
approach to the design & implementation of request fulfilment, incident
management, event management, access management & problem
management.
Request fulfilment process manager
Carrying out the generic process manager role for the request fulfilment
process
Planning & managing support for request fulfilment tools & processes
Coordinating interfaces between request fulfilment & other service

Roles
Request fulfilment roles
Request fulfilment analyst
Providing a single point of contact & end-to-end responsibility to ensure
submitted service requests have been processed
Providing initial triage of service requests to determine which IT
resources should be engaged to fulfil them
Communicating service requests to other IT resources that will be
involved in fulfilling them
Escalating service requests in line with established service level targets
Ensuring service requests are appropriately logged

Roles
Event management roles
Event management process owner
Carrying out the generic process owner role for the event management
process
Planning & managing support for event management tools & processes
approach to the design & implementation of event management, incident
management, request fulfilment, access management & problem
management.
Event management process manager
Carrying out the generic process manager role for the event management
process
Planning & managing support for event management tools & processes
Coordinating interfaces between event mgmt & other service
management processes.

Roles
Access management roles
Access management process owner
Carrying out the generic process owner role
for the access management process
Designing access request workflows
approach to the design & implementation of access management,
incident management, event management, request fulfilment & problem
management.
Access management process manager
Carrying out the generic process manager role for the access
management process
Planning & managing support for access management tools & processes
Coordinating interfaces between access management & other processes

Roles
Service desk roles
Service desk manager
Appointing people to the required roles
Managing resources assigned to the service desk, including the
supervisor(s)
Managing service desk activities
Acting as an escalation point for the supervisor(s)
Reporting to senior managers on any issue that could significantly impact
the business
Service desk supervisor
Ensuring that staffing & skill levels are maintained throughout operational
hours by managing shift staffing schedules etc.
Undertaking human resources activities as needed
Escalation point where difficult/controversial calls are received

Roles
Service desk roles
Service desk analyst
The primary service desk analyst role is that of providing first-line support
through taking calls & handling the resulting incidents or service requests
using the incident reporting & request fulfilment processes, in line with the
objectives described earlier. It is quite common to have this role as a
combination of the first-line analyst role & request fulfilment analyst role
described earlier
Super user
The super user role will consist of business users who act as liaison points
Facilitating communication between IT & the business at an operational
level
Reinforcing expectations of users regarding the service levels that have
been agreed
Staff training for users in their area

Roles
Technical management roles
Technical manager/team leader
Taking overall responsibility for leadership, control & decision-making for
the technical team or department
Providing technical knowledge & leadership in the specific technical areas
covered by the team or department
Ensuring necessary technical training, awareness & experience levels are
maintained within the team or department
Technical analyst/architect
Working with users, sponsors, application management & all other
stakeholders to determine their evolving needs
Working with application management & other areas in technical
management to determine the highest level of system requirements
required to meet the requirements within budget & technology constraints

Roles
IT operations management roles
IT operations manager
Providing overall leadership, control & decision-making & taking
responsibility for the IT operations management teams & department
Reporting to senior management on all IT operations issues
Performing line management for all IT operations team or department
managers/supervisors.
Shift leader
Taking overall responsibility for leadership, control & decision-making
during the shift period
Ensuring that all operational activities are satisfactorily performed within
agreed timescales
Liaising with the other shift leader(s) to ensure handover, continuity &
consistency between the shifts

Roles
Applications manager/team leader
Taking overall responsibility for leadership, control & decision-making for
the applications team or department
Providing technical knowledge & leadership in the specific applications
support activities covered by the team or department
Ensuring necessary technical training, awareness & experience levels are
maintained within the team or department relevant to the applications
being supported & processes being used.
Applications analyst
Working with users, sponsors & all other stakeholders to determine their
evolving needs
Working with technical management to determine the highest level of
system requirements required to meet the business requirements within
budget & technology constraints

Service operation organization
structures
Organization by technical function
Organization by activity
Organization by manage process
Organization by geography
Hybrid structures
Combined functions

structures
In this type of organization, departments are created according to
technology & the skills & activities needed to manage that technology. IT
operations will follow the structure of the technical & application
management departments. The implication of this is that the IT operations
department is geared towards the operational agendas of the technical &
application management departments.
This structure can work well, provided that these groups are fully
represented in the service design, testing & improvement processes, which
will ensure that their agendas are aligned with the requirements of the
business.
This structure also assumes that all technical & application management
departments have clearly distinguished between their management activity
and operations activity & that they have standardized these operational
activities so that they can be effectively managed

structures

structures
The advantages of this type of organizational structure include the following:
It is easier to set internal performance objectives because all staff in a
single department have a similar set of tasks on a similar technology.
Individual devices, systems or platforms can be managed more
effectively because people with the appropriate skills are dedicated to
manage these & measured according to their performance.
Managing training programmes is easier because skill sets are clearly
defined & separated into specific groups.

structures
The disadvantages of this type of organizational structure include:
When people are divided into separate departments the priorities of their
own group tend to override the priorities of other departments. An
example of this is when departments refuse to accept ownership of an
incident, each one blaming the other while the business continues to be
disrupted.
Knowledge about the infrastructure & relationships between components
is difficult to collect & fragmented. Individual groups tend to collect &
maintain only the data that is required to support their own function, & do
not give access to it very easily.
It is more difficult to understand the impact of a single department’s poor
performance on the IT service because there are many different groups
contributing to the same service, each with its own set of performance
objectives.

structures
This type of organization structure focuses on the fact that similar activities
have to be performed on all technologies in the organization. This means
that people who perform similar activities, regardless of the technology,
should be grouped together, although within each department there may be
teams focusing on a specific technology, application etc.
In this type of organization, there is no clear differentiation between the
different technical & application management areas. Similar activities from
many different areas can be grouped into a single department.

structures

structures
It is easier to manage groups of related activities because all the people
involved in these activities report to the same manager.
Measurement of teams or departments is based more on output than on
isolated activities. This helps to build higher levels of assurance that a
service can be delivered.
The disadvantages of this type of organizational structure include the
following:
Resources with similar skills may be duplicated across different functions,
which results in higher costs.
Although measurement is more output-based, it is still focused on the
performance of internal activities rather than driven by the experience of
the customer or end user.

structures
It is not a good idea to structure the whole organization according to
processes. Processes are used to overcome the ‘silo effect’ of departments,
not to create silos. However, there are a number of processes that will need
a dedicated organization structure to support & manage it. For example, it
will be very difficult for financial management to be successful without a
dedicated finance department – even if that department consists of a small
number of staff.
In process-based organizations people are organized into groups or
departments that perform or manage a specific process. This is similar to
the activity-based structure, except that its departments focus on end-to-
end sets of activities rather than on one individual type of activity.
It should be noted that this type of organization structure should only be
used if IT operations management is responsible for more than just IT
operations, e.g. is responsible for defining SLAs & negotiating UCs.

structures
Processes are easier to define.
There is less role conflict as job descriptions & process role descriptions
are the same. In other structures a single job description will typically
include activities for several roles.
Metrics of team or department performance & process performance are
the same, effectively aligning ‘internal’ & ‘external’ metrics.

structures
following:
By using processes as a basis for organizational design, additional
processes may need to be defined to ensure that the departments work
together.
Even if a department is responsible for executing a process, there will still
be external dependencies. Groups may not view process activities
outside of their own process as being important, resulting in processes
that cannot be fully executed because dependencies cannot be met.
While some aspects of a process can be centralized, there will always be
a number of activities that will have to be performed by other groups. The
relationship between the dedicated team or department & the people
performing the decentralized activities is often difficult to define & manage

structures
IT operations can be physically distributed & in some cases each location
needs to be organized according to its own particular context. This structure
is typically used in the following circumstances:
Data centres are geographically distributed.
Different regions or countries have different technologies or provide a
different set of services
Different standards apply to different countries or regions.
Each geographical department is structured internally using technical
specialization. This could be different in each region. For example one
region may be structured in this way, while another region uses a process-
or activity-based structure

structures

structures
Organization structure can be customized to meet local conditions.
IT operations can be customized to meet differing levels of IT service
from region to region.
following:
Reporting lines & authority structures can be confusing. For example,
does network operations report into the local data centre manager or to a
centralized network operations manager?
Operational standards are difficult to impose, resulting in inconsistent &
duplicated activities & tools, resulting in reduced economies of scale,
which in turn increases the overall cost of operations.
Duplication of roles, activities, tools & facilities across multiple locations
could be very costly.

structures
Hybrid structures
It is unlikely that IT operations management will be organized using only
one type of organization structure. Some organizations use a technical
specialization structure combined with some additional activity- or process-
based structures. The type of structure used & the exact combination of
technical specialization, activity based & process-based departments will
depend on a number of organizational variable

structures
Combined functions
One final type of organization should be discussed. This structure
incorporates IT operations, technical & application management
departments into a single structure. This is sometimes the case where all
groups are co-located in a single data centre. Here, the IT operations
manager takes responsibility for all technical, application & IT operations
management.
In this structure, IT operations management is responsible for the technical
& application management functions, which in turn are responsible for
managing their own operational activities. Each department is able to
delegate some of these activities to the operations control department.

structures
Combined functions

structures
Combined functions
The advantages of this organization structure are:
There is greater consistency & control between the more tactical & more
operational technical management activities.
It is easier to enforce the performance standards & technical
architectures that are created in service design, because the people who
were involved in design are managing the activities of the people who are
executing those activities.
As there is no duplication between location or activity, this structure is
often more cost effective.
The disadvantage of this organization structure is:
The scope of this structure makes it very difficult to manage effectively in
large organizations or in organizations with multiple data centres.

Agenda

Generic requirements
Event management
Incident management
Request fulfilment
Problem management
Access management
Service desk

Generic requirements
An integrated ITSM technology is needed that includes the following core
functionality
Self- Help
Workflow or process engine
Integrated configuration management system
Discovery/deployment/licensing technology
Remote control
Diagnostic utilities
Reporting
Dashboards
Integration with business
Software as a Service

Event management
The following features are desirable for any event management technology:
Multi-environmental, open interface to allow monitoring & alerting across
heterogeneous services & an organization’s entire IT infrastructure
Easy to deploy, with minimal set-up costs
‘Standard’ agents to monitor most common
environments/components/systems
Open interfaces to accept any standard (e.g.SNMP) event input &
generation of multiple alerting
Centralized routeing of all events to a single location, programmable to
allow different location(s) at various times
Configurable & programmable functionality to correlate similar/identical
events
Capability to manipulate events programmatically after they are
generated & before they are communicated & presented

Incident management
The following features are desirable for any incident management
technology:
Incident logging capabilities that allow for efficient entry of incident data
categorization, prioritization, tracking & reporting of incidents
An integral CMS to allow automated relationships to be made &
maintained between incidents, service requests, problems, known errors,
workarounds, & all other CIs
The CMS that can be used to assist in determining priority & aid in
investigation & diagnosis
A process flow engine to allow processes to be predefined &
automatically controlled – with flexible internal routeing to all relevant
support groups & external interfaces (e.g. email)
Automated alerting & escalation capabilities to prevent an incident being
overlooked or delayed
Open interfacing to event management tools, so that any failures can be
automatically raised as incidents

Request fulfilment
Integrated ITSM technology is needed so that service requests can be
linked to incidents or events that have initiated them (and been stored in the
same CMS, which can be interrogated to report against SLAs). Some
organizations will be content to use the incident management element of
such tools & to treat service requests as a subset & defined category of
incidents. Where an organization chooses to raise separate service
requests, it will require a tool that allows this capability.
Front-end self-help capabilities will be needed to allow users to submit
requests via some form of web-based, menu-driven selection process. This
may be integrated with an IT service catalogue & access controls to ensure
service requests are issued only by those authorized to do so.
Workflow engine capabilities will be needed to automate work steps &
authorization tasks for supporting service request models & fulfilment
activities.

Problem management
An integrated ITSM tool is needed that differentiates between incidents &
problems – so that separate problem records can be raised to deal with the
underlying causes of incidents, but linked to the related incidents. The
functionality of problem records should be similar to those needed for
incident records & also allow for multiple incident matching against problem
records.
Integration with change management is very important, so that request,
event, incident & problem records can be related to RFCs that have caused
problems. This is to evaluate the success of the change management
process.
It is also important to have an integrated CMS which allows problem
records to be linked to the components affected & the services impacted
An effective KEDB will be an essential requirement, which should allow
easy storage & retrieval of known error data.

Access management
Access management uses a variety of technologies, mainly:
Human resource management technology, to authenticate the identity of
users, authorize their access, & track their status
Directory services technology. This technology enables technology
managers to assign names to resources on a network & then provide
access to those resources based on the profile of the user. Directory
services tools also enable access management to create roles & groups
& to link these to both users & resources
Access management features in applications, middleware, operating
systems & network operating systems
Change management systems
Request fulfilment technology

Service desk
Adequate tools & technology support should be provided to enable service
desk staff to perform their roles as efficiently & effectively as possible. This
will include the following
Because a high percentage of incidents are likely to be raised by
telephone calls from users, the service desk should be provided with
good, modern telephony services with Automatic Call Distribution,
Computer Telephony Integration, Voice over internet Protocol & statistical
software.
There are a range of free-standing service desk support tools available in
the marketplace – & some organizations may choose to produce their
own simple incident logging/management systems. If an organization
seriously intends to implement ITSM, then a fully integrated ITSM toolset
will be required that has a CMS at the centre & provides integrated
support for all the ITIL-defined processes.

Agenda

Implementation of service
operation
It should be noted that service operation is a stage in a lifecycle & not an
entity in its own right. By the time a service, process, organization structure
or technology is operating, it has already been implemented, however this
section will focus on some generic implementation guidance for service
operation as a whole.

Managing change in service
operation
Service operation should strive to achieve stability – but not stagnation!
There are many valid & advantageous reasons why ‘change is a good
thing’, but service operation staff must ensure that any changes are
absorbed without adverse impact upon the stability of the IT services being
offered.
There are many things that may trigger a change in the service operation
environment. These include:
New or upgraded hardware or network components
New or upgraded applications or system software
Legislative, conformance or governance changes
Service operation staff must be involved in the assessment of all changes to
ensure that operational issues are fully taken into account.
The ultimate measure of success in respect of changes made to service
operation is that customers & users do not experience any unexpected
variation or outage of service

Service operation & project
management
Because service operation is generally viewed as ‘business as usual’ &
often focused on executing defined procedures in a standard way, there is a
tendency not to use project management processes when they would in fact
be appropriate.
Using project management to manage these types of activity would have
the following benefits:
The project benefits are clearly stated & agreed
There is more visibility of what is being done & how it is being managed,
which makes it easier for other IT groups & the business to quantify the
contributions made by operational teams
This in turn makes it easier to obtain funding for projects that have
traditionally been difficult to cost justify

Assessing & managing risk in
service operation
There will be a number of occasions where it is imperative that risk
assessment to service operation is quickly undertaken & acted upon.
The most obvious area is in assessing the risk of potential changes or
known errors, but in addition service operation staff may need to be
involved in assessing the risk & impact of:
Failures, or potential failures – either reported by event management or
incident/ problem management, or warnings raised by manufacturers,
suppliers or contractors
New projects that will ultimately result in delivery into the live environment
Environmental risk (encompassing IT service continuity-type risks to the
physical environment & locale as well as political, commercial or industrial
relations related risks

Operational staff in service
design & transition
All IT groups will be involved during service sign & service transition to
ensure that new components or services are designed, tested &
implemented to provide the correct levels of functionality, usability,
availability, capacity etc.
Additionally, service operation staff must be involved during the early stages
of service design & service transition to ensure that when new services
reach the live environment they are fit for purpose, from a service operation
perspective, & are ‘supportable’ in the future. i.e.
Capable of being supported from a technical & operational viewpoint from
within existing or pre-agreed additional resources & skills levels
Without adverse impact on other existing technical or operational working
practices, processes or schedules
Without any unexpected operational costs or ongoing or escalating
support expenditure

Planning & implementing service
management technologies
There are a number of factors that organizations need to plan for in
readiness for & during deployment & implementation of, ITSM support tools.
These include the following
Licences - The overall cost of ITSM tools, particularly the integrated tool
that will form the heart of the required toolset, is usually determined by the
number & type of user licences that the organization needs.
Deployment – Many ITSM tools, particularly discovery & event monitoring
tools, will require some client/agent software deploying to all target
locations before they can be used. This will need careful planning &
execution & should be handled through release & deployment
management. Care is needed to ensure that tools are deployed at the
appropriate time in relation to the organization’s level of ITSM sophistication
& knowledge. If tools are deployed too soon, they may be seen as an
immediate panacea & any necessary action to change processes, working
practices or attitudes may be hindered or overlooked.

ITIL service operations

More Related Content

What's hot (20)

Similar to ITIL service operations (20)

Recently uploaded (20)

ITIL service operations