Process governance may be a topic of interest, but there are many blindspots!
Process governance seems to have crept up the executive agenda in many service industries in recent times. Whether it’s because of increased regulatory scrutiny, the amount being spent on remediation projects or a call for greater accountability, there can be no doubt that it’s a topic of interest.
Unfortunately, it appears to be seen through a somewhat myopic lens – it’s more than just mapping processes. In discussions with colleagues over the last few months there are a number of common blind spots:
Lack of an overarching framework. Trying to govern and manage processes without a framework is like trying to complete a jigsaw without the box that shows the size, shape and picture of what you’re trying to do.
Confusion around ownership and accountability. You may be accountable for a process but that doesn’t mean the resources responsible for execution of the process will report to you.
Struggling with the implications of managing processes end-to-end. Understanding where an end-to-end process starts and ends, how the sub-processes that combine to deliver the end-to-end link, how they link to customer journeys and how to determine the metrics across organisational silos is not easy, but that doesn’t mean can you put your head in the sand and avoid the conversation..
Too much focus on the tools. Having a single repository to store process- related information – maps, metrics, initiatives, policies, standards etc. is critical but it doesn’t matter how good the tool is if the other critical elements of a process governance framework aren’t in place e.g. policies, standards, executives role-modelling the required behaviours.
Struggling with handling the “happy path” and the myriad variants that typically exist. Variation is the curse of all processes but is particularly pronounced in service industries. Channel, regional, product and customer variation is common not to mention all of the exceptions that each can throw up. If you only focus on the happy path, you’re missing the opportunity to realise one of the principal benefits of process management – consolidation.
Muddled thinking around levels in the hierarchy i.e. the difference between a process, an activity, a task and a step. If you ask someone to document their process, they will document what they do. What they do becomes the process. The person responsible for opening the mail will document how to open an envelope. The person responsible for managing the organisation’s brand will
A general misunderstanding about the differences between process maps and work instructions. Different users have different needs. Being able to visualise how processes connect as part of a major change is very different to a service agent talking to a customer and needing to know which button to click to resolve the customer’s query.
A misperception of process mapping as an end in itself as opposed to a means to an end. Mapping and document processes doesn’t provide benefit per se, it’s what you use the documentation for e.g. training to gain a better understanding of how the process works, the differences that exist, what’s required to implement a change.
Attempting to document every process as opposed to focusing on critical end-to-end processes. Following on from above, documenting all processes will be a bit like painting the Sydney Harbour Bridge – a job that never ends. But if the focus is on documentation, when it yields little direct benefit then the whole exercise will be seen to be bureaucratic.
A misperception that implementing process governance is a project with a start and an end date. Process governance is not a project. It doesn’t have a start and an end date. It is a continuous approach to running a business.
Struggling to see process mapping as anything other than a bureaucratic exercise and then giving up when the benefits aren’t immediately apparent.
A lack of process metrics. This goes back to the goal of instituting process governance in the first place. If you don’t measure the process how do you know whether it’s delivering what you wanted it to. Just because it’s hard to measure service quality doesn’t mean you can just ignore it or the other process metrics that contribute.
A lack of focus on tracking conformance. A bit like taxes and death, it seems the only thing you can say for certain with processes is that the process that’s executed is rarely the one that’s documented. If you don’t check whether what is actually happening relative to what is supposed to happen the consequences will be significant.
Not linking and prioritising projects based on process performance. Finally and most importantly, if everything an organisation does is the collected output of its processes, if you want to change the outcome, change the process. That means you must measure the process and those that aren’t performing in line with expectations is where you should be investing and prioritising your change efforts.
Initially I intended to write just a single post on the topic. But after listing each of the issues I thought the topic deserved a little more. In the rest of this post I’ll focus on a couple of the more strategic aspects.
Process as the Strategy Execution Lever
For most organisations, strategy is about setting the direction and objectives and allocating resources within a specific risk appetite that natural involves a range of trade-offs. Not only is strategy setting a process in its own right but realising and prosecuting the strategy is absolutely dependent on process design and execution. Process is at the heart of everything we do. It’s about taking inputs and transforming them into outputs. If you want to change the outcome – i.e. the core objective of a strategy – then you must change the process. So it seems strange that so many of those responsible for devising strategy pay little heed to the architectural building blocks of process.
Alongside the roles and responsibilities, principles, standards, toolsets and metrics the most critical aspect for me is a process classification framework. Generic versions are readily available and provide an excellent place to start.
Process Classification Frameworks
Imagine walking up to a table covered in jigsaw puzzle pieces with no box just a clue: “it’s an enigma”. You don’t know if there’s more than one puzzle’s worth of pieces, you don’t know if there are any pieces missing, you don’t know the shape or dimensions of the puzzle and whether the table is big enough. You don’t know what the key themes (colours) are or how they fit within the overall picture.
In the normal course of completing a puzzle you would have the box with the image on the front, the number of pieces, the shape and the dimensions. You would typically start by finding the edge and corner pieces to set the boundaries. You would then sort the pieces by colour and shape - the image on the box providing sufficient detail to cluster colour themes place them appropriately. Progressively the various motifs are linked together. Importantly every piece has its place and there’s only one place each piece will fit. Collectively, when all the pieces are assembled in place the picture reveals itself.
Trying to manage processes without a classification framework is like trying to complete a jigsaw without the box.
A process classification framework is simply a list, typically organised in a hierarchy. Each element has a definition. An element only appears once and they are grouped together into common themes e.g. Sales and Marketing processes, Fulfilment processes, Servicing processes, Finance processes. The hierarchy has multiple level typically 4-6. For example: Process Category->Process Group->Process->Activity->Task->Step. The themes are the process categories.
Comments