What is Process Discovery & Design and Why is it important for RPA?
The clue is in the title – to DISCOVER – and in a world determined by action and outcomes this needs to be the sharpest tool in your toolbox!
This article provides insights into the objectives and how best to approach this primary phase of the automation lifecycle and some top tips to make your own journey the most successful possible.
Journey of Discovery & Design
Process Discovery, Definition and Design are common enough terms that have been around for decades and are always being associated with the next new thing, but what exactly is process discovery and design, and what do they mean for your robotic process automations?
The Future of Work
A phrase often used to describe the revolutionary technological transformations taking place, which are changing the way businesses and people work today, for a better tomorrow. Robotic Process Automation (aka “RPA”), is one of the key drivers of “The Future of Work” and one of the fastest growing technologies in the world, with an estimated market value expected to exceed $25bn by 2027. The technology has proven successful across a broad spectrum of sectors, industries and functions, automating tasks from the simple and routine to the complex and curious. Despite this success, the ability to really scale RPA is still proving elusive for some, but why?
Research suggest that almost a third of UK businesses are behind when it comes to adopting new technologies, the majority of them being small to medium-sized companies (SMEs), who are either not aware of the true potential of RPA or are unsure how to approach it. Investing in new technology is sometimes a risk and requires a clear strategy with defined benefits before committing, as the cost of a wrong decision can be high.
This is where effective Process Discovery & Design comes in, to provide the critical insights into real opportunities for not only deploying automation to the parts of your business which would benefit most, but to also highlight obstacles, challenges and gaps within your processes and technologies that could block or enable your progress. So, Process Discovery & Design is an essential phase for any automation journey, and here’s how you should approach it.
Getting Started with Discovery
Process Discovery is, or should be, your introduction into the world of RPA and understanding the RPA Lifecycle. It gives you the chance to fully engage with your RPA experts to learn what RPA can and can’t do, address misconceptions and align expectations.
Discovery is the gradual process of identifying, considering and evaluating potential opportunities within your business, to produce a pipeline of process candidates that just might “fit the bill”. To properly identify suitable candidates for automation, you need to know what makes a process Robot friendly, which in real terms means being both technically feasible and operationally suitable. For starters, the best candidates for RPA hold true to these core attributes:
- Rule-based and logic-driven
- High degree of routine and repetition
- System applications involved are html or desktop-based
- Data is digital and well-structured
- High degree of system application stability
- High degree of process maturity
Conversely, these attributes make a process much less suitable for automation using RPA:
- High degrees of unpredictable judgement
- Unusual or even volatile frequency or occurrence
- Paper-based documents and non-digital data
- Unpredictable and unstructured data
- Unstable system applications
- Immature or temporary process maturity
However, just because these attributes make a process less suitable for RPA, doesn’t mean it’s not possible to automate them, it may just require a little more ingenuity and some more advanced automation technologies.
Relevant Reading: Process Automation Candidates
Discovering The Devil in the Detail
There’s no such thing as “too much detail” when it comes to understanding a process activity for automation. At this preliminary stage, when you’re working with your RPA team for the first time, there are a few essential questions you all really need to know the answers to:
- WHAT is the precise scope of the process you want to automate?
- WHAT are the major pain points that you have to deal with that the Robot must fix?
- WHAT is the primary benefit and purpose to achieve? (such as cost, productivity, quality, customer experience)
- WHEN does the process need to be automated by? (timelines)
- WHO are the key stakeholders of the process?
When you’re faced with answering questions like these, you may find yourself identifying even more process candidates for automation. And that’s not all, as your fascination with the technology grows, you’ll likely want to implement a robot for every conceivable task, including washing the dishes!
After defining these “What’s”, “Why’s”, “When’s” and “Who’s”, you can start thinking more scientifically about specific metrics of the process. These volumetrics of the process are used to calculate the average costs associated with currently performing the process manually and the potential benefits or savings from automation. You’re recommend to define the following at a minimum:
- Frequency of how often the process runs (daily/weekly/monthly)
- Volume per frequency (number of transactions completed each time)
- Average handling or processing time to complete
- Number of systems, applications and screens used
- Average % and time to review or audit the transactions
- Any process peaks, their frequency and volume?
- Error rate (%) encountered and the average rework handling time taken rectify
- Average number of Full Time Equivalent (FTE) people required to perform the process
- Average employee costs for those employees
Capturing this level of detail helps you to estimate and quantify the benefits to confirm if they outweigh the effort (and cost) required to deliver the automation, but it also allows you to order and prioritise your pipeline of different processes.
The most challenging part of this step is how to handle the more qualitative benefits, like customer experience, compliance, employee morale, business agility – it can be very difficult and subjective to determine a reasonable value for these. None the less, it may be very important to do so, especially if you’re required to justify technology projects financially based on their return on investment. Some companies approach this by simply ascertaining a standard cost value to each different intangible, others have a pre-defined company investment methodology. Whichever is yours, the importance of intangible benefits cannot be ignored, and they’re often far more important than the purely financial measures – after all, most customers don’t really care that you’ve reduced your operating cost by 3%, they just want a better service.
Next, we move on to the Process Definition & Design phase of the RPA Lifecycle.
Define & Design the Chosen One
Now that you’ve identified, evaluated and selected a suitable candidate for automation and straightened out what, why, when and who, next is the significantly important task of recording and capturing all of the details associated with the task or activity and how it is currently being performed (aka “As-Is”).
The most effective way is to arrange a Process Walkthrough meeting (or possibly a series of them, depending on size and complexity), in which the process subject matter experts and RPA team go through the full end-to-end process together. If you have access to process mining technology and believe this can capture the process adequately, then also consider starting there. And to keep things simple, you want to start by capturing what happens most often, most of the time (aka the “Happy Path”) to grasp an understanding of what the end-to-end process looks like. Further layers of complexity will then be added, as the numerous variables, issues and exceptions are teased out in performing certain tasks – and don’t forget to determine how those should be dealt with.
Every Process Walkthrough session should reveal the intimate details of the process down to keystrokes, showing every screen, mouse click, data field update, file accessed and action performed, from logging on to logging off and any important human thought processes involved that aren’t represented on a computer screen (especially system or process exceptions). From experience, process performers typically find themselves going into autopilot, rushing through and brushing over the critical keys to the process especially the parts which are less tangible or formal. So, be sure to slow things down, double-check, question and repeat to ensure nothing important is missed or overlooked.
Like everything with RPA, documenting processes properly is simple, but not always easy, but it can be straight-forward with the right experience and tools. It’s usually best to go with what you know, however, if you want to try something revolutionary but incredibly easy, give Skore digital mapping and analysis a try and replace the usual combination of applications and offline coordination. [Relevant Reading: How to Skore with RPA : Use Case ].
Once you’ve fully documented the current and detailed “As-Is” activities, it’s an important step to review with the process experts and people who perform the activities to ensure nothing has been missed or misrepresented, adding any changes or updates and finally getting their sign-off before proceeding with the next stage: To-Be Design.
This is where the excitement begins – designing the future “To-Be” automated solution for your process, because this is when you decide how and where the Robots work. At this stage, the “As-Is” process is thoroughly analysed by the RPA Team, with activities re-sequenced, reordered or revised to derive a streamlined and optimised operation. This is the time that the current process performers begin to learn what will be different in the future automated state of the process and what they will need to start, stop and continue doing differently than in the present.
The “To-Be” automated process design must very clearly define how exceptions and errors will be handled and handed off between people and Robots. You must also begin to formulate the business process continuity plans and support level requirements. The “To-Be” design also needs to be non-technical and from the current process performer perspective, so that they fully understand how and what the Robotic process will operate. A thorough review and sign-off is highly recommended before continuing on to the next stage, the Robotic Solution Architecture, but this essentially concludes the Process Discovery, Define and Design phase.
Your RPA Team can begin developing the technical solution designs at this point, and begin the process of setting up system access and permissions for the Robots and defining the test scenario and data requirements.
Bringing it together
Despite the RPA market boom and growing scale of adoption at pace, there are still a high proportion of businesses missing out on discovering their future of work using RPA. Therefore, it’s important for any businesses to at least consider and explore the opportunities that RPA might represent for them, and there’s no more effective way to start than with process discovery, definition and design, where you could gain incredible insight in to the art of your possible. You may uncover a wealth of automation opportunity that you never knew existed and find new ways to solve business pain points. Addressing and fixing these pains isn’t always easy, but that’s never been reason enough not to do something.
“The only impossible journey is the one you never begin.” – Tony Robbins
Other Relevant Reading: