Putting Lipstick on the Pig: The Downside of Automation
One issue that I see every now and then is that we tend to automate things because we can. I’m guilty of that myself. Ever since I started writing scripts and tests and tools and what not, I started to automate things. Because I can.
Don’t get me wrong, automating things is useful and a fantastic opportunity to reduce stupid work. But ever so often we automate the given process and are happy. We forget the chance to maybe optimize the process. We automate processes that are too tedious, error-prone, and binding too much capacity. Instead of asking why is the process the way it is, we start drafting what we need to automate.
First, why does the process look like it does? What does the process achieve? Where does it come from? Are there any relations that are not obvious?
Second, are there steps that we can optimize easily? And I speak from optimizing the process, not automating yet. Can we simplify a form? Can we remove unnecessary steps? Are all steps still relevant? Too often we deal with legacy in our processes. We have always done it that way. One of my favorite quotes, and I’m guilty of using it myself too often.
Third, should we automate every step of the process? Are there restriction that require human interaction? I’m currently working in medical device context, I have some experience in other regulated environments as well. Sometimes there are steps that need a human in the process. Sometimes it’s a step where some human evaluation is not the worst to have.
In general this step goes back to the Jeff Goldblum statement in Jurassic Park.
“Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.”
Fourth, continuing on the “think if you should” statement, what parts of the process need automation the most. Why are these steps so awful to use by a human? Do they have to be so awful? Isn’t there something that we could do about it? Yes, this is a repetition of “second”, but we – at least I – tend to settle too quickly with, “let’s automate”.
Fifth, is the effort of automation really worth it? There is a rather old chart from xkcd that helps quickly to evaluate how much time you save by automation. On the other hand, sometimes it’s worth automating, even if the immediate ROI is not positive.
Sixth, use the automation to spot more potential for process automation. When I automate a test case, then I’m also doing exploratory testing. The perspective of automation is a wonderful opportunity to evaluate a system. Use the chance to spot issues in the process. You don’t need to automate everything, maybe there are details that can be adjusted in the process without really changing it.
An example I had some time ago was automating documentation updates. The automation was supposed to work across two or three documents. The only issue was that the part of the document to update looked slightly different across the documents. One chat with the colleague who was in charge of the documents and three edits later, that part had the same structure and I could use the same script in all three places.
Seventh, implement the automation. Finally. We could have saved so much time and just automate it from the start. But then we would have lost a great potential to optimize the process. Processes need refactoring as well.
I’m currently working on a huge refactoring of a central process. The process reached a state where every step was defined in detail. That was the same point like in programming, when a function does what it should, then you can start refactoring.
When you define a new process, think about automation from the beginning, and design steps in a way that are easier to automate.
Happy Automation!
