In a recent discussion a senior consultant stated that “Incident Management is the most important ITIL process”. That is one of those statements that make you wonder about the level of understanding of what ITIL is all about. You might get away with the statement that Incident Management is one of the most visible processes out of ITIL, but it is certainly not the most important.
To start with, Incident Management is not a stand-alone process. Calling Incident Management the most important is like calling the engine the most important part of the car. Just leave out the brakes or the steering and you’ll find an engine alone is almost worthless. Incident Management is one of the processes in ITIL and without using the other processes there is not much value in Incident Management alone.
It is also one of the processes that kind of work even without any ITIL certification or consultant needed. When an IT Service is no longer working, it is clear that something needs to be done. Most IT staff I know are very willing to take on a good IT failure, the more problematic the better. As true firefighters or IT Heroes they take an incident heads on and often will no stop until it is solved. They might not do it the smartest way and it might not be the most efficient way: and the issue almost always gets kind of solved (for a while). Most often incidents that are not getting solved are not interesting enough from the IT staff viewpoint. And the business is not giving the incident enough attention (screams) to get it on the radar. Incident Management is done, but maybe not in a very mature and professional way.
Instead on focusing on the Incident Management process itself, it makes more sense to focus on processes that would help to either learn from how incidents are being solved (ic Problem Management) or help to prevent incidents from happening (like Availability Management). In many organizations these processes are either not existent or very rudimentary. Spending time and energy on improving these processes will help to improve the Incident Management process over time. Without an accurate incident management log it is hard for problem management to organize learning. And Availability Management will help to organize the best responses to incidents before these will happen, by organizing escalation paths within the IT department and with external providers and partners.
Incident Management process is part of a larger framework, it tends to organize itself and it will be improved by focusing on more complex processes like problem management. So why would a senior consultant state that Incident Management is the most important process? In this case the discussion is part of the procurement of IT services and the consultant wants to make sure that the provider understands that there is little room for service outages. That might explain the sentiment but it doesn’t really make that much more sense. If you are buying anything and you are focusing almost exclusive on the process to deal with failure, are you buying the right service? If you would buy a car and are mainly concerned with the process to deal with defects: how bad is that car? You might want to reconsider the purchase or choose to refocus on discussing on how the service would bring value and contribute to your business goals. Any provider that takes its customer serious will have an effective form of incident management in place. Service outages are just as problematic for most service providers as it is for their customer. Often the main concern is not the Incident Management process itself but the communication to and involvement of the business in the process. I would myself put more emphasis on Business Relationship Management than focus on the Incident Management process.
I cannot think of any reason why Incident Management can be considered the most important process in the ITIL suite. I think a statement like that misses the whole point of ITIL and Service Management. I think that focusing on Incident Management is not helpful in any way to get buy in for the use of ITIL or any other related framework. It is time to stop spending to much time on Incident Management and focus on those aspects that will really bring value to the business.
When you’re getting an enterprise to function in a more lean and efficient way, there are several frameworks that you can use to get there.
From Pocket http://ift.tt/2wg49HC
Most of the mid-size and large companies I work with have financial planning.
From Pocket http://ift.tt/2qEN5Gi
In Part 1 of this blog I offered five tips for getting started with ITIL, the IT service management (ITSM) best practice framework: establishing a formalized service desk, identifying root causes (problem management), managing changes, tracking software licenses, and starting to use a configuration
From Pocket http://ift.tt/2px9CXb
ITIL – the popular IT service management (ITSM) best practice framework – can be tough for people to wrap their heads around. So, to help organizations get a grip on ITIL 2011, I’ve put together a few tips to help ITSM leaders and practitioners get started.
From Pocket http://ift.tt/2pByI50
ITIL or the IT Infrastructure Library is not a term that we’re commonly familiar with. In fact, we’ve rarely heard about it. Well that was all about to change.
From Pocket http://ift.tt/2o57oOw
Many ITIL® training alums may wonder, “Now that I’ve learned these best practices, how do I actually implement them in my workplace?” An effective ITIL strategy is the product of a concerted focus on people, process and technology, as well as an ongoing, cost effective and valuable IT servic
From Pocket http://ift.tt/2iYt2zc
This blog shares some insights on how to best overcome some of the challenges in adopting ITIL – the IT service management (ITSM) best practice framework – and its processes.
From Pocket http://ift.tt/2m83hR0
In the time of the ITIL update to version 3 I was involved with updating the ITIL training materials at Getronics PinkRoccade (former PinkElephant). One of the discussions we had was about the underlying principles of ITIL. These principles were not made very explicit in the books; their existence were mostly only mentioned in the introductions. I did a search through all the books and distilled some more implicit principles into a slide that we started using in the introduction in all the different ITIL courses at that time.
Recently, with all the discussions about the differences and similarities between ITIL, DevOps, SIAM, etc., I was wondering if these principles were still relevant. In his guest blog on the ITSM Review. ‘Why is this content at the end of the conference? This should be a Keynote topic!’ – CEO” Paul Wilkinson refers to his guiding principles on Service Management:
These principles refer directly to Attitude and Behavior of the IT workers delivering services and value to the business. The principles we found so many years ago refer to the organization of IT delivering the services as well and I feel they complement Paul’s principles as well as adding another perspective.
- Agency principle
Service providers are made accountable to deliver services (value and business outcome) and are enabled to take responsibility for the costs and risks. A contract can be made to specify the value (price) against the costs and risks within the boundaries of laws and regulations.
Often IT departments are not enabled to truly take the responsibility for the services they provide. They have no authority over their budget and their spending, they can not negotiate contracts with suppliers and they have no possibilities to hire the staff they need. The first step therefore to make IT departments (managers/directors) accountable is to enable them to take responsibility.
- Balance Principle
It is a common thread in IT service delivery that IT engineers tend to look at the product and the business look at its use. “How does it work?” against “What can you do with it?”. Sometimes the IT view tends to be too strong and the focus is on technology for technology’s sake. On other occasions the business view tend to ask for impossible and impractical technical solutions. In order to deliver the optimal services there should be a balance between the Internal IT view versus the external Business View
- Service Measurement principle
There is a strong emphasis on metrics and performance indicators in service management. There is a need to show to the business that IT services deliver value as promised by the IT organization. This need leads to a continual monitoring and measuring of service delivery and the underlying processes. To make use of these data a service management system should be in place.
- System Principle
There are many definitions for a system (unfortunately) and in this case a system is an holistic and integrated function to deliver services. A system contains people, processes (activities), tools and instruments, relations, contracts and other concepts (4P’s) to perform (5th P) and deliver value to the business.
- IT Service Lifecycle Principle
Service delivery is a continuous process of design, implement, operate and improve. Continual Service Improvement is not a separate process or activity but a core element of managing the service provider as a whole. This enables an iterative and incremental approach to service improvements in line with DevOps and Agile IT.
- Knowledge Management Principle
This is in practice on of the most fundamental and difficult principles of service management: to make sure that the right information and knowledge is provided to the right people on the right time. This asks for an organization that keeps on sharing and learning, It asks for feedback from the users and the business. For people that listen with empathy, reflection and patience. For systems that enable to share information as well as keep the amount of information manageable.
Essex County Council has undergone an IT transformation to improve the credibility of its IT and achieve ISO 27001 accreditation.
Source: Case study: How ITIL has helped Essex keep IT aligned with council goals