“We’re going to automate this process”

“We’re going to automate this process”.

Now, it doesn’t matter whether you are a woautomationrker-bee in a factory, or a Sys Admin in a data centre, but when you hear the Boss use this phrase, let’s be honest, you get worried. And, frankly, you should be worried – especially if you are the person who has become the bottleneck. However, let’s look at it from a slightly different perspective for a few seconds.

If, by automating a task, we are planning on doing exactly the same amount of work as before, then by definition, automation means redundancy. But, if the plan is to increase throughput and at the same time make the workplace less of a drudge, then automation is an opportunity.

We have had the occasion to talk to quite a few Ops people in the last few weeks, primarily because their employer’s currently outsourced Managed Service contract is coming up for renewal and we’re helping them write a new tender. What is interesting is that most Ops people reckon that 25% to 30% of their daily workload is taken up by repetitive tasks and reactive work arising from fixing errors that those repetitive tasks cause.

Here’s the thing, they want to see the back of those tasks, so that they can focus on the more interesting project based work that keeps getting put off because they are so busy with the daily grind. Meanwhile, here’s what their boss has said.

‘We’ve analyzed all our workflows and have identified Type A and Type B tasks. Type A are higher order, require experience and judgment to perform or there is some inherent risk in the task. Type B are repetitive and of lower value. Many of the Type B tasks introduce human error and have associated rework costs or create further unplanned work downstream. We are looking to automate Type B tasks as much as possible and retrain and reallocate staff to Type A tasks where there is more value to the organization – and the work we’re asking people to do is more interesting’

All that said, it is going to take time and money, and a significant effort, to automate so the key is to pick those tasks that deliver the biggest wins early in the process. Ideally, the earliest automation should focus on where the organization gains the most increased throughput and at the same time, the staff lose the most pain. In an ideal world, you’re also going to simplify and make the end-to-end process leaner. So, let’s live in an ideal world for a few minutes.

Lean means removing hand offs, eliminating waste, automating as you go and continuously improving. DevOps means applying lean to IT processes and Release Automation(RA) is a critical element.

Agile delivers lean to the left of the committed line of code. Lean processes ensure you build only enough software to add a value to the business that is greater than the cost of writing the code. Workflow tools enable you to scale these processes, integrate remote teams, and make teams autonomous without sacrificing management visibility. Automated code integration and automated test improve developer productivity. (Hands up – we resell Jira/Bamboo and work with tools like Jenkins.) But note its process first and then tooling and then automation. Not the other way around.

We all know smaller more frequent releases won’t work without automations. The workload per release is simply untenable. So, if we’re going to get more work done, do more interesting work, and help our business succeed, which protects all our jobs, what we really need to hear the Boss say is;

“We’re going to automate this process”.

Tags

Leave a Reply

Your email address will not be published.

top