Why Not Automate More Processes?

A personal perspective from James Simpson of Solvexia Business Process Automation.

It has been common knowledge for over 150 years that you can raise the productivity of a business by using machines alongside people to complete work. It is also common knowledge that most businesses are competing (in part) on the basis of productivity. These axioms do not apply only to physical manufacturing, but also service industries, including those that primarily manage information as their currency of trade.

man working machineOddly, however, many businesses that have a stake in the “information economy” don’t automate the processes they use to manage information. They have investments in large ERP, CRM and specialised product systems, often costing millions; however, a large number of people in these businesses are still spending a lot of time manually copying, cutting, pasting, formatting, merging, aggregating etc… data in spread sheets and other file types.

Some examples of processes that I seen in the past month that are using people, not machines, include:

  • International and inter-subsidiary costing
  • Calculation of portfolio positions for exchange traded assets
  • The preparation of superannuation reporting for APRA

If I were to take a broader time period, say 6 months, this list would be 10 times as long. Each of the processes above were being driven by ‘manual labour’ (i.e. people using Excel spreadsheets). They were all taking more than 6 person-days in a month and had significant consequences if a cut-n-paste error slipped in. All of these processes were flagged as ‘essential intellectual property’ for the organisation; but there was no reliably accurate documentation for them (yep, this essential IP was in someone’s head!).

Now, these are smart people in what you would otherwise regard as modern and sophisticated businesses. I decided to ask a few questions and take a look at why they choose to do so many data intensive processes ‘by hand’ instead of automating them. Full disclosure – I am interested in this topic because we build and sell an automation service to solve these problems.

The question I asked was: “Why don’t you automate more of your processes?” (With the implied question being “surely you understand that the benefits would be huge?”) The answers I got could (and may well) take several articles to fully describe, but, in summary:

So, what’s holding businesses back from automating data intensive processes?

The ScreamWhat I found was surprising. While there were several reasons, one of the most prominent was the IT Department was a blocking factor. There was also quite a degree of pent up frustration when the IT Department was mentioned, with just a hint of derision, and maybe a dash of resignation and despair in equal measure.

Now, I come from a technology background, and have been raised to believe that technology can solve anything and everything. I am quite at home in the IT Department, and with the people who make up this group – so this was a little confrontational. Why was the IT Department perceived as a blocking factor when it comes to the automation of business process? I asked more questions – and have grouped the answers into four types of responses below:

  • The IT Department does not have the resources to deliver a solution in the time window that the business needs to work in. The automation of the process is recognised not to be a ‘once off’ event, instead, as the business changes, the automation will need to change with it. Apart from not having the resources to get the process automated quickly in the first place – they certainly do not have the resources to alter or adjust an automated process within the 24 hour response time that the business says it needs.
  • The IT Department insists on a large ‘uber project’ to solve the problem. This manifests itself as either the need to adhere to an existing ‘strategic direction’ or ‘architecture’ based on using product X (where product X was something like SAP, Oracle financial or similar large ERP investment). When I dug into this issue, at first I was sympathetic to the IT cause. The IT guys after all are responsible for shepherding an organisation towards viable and cost effective technology outcomes through a carefully thought through architecture and strategy. However, as I heard more, the sympathy was replaced with maybe a little empathy for the client’s frustrations. They were not only missing out on getting process automation outcomes, they were not getting the other outcomes the ‘uber-project’ was supposed to deliver. This meant that a faltering strategy was blocking the automation of processes.
  • The IT Department’s proposed solutions are too expensive – making it an uneconomic project. In some cases the IT Department was very willing to take on the automation project, and to do it immediately, however they insisted in the use of a technology option that either (a) was expensive in itself or (b) required a lot of labour hours to deliver, and therefore it becomes expensive via the IT ‘charge back’ mechanism.
  • It is on the IT Department’s plan to be solved in the year 2050 – you will have to wait. OK, 2050 was an slight exaggeration, but you get the idea. In this explanation, the IT Department has a project ‘penciled in’ to start at some date in the future, and consequently, any other initiative to get processes automated is viewed as redundant/wasteful/a duplication of projects. The business client will just have to wait. This is really a combination of the two items above – “we don’t have the resources to do it now” + “we already have a project for that”.

Does it have to be this way ?

A leading question maybe, but no, I don’t think it has to be this way. A large part of this will come down to the personalities and professional disposition of those in charge of the IT Department – and whether they can see past these obstacles. There are however some approaches we can take (we being people in either business or IT) that can help start useful conversations that can help organisations get past these blocking factors:

  • Look for solutions that are ‘self-service’ : It is inevitable that any process you automated today will need to be changed in a month or two. The rate of business change has become a cliché, which makes it all the more surprising that the need for rapid adaptation is so ignored in the IT world. There are technology solutions that can support being configured by the people at the frontline, who own and drive the business process. It doesn’t have to be IT that implements these changes. This is a form of decentralisation – which can present challenges to people who fear a loss of control. However, it is the only pragmatic way businesses can innovate and adapt with speed.
  • Position automation as something that should be lightweight, non-intrusive and flexible depending on the organisation. This might be counter-cultural; however, not all technology solutions need to be ‘big’ in terms of their implementation, cost and bearing on the business that adopts them. Communicating (and maybe challenging) the idea that large projects are not the only way to service business needs is the first step to opening up a wide range of possibilities – not just for business process automation – but for all sort of opportunities.
  • Look for solutions that are pay-as-you-go or pay-for-use. Projects that entail large up front capital costs will continue to be part of the landscape. However, they will have to share that landscape with projects that offer an alternative economic profile. This alternate profile is characterised by low or no upfront capital costs, licensing fees based on a subscription model, metered by actual usage. Importantly, if the service stops being beneficial, you can stop the expenditure without have a large depreciating capital asset on the books (as big ERP/CRM projects often become). This is the world of ‘software as a service’ and it is more of a pricing and economic change than a technical change.

None of the suggestions above offer a ‘quick fix’. These are all ways to begin conversations with the IT Department that will play out over weeks, months and maybe even years in some organisations. In some organisations these conversations might simply change the selection criteria that are used when choosing solutions, or allow more alternatives to be considered. In some organisations, they might be either the catalyst or fuel for sustain cultural change when it comes to how the IT Department seeks to support the business.

Either outcome would allow us to get on with the job of automating more of our data intensive business processes.

Leave a comment