222. Automating Processes with Software is HARD
We have decades of experience trying to automate processes. The biggest lesson is that automation is not about the easy and known flow, but about exception handling.
The best diagnosis for exception handling I can think of is to wait on line at the post office. If you’ve ever done that, you know the thought of “doesn’t anyone just want to mail a package” comes to mind. As it turns out the entire flow at the post office (or DMV or tax office) is about exception handling. No amount of software is going to get you out of there because it is piecing together a bunch of inputs and outputs that are outside the bounds of a system.
The ability to automate hinges not just on the ability to know the steps to take for predefined inputs, and not even the steps to take if some inputs are erroneous or incomplete, but what to do if you can’t even specify the inputs.
My favorite example of the latter is how the arrival of IBM computing in the 60s and 70s totally changed the definition of accounting, inventory control, and business operations. Every process that was "computerized" ultimately looked nothing at all like what was going on under those green eyeshades in accounting. Much of the early internet (and still most bank and insurance) look like HTML front ends to mainframe 3270 screens. Those might eventually change, just not quickly. It might be that the "legacy" or "installed base" of many processes is such that the cost to change is too monumental.