Automation prompts fierce debates at the moment. Many of the larger conversations around automation focus on whether it will create jobs or destroy them, what it will do to our economy, and how it’s helping or hurting various industries. But there are many other smaller conversations happening around automation, and many IT leaders are just looking for simple ways to improve productivity, increase speed, and reduce manual work in their day-to-day operations.
Of course, I believe that automating something is better than having to keep doing it manually. But I don’t overlook the opportunity to ask the important question: should we automate or should we obliterate?
Think about how many times you’ve questioned a process or approach only to be given the maddening response, “This is the way we’ve always done it.” The era of automation gives us a similar problem. If a process can be automated, it’s often automated without taking a step back to ask whether you should continue doing it in the first place.
Taking the time to ask that important question provokes a different type of thinking – kind of like a zero-based analysis. You are no longer assuming that what’s in the base has to remain in the base. Sure, it can be automated, but if it doesn’t have to exist in the first place, why not just eliminate it?
The case for obliteration
At CVS Health, we conduct surveys on an annual basis that ask colleagues hundreds of questions about the company, the work environment, the type of work they do, and more. We analyze their responses and choose themes that enable us to continually improve the work environment and experience year over year. One of the themes that emerged from the annual survey this year was the opportunity to reduce what is perceived to be “red tape” by our employees. This prompted us to put many process improvements onto our priority list – areas where we could automate or eliminate steps, processes, and functions in different parts of the IT organization, to reduce work and increase speed.
For instance, the time and steps that it took to get approval on staff augmentation was perceived by our employees as red tape, and they were right. We were able to reduce that time from weeks to one day. But we didn’t achieve these results through automation: It was through obliteration.
We looked at these opportunities holistically, taking into consideration both the administration and the technical aspects and processes in play. We reduced the number of project approvals by 41 percent and the technical design artifacts by 60 percent. By eliminating these steps altogether, we were able to reduce friction in the administrative processes of managing staff, projects, and programs.
If we had just focused on automation as a way to solve the problem, we would have ultimately been automating work that was unnecessary in the first place. Just because something is there now, that doesn’t mean it needs to be there tomorrow.
There are excellent tools to help IT organizations answer their own automate-or-obliterate questions. You can use Pareto analyses, for instance, to determine where time is spent in order to pinpoint improvement targets. Most importantly, don’t lose sight of the problem you are trying to solve. Start there, and use proven methodologies to scientifically analyze where your opportunities are, whatever they are, and then act on them.
Automation may seem like your team’s secret weapon to finding more time and productivity throughout the day. But, in the constant quest to find ways to move faster in IT, it’s important to sometimes slow down, pause, and ask yourself, “Why do I even need to do this?”
