The process owner grid is a powerful way of ensuring that links across the organization structure are not left to chance. It is similar in format to the decision grid (see a blog on this) – hence the similarity in the names. Instead of defining who owns a decision (‘who has the D’) the tool is about defining who is the business owner of a process.   So the following steps are needed to produce a process owner grid.

First, list the important processes that should be examined in the grid.   Start with your value chain map (see other blogs for this). The value chain (or value chains) is the most important process in the organization and should be ‘owned’ by the manager (or managers) responsible for delivering the value proposition at the end of the each value chain; so you do not need a process owner grid to make this decision. You need the process owner grid to record the next level or two of important processes and their owners.

If the value proposition is a manufactured product, the first level – the value chain – could be as simple as ‘buy’, ‘make’, ‘sell’. The second level of important processes would then be the buying process, the manufacturing process and the selling process.   Beyond this level, a third level of process would be the sub-processes of buying, the sub-processes of manufacturing, the sub-processes of selling, as well as processes for the main support functions, like Finance, HR and IT.

When drawing up a process owner grid, always go to the second level of important processes and then decide whether and where it is helpful to go to the third level. Frequently it is helpful to go to the third level, but only in areas where cross-organisational confusion might exit without the extra level of detail.

Once you have chosen which processes to examine with a process owner grid, start by listing these down the side of a grid, in the same way that you would list the important decisions down the side of a decision grid. Since a grid only has room for a few words down the left hand side, it is usually helpful to have a separate descriptor of each of these items explaining more fully what it involves.   So the label might be “buying process” and the descriptor might be something like “Buying process: identify sourcing needs, identify and approve suppliers, get quantities required, contract with suppliers, check quality, warehouse and deliver”.

The next step in developing a process owner grid is to list the organization units along the top axis of the grid. These will be taken straight from the organisation structure chart. Clearly it is impossible to do a process owner grid without clarity about the value chain and clarity about the organization chart. Continuing with the example of a manufactured product, the organisation units might be Finance, Sales & Marketing, Production Product A, Production Product B, Supply Chain, Human Resources (see exhibit).

Now that the grid is formed, the next step is to colour in the boxes showing which organization units are involved in which processes. Choose a different colour for each process. In the exhibit, the “buying process” involves Supply Chain, Production Country A, Production Country B and Finance.   Finance pays the suppliers. The two Production units tell Supply Chain what they need. Supply Chain does the rest of the work.

The final step is to mark on the grid which unit “owns” the process. This means that the unit is responsible for making sure that the process works well. It also means that, when other units want to make changes to their part of the process, they need to discuss their proposals with the “process owner”.

Normally, there is just one unit that owns the whole process. In this way it is usually easier to make sure that the process if fully aligned around delivering the value proposition at low cost. The process owner will often choose to set up a “process governance group” to involve managers from other units. But the process owner will lead this group.

Sometimes the ownership of the process is split between two or more units. In the example of the “buying process”, Supply Chain owns most of the process, but Finance owns the “payments sub-process” and the Production units each own their “forecast supplies needed” part of the process.   Splitting the process ownership is usually only sensible when there is a simple handover at the point where the process is split. The simple handover between Production and Supply Chain is the “production forecast”. The simple handover between Supply Chain and Finance is the “approved invoice”.

The Process Owner Grid is important because it needs to be clear who will responsible for design work at the next level of detail. Each organisation unit will be responsible for the operating models within their own units. But who will be responsible for designing the details of processes that cross multiple units? The Process Owner Grid makes this clear.

The Process Owner Grid is also invaluable to IT. When IT architects are designing the portfolio of software applications and deciding which applications need to be integrated into an enterprise system, they can go to the Process Owner Grid to find out who is involved in each process and who is the “business owner”. They can then be sure to take their guidance from the right people.

Because the Process Owner Grid is so important to IT, the work on who owns which process is often combined with the work on the high-level IT Blueprint. If this happens, the Process Owner Grid is often turned around so that the process steps are listed across the top of the Grid and the organization units listed down the side. This is done to align the process owner grid with the normal format of the IT Blueprint.

Why is the Process Owner Grid normally arranged one way and the high-level IT Blueprint normally arranged a different way? There is no particular logic. The Process Owner Grid evolved out of the Decision Grid. The Decision Grid was arranged with the decisions down the side because it was often important to write a short sentence to explain each decision, and this is easier to do on the horizontal. Also, decision makers can often be identified by a few letters (CEO, CFO, MD, HR, etc), which were easy to put at the head of a column. The IT Blueprint emerged out of process mapping thoughts, so it was natural to put the process along the top running from left to right. The organisation units were then put down the side. Do not feel constrained by these historic influences. If you want to change the axes around, do so. But make sure you communicate what you have done to the audiences you are trying to influence.

It is possible to add additional information on a Process Owner Grid. In the example below, the red arrows identify “difficult links”. These are relationships that are likely to be difficult given the choice of process owner.   Course Admin owns the workbook production process. This can create friction with the Course Director and Faculty members who request special features that Course Admin consider inappropriate. Faculty members each “own” the development of their course materials and can disagreed with Course Admin about how these materials should be presented to the participants.   By exposing these potential frictions the Process Owner Grid can help ensure that they are resolved before they become a problem.

The circles on the Grid identify organisation units that may require some protection from the dominant culture. In this case, the Faculty drive the dominant culture. Hence Media, who control the brand, and Course Admin, who are responsible for efficient administration in line with the brand, may need some protection from the dominant culture.   Normally this protection is given by ensuring that these units have “ownership” of the process that enables them to perform their role in the organisation.

The Process Owner Grid can also be used to mark problem areas and sources of advantage and parts of processes that could be outsourced. These are not shown in the examples. But, hopefully, you can see how valuable this grid is for helping consider important operating model choices.

If you have experience to share or improvements to suggest, please comment below.