As technologists, we live and die by the ticket. Support tickets create our pipeline of work, document when work is approved, prioritize our efforts, and provide evidence of what we've achieved. For many support personnel, we even receive bonuses related to support tickets - number of tickets closed, average close time, skill level of tickets. Tickets create order out of chaos and validate our success. But what if we challenged the paradigm of support tickets, and really took a deep look at all that we hold to be true about the value of support tickets? What if we killed the ticket?
The rapid adoption of the cloud has forced most organizations to re-evaluate processes. We have a relatively easy time understanding the shift from on-premise workloads to workloads hosted in the public cloud, and that new procedures are required to accommodate that shift. Organizations that have been successful in the migration to public cloud are companies that have taken an introspective look at the need for a change in process as well as infrastructure and applications. In order to achieve the speed, agility, and lower costs that the public cloud can offer, we need to fundamentally shift how we deliver Information Technology.
This shift requires that we also look at how we accept, prioritize, and deliver work. Think about the traditional model where a software developer requires a server for testing a new application. The process typically looks something like this for a cloud-enabled enterprise:
And, as a result, the whole process can take 15 days (assuming typical response time is 24 hours on a ticket). This, mind you, is the "vastly improved" process enabled by utilizing the public cloud. Had this been done in an on-premise scenario, 4-6 weeks could have been added to support procurement, physical installation and networking.
You may note in this example that the majority of the time is spent in between steps, and not so much the actual effort. In reality, this 15 day duration process only took minutes of effort to complete. When we look at the entire process, we can see that the ticket, our former friend, has now become our greatest limiting factor.
Now, let's re-envision this process without the ticket. That's right - completely eliminating the ticket. Now, our process looks more like this:
Now, our process occurs in minutes instead of weeks, simply by eliminating the queuing points around the ticketing system. There are similar problems with reporting tools that generate non-compliance reports or tickets to have a mis-configuration corrected. We see a comparable delay cycle (Identify->Report->Respond->Script->Change Request->Apply) because we're introducing a ticketing step; effectively a queue point, in between each of our value added steps.
A much better approach is to eliminate the reporting components and move directly to remediation (Identify->Remediate). This is especially true when we are talking about service misconfigurations that are out of line with Security Policy, or have the potential to inadvertently expose data. The goal in eliminating the ticket is to eliminate the time period for non-compliance rather than waiting days or weeks for manual remediation processes to catch up.
We all came to the cloud for the promise of decreased costs, faster service delivery, and greater agility. While we certainly get improvements through a lift and shift process, our real value comes when we completely re-envision our operational model. Looking at any process, tickets help to provide definition, but also significantly increase delay and add no true value. By eliminating the ticket, we free up a great deal of time that was being used to perform manual tasks, eliminate the queue time, and allow the most efficient delivery by better enabling our teams. Look for ways to kill the ticket in your organization, and you have the potential to truly embrace the paradigm shift that the cloud has opened to us.
Contact us for more information about Turbot , or schedule a demo to see how Turbot can help your company Kill the Ticket.