ISI3I3 – Manajemen Layanan
ITIL Management
Practices Part 2
Team Teaching ISM
Program Studi Sistem Informasi
Fakultas Rekayasa Industri
Outline
1. ITIL Management Practices Overview
2. Practices to Manage Operations
– Monitoring and Event Management
– Incident Management
– Problem Management
3. Practices to Manage Changes
– Service Request Management
– Change Control
ITIL MANAGEMENT PRACTICES OVERVIEW
34 ITIL Practices
Practices to Manage Operations
Practices to Manage Changes
PRACTICES TO MANAGE OPERATIONS
Monitoring and Event Management
Incident Management
Problem Management
Monitoring and Event Management
PURPOSE of Practice
Systematically observe services and
service components, and record and
report selected changes of state
identified as events.
Identifies and prioritizes infrastructure, services,
business processes, and information security
events, and establishes the appropriate
response to those events, including responding
to conditions that could lead to potential faults
or incidents.
Event
Any change of state that has significance
for the management of a service or other
configuration item (CI)
Events are typically recognized through
notifications created by an IT service, CI,
or monitoring tool.
Monitoring and Event Management
• manages events throughout their lifecycle to
prevent, minimize, or eliminate their negative
impact on the business
• monitoring in a highly automated manner actively or passively
• recording and managing changes of state
determining the significance, and identifying
and initiating the correct control action
• not all events have the same significance or
require the same response
• events are often classified as informational,
warning, and exceptions
Event Management
Example of Events
Informational
▪ A user logs onto an application
▪ A job in the batch queue completes
successfully
▪ A device has come online
▪ A transaction is completed successfully
Warning
▪ A server’s memory utilization reaches
within 5% of its highest acceptable
performance level
▪ The completion time of a transaction is
10% longer than normal
Exception
▪ A user attempts to log on to an
application with the incorrect password
▪ A PC scan reveals the installation of
unauthorized software
Incident Management
PURPOSE of Practice
Minimize the negative impact of incidents
by restoring normal service operation as
quickly as possible.
Incident
An unplanned interruption to a service or
reduction in the quality of a service.
Incident Management has enormous Impact on ….
• Customer and User Satisfaction
• Perception of Service Provider
Incident Management
Elements in Incident Management
Logging
Prioritization
Information
Management
Resourcing
Resolution
Incident Management
Elements in Incident Management
All incident tickets must logged and managed
Categorization helps to route to right support
groups
Realistic target resolution times should be
• Agreed
• Documented
• Communicated
Logging
Logging of an incident may be done through an
appropriate specialized tool with links to CIs,
incident histories, changes, problems, known errors
and other useful knowledge Repositories
Incident Management
Elements in Incident Management
Priority = Urgency X Impact
Prioritization
• Based on agreed classification with the customer
• Impact and Urgency
Incident Management
Elements in Incident Management
• Resource managed according to type of incidents
• Separate processes may be required for managing
major incident and information security incidents
• Support agreements required with suppliers
• Frequent interaction necessary
Resourcing
Major Incidents will require the service provider and
the customer to agree to the definition,
classification and the conditions that qualifies for
exceptional handling.
Incident Management
Elements in Incident Management
• Information recorded with timely updates
• Integrated Service Management tool
advantageous
• Automated matching of incidents
• Reporting facility with intelligent analysis
Information
Management
Timely updates may include:
• Symptoms
• Business Impact
• CIs affected
• Actions planned
• Actions completed
Incident Management
Elements in Incident Management
Resolution
Incidents may be diagnosed and resolved by people
in many different groups, depending on the
complexity of the issue or the incident type.
• Resolved by the users themselves, using self-help
• Resolved by the service desk
• Escalated to a support team for resolution
(typically based on category of incident)
• Escalated to suppliers or partners
• Major Incidents (and other complex incidents)
require a temporary team to collaborate towards
a resolution
• Disaster recovery plans invoked to resolve an
incident
Complicated incidents often requires knowledge and
expertise, rather than procedural steps.
Problem Management
PURPOSE of Practice
Reduce the likelihood and impact of
incidents by identifying actual and
potential causes of incidents, and
managing workarounds and known
errors.
Problem
A cause, or potential cause, of one or
more incidents
Known Error
A problem that has been analyzed but has
not been resolved
Every service has errors, flaws, or vulnerabilities that may cause incidents
Some errors in development may be unresolved or undiscovered when going
“live”
Problem Management
Problem vs Incident
Incident
• Impact to Business Process / User
• Must be resolved for normal operation
Problem
• Causes of Incidents
• Require investigation and analysis for
long term resolution
• Workarounds
• Reduce future impact to business
17
Problem Management
Phases of Problem Management
Problem
Identification
Problem
Control
Error Control
18
Problem Management
Problem Identification
Identify and Log Problems
• Trend analysis of incident records
• Detection of duplicate and recurring issues
• Major incident management, identifying a risk that an incident
could recur
• Analyzing information received from suppliers and partners
• Analyzing information received from internal software
developers, test teams, and project teams
19
Problem Management
Problem Control
Problems
prioritized based
on RISK posed
Problem Control
requires holistic
investigation of
all 4 dimensions
of Service
Management
Incidents may
have many
inter-related
causes!
Workaround
• A solution that reduces or eliminates the impact
of an incident or problem for which a full
resolution is not yet available.
• Some workarounds reduce the likelihood of
incidents.
Workarounds can be done at any stage of Problem
Management
• May be documented early in Problem Control
• Improved when analysis is completed
• May be a viable cost-effective solution long-term
• May be automated
20
Problem Management
Error Control
Fixing the Error
• Includes identification of potential permanent solutions which
may result in a cost-justifiable change request for
implementation of a solution
Re-assess Known Errors
• Effectiveness and improvement of the workaround
• Impact of issues on the customers and users
21
PRACTICES TO MANAGE CHANGES
Service Request Management
Change Control
Service Request Management
PURPOSE of Practice
Service Request
Support the agreed quality of a
service by handling all pre-defined,
user-initiated service requests in an
effective and user-friendly manner.
A request from a user or a user’s authorized
representative that initiates a service action
which has been agreed as a normal part of
service delivery.
Pre-defined pre-agreed as part of normal
service delivery
Formalized with clear standard procedure for
• Initiation
• Approval
• Fulfilment
• Management
Service Request Management
Request for
delivery action
Feedback,
compliments or
complaints
• Information on lack of
professionalism
• Delighted with
rendered service
• Access to an IT
service
Request for access
to resource or
service
• Report generation
• Replacing printer
cartridges
Request for
information
Service
Requests
• How to print
• Information on
planned downtime
Request for
provision of
resource or service
• New laptop
• Increase fileshare
size
Service Request Management
Guidelines
Standardized and automated to the greatest degree
possible
Policies should be established regarding what service
requests will be fulfilled with limited or even no
additional approvals for streamlined fulfilment
Expectations of users regarding fulfilment times should
be clearly set
Opportunities for improvement should be identified
and implemented to produce faster fulfilment times
and take advantage of automation
Policies and workflows for documenting and redirecting
of any requests that are submitted as service requests,
but should actually be managed as incidents or changes
Change Control
PURPOSE of Practice
Maximize the number of successful IT
changes by ensuring that risks have been
properly assessed, authorizing changes to
proceed, and managing the change
schedule.
Change
The addition, modification, or removal of
anything that could have a direct or
indirect effect on services.
Organizations have to define the scope of
Change Enablement
CHANGE CONTROL IS NOT
ORGANIZATIONAL CHANGE
MANAGEMENT
Change Control
Balance in Change Control
Benefits
Changes should be assessed
(without unnecessary delay) by
people who understand the risks
and the expected benefits.
Authorized before deployment.
Cost/
Resources
VALUE
In high-velocity organizations, change approval
may be decentralized, making the peer review
a top predictor of high performance.
Change Authority
The person or
group who
authorizes a
change is known as
a change authority.
The correct change
authority should be
assigned to each
type of change to
ensure that change
is both efficient
and effective.
Change Control
Standard
Change
Change
Schedule
Type of
Changes
Emergency
Change
Normal
Change
Change Management
Types of Change Example
Type of change
Basic type
Example
Procedure
New development
Normal
Project or major
piece of work
Service Portfolio
Lifecycle Stage
SS
SD
Business Planning Board
✓
✓
Normal
New Service Item
Service Pipeline
update
Service Change
Management
✓
Service Change
Normal
Service targets or
reporting
Service Change
Management
✓
Service Extension
Normal
Extension of
service hours
Service Change
Management
✓
Emergency
Service Extension
Emergency
Service extension <
1 day’s notice
Service Change
Management
✓
Project change
Normal
Project Scope or
product definition
Project Change
Management
Access Request
Standard
User access to std
application
New User or New Access
procedures
Tuning
Standard
Print queue or job
priority
Operations Procedure
1.3.17
✓
✓
ST
SO
CSI
✓
✓
✓
✓
✓
✓
✓
✓
Change Control
Types of Changes
•
•
•
•
•
Low-risk
Pre-authorized
Well understood
Fully documented
Can be implemented without
needing additional authorization
Standard
Change
Full risk assessment and
authorization done when the
procedure for a standard
change is created or modified
30
Change Control
Types of Changes
• Must be implemented as soon as
possible
• Expedited assessment and
authorization
• Documentation may be deferred
• Testing may be reduced before
implementation
Emergency
Change
May have a separate change
authority for emergency
changes
31
Change Control
Types of Changes
• Scheduled, assessed, and
authorized following a standard
process
• Different change models for
different type of changes (with
varying levels of Change Authority
required)
• Initiated normally by Change
Requests
Normal
Change
Change Requests can be
manual or automated (in
Continuous Integration /
Delivery DevOps Models)
32
Change Control
Change Schedule
•
•
•
•
•
Plan changes
Assist in communication
Avoid conflicts
Assign resources
Provide information
needed for incident
management, problem
management and
improvement planning
33