Process Risk Analysis (PRA) is a convenient tool for business process introspection and as a framework includes many of the common methods, including the Lean Six Sigma toolbelt. It not only helps identify areas of process improvement for today, and for the strategic future of a company, it is also a critical initial screening tool for digital transformation, especially when selecting a pilot project or initial process for implementation.
Digital Transformation (Dx) is "is the adoption of digital technology to transform services or businesses, through replacing non-digital or manual processes with digital processes or replacing older digital technology with newer digital technology." Since the baseline of transformation is the current state, and in this case the current state (pre-transformation) refers to the non-digital or manual processes, it stands to reason that these processes ought to be carefully examined before adding a digital component to their execution. In other words, we need to have a deep understanding of the current process, its constraints and limitations, and therein find the right implementation of Dx to realize true value.
However, most companies (from my anecdotal experience in speaking with many CIOs and heads of digital transformation) do not take the time to study the processes they wish to transform. Rather, pilot project processes are usually chosen based on their failure to achieve expected outcomes, with the idea that Dx will change everything. With this line of thinking, a poorly-performing process (i.e. inefficient, uncontrolled) is digitized and automated as a pilot project and everyone is shocked when the improvement is sub-par when, in fact, this should be expected.
What companies ought to do is perform PRA on their key processes (if not all of them). This will provide a much better idea of the right candidates for Dx pilot projects. It isn't always going to be the poor performers. In fact, I would argue that the real value of Dx should be clearly obvious when a well-operating manual/paper process is digitized.
In this article, I will lay out some considerations for PRA, and guide the reader to select the right process for a Dx pilot project or for the scope of initial implementation.
Considerations for process automation
Here are a few factors to consider when selecting the pilot process or initial scope for process automation. Note that this isn't a binary pass/fail scenario these are qualitative considerations to take into account and discuss internally.
Process Documentation
Is the process well documented and understood? If you ask five different users to explain the process, will you get the same answer from all five (I'll talk about process accuracy and precision later)?
Process Complexity
Is this a linear (A then B then C) process, or are there a lot of logic gates and decisions? How often does the process loopback or connect to other parts of the process? How many points of human input does the process have, and are they quantitative (e.g. enter the invoice number) or qualitative (enter the reason for request)?
What is the mean run time of a process? Is this a process that, in the manual state, has a run time of hours or days, or is it months? If an execution runs for months, how often does the process change? Does a process typically start and end on the same version?
Process Criticality
Is this a core profit-generating process or a support-services project? If the entire system shuts down for one day, what kind of bottom-line impact will it have on the company?
Process Integrations
How does this process impact up- or downstream processes? Does this process integrate with other software applications, customers, or suppliers?
Again, there is no right or wrong answer to these questions, but these are discussions that need to be had about each process being considered as a pilot project or initial scope for Dx. Once a few processes have been shortlisted for pilot project candidacy, we can move forward with looking at their accuracy and precision.
Process Accuracy and Precision
In line with Six Sigma methodologies, we can evaluate processes for accuracy and precision and use this knowledge to highlight processes that need improving.
Process Accuracy: A process is accurate if the end state of the process is always achieved.
Process Precision: A process is precise if the steps of the process are always followed.
Examples:
This is a documented process. If the actual execution of this process follows only the documented paths, and the end state is always "A", then the process is both accurate and precise.
This is a drawing showing a process that is both accurate and precise, meaning the executions follow the documented paths and the end state is always "A"This is a drawing showing a process that is both accurate and precise, meaning the executions follow the documented paths and the end state is always "A"
Accurate and Precise Process
This process is precise, but not accurate. This means that multiple users who follow all the steps as documented can end up with different outcomes. This usually indicates a problem with a specific task or decision, or often with an application used in the process.
This process is precise, as in users follow the documented steps correctly, but NOT accurate, meaning there are more outcomes possible than what is documented.This process is precise, as in users follow the documented steps correctly, but NOT accurate, meaning there are more outcomes possible than what is documented.
Precise and NOT accurate process
This process is NOT precise, but is accurate. This means users can use multiple ways to circumnavigate the documented process but still end up at the same result. This usually indicates waste, a lack of training, or a lack of proper documentation.
This is a process that is accurate, meaning user executions always end up in the correct end state, but not precise, meaning users have many ways of getting to the end state.This is a process that is accurate, meaning user executions always end up in the correct end state, but not precise, meaning users have many ways of getting to the end state.
Accurate but NOT precise process
This process is NOT accurate, and NOT precise. Clearly, there is no process discipline, users do whatever they want to do and get multiple results. This is chaos, and I hope it is only an academic concept and not a reality for any company. This indicates a lack of process definition, documentation, training and governance.
When we look at these models, it is sometimes easier to picture them in on a simple chart:
Once you have mapped your processes against the chart above, you can determine what steps need to be taken to prepare each process for Dx depending on the quadrant where it lies.
A: This is a mature, clearly defined process and is ready for digital transformation.
B: This process might be missing a checkpoint or might correctly reflect a tool in use. Since multiple outcomes are possible if a user follows all the process steps, determine which is the desirable outcome and create a process step to prevent the other outcomes. Then move this process into quadrant A.
C: Users can perform any number of steps outside the process, which means there isn't adequate training in the process and this most likely wastes time. Before training users to follow the documented process, have a team analyze why users are performing these extra steps or shortcuts. We might need to update the process to reflect what users are actually doing. Once this is done and the process is stable as documented, it can be moved into quadrant A.
D: This process needs definition, and user training. Do not try to automate such a process until it has moved into quadrant A.
This is the kind of in-depth analysis that needs to be be performed before implementing new technology and process automation, in order for digital transformation initiatives to be successful.
This high level overview shows you what needs to be done
but the details of how to quantitatively and qualitatively perform these analysis require a much more detailed study of process performance and auditing.