Spotlight | Expert's opinion

Avoid these process modeling mistakes: Part 1 - it's not a business process

This article series gives you the dirt from the trenches. I have been active in process modeling for many years, and in this article series, I share my experience with you.

Confused man

As process analysts, business analysts, architects, we aim to create useful, easy-to-understand process models in order to bring clarity to the everyday operational mess and fire-fighting of problems.

Unfortunately, we must admit that this sometimes goes wrong. In my years as a business process specialist, I have noticed three kinds of mistakes. Learn from the mistakes I noticed (and made) so you don’t have to repeat them! In this installment of the series, I talk about the first category.

Problem 1: It is not a business process!

What is the problem?

In many cases, we see process models that don’t really describe a business process. Unfortunately, people use the words “business process” to identify many different things:

  • Departments like customer services or marketing are no business processes and cannot be modeled using a process modeling language.

  • Application (IT) processes like the “create policy” process often refer to low-level tasks that are implemented by an application, but they do not refer to the end-to-end business process.

  • Groups of processes like “manage vendors” are a typical set of processes that is used in procurement departments. Keep in mind that a set of processes is not the same as a process. If you try to model this in a modeling language you will need to seriously bend the rules…

  • Procedures and work instructions are often (mistakenly) considered as textual representations of the overall end-to-end process. Most of the time they just refer to how a specific task must be executed. Using the correct level of abstraction in your descriptions of processes is essential.

We use the following definition for a business process - a variant of Alec Sharp’s definition.

A business process is a collection of tasks that delivers an identifiable, countable and essential result and is initiated by an independent trigger. What’s more, a business process can be labeled with an action-verb noun.

Bad business process identification & scoping is a common mistake, with a few causes:

  • Bad Project Scope

    • The project scope was defined on a small part of the process – we didn’t have the right to dig deeper.

  • The use of standard frameworks

    • APQC’s PCF, ITIL or any other process framework was used to build the initial business process repository.  I’m sorry APQC (or ITIL) but just throwing a number of activities together doesn’t make them clear end-to-end business processes. There seems to be a huge mismatch between a BPMN process and the processes that are described in the PCF. In fact, we experienced these problems in whichever domain we tried to use PCF. I will expand on this in a future article.

  • Simply not knowing what a good, manageable, business process is

    • When we start on a project, my first question (“Do you have a list of all your processes”) is always answered smilingly – of course, we do. So, my next question is obvious: “Show me your processes”. What follows next is often interesting. Every stakeholder (IT, Board of directors, …) shows a different set of business processes, but most of the items on the list are no business processes.

  • Bad tool choice

    • Most of the time we get boxes and arrows in a PowerPoint presentation, sometimes a Visio file with boxes and arrows was shown, or a SharePoint site with a list of processes, work instructions & procedures, or an excel file with many rows and different versions.

How can you avoid this pitfall?

  • Take your time to identify and scope business processes before you start modeling.

  • Take into account the rules that make a good business process. For instance, make sure that there is a connection between the start event of your processes and the tasks that must be executed for that start event. Most of the time there should be a 1-1 relationship between the start event and the tasks. If the trigger of your process is the receipt of a job application – every activity in the process must be executed once per job application. And for each job application, we create a new process instance. Many other rules are discussed in our Ultimate BPMN Bootcamp Track.

  • Create a shared definition of what an end-to-end business process is, and how & where this end-to-end business process fits in the overall hierarchical process architecture or repository. Make sure your processes follow a strict naming convention and clearly focus on the results that the process must deliver. Processes like manage vendor, incident management, problem management, or appraise and develop suppliers are all bad end-to-end process names and are probably groups of processes.

  • Use suitable tooling. There are now many useful tools for modeling processes the correct way. Use them.

I’ll write another blog post about how to do this in the future so please stay tuned.

Start learning for free, no strings attached