Insights

Business process automation is, arguably, the main driver behind the invention of the computer. So why does it feel like so much day-to-day complexity is at least related to, if not directly caused by these machines? Why hasn’t the ‘Automation Revolution’ already happened?

The answer is not in the speed of the machines. They are undoubtedly faster, more accurate, and not restricted in the same ways humans are. The problem, unfortunately, lies with us. People are inherently complex, and we have an unfortunate tendency to make simple processes into something complex.

At Chamonix, we’ve been helping our customers automate business processes for over a decade, and many of the problems we saw in 2010 are the same ones we’re seeing today, albeit the way we solve those problems has certainly evolved.

Many automation projects fail at the first step – justifying the cost of the platform. Almost everyone automates incrementally – but if the first process you need to automate requires hundreds of thousands of dollars of investment into licenses, server costs, training, support, and consulting, you either need a huge problem, or a finance department willing to sign off on ‘Might never return on investment’*. Even more dangerous than over-committing (and just as common) is under-committing – the oldest server and the cheapest employee are given a trial license and a warning not to break anything…..and sure enough it goes nowhere.

Those who get past the hurdle of actually starting often soon hit another problem – over-reliance on tooling to achieve objectives. As pointed out previously, any process that involves a human is inherently complex – what if they hit the wrong button? What if they’re off sick? What if they don’t quite understand the instructions? What happens when they leave? What if there are two people filling that position in the future? Far too often, once an ‘Interact with a person for any reason’ step is reached, the complexity of the automation skyrockets, and the more it’s tested, the more issues are found.

Even projects that eventually make their way into production often have a shelf-life of under six months for a plethora of reasons; because one of the dependent systems changes, some of the staff change, or a minor alteration is required to the process itself but there’s nobody available to make the change. All too often, a process with an in-place automation is still completed manually.

So, what can be done to combat each of these?

Firstly – automation should be done as close to the team that owns the process as possible. By all means, work with your IT department – share some of the costs if possible – but a surprising number of modern tools require little to no IT involvement. They can run on desktop PCs and directly augment or enhance the processes you already manually perform.

Secondly – the aim of automation should not be to automate every single step of a process. The biggest example here is securing approvals. If the current process is extremely complex but culminates in an informed executive deciding to either approve or reject, then the only step that should be built into the automation is seeking approval from the executive. She can still go and seek opinions from whoever she wants, can run a committee, can request presentations or anything else that is required, but at the end of the day the only thing the process needs to know is whether to proceed or not, and the only signature that really matters is that of the sponsoring executive.

Thirdly – rather than attempting to automate the process yourself, consider instead ‘selling’ the process to either IT or to a managed service provider. If you know (for example) that with a specific set of inputs, you need a specific set of outputs which is currently consuming one and a half staff paid $80,000 each (not to mention associated opex costs) try approaching an external party to see if they would be willing to commit to delivering those outputs for less than $120,000 per annum. This is a pattern that is already extensively used within IT itself for things like onboarding and offboarding staff and for management of hardware. There’s no reason the same pattern couldn’t be used for core business work whereby all costs associated with development, monitoring and maintaining the process automation are managed by the service provider.   

When considering an automation platform – whether it’s managed by the business, IT, or by a third party – you always need to consider how that platform is going to be governed. You don’t want to end up in a situation where you have multiple automation platforms competing, where an automation has been built but can’t be maintained, and especially where an automation system opens your business up to cybersecurity issues!

For further information on how our team can help you on your journey towards automation, get in touch.

*Read our earlier article for insights on how to ensure ROI.