Automation requires a change in paradigm
Businesses are running headlong into automation as a useful way to improve consistency, flexibility and speed, and decrease costs. However, there is a need for businesses to reconsider what is being automated, and more importantly why automation is being used. Implementation of automation requires a change in paradigm, similar to the way that virtualisation needed a change to the way that servers were handled.
Automation requires a change in paradigm
We’ve seen this before in the IT industry – and it’s still going on. Businesses will take their existing processes, approaches and practices – and simply transfer them into an IT system. It happens so often that organisations will blindly repeat broken processes into new systems – “because that’s the way things are done“.
We’ve seen it with virtualisation of servers – for many organisations, they treated virtual servers in the same way as physical servers; departments had invested budget in [or had ownership of] the hardware and so restricted vMotions, IT departments installed, maintained, updated and used monitoring agents, backup agents and locally installed anti-virus for years, servers are often still named around their site or role (DR/Prod), Infrastructure teams scaled servers with multiple CPUs and large RAM sizes, DBAs dictated the RAID level for storage volumes – the list goes on.
Automation of an existing process may make that process faster or more repeatable, but it will still be the old process. If this process has not been reviewed or optimised for the capabilities of the automation tool, or for the business outcomes that are required, then it is doomed to have the same restrictions and drawbacks of the previous process – just a bit faster and cheaper.
If this is what is needed for your business, or you believe that your business processes are as optimised as much as they can be, then you may be missing the point.
The benefits of automation include change
Investing in an automation solution is not a silver bullet. Just like investing in a firewall [and thinking that you therefore are protected from viruses], buying it and putting it in is not going to solve all your problems. It’s not even a turnkey product that can just be switched on, it’s more like changing to activity based working; it’s not going to deliver benefits without customisation, and configuration to suit the needs of your business. Further than that, it is necessary to change your business approach to suit the benefits that become available through the new paradigms.
If your business has surges in demand in remote access at some times, then you may consider short term expansion of your load to Cloud services. Cloudbursting may be a great idea, but unless you can ensure that your data is consistent, secure and responsive – it’s not going to deliver the benefits that you expect.
The process of re-investigating business processes is, in itself, beneficial in many cases. It may be that you find out that a previously inefficient process can improved simply by removing some human aspects, or that a process needs no enhancement at all (so should not be automated). However, I find that sometimes the best way to re-investigate a process for consideration for automation is to start at the end.
Automation requires a change
Defining policies for automation should start with a blank sheet. This may be the most difficult part of the entire process! More than that, a blank mind is also a benefit so that old processes and practices are not replicated – external consultants can assist in this effort. Defining automation workflows does not simply require an optimisation, but may also require a pruning of practices (and people) and even parameters/fields that have previously always been used. Have a look at my article on designing data entry for a system for inspiration on choosing what is really required – do you need to know the CPU speed in an asset register?
