Sign up for my newsletter and receive my FREE white paper, “Preparing For Process Improvement: An Executive’s Guide To Setting Things Up So Your Process Improvement Efforts Succeed.”
Flexible Process Management (FPM) is a way to manage highly unpredictble and variable processes. FPM is very different from traditional Business Process Management (BPM). Here are the key differences.
There are several key differences between Business Process Management (BPM) and Flexible Process Management (FPM):
BPM attempts to control the process. It does this by defining it in advance. FPM doesn’t even try to control the process. It leaves the user to define it as it happens.
BPM reduces the need for judgment. The process designer builds all the decisions about what happens into the process. People just need to follow along. Not only can that be pretty soul destroying, it also creates a problem for the inevitable exceptions that crop up. If the process is rigid, what do you do when there is a set of circumstances the process cannot deal with? At the very least it can cause frustration of the “I-hate-this-stupid-system” kind.
FPM gives the user control over what tasks they do and what sequence to follow. One reason FPM can take hold quickly is that users realize they get more, not less, control over their working day with this approach. They get to route things to the right people when they see the need, without any software barriers preventing them from doing so.
BPM considers only one process at a time. This is a good perspective for the assembly line. In the real world, people are part of many processes at the same time. In effect, they work on many assembly lines. This creates all kinds of conflicts.
Instead of ignoring what people have to deal with, FPM embraces it. It assumes people work in multiple processes. And it provides a method to help manage the conflicts.
BPM is the software coder’s dream. It’s all about sequence and rules. The job of the coder is to build the process sequence into the application. But that needs customization or, in the case of off the shelf software, compromise during implementation. That’s why there is a lengthy, not to mention risky, period whenever a new application is installed.
There is software to support FPM. But the purpose is not to encapsulate the process. instead it is to make what is going on visible to all who need to see it. It allows for visibility, prioritization and accountability. FPM software apps are very lightweight and require no customization. It is simple and speedy to get going. And that means reduced cost and risk.
### No process diagrams
BPM is all about following a process. And that demands a process diagram. There is nothing wrong with process diagrams. I create them all the time. But they are difficult to create, keep up to date. It’s also very hard to ensure people follow them.
FPM does not attempt to pre-plan processes. So, there is no need for any process diagrams. People do not sit through tedious mapping sessions. An FPM project starts fast and finishes fast.
Both BPM and FPM have their place. The right tool to use depends on the nature of the process you want to fix. If it is routine and predictable, in other words a structured process, use Business Process Management. If not and it is an [unstructured process], Flexible Process Management is the way to go. Neither works well in the other’s space