After consulting on, teaching, designing, building, and delivering countless business automation solutions over a number of years, we thought it might be valuable to share some wisdom with the wider community.
In this post we look at some simple strategies to help reign in sprawling business automation projects, and incrementally automate, measure, and evolve them.
Imagine business processes as the steps performed throughout the organisation to achieve a given outcome. The first step towards that goal should therefore replicate existing processes — delivering human tasks throughout — asking staff to check and act on external systems, interfaces, and applications in the same way that they might have done in the past.
While this approach might sound like a step backwards, there is a major benefit — you can roll out the process design quickly. Over time, each human task can be reviewed, and integration opportunities explored.
Do we assist the user for a given task — fetching information to support a decision, for example — or do we replace the human entirely? Building scaffolding affords the opportunity to start along the road before the vehicle is perfected.
Integrations take time to build and test. While you’re waiting for them, why not start getting the staff used to having a task list that guides them through their day? You’ll immediately lower training, because tasks can include links to guidance (time to start writing that Wiki!).
The “blue sky” end goal is often to remove humans from processes as much as possible. In our experience this is dangerous. Humans are really good at some tasks — better than a computer will ever be. Conversely, computers are excellent at other tasks, so it pays to play to the strengths of each actor in your bigger picture.
As mentioned previously — why not use integrations to take the drudgery away from repetitive work, and compile information for humans to review — allowing them to make informed decisions, and steer processes forwards.
RPA stands for “Robotic Process Automation”. It has come to refer to the process of teaching a workflow engine to control an external application in the same way that a human might — by reading the screen, inputting data into on-screen forms, and clicking buttons. There is a tremendous temptation to think of it as a hammer for every nail.
To illustrate the problem, we’ll pose a question: how does the autopilot on an Airbus fly the plane? It turns out it’s connected directly to the navigation system, the planning system, and the flight controls. RPA doesn’t work like that — RPA tries to build a robotic pilot that reads the instruments, interprets them, moves the controls, flicks the switches, presses the pedals, and makes decisions based on the results. To do this, it needs to know where the controls are, how to manipulate them, when they can be manipulated, in what order to manipulate them, what to monitor while waiting to manipulate them, and so on. It’s deceptively difficult, and rarely works well.
There’s a reason computer systems have APIs (application programming interfaces) — so other computer systems can talk to them both quickly and efficiently. Where APIs don’t exist, RPA can be considered — but only for simple tasks. Just imagine what happens when a user interface changes.
If a process design is complex, ask yourself why. Can it be broken down? Does the workflow engine really need to do all of the work? If a decision point is complex, is it better served by a human? We are still much better at making decisions than computers — especially when experience, knowledge, and judgement are factors.
There’s a great temptation to build “if this, and this, or that, or the other, then maybe this, but sometimes that” rules into process designs. Not only do the processes become hard to test, they become almost impossible to maintain in the future.
Complex decisions are often the result of inheritance. In the distant past the business may have done something in a certain way — and that has been carried foward, adding further rules and considerations over time rather than stepping back and re-thinking the entire approach.
It’s enlightening to step back and ask “why do we do it this way?” — very often either nobody knows, or the best answer available is “because we always have”.
Business processes can be thought of as streams of automated sequential actions. If a process is punctuated by a lengthy hold — waiting for the expiration of a contract, for example — it makes sense to end the process at that point and build a separate process to check for the conditions through which a related process should initiate.
There are operational benefits to chopping up longer processes. Most processes pick up data along their run that governs future decisions — and unless designed to do so, will afford no opportunities to change that data. If a longer process is segmented, each stop and start point becomes an opportunity for the process to see the world anew.
Perhaps the most obvious reason to break a process up is to launch it faster. It makes sense that it takes less time to agree on the first few steps of a process, than on an entire process. In the real world you might think in terms of teams or departments — and break a process as it leaves or enters different parts of the business.
We have all sat in inter-departmental meetings, where teams struggle to appreciate each other’s concerns. It therefore makes sense to break processes into realms of knowledge and expertise — allowing subject matter experts to concentrate on their part of wider solutions.
There is an opportunity to implement “just in time development” of processes — where you only work on the next piece of process required — divorcing yourself of the need to design, plan, and test an “all up” organisation-wide concept.
It doesn’t matter that instances of business processes might run off the end of their track either — they can be picked up when the next part of their process is finished and launched on their way.
If you have to change an operational process design, you may have to re-deploy all existing instances of the process to inherit the changes — stopping them, starting them, and navigating them to the point they had already reached. A segmented design allows any part of a larger process to be swapped out — allowing in-place evolution and adaptation.
Breaking processes up introduces natural measurement points — allowing you to compile data on the performance of smaller parts of larger workloads. If those sections are related to specific areas of the business, you can then concentrate on removing bottlenecks, focusing resources, and so on. You might also engage in alpha/beta testing of alternative process designs — measuring their effectiveness against one another.
Hopefully we have provided food for thought. It’s tempting to see complex systems as tangled labyrinths and attempts to introduce automation can seem daunting. Breaking problems down allows us to understand them, to improve them, and to innovate — transforming the way the business operates from within.
Business automation and process design can seem like a jungle at times – we have both the experience and the skills to help you navigate through it.
In the new year Microsoft is implementing changes to their Enterprise Agreements (EA) which are set to impact how businesses manage their Microsoft software and services, particularly for those using cloud-based solutions. The changes are in line with Microsoft’s broader business strategy to streamline licensing and emphasise subscription-based models.
Before Copilot, our Sales Specialists, like Jamie Cronk, had to balance customer calls, detailed note-taking, and proposal creation, which was time-consuming and prone to human error. By using Copilot in Teams and Word, our Sales team have reported a really satisfying increase in productivity and accuracy.
