I present the translation of the article “The Past and Future of IT Service Management” (“The Past and Future of IT Service Management” by Stuart Rance), published in the ITSM.Tools blog.
The article is of an overview nature and can be interesting, both at the initial stage of immersion in ITSM due to the fact that it provides the direction of movement, and to the more experienced participants of the ITSM processes, making it possible to compare their own feelings with the opinion of a fairly authoritative specialist and speaker of ITSM events in the world.
Warning: the article is clearly selling and, in the modest opinion of the translator, contains overly enthusiastic assessments that you may not meet in the real world and have a detrimental effect on immature minds.
(Hereinafter, the translator’s notes are in italics.)')
I have been involved in IT service management (ITSM) since the 1970s and have witnessed many changes since then. This is a brief collection of my thoughts and observations, what ITSM was and what I think will be in the future.
Extremely technical focus in the 1970s
My work in IT began in the late 70s. I was engaged in support, restoring equipment, and for a long time developed in the direction of solving incidents and problems of a wide range of hardware and software. Like the others who did similar jobs in IT, I went to many training courses, where I studied various hardware and software products and how to restore them, but among them there were no programs on processes, services or work with customers. If someone asked me what I was doing “in life”, I answered something like: “I repair computers” or “I solve problems with computers”. At that time, I never even heard of ITSM and, of course, did not think that I was doing such things as Incident Management or Problem Management (Roblem Management).
ITIL in the 1990s
In the mid-1990s, I stumbled upon ITIL (a leading set of best practices for implementing ITSM), and this was a revelation to me. It was like finding a family I never knew. I discovered ideas for my business, such as availability management, service continuity management, change management and problem management. Now I had a set of templates that I could use to add more consistency and rigor to my work. I also now had slang that facilitated communication with colleagues and customers. I went to the ITIL Foundation and ITIL Service Manager courses, and eventually became an ITIL instructor, passing on these great ideas to other people to help them achieve their career goals.
At that time, ITIL was most focused on processes, and provided a set of ideas for creating them. In companies that started to use ITIL, IT support teams stopped living from the incident to the incident, from crashing to crashing, determining the importance of the problem by the volume of the person who called. Instead, they directed their energy towards negotiating the level of service with their customers. As a result, they were now confident that the levels that they agreed on using ITIL ideas help them create repeatable processes, and this, in turn, allowed them to be confident that the agreed service is provided systematically.
ITIL 2007 edition
In 2007, a new release of ITIL. The biggest change was the new structure, built around the life cycle of services. Now it’s easier to understand what the services are, and the focus has become on their importance to users. The greatest emphasis was placed on the Strategy (Service Strategy, SS) and Service Development (Service Design), and a whole book on Continuous Service Improvement (CSI) appeared. It also began to imply that compliance with the SLA may not be the most important thing that IT does in an organization. It was so common for us to deliver SLA while our customers were sad, disappointed or frantic. The focus on services was what we actually needed. We had to understand our customers with users and provide them with real value from our services.
So I changed my approach to work.
I continued to try to achieve agreed targets, but when circumstances force, I realized that I can ignore the targets and focus on what the customer really wants. An important thing was customer satisfaction and experience with the customer. But, of course, it is only worthwhile to behave when it is appropriate, and this requires from the IT organization, first of all, mature processes, as well as an experienced staff who confidently works without hard dependencies on the routine and repeatability of processes.
Many consider the transformation from a focus on processes to a focus on services extremely difficult. In ITSM, people remain confident of the need to adhere to SLA, even when it hurts their customers. I often communicated with such people one-on-one and on social networks, trying to convince them to move away from a very old-fashioned process-oriented approach. Sometimes I succeeded, but often they continued to work without changes, causing problems for their customers in any industry.
What's next?
In the meantime, ITSM is moving forward again. The world of software development has introduced Agile and DevOps ideas. Many members of the ITSM community also recognize that they also need further development in order to provide more value to their customers. Here are some of the things that I think will affect the future of ITSM. There is not enough space for me to present all the ideas in detail, but I hope that what has been said will be enough to warm up your interest and give you more time to study yourself.
AgileThe Agile Software Development Manifesto was published in 2001. It emphasized the importance of:
- personalities and their relationships are more important than processes and tools
- working software product is more important than completeness of documentation on it
- cooperation with the customer is more important than contractual obligations
- reaction to changes is more important than following plans
The result of this is a much more flexible and fast approach, which provides tremendous improvements in the quality of new software, as well as facilitates the ability to quickly respond to changing business needs.
Some Agile ideas are now being applied in ITSM. They changed the concept of a better approach to deploying and improving ITSM (there are no longer multi-year ITSM projects) and better ways to support customers (people and their relationships are more important than processes and tools).
LeanLean is a management approach that emphasizes the importance of creating maximum value for the customer at the lowest possible cost. If you want to learn more about this, you can find articles on the Internet about Lean production, Lean product development and Lean software development.
In the context of ITSM, the most important aspects of Lean are:
- determination of the end-to-end value chain, of which you are a part
- guarantee that all your actions create value for the Customer
- elimination of empty costs in any actions, reducing the stages of the processes to the maximum simplicity necessary to create value.
AutomationAutomation has always been a part of IT management. Even when I started (in the late 1970s), we automated tasks wherever we could. What has changed has changed? Tools that provide automation and ease of use have become more accessible. Now you can automate almost anything if you decide to do it.
There are only a few things that cannot be automated, because they require human expertise as part of the process. We can automate everything else that we are capable of doing, as long as:
- we really understand what and how we do
- simple enough actions that can be easily documented.
- what often happens and automation can improve and improve it.
- automation will not be able to replace human assessment by flexible rules
DevopsDevOps exploits ideas from Agile, Lean, and automation to improve the passage of software from design to customers. DevOps emphasizes
three areas :
- Flow / Path - understanding how you adapt to the end-to-end value chain, excluding bottlenecks that limit development
- Feedback - providing quick feedback to assist in identifying and eliminating insufficient quality as quickly as possible and at minimal cost.
- Experiments and training - making assumptions and predictions, testing them, studying and improving.
The combination of these three areas with the intensive cooperation of related teams and the extremely high level of automation results in the most rapid deployment / introduction of new and modified software with high flexibility and user satisfaction.
DevOps typically automates many of the tasks that software developers perform, but it does not include the operational aspects of development.
ITSM should use this. We must foster the development of new ideas and help ensure that a significant increase in the automation of routine operations does not hurt a person's assessment through the whole process.
Corporate Service Management (Enterprise Service Management)The many ideas, tools, and processes that are used in the development and support of ITSM are also useful in supporting non-IT services. Corporate Service Management uses the same approaches for the entire organization, including capacity management, personnel management, lawyers, and any other departments that provide services.
We all need to manage incidents and problems, fulfill service requests and interact with customers. Using the same tools and processes for you, we can provide corporate-wide services.
Effective corporate-wide Service Management is not only the use of ITSM tools by other departments, but also the involvement of end-to-end cooperation and training for the entire organization. Often, the IT department can learn a lot in service delivery.
ITIL PractitionerThe latest ITIL replenishment is the ITIL Practices Guide (ITIL Practitioner Guidance), published in January 2016. This publication supports many of the ideas described in this blog.
The ITIL Practitioner sets out nine guidelines:
- Focus on value
- Work for people (Design for experience)
- Repelling how it is now (Start where you are)
- Work systematically (Work holistically)
- Progress iteratively
- Observe at the place of use (Observe directly)
- Be transparent
- Collaborate
- Keep it simple
Three root competencies are also discussed:
- Metrics and measurement process
- Communications
- Change Management Organization
And all this is described in the context of Continuous Improvement of IT Services. If you want to learn more about the ITIL Practitioner, I recommend reading
the ITIL Practitioner Guide and go to the training course. You can also read the
ITIL Practitioner review from my good friend
Stephen Mann .
In custody
ITSM has helped IT organizations transform from a technology provider to a value service provider. And we can not stop, if we solve the problems of the 21st century by the methods of the 1990s, we will quickly become inadequate.
Everyone who provides or supports IT services needs to use new approaches and the adoption of new ideas, because they add value to the customer.
Some of the concepts that you might think about accepting are described in this blog, but there are still many others that will also be useful.
I like very much:
- Kanban is a development / production management method based on the “just in time” principle,
- Cobit 5 - a collection of IT Leadership Practices / Recommendations for Business Value Creation,
- Resilia - a collection of practices and certification system for information security management specialists from AXELOS
You can learn more from current discussions of these topics on social networks:
Well, and attend events organized by:
From myself I will add a couple of links to Russian-language resources on the topic of ITSM:
That's all. Hope reading was helpful.
Thank you for your attention, leave your ratings in the comments.