This post is a follow up to our previous post 10 common mistakes in automation earlier this year.
When discussing Gartners list of mistakes in automation, we were missing some that we quite often see at our customers and decided these should also be mentioned.
This post continues the list. If you missed the previous post, you might want to head over there first.
11 - Fragmentary automation
This mistake can happen fast, especially in the starting period of automation. An initial task is assigned and addressed rather quickly. A single, simple process is automated and optimized. This means the first item has been automated; or from a different point of view: an automation silo has been created.
As long as the new process works, it can survive in a maintainable state for quite some time. Somebody not involved in automation will rather not touch that, though.
This is not what we want. Should the automation process stop at this step, all you have created is a technical debt. It is vital to continue automating at this point and to turn the exception into routine.
The key personnel familiar with the new implementation stays rather isolated until more and more competence has been shared within the group. The more people work on automated processes and workflows, the more the knowledge spreads and the more things will get better.
The cultural aspects mentioned in point 04 and 10 from the previous post are affecting this as well.
Lesson to learn: There is a point early on which needs to be passed in order to turn technical debt into a success within automation. Abandoning the project too early can do more harm than good. The risks are reduced over time as automation continues.
12 - Over-complex Engineering
If you keep the complexity of the existing processes and transfer them directly into automation workflows, you will missing out on the chance of optimizing your processes. By only migrating over to automation you increase the complexity level even further. Making changes to processes is getting even harder. That is not a good trade-off for increasing automation.
Rather aim to simplify processes where possible and only then convert them. Ideally you are reducing complexity and making all easier to maintain. The goal should be to make it as simple as possible while still satisfying all requirements. This can e.g. mean to break a process into smaller pieces or agree on certain shared defaults to get rid of any snowflakes in the process-chain.
The second pitfall with complexity is to misuse the opportunity and prepare for a possible future requirement. This preparation will never end. Basically you set yourself up for failure. It is not possible to anticipate 100% of any future requirement in advance. Adding more functionality is a common request and you will have to develop further anyway. That is for sure.
As a third point we recommend not to reinvent the wheel unless absolutely necessary. Most problems have already been encountered somewhere and solutions are available. Even if these might not suit you completely, they can usually be adapted or grown into a custom workflow. It is easier and faster to learn from other people (and their mistakes).
Lesson to learn: Let current requirements and common sense take the steering wheel when it comes to you creating solutions. Too much complexity can render a system inflexible and to the point of being unusable. Complexity does not mean flexibility, nor does it include it.
13 - Not calculating ROI
Automation is fun, but expensive. Before starting, you should be aware of the costs. They obviously should not be higher than the return of investment within the automation project. If automation does not save more than it costs: Don’t do it. Think about:
- Any licensing and purchasing costs
- Implementation costs
- Running and maintenance costs
- Training and development costs
- Savings compared to the replaced processes
With these numbers behind you any decision will have a much better foundation to stand on.
Lesson to learn: Like any project, automation requires you to do your homework and calculate the costs. The outcome might point into the opposite direction you want to go.
14 - No change is unimportant
Any change, no matter how minor, trivial or uncritical, needs to be communicated.
There are no irrelevant or unimportant changes. Somewhere, somebody will have implemented a peculiar feature of your automation solution into his workflow and depend on it.
We even have a real life example with rather dire consequences: The recent crashes of two Boeing 737 MAX were partly due to the introduction of a system called MCAS, affecting the flight controls. MCAS was intended to improve the flight handling capabilities of the aircraft. Due to the repositioning of the engines further back on this type of aircraft compare to the previous versions, the nose of the plane tended to rise unintentionally during a power increase to the engines. The MCAS should counter this action by pitching the nose down a bit. The system was completely invisible to the pilots and not disclosed in any documentation on introducing the plane. When this automated system acted due to misleading input from a sensor, the pilots therefore could not appropriately diagnose the problem. Ultimately this lead to the loss of two aircraft. Boeing or the engineers introducing MCAS had concluded this change to be too unimportant to be communicated further. On a side note: adding MCAS to the control of a plane would possibly have required re-certification of the aircraft - a rather costly process.
While this is a rather extreme example with consequences unlike most environments and leaving out other contributing factors, the basic point remains: Disclosure of any change to automated processes is vital.
Lesson to learn: You can not foresee all consequences of a change, it is mandatory to disclose all updates and changes. Mistakes will be made, disclosure will limit the possible harm and mitigate further damage.
15 - Not meeting expectations
The expectations towards automation are high. The goal is usually not only to replace, but also to gain efficiency and speed from the involved processes. It is easy to forget that automation is a process in itself, not a software-solution you simply buy and put to work. If you start with the wrong expectations, you are bound to be disappointed quickly.
With unrealistic goals, it seems like the automation project is mainly riddled with problems and it looks like there is a huge number of processes, that simply cannot be automated. In the end: your processes are special and more complex than in other places, of course.
What really is happening is that you blame the complexity of a process for the failure of automation, rather than too high expectations.
If you see the automation process as organic and growing with some dead ends here and there and mistakes to learn from, the experience will be different. A continuous development, adjustment and optimization process will quickly spread through the organization based on the quick results it delivers.
At some point goals might also be overfull-filled, new solutions be presented and side-line problems be solved, which originally were not on the Agenda. These are some additional benefits of automation.
Lesson to learn: While expecting too much might put the project in danger for not meeting unrealistic goals, expecting too little and missing opportunities for additional chances can also easily be overseen. The right level of expectation is – as usual – somewhere in the middle.
16 - Manual overrides (because you can-syndrome)
The final, common mistake points directly back to the start of the automation journey, to the place where everybody has been.
Running everything automatically is awesome. But sometimes you (as a human) are faster. The temptation of just running manually a minor part of a long, automated process to save some time is always there. All the additional automation steps might not be needed right now and you just would like to see the result of a simple, single test for you problem, right?
If you do this, you just shot yourself into the foot. Not with a shotgun, but a minor one. Not only did you bypass all the other implemented tests, you also gave away a chance of improving the current automation process in way that will deliver results faster. Be honest: You will do the same trick the next time again (because it already worked you last time) and you still have not improved automation. Neither for you, nor for you colleagues.
Maybe you just want to run a process manually because you feel like you know what to do. If something has been updated in the automation process that you are not aware of, you actually also might miss an important step.
Avoiding this mistake is difficult, I do this mistake often myself. Each time I discover again that spending time on optimizing the automation would have benefited me more in the long run.
There are multiple reasons for this. Usually: I can do it and I get away with it. This is the case as long as I only work for myself and my actions have no consequences. The second I reach out to colleagues or have to do a hand-over, I am back to the beginning and have to face the down-sides.
Running my own tests in a limiting way that only benefits me, deprives my team of gaining any benefit from my work. Even worse, they probably are doing the same work themselves and are wasting time.
Sharing a tool pipeline with a team is obviously more hassle than just maintaining it for yourself, but the benefits fall to a bigger number of people and the time savings are accumulating immediately.
Lesson to learn Even though you (feel like you) know what to do, stick to the automation process once it is in place. This will improve the process, share your knowledge and deliver repeatable results across the board. Your team will save time by not doing the same tasks multiple times.
Some final words
While thinking and writing these two blog posts about the common mistakes part 1 and 2, there seems to be an underlying pattern unifying all of this.
Boiled down to a shorter list, these advises might represent the core of good traits during the automation journey:
- Communicate widely
- Share your work
- Base decisions on data
- Learn from errors
- Continue to improve
All listed mistakes seem to fit into one or more of these categories. Even more astounding it is that we see us and our customers repeating some of them.
It shall also be mentioned that all of these mistakes are not living in a black and white environment. The world is not black and white. Every environment and every situation is different and has many shades of grey. Usually common sense is a good companion on the journey of automation. But some miss-steps can be avoided by learning from others in the field.
We hope that these posts can give you guidelines and help on your way to automation.
Any feedback or suggestions are welcome. Topics are changing and what might be right today, might have a better solution tomorrow.
