Standardise, Simplify, Automate – In That Order!

There are not many topics in which success and failure are that close together than in an automation project. It does not matter if you automate a process or code generation – it is a small misstep to turn a possible success into a definitive failure. To change the odds to our favour, we should split our automation project into three distinct phases:

While everyone has their own ideas what could go into these phases, let us take the time to define them so that we have a common base of understanding.

 

Standardisation

The scope of the standardisation is as narrow as the topic of our automation project. We do not aim to standardise the world. In the contrary, if we want to succeed, we need the focus our effort.

If we try to automate a process, we must first find the different ways the process is currently done and settle for one approach. You may find that a contradiction, then the process should be defined in a way that there is only one way to do it. But you will be surprised how different people found different approaches to do the same work. It may be a neglectable difference, but more often you will be astonished about how different people work.

If we try to automate code generation, then the scope of our standardisation is the application for which we want to generate the code.

Whatever we want to automate, we first need to define that single way of doing it. Only then can we go on and make it simpler.

 

Simplification

In a process we may find a lot of work that is still done, even if the reason for doing so is long gone. Especially if the company is in business for a long time or has grown significantly. There are forms that are filled out that no one ever looks at. There are lists that are updated, even when the same data can be found inside an application. There are checks that are made that have been done before. The list of wasteful process steps is huge, not because the people who are doing them are stupid, but because there was never time to look at the processes and get rid of clutter.

But the time to declutter has now come with the automation project. Everything that we automate that is not needed, is waste. Everything that we do that does not need to be done is waste. All that waste costs money: first by documenting it as part of the automation, then for the automation itself and the maintenance that must be done in the future.

The biggest chance we get to reduce the cost of the automation is to get rid of all unnecessary work before we go into the automation. Everything we find later has already cost us money.

 

Automation

Before we enter the automation step, it is a good opportunity to check if the automation is still needed. Maybe we got enough benefits with the standardisation and the simplification that we no longer need to automate the work. If that is the case, stop the project and enjoy the benefits you got.

If there is still a need for automation, make sure that you automate the repetitive parts. You would not believe how many developers want to automate the things you only do once. But if you only need a thing once, you better do the work directly than to add the complexity of the automation.

The more often you do the repetitive steps, the faster the automation can show its benefits. Work that we do one hundred times per week is therefore a better candidate for automation than a step we only do ten times a month.

However, there is another aspect of automation that contradicts this heuristic a bit. Automation can also be a living documentation of a process. It may be worthwhile to automate work you do only a few times a year if the risk of doing them wrong or missing steps is high and has massive consequences.

 

What happens if we do the phases out of order?

If we start with the automation and do the standardisation later, we have to automate multiple approaches. We may pick only one approach, but which approach will that be? Do we really believe that people who have no working knowledge of the processes pick the right approach? It is possible, but highly unlikely. It is much better to let the domain experts figure out what the right way is and only start the automation when that is clear.

If we simplify before we do the standardisation, we are in the same situation. We have multiple approaches, and we need to optimise them all. This extra work reduces our chances of success drastically, then most of that work will be thrown away after we have spent a lot of time optimising it.

To succeed with an automation project, we need to focus on repetitive things and make sure that we get rid of all unnecessary work as soon as possible. The later we separate the needed from the unnecessary work, the more money and time we will have spent on the wrong things. There will be enough unplanned surprises and we better make sure that we have enough time left to address them.

 

Next

Over the next weeks we take a deeper look at the three phases before we dive into an automation project in which we generate code with T4 templates. Next week we explore the nice side effect of standardisation, the increase in consistency.