In this post you will learn:
IT service management (ITSM) is the full set of activities that make up IT’s delivery of services to end-users. It involves managing everything involved, from design to support, to deliver quality user experiences and meet business goals. ITSM draws from Technology Infrastructure Library (ITIL) practices that center 4 Ps: people, products, process, and partners.
A modern enterprise has a diverse set of end-users with varying technology needs. Its systems include internal-facing technology for knowledge workers and citizen developers, and external-facing platforms for customers and software engineers. ITSM encompasses delivering to these audiences all the tools and technology services they need.
For example, when internal provisioning is handled using an ITSM framework, employees receive hardware in a streamlined way, with minimal touchpoints. Maybe they receive a user-friendly catalog of device packages to choose from. Once they make a selection, many moving parts work together behind the scenes to deliver the requested items seamlessly.
Similarly, IT provides infrastructure and operating services for customer-facing applications and experiences being built by software engineers. Many of these teams follow Agile or DevOps methodologies. While ITSM has roots in the traditional format of ITIL, it can be applied to modern practices as well.
Conventionally, delivering services through ITSM by following the ITIL framework often looked like building technology first, then creating processes for it, then asking users to learn how to use it. With more modern Agile and DevOps frameworks, ITSM now depends on the team and its choice of framework. DevOps teams work in an iterative way, not a strictly linear one. Their collaborative, automated approach demands speedier timelines than ITIL delivers. Still, applying ITSM concepts that came from ITIL can bring helpful structure to DevOps. ITSM can incorporate the best of both frameworks, applying practices as needed for various scenarios. IT operations teams that support knowledge workers and those that support development teams share common tools, skill sets, and goals, meaning ITSM is a resource they can both use.
The process for delivering service isn’t set. Rather, several key traits define cycles of work that happen under ITSM.
Designating a single point of contact is a critical part of ITSM. Everybody on the team needs to know who will mediate communications during the services engagement. Often, a technical support engineer will take this role. This person stays in active contact with the party that requests service and the people who do the work, driving the entire task.
A key distinguishing characteristic of ITSM is the concept of IT as a service, not just as a means of distributing tools or technology. The main difference is that service includes the end-to-end user experience that extends beyond a physical device and its applications. Therefore, ITSM covers a whole spectrum of IT services: the process of requesting service, the way technology integrates, and continuous improvement of the entire ecosystem. IT is now evolving to become a source of innovation in the enterprise, so IT teams must go a step further and think about the services they provide as internal product offerings for the organization. This is a major shift; historically, IT would exclusively take on project work that lines of business required to be completed.
The cycle begins with change. System changes can introduce unknowns that lead to incidents — unplanned events that require engineering action to correct. After an incident, the incident management process identifies how to mitigate the incident and applies a bandage solution to restore service.
Data from incident reports and continuous monitoring practices go to the problem management team, which takes a holistic view of system health and identifies risks and opportunities to improve. Investigating patterns of incidents can reveal causes—underlying problems that need to be addressed.
Often, solving a problem or making an improvement requires system changes, which means engaging the change management process. However, any change can begin a new cycle.
ITSM has historically been governed by the ITIL framework, which originally recommended a set of highly structured processes for ITSM, but has evolved over time. Now, it recommends more flexible practices. With the ITIL approach to ITSM, multiple practices come into play when managing services.
DevOps practices, such as continuous monitoring and continuous delivery, allow teams to iterate more quickly than the traditional change, incident, and problem management practices of ITIL. This works well for the regular iterative work of building and maintaining software. However, organizations often find they need some of the structure of ITIL for larger-scale innovation and issues. DevOps does not really provide a more detailed framework for managing operations, meaning DevOps teams may benefit from borrowing some ITIL concepts for service management.
Modern ITSM is usually a hybrid undertaking that incorporates both ITIL and DevOps concepts.
There are several key ITIL processes that lend helpful structure to service management.
Using a ticketing system is a great way of managing requests. Communicating information in tickets feeds into the practice of knowledge management. However, the downside of traditional ticketing is that the approach to resolving tickets is often highly structured and hierarchical. Modern teams can adopt more of a collaborative approach to ticket resolution.
The flow of information within an organization can easily become unwieldy to manage. New knowledge often comes to a team through tickets. Capturing this knowledge for accurate retention and reuse is an important part of ITSM. Centralizing knowledge is a way to expand the benefits of a single point of contact from the customer to the whole team. The person in that role might be in charge of integrating new knowledge within the main ticketing system as part of an easily accessible knowledge base.
The equipment within an organization has its own life cycle that requires management. The matrix of physical and virtual IT assets must be managed and overseen.
When something occurs unexpectedly, an incident management process helps the team restore service quickly.
Problem management looks at system health holistically and seeks out long-term fixes to the deeper problems that cause incidents.
Any change to production systems has the potential to cause disruptions for end-users. A mindful cadence and collaborative process are needed for change management to ensure teams make system changes with minimal disruption to service. Teams need to balance structure in their change management process with freedom for developers to innovate and move quickly.
The following DevOps methods and practices support smooth service cycles.
Agile methodology is the key to shorter, more efficient cycles. This approach uses collaborative, iterative sprints to make incremental releases that can respond effectively to an ever-changing technology landscape.
Through continuous delivery practices, teams maintain code within a perpetually deployable state by automating the process of building, testing, and updating.
DevOps culture is centered on communication and collaboration. These practices work to integrate teams cross-functionally and prevent silos of work. Communicating well and working closely together empowers teams with more knowledge, flexibility, efficiency, and accountability for their work than they’d have if it were siloed.
This practice moves configuration from physical hardware and user interfaces to the code repository, bringing automation and version control to infrastructure management. By practicing Infrastructure as Code, teams can produce faster, more consistent configurations than ever before.
Teams practicing this framework may designate members to some of these common roles.
People drive ITSM, but the right tools make all the difference.
Service desks simplify service requests. A ticketing system can integrate both internal and external tickets to prevent the streams of work from being siloed. Physical kiosks or devices are sometimes used to give customers easy access to ticketing systems.
Version control tools allow teams to accurately track their work. Through numbered service tickets, the system can track relationships between linked incidents, problems, issues, and version numbers. Git is a system for version-controlling code only, but it can be used in conjunction with incident reports to derive more insightful pattern recognition.
Key performance indicators (KPIs) have traditionally been used to measure the level of service IT support provides. They often focus on responsiveness and satisfaction, but sometimes they’re tailored a bit to meet the needs of a specific workflow. While measuring service takes nuance, it’s standard to measure some of these favorites:
Transposit’s fully integrated, data-driven approach brings process, data, and people together, empowering teams to maintain both agility and governance.