One of the topics that always pops up when I discuss the principles behind BPM with our clients is that of the process hierarchy, or sometimes called process taxonomy. It is the way you have organized your business processes in a layered or nested structure. Quite often I resort to the analogy of sorting LEGO bricks. Imagine you have a large pile of unsorted LEGO bricks and you want to build all the sets from the LEGO City collection (think about the police station, the fire station, the train station etc). All the bricks you need are in the pile, but finding the right brick can take forever. Even if you scan the entire pile of bricks and apply AI to it, you would still only be capable of quickly determining if the right brick is in the pile, but it will be quite difficult to pin-point the right location.
So, what do most experienced LEGO builders do? The first sort the pile into smaller piles (I used to do this using old shoe boxes) and they can do this either by color, or by function or by format/size. Let’s suppose we sort by color first, this still leaves quite a potential big pile of colored bricks. So, we keep on sorting and divide the colored piles into smaller piles (for example all blue windows in one place, all blue wheels in another place and so on and so forth. In the end, we have a collection of small piles in which we can find the bricks we are looking for relatively quickly.
Now, back to processes and let’s work from the assumption that a single business process is basically the same as a LEGO brick. Why? Well, let’s look at how we built a LEGO set. If you want to built the LEGO Titanic you need to select specific LEGO bricks in sequence and put them together in a very specific sequence. If we state that an end to end process (i.e. procure to pay) is also a collection of very specific processes (=LEGO bricks) put together in a very specific sequence, then we can conclude that this analogy still holds strong.
So, let’s start building our collection of small LEGO bricks piles called the process hierarchy. General knowledge and experience tells us to first set up a purely functional decomposition of your process hierarchy. In other words, you start with level 1 aka the main functional domains. Nothing spectacular, just a list of 10-15 functional domains such as Finance, HR, Marketing & Sales, Purchasing, Quality Management, IT, R&D, BPM etc. Each one of these main domains is usually owned by one global process owner.
On Level 2 you will then find one or more layers of sub-domains. For example, the purchasing domain will break into smaller sub-domains called Sourcing, Procurement, Vendor Management and maybe more. Procurement can then further be decomposed into Requisitioning and Ordering. Once you hit the level where you can define actual business processes (for example, Create purchase order) you have reached level 3. Your process hierarchy is basically the combination of level 1 and level 2. Sometimes, you will also see a level 0, which can be called the Process Map, or Process House and this contains a combination of all main domains and the major end to end processes in a graphical appealing way.
What happens very often is that the BPM principles are implemented or re-invigorated by larger transformation programs. Think about ERP transformations or other seismic change initiatives within the organization. It is only natural and logical that you look at the best practices that the ERP vendor provides. Examples are the S4 best practice framework from SAP, or the collection of processes that Microsoft provides for its Dynamics 365 platform. These best practices can give you a head start when it comes to setting up and populating a process hierarchy, no doubt about that. There is however one thing that still puzzles me greatly.
Over the course of the last years, there has been a trend to start referring to the main functional domains with terminology that suggests a more end to end perspective. For example, in stead of calling something Purchasing, it is now called Source to Pay. In and by itself, this is not a big issue, but I do feel compelled to highlight some issues that might arise because of it:
- Source to Pay as a level 1 main domain suggests that you will find all processes in this part of the hierarchy that are covered by this end to end process. So, this would include spend analysis, contract management, requisitioning, ordering, good receipt and invoice management. In reality however, most of these processes are owned by different global process owners. Sourcing, requisitioning and ordering typically fall under the GPO Purchasing, but invoice management (Accounts Payable) usually is in the remit of the GPO Finance. So, this leads to ambiguity in the process governance framework.
- If you structure your process hierarchy this way, you will create a lot of duplication on your level 3 processes, as some L3 processes are present in multiple end to end processes and this can lead to unnecessary efforts to maintain all processes.
My recommendation always is to set up two process hierarchies:
- A functionally decomposed process hierarchy, used for the creation and maintenance of your business processes and providing the template for your process governance. A minimum viable collection of individual processes that covers your entire organization. This is the golden source location for each business process.
- An end to end hierarchy (usually this is quite small and easy to maintain) that contains all your end to end processes (and its variants) and that are constructed from the building blocks (L3 processes) that sit in your functional process hierarchy.
You can use these end to end terminology all you want in the second hierarchy and use this to communicate to end users, but your process experts who need to maintain the L3 processes are better off with a functionally decomposed process hierarchy.
So, create 2 dedicated process hierarchies, not one hybrid version.