There’s a common misconception that IT automation is the destination for an IT organization. Leadership, leaders, and practitioners are all making the same mistake: automation is the vehicle that gets you to your destination, not the destination itself.
Time and again, I interact with clients that are very sure that they need to automate… something but don’t really know why or what they should get from that effort.
So, Chris, if you’re telling me that automation is a “how”, what is the “why” we should be aiming for?
Un-focus your eyes
Un-focus your eyes a little and stare off into space. What does the current way of doing whatever tasks you are responsible for the limit you from doing?
What does it stop you doing?
Why does that matter to you?
Does it force you to spend time on repeated work?
What would you do in place of this?
Would you start doing something more interesting/valuable/challenging if you didn’t have to do this task?
Think about the “Why” you’re realising
Now we’re finding the “why”, or value. Automation offers you the chance to realise the value in one of three general categories:
1) Efficiency – We can do things better.
2) Productivity – We can do more things, better.
3) Optimisation – We can do different things, innovate, and improve.
Instead of framing things as “We will automate (X)”, reframe it as “We need to be more efficient with (X) so we can get to (Y)”. That sets the direction and the goal, and if you include how much time/effort/problems are saved by doing this, you’re already thinking in value terms.
Turn it on its head and see if from the leadership side: “We need my team to be able to spend more time innovating and improving our processes, so I want to remove the rote work that can be automated to free up that time”.
Challenge the individual or team to identify what the opportunity is to improve a process. Does the overall execution time of the process decrease? Did the quality of the service increase? Can the consumer of the service now use self-service? Is the automated task a part of a bigger process? (Hint: you’re starting to build your measures when you think in these terms.)
Automation versus Orchestration
While it may seem like a thin distinction to draw, there is a difference between automation and orchestration. Automation is primarily task-focused, as it deals with an atomic, individual step that can be automated.
Deploying a virtual machine template, verifying a configuration value, installing a piece of software are all examples of individual tasks that can be automated.
Orchestration is about the sequencing of these automated tasks. By its very definition, orchestration is mapping the process that executes and translating that into a set of steps.
Each of these steps can be automated, they will be reliant on the previous step for information or attributes that are needed to proceed, or they are a manual step that either hasn’t been automated or has been determined to need to be manual (for now…).
Why bring this up? Because thinking in terms of automation and orchestration helps to build the roadmap for the journey to automation value that you’re on.
First, automation that can be built to make the individual more efficient and productive should be prioritised.
Second, these automated tasks can then be mapped to a process that can be orchestrated. This increases the delivered value as more manual steps are removed, wait time evaporated, and errors eliminated.
Third, this approach also helps to keep the work to manageable efforts: instead of staring at an end-to-end process of 100 steps, you and your team are able to look at it as individual steps that can be tackled, and work your way through the list of steps.
Automation is good, it’s even better with orchestration
Like a lot of things, the combination makes for better solutions. Building a solid foundation of automation, particularly related to ensuring that automation can be run by someone else (or ideally, no one else – a system runs it) is the initial goal.
From there, snapping in automation to improve a process is the logical progression. But keep in mind that the “why” is improving the way, amount and value of the work that is being done.
First published on Gartner Blog Network
