There is plenty written about the importance of proper
Business Process Management (BPM), the relevance of BPM Suites (BPMS), and the difference between cloud BPM Suites (i.e
Flokzu ) and on-premise BPM Suites (i.e
INTEGRADOC ). There is also plenty written about the dichotomy between automating processes as they are ("As Is") or applying re-engineering to improve them prior to automation ("Should Be").
However, very little has been written about the absolute importance of simplifying processes prior to automation. In business jargon, KISS usually refers to keeping it simple, stupid. In this post, we'll see why it's really foolish failing to simplify processes prior to automation and how this foolishness can cause million-dollar projects to sink.
Just an example of a (simple) BPMN diagram:
» The 80/20 Rule
In business processes, as in almost any other field, the 80/20 rule applies. This means that 80% of the processes will be executed following 20% of the possible paths. In other words, no matter how complex our process model is, 80% of the time the processes will follow the same common path. We will call it the "basic path" of the process. And the rest of the possible ways, we will call "alternative ways".
At this point, it is convenient for the reader to know at least the basics of process modeling, and notation (Business Process Modeling Notation - BPMN, universal standard for this purpose). The 80/20 rule also applies in reverse. Modeling and automating the basic path will take 20% of the time. Considering, analyzing, and automating all the possible exceptions of the alternative paths will take 80% of the time.
Therefore, the first recommendation is to focus exclusively on the basic path, until it is working and adjusted. Only when the
business process management system is in production and adopted by users for the basic path will it be necessary to evaluate whether to automate (or not) the alternative paths.
» Fast Delivery
One of the most important elements when automating processes is being able to deliver results quickly. That is, to show stakeholders and detractors that automation is technically possible, economically feasible, and above all that it produces the business results sought. This is possible only if you focus initially on the basic paths.
When an automation project also attempts to automate all alternative paths, the instrumentation times skyrocket. Stakeholders get nervous. The results do not come. Sponsors begin to doubt. The team is demotivated. The counterparts get tired of endless meetings discussing improbable cases.
» Ensuring Quality
Testing and quality assurance of an automated process is a complex task. It involves simulating login with different users, who have different roles and permissions. For each user, verify that they can see the right information (and not more than it), and do the actions that their role allows them to do (and not more than they do). It also involves testing all possible combinations of routes. That is, testing all possible conditions to "visit" all stages of the process.
This can lead to huge case tables since the number of possible paths is multiplied at each stage by the number of outgoing routes. When we have a process that only contains the basic path, the number of users and stages is much smaller, so it is possible to perform much more effective testing and quality assurance. On the other hand, when the process has not been simplified, and in addition to the basic path of all possible alternative cases, it is extremely costly to carry out adequate quality assurance.
» Measuring the Automated Process
A fundamental aspect of the BPM discipline is to measure processes in order to improve them, using objective performance indicators (
Key Performance Indicators - KPI's). KPIs are direct and indirect indicators of how the process is working. Therefore, they should be as clear a measure as possible for the analyst in order to make decisions.
When the processes are very complex (they contain all the alternative paths), it is much more difficult to define KPI's that are simple to understand, as they are "contaminated" by exceptional cases, and avoid analyzing the process in question. By way of example, exceptional cases (which go down alternative paths) usually take much longer at each stage and require more analysis from each person working with them.
In addition, they tend not to be repeated, so they imply specific efforts and knowledge that the organization cannot take advantage of for similar cases in the future. Therefore, measuring these instances of exceptional processes that go down alternative paths, together with the instances of processes that follow basic paths, "contaminates" the indicators. The cases should be separated, which again implies more complex management of the KPIs, both in their definition, in their interpretation and in their subsequent maintenance.
» Conclusion
Simplifying business processes before automation is extremely important to maximize the chances of project success. Doing it correctly reduces the delivery times of the process, facilitates its adoption by the users, improves the quality of the software, and allows to measure with greater precision its execution using KPI's. If we add the simplification of the process itself, with the use of agile BPM tools, in the cloud that does not require coding; we will be able to put into production processes that really add value to the organization, in record time.
In our experience in
Flokzu Cloud BPM with more than 8000 organizations, it is those who simplify their processes before automating them, who obtain the best results. In short, Keep Your Processes Simple...!!
