Menu
“Swish.ai is like putting a Ferrari engine in your Volvo”, said one of our enthusiastic customers. How can Swish.ai have such an impact on your existing ITSM system? Let’s take a look under the hood…
What is the most dominant factor affecting the time it takes to process and resolve
an ITSM ticket? When I ask this question, the common answer I get is, “It depends on the nature of the ticket”. Indeed, the nature of the ticket is an important factor, but it’s not the single most important factor.
The single most dominant factor is ‘wait time’.
Most of a ticket’s lifecycle is spent waiting in a queue until someone becomes available to attend to it. And if the ticket is transferred between groups and assignees, then each transfer triggers another wait in the queue.
When I explain this, people can understand and relate to it because they can imagine themselves waiting in queues or simply stuck in heavy traffic, but it’s hard to get a grasp on ITSM ticket queues – because you don’t see them. They don’t pile up in anyone’s office. They are intangible and go unnoticed.
Similarly, what is the single most important factor affecting the time it would take you to commute into any metropolitan area? Everybody gets that one – traffic. A journey that may take a few minutes early Saturday morning may take hours during rush hour. Again, it’s the wait time, getting stuck in traffic jams and moving along slowly.
Like traffic congestion, ticket congestion is the single most dominant factor determining ITSM MTTR (Mean Time to Resolve). When tickets pile up, queues are created and the system slows down.
To speed up the system, you need to identify and relieve the congestion bottlenecks. This concept introduced by Eliyahu M. Goldratt in the mid 80s is known as the Theory of Constraints (TOC) and has revolutionized manufacturing and supply chain operations. Eventually, TOC influenced Software Engineering with the advent of DevOps as an approach to optimize against the most dominant constraints in the software delivery processes. However, TOC never reached ITSM.
Another management philosophy that revolutionized the world is The Toyota Production System (TPS), born in the 1930s and evolved as “Lean Manufacturing” in the late 1980’s. Lean too, had a revolutionary impact on Software Engineering with the advent of Agile. But neither TOC nor Lean have had a substantial impact on ITSM.
As an Industrial Engineer, inspired by these philosophies and holding various executive IT Delivery positions, I have been practicing TOC and Lean, and looking for ways to apply them at scale. I wondered why ITSM is lagging behind while other industries are making quantum leaps?
There are good reasons why TOC and Lean are so difficult to apply to ITSM, and now that we’ve cracked it, we can look back and explain:
Information Technology Service Management is probably the most diverse and complex form of service management practice on the planet. An IT organization in a typical enterprise manages hundreds and thousands of different applications, devices and services. There are numerous technology stacks and layers that interconnect and integrate with each other. The knowledge base required to maintain all these elements is vast and requires people from different skills sets. Employees, contractors, managed services providers, software vendors, saas vendors, on-shore, near-shore, off-shore, follow – the sun bots. You name it, IT has it. And this kaleidoscope of people and technology is on the constant move. New technologies, upgrades, new applications. Learning curves and compatibility issues – it never stabilizes. It never reaches a steady state, and you cannot standardize it.
When you analyze business processes in any form of delivery management, you find a ‘Happy Path’ (a.k.a ‘Happy Flow’). The happy path is the scenario that works out in the easiest and best way possible for the business. It is generally free of exceptions and features a ‘normal’ progression of events. ITSM Delivery does not have a ‘Happy Path’. Instead ITSM delivery has numerous Process Patterns corresponding to the variety of applications, services and devices. ITSM delivery is a Stochastic system, having a random probability distribution or pattern that may be analyzed statistically but could not be predicted precisely. Not until the advent of Business Process Mining combined with Artificial Intelligence.
“Since the strength of the chain is determined by the weakest link, then the first step to improve an organization must be to identify the weakest link.”
Eliyahu M. Goldratt
Swish.ai was founded with the idea of harnessing big data and data science technologies as innovative enablers for the successful application of TOC and Lean methodologies to IT Delivery.
Measurement – As Peter Drucker taught, “If you can’t measure it, you can’t manage it”. So first things first – make ITSM processes tangible and measurable. Swish.ai established objective process flow metrics that measure performance and detect impending bottlenecks in real-time for every agent and every team. Swish.ai also monitors and measures incidents transitions between individuals and groups, providing objective measure of their contribution to the resolution as well as identifying ping-pongs and excessive ticket hops.
The Focusing Process – The Theory of Constraints provides a specific methodology for identifying and eliminating constraints, referred to as the Five Focusing Steps. These are continuous cyclic steps that happen in real-time:
Application of Lean concepts by waste reduction, continuous improvement and standardised services.
Swish.ai delivers outstanding service improvement coupled with exceptional efficiency that can be realised in substantial cost savings. On average the results achieved by implementing Swish.ai are
