There’s a common misconception that IT automation is the destination for an IT organization. Leadership, leaders, 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 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 realizing
Now we’re finding the “why”, or value. Automation offers you the chance to realize value in one of three general categories: 1) Efficiency – We can do things better. 2) Productivity – We can do more things, better. 3) Optimization – 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 be 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 prioritized.
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.