Is process modeling redundant? A necessary evil? Or a blessing in disguise?
The reputation process modeling (or documentation) has enjoyed (or, better, endured) can best be described as a rollercoaster: A slow rise, a quick fall and a lot of ups and downs. The question is, do you still need it?
In this monthly edition of my blog, I would like to jump to the aid of process documentation and explain why I (and Software AG) believe that it is a blessing in disguise (although it can also be perceived as a necessary evil!).
The path to bigger and better things
I believe the most common mistake around process modeling is to treat it as a goal, rather than a path leading to something bigger. Unless you are a process modeling aficionado, you document your business processes because it contributes to a greater level of transparency and stability in your organization. Yet, process documentation is often seen as a one-off activity that is needed to satisfy the requirements of a larger project (like ERP projects, since they lean very heavily on processes). I would argue that, on the contrary, once the ERP project has finished, the repository of business processes will help your organization to stay in control amid the many changes that will be requested after go-live. For my full blog on this topic, please go here.
The dichotomy of process modeling
Process modeling serves two purposes, and they both need to be considered when you are starting up your process documentation efforts. The challenge of process documentation is that, after you have created it, it needs to be maintained and consumed. These two purposes can sometimes pose conflicting requirements to the modelers. If you are tasked with maintaining process documentation then you want it to be structured, predictable and consistent. But this does not automatically mean that the end users like to consume this information in this form or shape. Structured and predictable often is perceived as dull and boring and hence does not help your adoption efforts. In the full blog (found here) you can read about a way to mitigate that.
Start small and scale up
Documenting business processes very often starts very small - and that’s perfectly fine. But when this becomes successful it sometimes needs to scale up quickly. Before you know it, you are trying to manage a large community of process modelers, and this can be a daunting task. How do you make sure that they all stick to the modeling conventions or the process taxonomy structure? Are they all using the split and join rules in the same way? These are questions that can keep every BPM manager up at night. Another dynamic is that the way that your process modeling is organized bounces up and down between centralized and de-centralized. This happens without you realizing that there’s also something like the hybrid model, which tries to capture the pro’s from the other two types of organizing your modeling without the con’s. Read more about this here.
Governing your process modeling
Having various employees documenting business processes in a consistent and structured way is one thing. But making sure that the created documentation (process model) is reviewed, approved, and owned is a completely different challenge. This is the realm of process governance, and this branches out to each nook and cranny in your organization. The ownership of the content (the process documentation) always must lie with the responsible process owners (and never with the BPM group), after all it concerns their business processes (and the subsequent execution of them). Want to know more? Please continue here.
To learn more about ARIS Process Modeling, click below.