Every organization has many business processes.

I'm counting processes at all levels, not just those that are completely end-to-end. Not everyone will agree with that approach, but I see processes as being essentially the same at the top and the 'bottom' of a process architecture. A uniform definition can be used for processes large and small. A process architecture or hierarchy has fractal characteristics. Anyhow, that's my frame of reference.

Counting processes

How many processes are there?

Of course, that depends on the organization, but some basic arithmetic will give us some ballpark estimates. Imagine we start with three highest-level core processes and that each process throughput the architecture has five subprocesses. At level 4 we have nearly 500 processes, and go down two more levels and we've broken through 10,000. And that's just the core processes to which we'd need to add management and support processes.

Different initial parameters will give us different growth rates, but we are all too aware these days of the overwhelming impact of 'exponential growth'.

How many processes are there? A lot. Too many to manage all of them. The good news is that we don't have to manage all of them; indeed, we can probably do very well by actively managing a tiny percentage of them.

This is not just idle arithmetic. The idea of investing 'lots of resources' in the management of 'all our processes' is quite rightly a roadblock for executive support for process-based management. To gain and sustain that support we must replace that mistaken idea with the correct concept of efficiently and forensically-targeted process management.

A pyramid of process

It's useful to think of an organization's processes as a pyramid with the critical few at the top and the important many further down the structure.

Figure 1 shows a process priority pyramid with four categories in which a process might be defined and amongst which a process might be reclassified from time to time.

Figure 1. Process Priority Pyramid

At the base of the pyramid are the Unknown Processes, the thousands (or tens of thousands) of processes that will be never managed, never even named. We know they exist because every process has at least two subprocesses — it's processes all the way down! — but there will never be a reason to name and document them. It's not that they are unimportant (if a process were genuinely unimportant, we'd probably delete it), but in a world of finite resources available to be used in an 'infinite' opportunity and problem space, choices must be made.

At the next level up, we have Named Processes. All they have is a name, but they've made the cut and are out of the unknown thousands and into the hundreds that have at least been recognized. These are the processes that would be found in the basic process architecture. Their purpose is to give structure and context to the ecosystem of processes.

For me, that would be the top three levels of core, management, and support processes (starting top-down from the strategy). It depends on the organization and its value proposition(s), but there is likely something like 300 processes in this category.

A further refinement in the next category gives us the Documented Processes. These are processes for which there has been a good business reason to document them. Documentation would likely include some form of traditional process model as well as any other information or diagram that explains the purpose, context, and operation of the process. Expending lots of resources on documenting a process without a good business case for doing so is waste. Documentation should be done just in time, not just in case.

Many reasons might support a sound business case for documenting a process, including:

• better understanding of the process to enable better outcomes


• a need to improve the performance of the process, perhaps requiring a deep dive into the operational detail


• the need for a good level of documentation before a process can be automated in any way


• process documentation that can be the basis of training material


• a possible regulatory reason to track some aspect of process operation, e.g., identify every time customer data is used.

The number of documented processes will vary between organizations and over time, but as an order of magnitude, 100 is usefully indicative.

We've come a long way from (tens of) thousands to just 100 processes, and we can go one step further to define those processes at the top of the pyramid, at the top of our priority list.

The Managed Processes are those that we must actively manage to assure quality performance. These are processes that can have a significant impact — positive and/or negative — on organizational performance. They are often called the high-impact processes (HIPs).

Most organizations can identify, say, 20–30 HIPs where poor performance will cause follow-on problems. They can have a serious knock-on effect across the organization, creating an avalanche of problems. Alternatively, it may also be that improvements in the performance of HIPs will have a positive multiplier effect on the performance of other processes.

There is no magic formula for the selection of HIPs. The common criteria include: customer and other stakeholder impacts, regulation imperatives, number of staff involved, cost of execution, current performance level, strategic impact, major project impacts, resilience demands, etc. HIPs will often be from the set of core processes but may also be found in management and support processes.

A research question

I am currently facilitating some research amongst process practitioners to better understand how we should select HIPs. The question I would like to answer is a simple one — what criteria should be used to select the HIPs? If you could only manage, say, 30 processes, how would you choose them? The question is simple. I'm not sure if the answer is!

In general, the criteria will relate to issues like impact, reach, scope, strategic importance, current problems, key stakeholder involvement, change plans, pain/gain. But this is nowhere near a usefully-defined approach. To be useful and generally applicable, selection criteria will need to create an objective 'score', a mechanism that allows a valid and repeatable selection.

This is likely more than the pain/gain analysis we might do to select the 'best' process for performance improvement. We are likely talking about some form of decision matrix, but the objective is to select the processes that must be actively managed irrespective of current performance levels.

Do you have experience to share about detailed HIP selection criteria and their use? Even without personal experience, perhaps you have some suggestions about how it might be done? It would be very useful to receive links to any published material on this topic. Please send any contributions to me at roger@tregearbpm.com.

Thanks in advance for any insights you can offer. The outcomes of this will be published and be made freely available. With permission, all contributions will be acknowledged.

# # #