Nitesh Naveen, Managing Consultants – Business Process Automation
1point21gws – Boutique tool agnostic RPA consulting firm
Robotic process automation (RPA) is evolving at a rapid pace, promising to deliver significant cost, performance and scalability benefits by automating redundant business processes. As with any new technology, adopting RPA requires investment of time and resources, as well as a commitment to change. Moving forward, the next stage of the journey is to carefully choose which processes are best suited for automation and has the potential to produce the most value.
Perhaps the hardest aspect of RPA is choosing which process to start with.
A recent survey by Redwood Software 300 corporate decision makers from the US and the UK founds “79% of enterprises said automation delivered time savings, 69% cited ‘improved business productivity’ as the key benefit of automation, [and] 61% said automation regularly provides cost savings.”
From these statistics, it’s obvious that robotic process automation (RPA) is capable of significantly driving operational improvements. But even though RPA has a wide range of automation abilities, some business operations are more suitable for automation than others. For example, it can be argued simpler processes should be considered first and more complex activities should only be automated once companies are more familiar with RPA. At the same time, companies are more likely to attain success when automating rules-based activities as compared to non-standardized, variable ones which are often difficult, if not impossible, to define within the limits of RPA software.
But what does this mean for companies considering automation? What kinds of processes should be automated in order to drive the most meaningful outcomes? In order to gain a clearer picture of what business activities are ideal for automation, let’s investigate few of the most relevant factors that can help organizations determine if a business process is well suited for automation and how it will benefit from RPA.
How to choose which process to automate first
A good way to get started with workflow management is to start with a small pilot project, to build up some local knowledge and experience before trying to use workflow management extensively. Although there may be several business processes that you would like to automate, you need to find the one that –
To choose a good business process to automate first, you make trade-offs between competing tensions. The ideal process is:
- Highly dependent on staff attention and involvement
- simple enough to be modeled quickly by one person, but
- complex enough to benefit from software support;
- relevant enough to the organisation that off-the-shelf software isn’t available, but
- generic enough to be understood throughout by all stakeholders;
- important enough that improvements deliver real benefits, but
- not so important that it would be too risky to use new techniques.
There are other dimensions to consider, but simplicity, relevance and complexity are enough to start with.
Many operational processes are suitable candidates for automation if they are: time-consuming; impacted by changes in transactional demand: and, most importantly, highly dependent on employee attention and involvement. Relevant activities in this area can include order and claims processing, data migration, or entering customer information into a database.
The same survey by Redwood Software suggests “99% of organizations still spend considerable personnel time doing repetitive manual tasks, with almost three quarters (74%) spending over a quarter of their time doing so.”
Automation of these manual activities means their execution will become quicker and less error prone. At the same time, employees who previously dedicated large amounts of time making sure that these activities were properly executed are now able to focus on more meaningful and innovative tasks like customer interaction.
The most obvious way to start is to start small. Choosing a simple process limits the scope of the pilot project, so you can get results quickly. To borrow a phrase from somewhere else, you’re looking for the Minimum Viable Process.
A process may be too complex because there is too many steps, for example, which mean you can get bogged down with all of the combinations of exceptions – things that can go wrong. Once a process has six or seven steps, say, then additional tasks and decisions probably won’t add anything to the pilot project, except more work.
A process may also be too complex because it involves too many people or even separate departments, which means more people involved in the pilot project. A better choice would be a business process that a single person can model. Again, what this process is depends on the organisation.
However, a process can also be too simple for a pilot project. The canonical example business process in Business Process Management (BPM) might just be the employee vacation request. This is probably too simple to benefit from software support, so the results of a pilot project to automate vacation requests won’t mean much. You might as well stick with that spreadsheet for now.
Relevance – specificity
An initial automated process must be relevant to the organisation: a process that is not organisation-specific, but which benefits from software support, is probably served by standard off-the-shelf software. Software developers in different organisations, for example, tend to use the same tools as other developers because their work is similar enough. Similarly, many finance processes are well served by standard accounting tools.
A business process is too specific or niche has a different problem: there may be too few people in the organisation who understand the process for the pilot project to be a good example. In a company that makes physical products, details of the manufacturing process might not mean anything to all of the workflow management stakeholders.
Most online businesses, service providers, and organizations do not have a defined set of opening hours, meaning a high volume of orders, requests, and complaints are received around the clock, regardless of weekends and holidays. When a company is entirely reliant on human employees, this workload can only be addressed when employees are present in the office. In comparison, RPA is the most efficient and productive tool to address these high volume tasks because the software robots are able to work24/7/365. Instead of being limited to working at a certain time of day or week, RPA software robots are able to tackle activities quickly and accurately even when employees are out of the office.
Standardization and Stability
RPA is best most suited for automating tasks that are highly definable and occur the same way every time. These activities are be rules-based, consistent, and data driven. On the other hand, RPA is not meant for automating tasks that are constantly changing, non-standardized, and unstable because they cannot be easily defined.
Considerations in this area should address whether the task takes places in the front office or in the back office. Back office tasks include, for example, claims processing, transaction duplication, or account opening automation. While front office automation is possible, back office tasks tend to be more transactional and repetitive, making them more suitable for automation. Activities that occur in the front office, on the other hand, tend to revolve around complex thinking, judgment, and decision-making skills. Front office tasks, such as marketing, tend to be more variable and inconsistent, so they are more challenging to define within RPA software.
Difficulty of Outsourcing
Many business activities, especially in financial services, require a high level of regulatory compliance. This kind of security is often difficult to achieve and maintain with offshoring because companies have a lesser degree of oversight and direct control when processes are managed by a BPO provider. As an alternative to outsourcing, RPA allows businesses to be in control of executing their own transactions internally and can enable organizations to develop more robust compliance strategies.
Many RPA software robots are able to save their actions into an activity log that can later be monitored and reviewed. This log file can help employees identify the root cause of exceptions, offers the ability to produce detailed analytics, enables compliance with industry/governmental regulations, and provides the critical information that is needed in case of an audit.
Importance – business value
The process’ importance to the organisation – its business value – is a bigger factor than simplicity or relevance, but is easy to overlook. But it is important. There’s no point automating an organisation-specific process that’s just the right size and complexity if the process results aren’t important enough to justify the effort. For example, a workflow for organising office parties is likely to be too far down the list of priorities for senior management to pay much attention to the pilot project’s results.
The most important processes tend to be those related to core business, and getting paid, in particular. However, these aren’t necessarily a good choice for a first automation either, because the risks of mistakes and teething troubles with a new process implementation may be unacceptable. To the extent that the first process automation project is a learning exercise, it makes sense to choose a process where you can tolerate and easily correct mistakes.
Given the contradictory requirements, choosing a first business process to automate seems like a daunting task, but there are some common patterns. In particular, the size of the organisation provides the first clue about where to look.
For small organisations that operate as a single business unit and department, good choices tend to be core business processes. In large organisations, the core business process tend to span too many parts of the organisation to be a good choice: instead, look for support processes that are the ‘core business’ of a single department, such as personnel (HR) management.
Two great examples of suitable HR processes for a workflow management pilot are:
- hiring employees
- on-boarding new hires.
As well as being likely to satisfy the requirements for simplicity, relevance and importance, these processes have other advantages for demonstrating process automation.
- They are long-running, so coordination over a long period is useful.
- The work involves a number of people, so collaboration and task assignment benefits from software support.
- They are relatively low-volume, so there is more time to make process improvements between cases.
These two finance examples are also both parts of a larger process that you can split in order to choose a balance between simplicity and complexity:
- customer invoicing
- chasing late payments.
Of course, perhaps the best way to get management support for workflow initiatives is to provide workflow support for their own work. A simple management process often takes the form of a:
- management approval– such as a purchase order or report sign-off
The challenge with management approval workflows is to pick one with a good balance of simplicity and complexity. The work ideally involves at least one other person, and one or more tasks that time to complete.
What to do after selecting potential processes?
Define the processes
This is the obvious step after selecting potential processes. After all, you can’t automate a process if you haven’t defined it in the first place.
To start off, get the people who know the processes, aptly named the Subject Matter Experts aka SMEs, in the same room and get them to help you to define the process.
It is important to first define the start and end of the process. For example, the recruitment process can start when the need for a new employee is realized, the position is advertised, or the first interview starts. Similarly, it can end when the last interview ends, the decision to extend an offer is made, an offer is accepted, a new employee starts their first day at the office, or they are considered a productive member of the team. Defining the start and end points early help focus the conversation.
Let’s say the recruitment process ends up only looking at the interviews: the process starts when the first interview starts and ends when the last interview ends. There are a lot of things left out of the scope which will not be looked at at all. This might sound harsh, but it helps the team focus their time and efforts on what they deemed to be the core of the process – all other things are outside of the scope and not considered.
At the end of this part there should be a detailed process map document written down.
Observe the process in action
Go back and observe people follow the process. Amend the document where needed. This is crucial. Very often there are two processes in place: the official one people say they follow, and the unofficial one they actually follow. You want to make decisions based on the actual process in place, not the official process, which might not be followed. The practical process is the one actually affecting people’s everyday life, not the unused one.
Improve the process
Next take what you’ve seen and heard and see if you could make it better. Identify bottlenecks and problem areas. Streamline the process where possible. Identify parts which can be speeded up or performed congruently instead of linearly. Define time standards for how long to wait for responses and reactions, for example when chasing a new sale, and escalation triggers for when to pass responsibility on to a higher up, for example in customer support cases. Identify whether the process or any part of it could be automated.
Iterate with the Subject Matter Experts
Get back together with the SMEs and introduce the improved process map to them. Get feedback and reiterate it together with them to make it better.
Have the SMEs write the final version of the document as a standard operation procedure document, which can be used when training new people in the future.
If any part of the process is to be automated, start the automation process.
In the end, even if the process ends up not being automated at all, it is now defined better, people do it the same way, and thus it is most likely more efficient and pleasant for the people working it. You also have a better idea about what kind of processes are fit for automation and what aren’t.
To discuss more with our consultant, please email me at Nitesh@1point21gws.info
Visit us: https://1point21gws.com/consulting/rpa/