Automation Journey

The road to automation is often long and arduous. The promised land of full automation of the business processes across all of the disciplines within your organisation seems a long way off.

The road to automation is often long and arduous. The promised land of full automation of the business processes across all of the disciplines within your organisation seems a long way off.

Whether you’re looking to automate A-to-B type transformation activities or perhaps the mundane tasks which you employ people to undertake on a daily basis, the journey is fraught with obstacles, wrong turns, bad directions and always takes longer than you hoped. Traditionally you are unlikely to reach your destination, you might get somewhere near but not exactly where you first thought you might end up. I call this the budget airline automation syndrome – you were promised Barcelona but you ended up at an airstrip somewhere in rural Spain.

Why does this happen?

Traditional automation projects rely upon 3 things;

1) Runbook/Playbook

This is the definition of what you want to automate. Your business process for instance. You understand it well, or at least the people within your organisation you employ to undertake the activity do (consider where your people deviate from the Runbook). This must be communicated and well understood by the team (internal or external) creating the automated replacement. How effectively this is handed over and so understood by both sides is critical. Furthermore, consider the inherent reticence of the individuals relinquishing the crown jewels of their job position to a team tasked with replacing their function with automation


Traditional automation projects require CAPEX. There are no two ways about this. They require infrastructure (and everything that goes with that), they require licenses, support agreements, depreciation accounting etc etc etc. This is no mean feat in getting in place and without all of the above most automation solutions go nowhere. In short, the upfront cost is large!

3) Technical Expertise

Typical automation projects require expertise in the shape of consultants who are adept at creating automations within the chosen technology space. These individuals know little or nothing of your organisation but they (hopefully) do bring to the table a wealth of experience in implementing the automation suite and its integrations. These people are expensive

How does RPA differ?

Robotic Process Automation is not categorised as a traditional automation technology and neither is it implemented as such.

The absolute key differentiator is that RPA automations are created (typically) to perform tasks that a human operator would perform. Same interfaces. Same interactions. Same sequences. The advantages to this are apparent – the robot performs the same actions as the human but it does it faster, without human error, more consistently and is not limited by those same constraints all us humans are (motivation, fatigue, sickness, etc etc)

Also, whilst it is not true to say that RPA projects do not require infrastructure or licenses are any of those other CAPEX things we talked about before – they do. However, the way in which the CAPEX is consumed is different. Licenses may be purchased as required, as more robots are brought online servicing more automations. This means that the cost base grows more organically as the ROI increases.

More than likely your RPA project will require some technical expertise in order to get it off the ground. Whether you have chosen UIPath or BluePrism or Pega or whomever as the RPA technology provider, you are going to need some setup and knowledge transfer and consultancy to start creating your automations. But here’s the winner.

Because RPA technologies are used to automate existing interfaces and tooling, your existing staff who do that, sit with your RPA consultant and create the automation together. No lengthy educational lead time bringing your automation consultant up to speed.

No disempowerment of your staff as they are front and centre in the automation transformation. This means quicker more robust automation and helps to identify further opportunity.

In summary, the main differentiators are:

1) Faster ROI through joined up working between automation and existing process-oriented teams

2) Smaller CAPEX which is spent more organically

3) Less consultative (expensive) more collaborative (positive)

You still might not get to the promised land! But I guarantee the journey will be more exciting, there will be more to see and you won’t be disappointed when you arrive at your destination

Related Posts

Leave a reply