The Limits of Robotic Process Automation

Is your IT helpdesk drowning in tickets? Does incident handling consume your DevOps teams? Are you struggling with hiring IT specialists and bind them in the long term? Are you grappling with innumerable systems and tools, requiring niche skills and experiences from many years?

You are not alone. One CIO faced backlogs of more than 2,000 tickets, regular maintenance tickets were already ignored, and critical development milestones 1.5 months overdue. The situation further escalated as IFRS related incident and development tickets for specialized finance on-premise applications were piling up. The department concentrated on fast deployments of servers and “quick and dirty” fixes only exacerbating the problems going forward. This is outright ticket hell.

But many more IT departments are at least in what we call ticket purgatory. By harnessing all their strengths, IT tickets are processed within 24h hours. Still, the effort interferes with IT operations, especially in areas of development, maintenance, and IT’s participation in corporate missions, like the development of future business models. 

Advanced ITSM tools like ServiceNow and Robotic Process Automation (RPA) do alleviate the problems but are not resolving them. The automation rates remain low because IT environments are mostly too complicated and are changing too fast for fixed automation approaches. In the meanwhile, maintenance requirements for the installed robots increase quickly, and quality issues appear on the horizon. Changed user interfaces after updates, swapped columns in relational databases, unknown error codes, and many other usual IT evolutions cause much trouble to fixed solutions.

Automation Dashboard

The dashboard shows the impressive automation rate of more than 90% of all incident tickets delivered in just four months. Such results are achieved by applying Machine Reasoning that orchestrates existing ITSM and RPA tools or automates digital processes directly. In a first step, we create a representation of the real world. In this case, we used the MARS ontology (Machine, Application, Resource, Software) for describing the entities and their relationships, and imported the customer’s CMDB. In the second step, we build a knowledge repository based on our library that allows solving many standard tickets. In parallel, we adopt connectors and action handlers to the customer’s systems. Finally, we performed iterative functional testing and integration testing before production go-live after one month. While the average automation rate was already about 50% in the beginning, you can see spikes of manually solved tickets during the first couple of months. To address those ticket types and further increase the automation rate towards the 90% target, we continuously added knowledge items over three months. During this phase, designated members of the client organization were enabled to run the solution. The complete hand-over took place when more than 90% of all tickets were constantly solved automatically.  

So what is it for you? Heaven or hell?  

Thanks to my co-author Felix Hornung.