Process Models are the Worst

It hurts me to write this, but it needs to be said. Process models are the worst.

But how can this be? Our most treasured analytical tool is somehow betraying all of us faithful followers?

Well, just like the legendary song Who Let the Dogs Out, what was once a purposeful novelty has now become as over-used as the rest of the soundtracks in our baseball stadiums.

All joke aside, process models continue to yield great power in analyzing our businesses. But today I’d like to address some increasingly common pitfalls when using our favorite tactic.

The Mighty Process Model

For our process minded community, its no surprise that modelling processes is one of the most popular activities in our analyses. Nothing screams pure joy more than mapping out tasks to discover hidden insights, of which even Indiana Jones would appreciate (Yes, I sadly equate discovering bottlenecks to uncovering lost Mayan treasures).

And the process model no doubt deserves this popularity. When done correctly, a single artifact can help define all the tasks, sequences, users, and systems related to a particular use case. That’s an amazing amount of information, somehow organized in a way to maximize your chances for analytical discovery.

How does a process model do this?

The key is utilizing a standard notation called BPMN. This helps define the symbols and conventions used to create these models, so that a task is always a task and swim-lanes are always used in the same way. This standardization is so powerful that two users on opposite ends of the Earth would still understand a BPM (Business Process Model) that was passed between the two. If only spoken language could achieve this!

The other key benefit to a process model is how it infuses logic into the complex and chaotic world of our businesses. The average employee is responsible for hundreds of tasks and is forced to multi-task for most of the day. If you were to take that person and ask her about a particular process, you most likely will be presented with paragraphs of information without any discernible order. That type of information is very hard to extract important bits to be used in improvements later on.

But by working through a particular function step by step, the resulting process model helps isolate exactly what is required for a particular outcome. This logical version of your chaotic business serves to help us identify things like:

1. There are five different teams supporting this one process. Perhaps we can eliminate some of these hand-offs?
2. Each task is done sequentially by one person. Can we do some of these in parallel?
3. The team is managing system errors at each point in the process. Can we deep dive into what are causing these?

These types of insights may have never been found without the mighty process model showing us the light.

With Great Power Comes Great Responsibility

So yes, process models are not inherently the worst. But they’ve become so popular these days that poor outcomes are often attributed to misuse and misunderstandings of BPMs.

For one, value isn’t created just because you finished your process model. Similar to how delivering analysis is not the goal, neither should be creating that model of yours. If you’ve ever walked away after “gifting” a process model to one of your clients, you may want to check back in and see if they were ever able to achieve their goal afterwards.

On top of that, some suffer from model reflex disorder (my completely made-up name). This is when folks enjoy process modelling so much that they dive into one on every single project. Looking to define a 5-year target operating model? Let’s build out a process model. Or looking to find a quick fix on a straightforward function? Another process model!

This is a self-spiraling issue, as more people see more BPMs created and then are more inclined to do this themselves. There is a time and place for when this methodology is useful. Batman has a utility belt full of different tools, and so should you.

A process model is not usually the best decision if:

• The activity is very straightforward and well defined
• The function is ad-hoc and random (a process has not yet been put in place)
• The scope of the project is extremely broad (a value chain would be more useful)
• Your client ALREADY HAS ONE

Ultimately, process modelling has achieved an aura of effectiveness that doesn’t always hold true. If you are on a project that is still struggling after your model is complete, take a look at some other major pitfalls that may shed some light on why process isn’t simply the holy grail of analysis.

Other Process Model Pitfalls

It Doesn’t Have All the Details

Process models show a huge amount of information, but not everything. Very rarely do I see BPMs with duration data (ie how long each task takes to complete) or stats on how often the happy path is followed versus an exception path. More importantly, the business context as to why certain tasks are performed is usually ascertained outside of the model. Good analysis produces a BPM with additional supporting details to explain the business around it.

It’s Not Actionable

Process models are not sets of requirements that someone can easily use to build a solution. Even if you have the ability to execute on what you’ve modeled, you will still need some backlog of user stories to help define exactly what the solution should be. If you found a bottleneck as an example, create an improved process but then also write down in bullets what needs to be done to eliminate this pain point. Don’t leave it up to someone else to interpret how to get from current to future state.

It’s at the Wrong Level of Detail

Determining the right detail level for your process model is usually make or break for your insight finding opportunity. Too detailed and you may get lost in what buttons the users are pushing or what color socks they are wearing. Too high level and you may be staring at two generic tasks with no sense of what to propose for the future state. Try focusing on outcomes to make sure that each artifact is at a level that at least you can use to build out solution requirements.

It has the Wrong Start and End

Sometimes the start and end your client speaks about is only a small part of the overall process. If you are only modelling a narrowly scoped set of tasks, you may never reveal the actual root cause of an issue. This then dooms you to propose solutions of limited value, as they become workarounds to the real issue either upstream or downstream from your “process.” Always remember to ask what the outcome of the process is from a value perspective (ie what is it trying to achieve). This will help frame the full picture, and ensure that you don’t miss out on major innovative opportunities.  

Final Thoughts

Ultimately, process modelling should be treated as much like an art as it is a science. Half the battle is knowing when is the right time to use it, and the other half is using it correctly.

Adding clarity and actionability to a client’s project is what all analysis should strive to do. Ensuring your process models are part of that story will make sure this great tool goes from worst to first!

Happy Modelling!