The world’s Largest Sharp Brain Virtual Experts Marketplace Just a click Away
Levels Tought:
Elementary,Middle School,High School,College,University,PHD
| Teaching Since: | Apr 2017 |
| Last Sign in: | 103 Weeks Ago, 2 Days Ago |
| Questions Answered: | 4870 |
| Tutorials Posted: | 4863 |
MBA IT, Mater in Science and Technology
Devry
Jul-1996 - Jul-2000
Professor
Devry University
Mar-2010 - Oct-2016
Read the following article on Using the ITIL Framework Effectively. If you are unfamiliar with ITIL or in need of a refresher, you can also read ITIL: The Basics. Pick one of the ten key rules and describe a situation you have been directly involved in or observed that could have been resolved using that key rule. Explain why this rule is important and what happens if it is ignored. In addition, if there was a placeholder for an eleventh key rule that you could author, what would the rule state? Justify your new rule with at least one example.
ITIL®: the basics
Valerie Arraj, Compliance Process Partners LLC White Paper
July 2013 © The APM Group and The Stationery Office 2013 2 ITIL® : the basics Contents
1 What is ITIL and what are its origins? 3 2 The service lifecycle 3 3 Why would an organization be interested in ITIL? 4 4 Which companies use ITIL? 4 Further reading 5 About the author 5 Acknowledgements 5
Trade marks and statements © The APM Group and The Stationery Office 2013 5 ITIL® : the basics As the most widely adopted framework for IT service
management in the world, it is hard to believe that ITIL® is more
than 20 years old. Its practical, no-nonsense approach to the
identification, planning, delivery and support of IT services to
businesses has revolutionized IT service management, and
thousands of practitioners now implement ITIL best practice in
their working environments. The latest editions of ITIL from the
Cabinet Office were published in July 2011, and these five
publications (ITIL Service Strategy, ITIL Service Design, ITIL
Service Transition, ITIL Service Operation and ITIL Continual
Service Improvement) form the core guidance of best
management practice.
In the early 1980s, the evolution of computing technology
moved from mainframe-centric infrastructure and centralized IT
organizations to distributed computing and geographically
dispersed resources. While the ability to distribute technology
afforded organizations more flexibility, the side-effect was
inconsistent application of processes for technology delivery and
support. The UK government recognized that utilizing consistent
practices for all aspects of an IT service lifecycle could assist in
driving organizational effectiveness and efficiency, as well as
achieving predictable service levels. It was this recognition that
gave rise to ITIL, which has become a successful mechanism to
drive consistency, efficiency and excellence into the business of
managing IT services.
Since ITIL is an approach to IT ‘service’ management, the
concept of a service must be discussed. A service is something
that provides value to customers. Services that customers can
directly utilize or consume are known as business services. An
example of a business service that has common applicability
across many industries would be Payroll. Payroll is an IT service
that is used to consolidate information, calculate compensation
and generate pay cheques on a regular basis, and which relies
on other business services such as ‘time tracking’ or ‘benefits
administration’ to provide the extra information necessary for
its calculations.
In order for Payroll to run, it is supported by a number of
technology or ‘infrastructure’ services. An infrastructure service
does its work in the background, so that the business does not
directly interact with it, but nevertheless this service is necessary
as part of the overall value chain to the business service. ‘Server
administration’, ‘database administration’ and ‘storage
administration’ are all examples of infrastructure services
required for the successful delivery of the Payroll business
service (see Figure 1).
IT organizations have traditionally focused on managing the
infrastructure services and technology silos. ITIL suggests a
more holistic approach to managing services from end to end.
Managing the entire business service along with its underlying
components in a cohesive manner ensures that every aspect of a service is considered (and not just the individual technology
silos) so that the required functionality (or utility) and service
levels (or warranty) are delivered to the business customer. With
respect to Payroll, this means accurate pay cheques for all
employees, and service levels delivered within a certain
timeframe, properly secured, and available when necessary.
ITIL can be adapted and used in conjunction with other good
practices such as:
■■ COBIT (a framework for IT Governance and Controls)
■■ Six Sigma ( a quality methodology)
■■ TOGAF (a framework for IT architecture)
■ ISO 27000 (a standard for IT security)
■■ ISO/IEC 20000 (a standard for IT service management). 2 The service lifecycle
ITIL is organized around a service lifecycle which includes service
strategy, service design, service transition, service operation and
continual service improvement.
The lifecycle starts with service strategy – understanding who
the IT customers are, the service offerings that are required to
meet the customers’ needs, the IT capabilities and resources
that are required to develop these offerings, and the requirements
for executing them successfully. Driven by strategy throughout
the course of delivery and support for the service, the IT service
provider must always try to ensure that the cost of delivery is
consistent with the value delivered to the customer.
Service design ensures that new and changed services are
designed effectively to meet customer expectations. The
technology and architecture required to meet customer needs
cost-effectively are an integral part of service design, as are the
processes required to manage the services. Service management
systems and tools to adequately monitor and support new or Time tracking End-to-end service 1 What is ITIL and what are
its origins? 3 Payroll Core business service Supporting
business service
Can stand on its own
as a core service Benefits Kronos VMServer1 VMServer3 Server administration
(infrastructure service) VMServer2 DB1 Supporting
business service
Can stand on its own
as a core service Database administration
(infrastructure service) VMServer4 Storage array X Storage administration
(infrastructure service) Figure 1 The end-to-end service
© The APM Group and The Stationery Office 2013 4 ITIL® : the basics modified services must be considered, as well as mechanisms
for measuring the service levels, the technology, and the
efficiency and effectiveness of processes.
Through the service transition phase of the lifecycle the
design is built, tested and moved into production to enable the
business customer to achieve the desired value. This phase
addresses managing changes: controlling the assets and
configuration items (the underlying components such as
hardware, software etc.) associated with the new and changed
systems; service validation; and testing and transition planning
to ensure that users, support personnel and the production
environment have been prepared for the release to production.
Once transitioned, service operation then delivers the service on
an ongoing basis, overseeing the daily overall health of the service.
This includes managing disruptions to service through rapid
restoration after incidents; determining the root cause of problems
and detecting trends associated with recurring issues; handling
daily routine end-user requests; and managing service access.
Enveloping the service lifecycle is continual service
improvement (CSI). CSI offers a mechanism for the IT
organization to measure and improve the service levels, the
technology and the efficiency and effectiveness of processes
used in the overall management of services. 3 Why would an organization
be interested in ITIL? ■■ Negotiated achievable service levels Business and the
IT service provider become true partners when they can
agree upon realistic service levels that deliver the necessary
value at an acceptable cost.
■■ Predictable, consistent processes Customer expectations
can be set and are easier to meet through the use of
predictable processes that are consistently applied. In
addition, good-practice processes provide a solid foundation
on which to lay the groundwork necessary to meet
regulatory compliance requirements.
■■ Efficiency in service delivery Well-defined processes with
clearly documented accountability for each activity as
recommended through the use of a RACI matrix can
significantly increase efficiency. In conjunction with the
evaluation of efficiency metrics which indicate the time
required to perform each activity, service delivery tasks can
be optimized.
■■ Measurable, improvable services and processes The
adage that you can’t manage what you cannot measure
rings true here. Consistent, repeatable processes can be
measured and therefore can be better tuned for accurate
delivery and overall effectiveness. For example, a critical
success factor for incident management is to reduce the time
to restore service. When predictable, consistent processes are
used, key performance indicators such as mean time to
restore service can be captured to determine whether this
KPI is trending in a positive or negative direction.
Additionally, under ITIL guidelines, services are designed to
be measurable. With proper metrics and monitoring in place,
IT organizations can monitor service level agreements (SLAs)
and make improvements as necessary. Although today’s technologies allow us to provide robust
capabilities and afford significant flexibility, they are very
complex. The global reach available to companies via the
internet provides tremendous business opportunities while
presenting further challenges regarding the confidentiality,
integrity and availability of services and data. Additionally,
IT organizations need to be able to meet or exceed service
expectations while working as efficiently as possible. Consistent,
repeatable processes are the key to efficiency, effectiveness and
the ability to improve services. These consistent, repeatable
processes are outlined in the ITIL framework. 4 Which companies use ITIL? The benefits of ITIL ■■ Financial services organizations such as Citi, Bank of America,
Barclays Bank The main benefits of ITIL include:
■■ Alignment with business needs ITIL becomes an asset to the
business when an IT organization can proactively recommend
solutions as a response to one or more business needs. The
IT steering group recommended in ITIL Service Strategy and
the implementation of service portfolio management gives
the service provider the opportunity to understand the
business’s current and future needs and develop service
offerings that can address them. © The APM Group and The Stationery Office 2013 ■■ A common language Terms are defined in a common glossary. Literally, thousands of companies worldwide and industries of
all shapes and sizes have adopted ITIL. These include:
■■ Large technology companies such as Microsoft, HP, Fujitsu, IBM
■■ Retailers such as Target, Walmart and Staples ■■ Entertainment entities such as Sony, Disney
■■ Manufacturers such as Boeing, Toyota, Bombardier
■■ Life sciences companies such as Eli Lilly, Pfizer, Takeda
Pharmaceuticals.
Because ITIL is a ‘framework’, it is meant to be adapted to suit
the company’s industry, size, organizational structure and
requirements. It can be adopted broadly across the lifecycle or
within particular process areas to enable any IT organization to
be a true strategic asset to the business it supports. ITIL® : the basics Further reading
Cabinet Office (2011). ITIL Service Strategy. TSO, London.
Cabinet Office (2011). ITIL Service Design. TSO, London.
Cabinet Office (2011). ITIL Service Transition. TSO, London.
Cabinet Office (2011). ITIL Service Operation. TSO, London. © Copyright The APM Group and The Stationery Office. Reuse
of this White Paper is permitted solely in accordance with the
permission terms at http://www.best-managementpractice.com/Knowledge-Centre/White-Papers/
A copy of these terms can be provided on application to Best
Management Practice White Paper Permissions, TSO, St Crispins,
Duke St, Norwich, Norfolk, NR3 1PD, United Kingdom. Cabinet Office (2011). ITIL Continual Service Improvement.
TSO, London. First published May 2010; updated July 2013. See also the following websites: Trade marks and statements www.best-management-practice.com
www.itil-officialsite.com About the author
Valerie Arraj is cofounder and managing director of
Compliance Process Partners, an organization that specializes
in laying the groundwork for IT compliance and service
management excellence. Previously she was the ITSM global
practice director delivering and overseeing ITSM consulting
and training for a managed service provider. 5 ITIL® is a registered trade mark of the Cabinet Office.
The Swirl logo™ is a trade mark of the Cabinet Office.
Best Management Practice is the overarching brand that
umbrellas multiple Cabinet Office best practice products. The
internationally renowned portfolio is adopted as best practice
through high quality training, publications, software tools and
consultancy for portfolio, programme, project, risk, value and
service management disciplines. Acknowledgements
Sourced by APM Group Limited and published by TSO on
www.best-management-practice.com
Our White Paper series should not be taken as constituting
advice of any sort and no liability is accepted for any loss
resulting from use of or reliance on its content. While every
effort is made to ensure the accuracy and reliability of the
information, APM Group Limited and TSO cannot accept
responsibility for errors, omissions or inaccuracies. Content,
diagrams, logos and jackets are correct at time of going to press
but may be subject to change without notice. © The APM Group and The Stationery Office 2013
Journal Online
Debasis Bandyopadhyay,
CISA, CISM, CGEIT, PMP,
TOGAF9, ITIL v3 (F),
has more than 25 years
of industry experience
in the field of RADAR
(Radio Detection and
Ranging) technology;
satellite communication;
VSAT (very small aperture
terminal)-based network
design for voice, data and
video communication;
telecommunication switching
networks; electronic payment
systems; and IT service
management. He is the chief
information security officer
(CISO) at RS Software Ltd. in
India, and holds the COBIT®
Foundation Certificate. Do you have
something
to say about
this article?
Visit the Journal
pages of the ISACA
web site (www.isaca.
org/journal), find the
article, and choose
the Comments tab to
share your thoughts.
Go directly to the article: 10 Key Rules for Using the ITIL
Framework Effectively
IT Infrastructure Library (ITIL)1 is well
established as the framework of best practice
guidance for IT service management in the
industry. This article shares some of the practical
challenges in IT service management (ITSM)
and how the ITIL framework can be used to
overcome those challenges. The following 10 key
rules for using the ITIL framework effectively are
based on the real-life experience of IT engineers
and IT managers:
1. Do not ignore system-generated alerts—IT
service engineers and managers are generally
maintaining large and diverse IT systems with
hundreds of applications running in multiple
servers, databases and networking equipment.
They may find that many alerts are generated
every day and auto-generated emails are
sent by the monitoring system to concerned
groups. The rule of thumb is: Do not ignore
alerts. There are many cases in which alerts
are ignored, leading to major problems with
serious consequences, including massive
financial losses.
The question is how many alerts one needs
to address when one is getting hundreds of
alerts every day. Considering the potential
problems of unaddressed alerts, one should
carefully categorize and prioritize alerts that
can have the most impact, and address them
quickly. To do this, IT service engineers need
to understand the business impact and the
criticality of the applications they support. If
in doubt, they should escalate or inform the
application owner without losing any time.
This can prevent major catastrophes.
2. Understand the difference between a service
request and incident management—Service
requests (part of the request fulfillment
process of ITIL) are simple requests or
questions such as “Please unlock my domain
password” or “Where do I find the FTP
software for downloading?” These requests can be addressed immediately by help-desk
professionals or by the requesters, if they are
directed to a self-help site where most of the
common questions and the corresponding
solutions are provided.
On the other hand, incidents (part of the
incident management process of ITIL) are
unplanned interruptions to an IT service or
reduction in the quality of IT services. Incidents
are logged, tracked and analyzed until closed.
So, IT engineers should not unnecessarily treat
service requests as incidents, thereby increasing
the number of incidents that need more effort
to resolve and that can result in overhead,
such as incident aging calculation, incident
categorization, root-cause analysis (RCA),
resolution steps and closure.
3.Write in detail the incident resolution steps
and lessons learned—It is a common practice
that after diagnosing and solving an incident, IT
service engineers do not detail the steps followed
to solve the incident. There is space provided
in every incident management tool to elaborate
on the resolution steps in plain text. Frequently,
the IT service engineers write “fixed,” “problem
solved” or “closed” in that space. Unless the
IT service engineers elaborate on the methods
used and steps followed to resolve the incident,
it will be of no help for other service engineers
to reference in the future when encountering
the same or similar types of incidents. Detailing
the resolution steps enhances the knowledge
repository of the enterprise, improving the
effectiveness and efficiency of the knowledge
management process.
4. Understand the problem clearly before
jumping in to solve it—In many situations,
the IT service engineer does not understand
the problem clearly and tries to solve it
immediately. For example, Jenise picks up her
phone and tells the IT service engineer that
she is unable to log in to a server but needs to ISACA JOURNAL VOLUME 4, 2012 1 do so urgently. In this case, the IT service engineer should
not jump in to solve why Jenise is not able to log in to the
server. First, the IT service engineer should ask questions
such as “When was the last time that you logged in to this
server?” By asking this question, the IT service engineer
may discover that Jenise has never logged in to that server
and has no reason to log in. The deeper question is: Why
did Jenise suddenly require login to a server into which she
has never logged in to previously? Probably Jenise was part
of a group email ID and, as part of that communication, she
got an email (asking her to log in to the server) for which
she need not take any action. The email was probably
meant for other team members who really needed to log in
to find more details, and was not meant for Jenise.
5. Incident management—go parallel, not serial—Let us
assume that an incident has been reported, and based on
that, an incident ticket has been opened and assigned to a
service engineer. The service engineer’s job is to categorize
and prioritize the incident to figure out its severity. In a
high- or medium-severity incident, one needs to open a
teleconference bridge and ask all concerned parties—the
database administrator (DBA), middleware persons,
application owners, server and network administrator, and
even the supplier’s representative—to join. The idea is to
bring all the stakeholders onto one common platform and
find out what has gone wrong. The advantage of this mode
of parallel working is that no one can pass the responsibility
to another saying, for example: “It is not my problem; the
DBA needs to look into this.” The problem can be detected
and fixed or a work-around can be found in a short period of
time compared to a serial method of calling one individual at
a time. So the mantra is: “Go parallel, not serial.”
Another important point is that the incident ticket should
be closed by the person who has raised the incident and
not the person to whom it was assigned. Having the
service engineer to whom the ticket is assigned close it is
a common mistake. The service engineer can say that the
problem has been resolved, but not closed. The incident
owner, when he/she is satisfied with the solution, should
close the incident ticket.
6. K
eep a close watch on how the new or modified system is
working; the importance of post-implementation review
(PIR)—PIR is a very tricky aspect of service management.
When the IT service developer has developed a new
2 ISACA JOURNAL VOLUME 4, 2012 • Read Aligning COBIT 4.1, ITIL V3 and ISO/IEC 27002
for Business Benefit. www.isaca.org/cobitmappings
• Read COBIT Mapping: Mapping of ITIL V3 With
COBIT 4.1. www.isaca.org/cobitmappings
• Discuss and collaborate on ITIL in the
Knowledge Center. www.isaca.org/topic-itil
service or has modified the existing service and moved
it to production after proper testing, as per the test plan,
the first point to remember is to call all the stakeholders
(e.g., the DBA, middleware, application owner, server and
network maintenance folks) before moving a new code
to the production environment. A quick smoke test2 must
be conducted to verify that the main functionalities of the
service are working fine, and then the code can be moved
to production. IT service developers cannot take their
attention from a new or modified service even after successful
movement of the code to the production environment.
Problems can begin to surface in the production environment
even after three months. Therefore, it is important to set
up a PIR process and keep checking the service input and
output results, database and error logs. The results may show,
for example, that a field of a database table is not getting
populated due to a coding error—a problem that would
only surface in a report due every three months. Rather
than waiting three months for the problem to surface, the
IT service developer must keep checking the system and do
smoke tests periodically to check major functionalities and the
back-end results. It is important to include the PIR effort in
the project effort estimation process.
7. Automate the processes that are repetitive in nature—It is
always advisable to automate processes that are repetitive
in nature. This can be achieved by writing a small script
or even a full-fledged system. Automation brings higher
productivity and reduces manual errors. word of caution for processes automation: Simplify
A
the process and clarify the flow of activities before
automating them. One should not be in hurry to automate
tasks that are neither simple nor routine. 8. Understand the problem from the customer’s perspective
and provide solutions accordingly—It is important to
understand the problem from customers’ perspectives
and the context in which they are looking for solutions.
For example, an IT service engineer gets a call from a
customer who says that her printer is not working and she
has to print a document to circulate in a meeting that is
taking place in 15 minutes. The service engineer can judge
from the customer’s voice that she is extremely anxious. In
this situation, the service engineer should not try to fix the
printer, but rather give the customer an alternate solution,
such as printing to a different printer. Considering the
situation and the urgency, this might be a better solution
than asking the customer to take the time for routine
checks to fix the printer. 9. Put ‘known solutions’ in the intranet (S-help, FAQs)
to reduce the number of calls—The IT service manager
should analyze the service calls and determine the
most common problems reported by various users.
If the solutions are known, they can be placed in the
organization’s intranet in the form of self-help (S-help) or
frequently asked questions (FAQs). This will save a lot of
time and effort and will improve process efficiency.
10. Check before making any changes to ensure that no one
else has initiated those changes—IT service developers
have to deal with frequently changing management
requests. IT service developers may encounter a need
to change code, database or other parameters to
accomplish the desired outcome. This is part of the
change management process of ITIL. Before planning any
change, it is critical to make sure that the same changes
have not already been taken up by other groups within
the enterprise. This is a typical problem of large, global
organizations. It is important to avoid duplication of work
and improve service effectiveness and efficiency. CONCLUSION
These 10 key rules are based on the real-life experiences of
IT professionals who work in IT service management. These
rules can help the IT professional effectively use the ITIL
framework.
It was once a headline in all leading newspapers of
Singapore when an alert was ignored while conducting a
routine repair job and the oversight caused a major impact to
a chain of banks in Singapore.
As a result, the banking
Simple automation can operation was shut down for
improve productivity three hours. So what went
wrong? It might be that the key
significantly.
first rule was not followed: Do
not ignore system-generated
alerts. What actually went wrong is not publicly known, but
there are numerous examples like this of disasters that could
have been averted if simple key rules had been followed.
Additionally, simple automation can improve productivity
significantly. The automation of running shell scripts or other
routine jobs can avoid problems with manual errors. Manually
running a wrong shell script may bring down the wrong server
or even a complete data center at the wrong time.
Implementing ITIL practices in an organization with a
disciplined approach, which can be done more effectively with
the 10 key rules provided here, can help organizations reach
higher maturity levels. “ ” ENDNOTES
Information Technology Infrastructure Library (ITIL), Best
Practice Guidance, 2011, www.best-management-practice.
com/Knowledge-Centre/Best-Practice-Guidance/ITIL/
2
This term was probably coined from hardware testing in
which one ensures that no smoke comes out when the new
hardware system is plugged in to the power socket.
1 The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription
to the ISACA Journal.
Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance
Institute® and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.
© 2012 ISACA. All rights reserved.
Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in
writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St.,
Salem, MA 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date,
volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without
express permission of the association or the copyright owner is expressly prohibited.
www.isaca.org 3 ISACA JOURNAL VOLUME 4, 2012
-----------