In my previous post, I explored two different approaches that can be used to make a Business Process Management Software (BPMS) and a Robotic Process Automation (RPA) tool work together. This post expands on the same topic but from a different perspective. It uses process hierarchy as a reference to identify the tool that is better suited for each level.
A Process Hierarchy is a way to structure processes to ensure the value they provide can be measured and the process outputs align to the organizations business goals.
Source: LinkedIn
Process hierarchy is usually represented as a pyramid as shown in Figure 1.
Figure 1: Process Hierarchy Pyramid
Each level in the pyramid defines the granularity of processes in the hierarchy. Normally processes are divided into 5 levels in the hierarchy.
- Level 1: Process categories
- Level 2: Process groups
- Level 3: Processes
- Level 4: Sub-Processes
- Level 5: Standard Operating Procedures (SOPs) / Work Instructions
For simplicity, I have created another version of the process hierarchy as shown in Figure 2. In this simplified version Level 1 and Level 2 have been merged into a single layer, and Level 3 and Level 4 have been merged into a single layer.
Figure 2: Simplified Process Hierarchy Pyramid
Now let’s take a look at tools that you would be suited for each layer.
Level 1 + Level 2 (Value Chain)
Processes at this level are at a very high-level and there is not much automation that happens at this level. They are primarily used in reporting to senior management, so the purpose of this level is mostly for categorization, grouping and/or summarizing metrics of processes at lower levels.
Level 3 + Level 4 (Processes / Sub-Processes)
Processes in these two levels are also referred to as executable processes. These consist of processes and subprocesses that can actually be implemented. An example of this would be the end to end Order Management process. Automation of such end to end processes is best suited for a BPMS because they provide necessary tools to model, build, optimize and monitor long running processes.
Figure 3: Order Management Process
Level 5 (Standard Operating Procedures – SOPs)
This level consists of procedures or, work instructions that are created to help individuals navigate a screen, a system, perform a single activity. These are very detailed instructions and rules that list exact steps that a person needs to perform in order to complete a task.
Referring to the earlier example of order management process, once your process reaches the Ship Order activity, in a manual process a user will need to work on multiple systems to ship an order. Here is a quick list of different tasks that a user might need to perform.
- Login to order management system
- Search and open order details
- Login to the shipping vendor’s system
- Copy and paste all the required data from order management system to shipping system
- Ship the order and copy tracking number from shipping system back into order management system
- Log out and close the shipping system
- Mark order as shipped in order management system
- Log out and close the order management system
Compared to a BPMS, in this case, an RPA tool can be quickly and easily trained to automate these activities. So, instead of a human doing all the tasks, a trained bot can perform all the tasks.
Figure 4: Ship Order Activity
Conclusion
As I concluded in the previous post as well, in my opinion, BPMS and RPA are a great match, but you just have to make sure that you are using them for the right kind of use cases.
Share your thoughts on how you are planning to use BPMS and RPA in your organization. What opportunities or challenges do you see in implementing both together?