S03E07 Defining your process hierarchy

Sometimes you get these rare days where all of a sudden there is a blank space in your schedule and even though you still have a ton of things to do, you also get the opportunity to reflect a little on what has happened over the last few weeks and what kind of #BPM topics have come across your desk. Needless to say that I deal with a lot of BPM topics, because for one, it’s my job and besides that I love this topic. Nevertheless, there was one topic that popped up more than once at various different clients, and that is how to deal with structuring your process hierarchy. 

So, let’s dive into that one in this episode of the Process Extraordinary Newsletter. 

What is a process hierarchy?

First and foremost, let’s define this and one of the most important topics here is the naming. Some people call it a process hierarchy, others call it a process framework and even some people call it a process structure, however it all comes down to the same very thing: a process hierarchy is a structured approach to collect and sort the various domains, sub domains and single business processes in order to be able to describe the way of working of your organisation with a minimum (preferably no) redundancy. 

As this is quite the statement, let’s unpack it. 

First it deals with a structured approach and this is also the most complicated topic. The challenge that organisations have to deal with is that all of the content that you document using a BPM tool has two purposes: 

(1) It needs to be created / maintain

(2) It needs to be consumed

The audiences for these two purposes are significantly different. The creation/maintenance purpose is the playground for process experts and modellers. They like functionality to do their job as efficiently as possible. The consumption purpose is the playground for virtually everybody else. They like simplicity, a clean UI/UIX and as little clicks as possible to get to the gold nuggets of information. 

One other thing we learned along the way as a profession is that the expert audience loves functionally decomposed process hierarchies and that the consumers really don’t. This puts the BPM CoE often in a pretty tight spot because how do you keep both audiences happy? 

One way of solving this is to make sure that you cater to the needs and preferences of both and this means that you need two hierarchies: one functional process hierarchy and one hierarchy that is much simpler and based on end to end processes (as non-technical users tend to recognise themselves easier in an end to end process compared to a functional sub-domain). 

Given the fact that end to end processes are built up from stringing together individual business processes and these business processes are created and maintained in a functional decomposed hierarchy, I always advise to start with the functional process hierarchy. And the good news here is that you don’t have to invent this anymore, plus it’s more or less the same for most of the companies in the world. Mind you, I’m talking about the hierarchy here, not the content of the individual business processes (there will be difference there of course, next to some really standard business processes, but that will be an entirely different episode). 

So, the functional hierarchy basically breaks down your organisation by function. Every organisation in the world needs Purchasing, Human Resources (debatable though… just kidding), IT and many more. The good news is that organisations like APQC and most of the management consultancy companies like Deloitte, KPMG and more have already gone through this exercise a million times before and have ready made process hierarchies available. This doesn’t mean that these are a 100% for your organisation but the fit will typically be more than 75-80% and where you differ, you adjust the hierarchy to suit your needs. 

Where it becomes more difficult is when you arrive at the level of the business processes. Here, most of these predefined frameworks draw sort of a blank. They do have standardised processes (and in some cases these are sufficient) and for the rest it is up to you (as it should be because you know your own business best). 

Below you’ll find an example on how this should look like conceptually. 

Making a long story short(er), once you have finalised your functional process hierarchy and have defined most of your business processes, you can now start to look at your end to end hierarchy. Fortunately, this is a lot less work and more straightforward compared to the functional process hierarchy. In many functional domains (but not all) you will be able to define so-called end to end processes. The fun part though about these end to ends is that they never really belong to just one functional domain, do they? Let’s take the most used end to end in the history of BPM: Procure to Pay. 

This end to end starts in the business where a purchase requisition is created and you could argue that creating a purchase requisition is part of the functional domain of Purchasing (and I would agree with you). Next up the creation of the purchase order (still Purchasing). The water becomes mirkier when it comes to the goods receipt stage. Is this still functionally speaking Purchasing or did we cross into Warehouse Management (can be both I would say), but there is no debate about the whole Accounts Payable part of this end to end process. That belong to the Finance function (at least to 99% of the finance managers).

This means that when you are thinking about setting up a end to end hierarchy in order to maintain your end to end processes, you will need to decide to what main functional domain each of the end to ends belong and maintain them accordingly. You now have successfully put the v-model for the process hierarchy in place (see picture below). 

Let me stop it here, as I don’t want to confuse you all more than necessary on a Friday. 

Ciao, Caspar