automation

Note

• The end goal is always to automate.
• If the computer can do it, give it to the computer

Now I will admit that the road to automation is quite often not the path of least resistance. I have also come to realize, that there are very few of us, who truly enjoy the journey.

The road to automation §

Here is the process I have over the years replicated over and over. I didn’t read it in a book, I wasn’t taught it in school, I didn’t learn it from my boss, it just came naturally.

flowchart TD
    A(Learn Task) --> B(1-on-1 training)
    B --> C(existing documentation)
    C --> D{Did I Learn the Task?}
    D -->|No| B
    D -->|No| C
    D -->|Yes| E(update documentation)
    E --> F(Automate the Task)
    F --> G{automation working?}
    G --> |No| F
    G --> |Yes| H(document new automated process)
    H --> I(create developer guide)
    I --> J(offload the task)
    J --> K(pick up a new task)
    K --> A

Let me set the scene for you §

When I start a brand new job, the first goal I set is simple, learn whatever task I am assigned to take over. I usually have one team member sit with me and they go over the task. Documentation might be provided, but in general, most of my information gathering at this point is from whoever is teaching me the task.

Learn the process §

After some time, I am left on my own, and here is where I attempt to do the task with little assistance. Now, have in mind that as I am learning the process, I am seeing a bunch of issues and opportunities for improvement. At this stage I keep my mouth shut. My goal is to learn the process as it is currently done. Regardless if it does not make any sense or it is clearly done incorrectly.

Document the process §

The next stage is pretty simple, I start to document the steps. The goal of this step is to write down every step (yes, every step) so the team has updated instructions on how to complete this task. This is a great exercise as it forces you to truly understand how to perform the task. You will hit certain steps that have multiple solutions. For example, if a file is missing from folder “abc”, you need to go to location “def”. Edge cases or issues that pop up in rare occasions are usually not documented. Even in the rarest of cases, you need to write it in the documentation. Make sure to include screenshots as it will make your document look better and much easier to understand. I use Microsoft paint to edit and crop the screenshot. Nothing fancy is needed for documentation.

Volume is your friend §

Let’s summarize what we have so far, we learned a task, and we have fully documented all of the steps to complete the task. Now to be honest, we have not technically learned everything we need to learn. We need more time, more practice, to fully acquire all the experience and encounter all the possible scenarios for a specific task. So how long or how many times does one need to do a task in order to feel confident there is nothing left to learn? The key is volume, the more times you do the task, the closer you will get to understanding all there is to know about the task.

Teach others §

At this point, you now have the option to teach someone else the task. You know how to do the task and you have step-by-step instructions. So the first reason to document is for you to learn the task, the second reason is for you to be able to offload the task to someone else.

Tools and programming languages §

Now that you know how to do the task and have all of the steps written down, we are ready to automate the task. Now to be honest, in order to automate you need to be able to program or understand a tool that will allow you to offload the task to a computer. Early in my career, I only knew Excel and this is what I used. Excel has macros, a scripting language vbScript, and don’t forget about the solver. The more tools and programming languages you know, the easier it is going to be to automate a task. Use the tools you already have and continue to pick up new ones over time.

Start automating §

Pick your tool of choice and start automating. Your first step could be, can I get the computer to read a file. Then the next step can be, can I get the computer to count the number of rows it just read into memory. This was just an example, but at the end, your goal is to automate the entire process.

Test your automation §

I would then complete the task manually, via my automated process, and compare the results. You want to make sure that the automated process returns the same results as the manual process. Don’t forget, you are allowed to be creative here. You might have to perform certain steps differently or in different order in the automated process. It’s ok! The goal is simply to automate the manual process in the best way you can imagine. The keyword here is imagine.

Show and tell §

Once you have the process automated, it is time to show your peers your hard work. Show them how it works, how much faster it is, and tell them how much fun you had throughout the entire process.

More documentation §

As soon as you are happy with the automation, the code is cleaned up, you added your comments, and have tested it enough times, it is time to document the new process. Yes, you have to create a new document. You have officially created a new process so this new process needs to be documented. The good news is that it should be a lot shorter and allow team members with little to no technical skills to perform the task.

Even more documentation §

If you want other team members in the team to maintain the automation, you will have to create a new document that explains your code. I would do a very detailed walkthrough of the code and explain the folder structure. The number of persons who are at your level will be small, so you should already have a good relationship with them, and make the transfer of knowledge process easy. Another reason to write technical documentation is so that when you need your automation breaks (and it will at some point), these notes will help you refresh your memory, and fixing the issue much faster.

Rinse and repeat §

At this point, you can offload the task to someone else or simply pick up another task and perform the entire process all over again. In my professional experience, it takes me about 1 year to learn every task I am responsible for at my job. I am able to automate some of the tasks and some of the tasks I am not able to automate. At the very least, I will have learned the task and fully documented it. That I can assure you of. Automation is not really guaranteed.