How many business processes do you think there are in your organization? A few? A handful? Dozens? Depending how deep you go into the process hierarchy, there are at least hundreds and more like thousands. And they are all important. If you found an unimportant process, you'd just delete it wouldn't you?
So, you have thousands of important processes to be managed and continuously improved? Thousands of them! How could that work? It's just not possible.
The good news is that neither is it necessary.
We need to focus.
Knowing a little bit about lots of processes is quite useless knowledge. It takes a lot of time, gives us dangerously superficial knowledge, and leaves us with the mistaken idea that we know a lot.
A much better scenario is to know a great deal about many fewer processes. In that way we build deep knowledge with a thorough understanding of content and context allowing us to make better decisions about managing process, and therefore organizational, performance.
Focus on impact
A problem I often encounter in introducing process-based management to decision makers is that they perceive it to be, or likely to become, a massive additional workload not justified by the possible benefits. To be fair to them, there is compelling evidence that this is exactly what has happened in too many organizations.
We need to focus.
You can't actively manage your thousands of business processes. Even if you are attracted to the alluring, but flawed, notion of “managing all of our processes”, it's just not possible. What are your high-impact processes, the processes that you must get right? Focus.
Most organizations can identify, say, 20-30 high-impact processes (HIPs). Poor performance in these processes will cause many other problems; they can have a serious knock-on effect across the organization.
Focus. Select HIPs based on criteria such as: 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.
Use the work on the initial few processes to build a body of knowledge and experience that will be useful in bringing further processes under active management. Demonstrate the practice and power of process-based management.
You can't manage all your processes. Don't even try. Focus on the HIPs for maximum impact. Better to manage 20 processes well than 200 badly. If you get active process management working very well on those, then add some more if that seems useful.
A measured approach
In my work helping organizations discover and document process architectures we initially work top-down in the first three levels of hierarchy to establish the architecture and related management practices. The number of processes involved will vary depending on the number of highest-level core processes, or in other words the number of organizational value propositions. Most times we end up naming and arranging some 200-300 processes.
It can be a valuable test of the validity of the named processes to consider how their performance might be measured, to document some initials thoughts on possible process KPIs. If you can't imagine some practical way of collecting useful performance data, then maybe there is something wrong with the way the process has been conceptualized.
So, testing lots of processes against general ideas for performance management is useful. However, when it comes to active management using well considered and closely defined process KPIs and targets, leave that for the HIPs. Control the number of KPIs and targets to avoid an unmanageable avalanche of performance data.
There is nothing more wasteful and pointless than laboriously setting KPIs and targets for processes whose performance will not be closely managed either because nobody cares, or the process performance is unlikely to be variable or problematic.
We can't do it all. We need to make choices. Focus on the minimum number of KPIs for the minimum viable set of high impact processes. Of course, over time those targeted processes, their KPIs, and the targets will change as circumstances evolve and the processes themselves change.
Making change
It's a common experience—perhaps you've had it yourself—that a process improvement project seems to go well with lots of good analysis and change recommendations that will improve performance, but little happens, and the changes don't get made. It's very frustrating for those involved in the process improvement project and seems like a significant lost opportunity for the organization.
The cause of this might be poor project/management when it comes to executing the change projects. Or it might be that although the changes, if made, would have a beneficial effect, there was not enough urgency to effect the change. Not enough people cared about the problem the change would address. A good change in theory, but in practice…meh, who cares.
It's a classic Darwinian response—the survival of the fittest change proposal.
Apart from the waste of resources in the analysis project and the possible loss of a performance improvement opportunity, this outcome also contributes to change resistance in the organization. We want to get good at making effective change, not at ignoring change proposals.
When it comes to process improvement projects, we need to make change proposals only where there is a real need that the change will address and for which there is an appropriate level of urgency. If you think the change is important but the urgency is missing, then there is another, more fundamental, change required.
The purpose of a process improvement project must be to deliver a new current state, not just a description of a potential future state.
Focus on making change, not just recommendations.
A model process
Just as we can't, and don't need to, manage all our processes, neither do we need to model them all either.
Ever heard someone say that their organization was modeling all its processes? When I hear that I wonder why you would want to. That's a lot of modeling. It's a big disruption. It has quite a cost. What's the return on modeling?
Of course, modeling is an important process management tool, but it's not an end in itself. Nobody has a business problem called we don't have enough process models.
The most important model is the highest-level view of the process architecture which names processes and shows their main inter-relationships. Modeling process detail beyond that should be done on demand in response to a problem or opportunity.
Needing to better understand a process is a good enough reason to model, but modeling in case we ever need it, is not. Some processes will never be modeled if there is never a good reason to do so. Modeling 'everything' is waste.
Focus. Model for a purpose. Model just in time, not just in case.
More of less
When we try and do it all, we end up doing nothing.
Carefully choosing a set of high-impact processes and then proactively managing them is going to deliver better process analysis efficiency, stronger commitment to process-based management, and most importantly enhanced improvement in organizational performance.
Roger Tregear
Latest posts by Roger Tregear (see all)
- Practical Process: Process Improvement Is Not Enough - June 6, 2022
- Practical Process: What Should a Process Owner Know? - January 3, 2022
- Practical Process: Why is Process Work Different? - September 7, 2021
- Practical Process: A New As Is–Making Process Improvement Real - May 31, 2021
- Practical Process: Speaking to the Board–A Fab Way to Communicate with Strategic and Effective Executive Decision-Makers - April 5, 2021
Speak Your Mind