With the business case approved, and process selection complete a process deep dive is conducted. This stage has several objectives;
mapping the process end-to-end
establishing data inputs (source and structure)
determining the complexity
identifying the technology requirements and RPA+ elements
To ensure the process map is captured accurately, it is essential to conduct this exercise at the end-users desktop, in their environment and in partnership with the staff member who undertakes this task. I’ve seen examples where, for example, a Service Manager has been responsible for working with the automation team to capture the process, only for the result to be inaccurate and not a true reflection of the real-world situation. It is also important not to rely on outdated Standard Operating Processes (SOPs) even if these are up-to-date an SOP will not record the many subconscious decisions, or logic staff apply to any process.
Engaging with front-line staff at the ‘coal face’ to conduct a process deep dive is only possible where the organisation culture portrays automation technology as open, honest and in a supportive way.
So how do we conduct a process deep-dive? With some experimentation, I have made it as straightforward a possible. Using Microsoft Teams, we record the session (both video and audio in high definition), and this is used as a constant reference as we work through the automation development life-cycle.
Mapping the process end-to-end
For the first pass through, we ask the staff member to do the process end-to-end in real-time speed while we watch in silence. The main reason for this is we want to capture some current timings to accurately see how much time will be saved.
For the second pass through, we go through each staff step-by-step slowly, asking questions, determining what decisions are being made, any process variations depending upon inputs and asking what happens when things go wrong. This provides us with enough data and information to move onto stage 3 and to develop the Process Definition Document.
Establishing data inputs (source and structure)
During the deep dive, it is essential to identify the data sources being used. Are they structured, semi-structured or unstructured? Do all the required inputs come from a single email, a word document or several clinical systems? It is also here where we discuss the ‘trigger’ for work. What event will tell the virtual worker to start the process?
Determining the complexity
The deep dive allows us to assess the complexity of automation. How many systems do we need to access? Are they smart card enabled? Does the process need to be run within a specific time limit? Is there a clinical risk associated with this process that will require sign off from our clinical safety officer?
Identifying the technology requirements and RPA+ elements
Do we need RPA+ components such as OCR, e-forms or maybe some cognitive features? Are there any new technical challenges that we haven’t seen before, such as the use of a physical smartcard?
The final part of the deep dive process probably breaks all the RPA development blueprints. For any applications for which we do not hold any pre-written objects in our library, we briefly write an object or two in our development environment. This helps us pre-empt any application challenges (for example, the need for a java bridge, surface automation, or just having to deal a lousy application).