We often obsess over process automation in IT as a means to reduce costs and increase transactional speed. However, sometimes discretion is the better part of automation.
I've spent most of my career deploying technology to automate and streamline processes in one way or another -- from my early days of implementing ERP systems that promised to speed core activities in accounting and manufacturing, to deploying modern cloud applications that promised to make processes faster and more flexible. However, I was recently reminded that enabling automation without allowing some human discretion can backfire.
I've always loathed expense reporting. Having worked for a large variety of companies and being subjected to everything from Excel worksheets to automated web applications, this seemingly trivial task is always painful. Recently I received a notification from my employer's "expense police" demanding a response within five days, lest my $1,000+ expense report would be rejected in its entirety. My "crime"? Submitting a duplicate charge for $1.78 in tolls.
Documentation and explanations were demanded, so I put revenue-generating client work aside to fire up our expense application. In the ensuing comedy of errors I spent approximately two hours performing Java updates and browser reconfigurations to get our expense application to work, only to discover it was temporarily offline.
The next day, I was finally able to get the application open, and discovered that the $1.78 toll charge had been entered on the wrong date, a date where a previous expense report had a similar charge. In my defense, the "date picker" of the application automatically resets the month each time it is opened if your report straddles two different months, so a charge intended for April 29th could easily be entered on March 29th. I corrected and resubmitted the report, spending around three hours chasing down $1.78.
Automation gone wrong
Presumably, some well-intentioned person had established a rule that any charge for the same amount, date, and category be flagged for review. This appeared to be coupled with a policy that eliminated any discretion from the back office personnel, aka the "expense police," creating a policy that clearly cost the company significantly more than $1.78. As these were client billable charges, I can certainly imagine that my company did not want to risk an incorrect charge to a client, but "eating" the $1.78 would certainly have been the wiser move from a total revenue perspective.
There are all manner of areas where well-intentioned technologies and business processes have gone awry. I've seen convoluted IT chargeback schemes that required elaborate tools and weeks of negotiations, all to ultimately take money from the company's right pocket and put it in the left pocket, at a cost that exceeded my expense reporting follies exponentially.
Consider the cost of automation
When automation is considered, too often only the positive aspects are investigated with any rigor. We'll tally up time and cost savings for the "happy path" process, and ignore likely exceptions. While designing automation around exceptions is a recipe for disaster, so is pushing any exception down another automated path rather than tossing it to an empowered human.
Furthermore, we often fail to consider "total cost of automation," where we regard the benefits of the automation we're considering in conjunction with the costs of "care and feeding" for that automation. Tracking the cost to send a single email and charging it back to some business unit might be neat and tickle someone's misguided fancy about managing IT costs, but is the administration required to support this process really worth what's essentially little more than trivia?
As you design your automation, take a moment to consider how you'll handle exceptions to the rules you carefully establish, and how much it will cost to administer the automation. Preventing your own $1.78 errors is nice, but not if it costs several hundred dollars to make it happen.