Automation isn’t a shortcut. Understanding the manual work first is essential to a successful manual to automation process.

“Let’s automate this!” How often have you witnessed automation being heralded as the one and only solution to every problem?

In the IT industry, automation is paramount. Automation is second nature to engineers — from server maintenance to data migration to administrative functions in the back office. As I am both an engineer and the Founder & CEO of Yonder, I am the driver behind quite some automation efforts in our company.

But let’s think twice. Is automation the right answer in all cases? Here are some insights based on real-life experience.

Step 1: Know Your Tasks

Automation can never be the first step, as you need to know what you want to automate before you can automate it. Unless, of course, you’re automating straightforward tasks like sending an expense sheet to all your employees.

Let’s look at two specific examples from Yonder.

Our software can import very complex documents in XML format, for example, Airbus or Boeing manuals. Document import is easy, right? Not really in the case of Airbus or Boeing manuals. Aircraft serial numbers need to be translated into tailfin registrations, graphics need to be converted from CGM to SVG format, XML data need to be transformed from one DTD to another, etc. This might sound very technical and irrelevant, but the relevant point is that I can only name those tasks because we executed them manually many times before we started to automate them. Automation needs a deep understanding of the core tasks, the possible exceptions, and the edge cases.

Another example is the very detailed permissions concept embedded in our software. By adding customer-specific permissions for workflow and organization settings, our customers can configure our software to work in a small organization or an international group of airlines based in multiple countries. Configurability is a great feature, but it bears the risk that certain things evolve so specifically that automation becomes harder and harder. But again, the deeper the understanding of the different customer configurations, the easier you can automate them. In the case of the permissions configuration, we invested countless hours of manual work to understand and set permissions manually before we started automating this task.

Step 2: Assess Automation Potential

Once you know your tasks in-depth, don’t start automating them right away. Automation is a process, not a project. Therefore, I would advocate a step-by-step approach: Start with the easy tasks, then move on to the more complex tasks.

However, automation potential is not just about how easy or difficult it is to automate a task, but also about the benefits of automation.

First, how many hours can you save per week by automating a certain task, and how much time does the automation take to set up? Think of it like a business case — how long before your automation efforts pay off?

Second, how error-prone are the tasks that you are looking to automate? The more error-prone they are, the sooner they should be automated to avoid downstream efforts to fix human errors.

Step 3: Automate

And now it’s time to start the real automation work. If you know exactly what to automate and why, then you can start to answer the question of how to automate. Some tasks can be easily automated using tools such as Zapier or Microsoft Power Automate, other tasks will need specific implementation in your software product. Irrespective of your choice of tools, always remember to automate step-by-step. In this way, you can reap the first benefits of automation long before the full-blown all-encompassing master solution is ready.