Supplier matrix

One of the core tools in operating model work is a supplier matrix.   The matrix helps clarify why some activities are done in house and others are subcontracted or bought in.  It also identifies those suppliers with whom the organization needs to have a carefully designed collaboration.  The “collaboration tests” are then a tool for checking that the “carefully designed collaboration” has been well designed!  This blog will briefly describe both tools.

Supplier Matrix

The supplier matrix has two axes – yes it is a matrix!   The horizontal axis asks the question “Is this a key activity in delivering value?” and is scored in a binary fashion – yes or no.  But the axis can also be used as a scale, with a “maybe” position somewhere the middle.  The vertical axis asks the question “How good are we relative to others?”  Again, it is scored in a binary fashion – better or worse.  But, like the horizontal axis, there can be a middle position of “about the same”.

This two by two matrix has four boxes.  Bottom left is where the activity is not a source of advantage or excellence and where we are relatively bad at it (costs too high or skills too low).  For these activities, the answer is to outsource with a simple contract.

Top left is where the activity is not a source of advantage and where we are relatively good at it.   For these activities, we can do it ourselves if it does not distract us from more important activities.  If it is a distraction, for example because we are short of skills or money, then we should outsource the activity with a simple contract.

Top right is where the activity is a source of advantage and we are relatively good at it.  These are activities that we should give priority to: they are the core of our reason for existence.

Bottom right is where the activity is a source of advantage, but we are not very good at it.  This is a dangerous position on the matrix.  If we do it ourselves, we are likely to do it badly, and, because it is really important, we may be hurting ourselves or our customers.   If we outsources this activity, we are placing ourselves in the hands of a third party who may take advantage of us (demanding high prices) or let us down.  We are between a rock and a hard place.

The solution to this box on the matrix is to design a collaborative agreement which will motivate the supplier to want to do the best for us and which will still leave us with enough bargaining power to resist exploitation.   As you can imagine these are difficult agreements to design.  Often they involve joint ventures or special purpose vehicles or pain and gain sharing agreements.

Rather than continue this blog on the topic of collaboration tests (tests that help you design good agreements with important suppliers),  I will deal with this in the next blog.

Posted in Supplier Matrix | Tagged , , | Leave a comment

Process evaluation grid

In response to my recent post on the Process Owner Grid,  Richard Rawling responded that he frequently uses a tool called Process Evaluation Grid.    This tool also has the process laid out along the top of the grid – same as my adjusted Process Owner Grid.  The difference is that down the side of the grid are listed performance evaluation criteria, such as customer satisfaction and cost – see example from Nous Group.

This tool reinforces my earlier blog about the value of positioning the process steps along the top of the grid.  It also fits with a strategy tool that I often use which I call “value chain analysis”.  This involves laying out the value chain and then asking under each step in the chain two questions

  1.  Is the cost of this step, as a percent of sales, higher or lower than that of competitors and why?
  2. Is the value that this step creates for the customer, higher or lower than that of competitors and if so why?

To do this well, you need to have an idea of the cost of each step, at least in terms of percent of sales; and you need to know where the customer touch points are and what factors customers most value.

The Nous Group chart has some other questions on it – which can be selected to suit the issue being examined.  It also has the customer touch points and the expectations of the customer at each touch point on the chart, which helps ensure this is front of mind.

My first reaction is that the Process Evaluation Grid is more about strategy analysis than operating model analysis, but I can see the benefit of using it as part of a toolbox for operating model work as well.  It could be used to back up the value chain map.    As you may know, it is often helpful to record “areas of competitive advantage or excellence” and “areas of problem or opportunity to improve” on the value chain map.  This helps ensure that attention is directed at the most important steps in the value chain map.   The Process Evaluation Grid is a tool you might use to help you make these “competitive advantage” and “problem” judgements.

Thanks Richard.

 

Posted in Process Owner Grid, Value chain | Tagged , , | Leave a comment

Which way round to do the Process Owner Grid

At my most recent course on operating models,  I had an ahah moment about Process Owner Grids.  It is better to lay out the grid with the process steps of the value chain along the top and the organization roles down the side – rather than the other way around.

In my recent blog on Process Owner Grids,  I showed a number of examples with the organization roles along the top and the process steps down the side.  As I understand it, this is the traditional way of doing a Process Owner Grid.  It follows the format of the Decision Grid.  The rationale for this format is that it is typically easier to define an organization role in one word (Finance) or a couple of letters (HR or CEO) than it is to find a short definition of a decision.  Hence, given the space constraints at the top of a column compared to those at the beginning of a row, it is best to describe the decision in a few words on the horizontal (i.e. at the beginning of a row) and define the organizational roles on the vertical (i.e. at the top of a column).  So a decision might be “define the monthly sales target” and those involved might be “Head of Sales”, “Sales Managers”, “CFO” and “CMO”.

The ahah message was that the steps in a value chain are typically laid out horizontally in sequence.  Moreover they are laid out like this in the Operating Model Canvas.  So, when thinking about the value chain the mind is naturally thinking left to right rather than top to bottom.  So it is most natural to put the steps of the value chain at the head of columns in the Process owner grid.  Typically the steps are one word, such as “buy”, “design”, “make”, etc; so they fit comfortably at the top of the columns.   The organization roles must then go down the side of the table.

The ahah moment occurred because we had drawn up a Process Owner Grid for an example in the traditional way.  Then one of the participants, who was only paying partial attention, asked for it to be explained.  To aid the explanation, another participant turned the Grid on its side to show his colleague that the rows down the side of the grid were the same as the steps in the value chain.  This caused everyone involved to question whether it would not be better to redraw the Grid the other way around.

So, from now on, I think I will draw it with the value chain steps along the top.   This has the added benefit of being the same way round as the High-level IT Blueprint.  So the Process Owner Grid and the High Level IT Blueprint are similar charts/grids.

I am ashamed to say that my colleague and co-author Mikel Gutierrez had lobbied to have the Process Owner Grid presented with the value chain along the top in our book Operating Model Canvas – and I resisted because I wanted it to be like the Decision Grid.  But I was wrong!  Much better for it to be like the High-Level IT Blueprint.

Posted in Process Owner Grid | Tagged , , , | 4 Comments

Process Owner Grid

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.

Posted in Process Owner Grid | Tagged , , , , | Leave a comment

Management calendar

There are two parts to what I have been calling a management system.  The first part is the management calendar and the second part is the scorecard.  This blog is about the management calendar.

A management calendar is a timetable of management meetings and events laid out over a year or a quarter or a month depending on the rhythm of the management cycle.  For most organizations it is a year.  But if you were doing a management calendar for an agile process, the rhythm is typically 6 week sprints, so the calendar would be six weeks.

A management calendar can be displayed like a clock or like a table.  You have both examples in this article.

So the big question is what should be included in the management calendar?  The answer is all the meetings and processes that the leadership use to run, motivate and control the organization.  Typically this includes:

  • board meetings or governing body meetings
  • planning or strategy process and meetings
  • budgeting and target setting process and meetings
  • performance monitoring and review process and meetings
  • risk management process and meetings if different from the board process above
  • people review, talent assessment and career planning process and meetings
  • incentive definition and allocation process and meetings
  • management conferences

Please suggest other items.   The difficulty in choosing what is part of the management calendar is also partly about deciding what is part of the role of support functions (HR, Finance, IT, etc) versus what is the domain of the leaders.   If something is clearly the remit of a support function, such as accounting rules, audit process, IT security,  and talent development process, then I think it should be excluded from the management calendar and included in the calendar of the relevant function.  So only those processes and meetings that are driven by and led by the top team should be part of the management calendar.  This split between functionally driven and top team driven is rather arbitrary, and may be difficult to make in some situations, but it is a way of limiting what is included in the “management system” bucket.   The functionally driven items are then considered part of the “organization” bucket in the operating model canvas.

So let me give a couple of examples.  I include one from GE, which is a company that, particularly under Jack Welch, had a very carefully thought out management system.   The whole system started early in the year with a management conference in Boca Raton and continued throughout the year with the aim of delivering exceptional performance by the end of the year.

slide1

The second example is a made up one based on many similar examples that I have seen.  It illustrates the importance of thinking through the sequence of events and how they link to the ultimate governance body: the board.

slide1

The last example I want to mention concerns a British company where the CEO’s main contribution was to drive performance improvement.  The whole system started the year before when the CEO would spend time in the trenches traveling with sales people or sitting with engineers.  These experiences would give the CEO insights about what improvements might be possible.  I remember him telling me that on one of these visits he discovered that on average it took two visits to repair machines that had stopped working.  So he calculated how much money could be saved by repairing in one visit, and then included this in his target for that business.  He would then set, at the July strategic planning sessions, what were described as “unreasonable targets” for each business for the following year.   This gave him 6 months in which to interact with the businesses during the planning and budgeting processes.  The 6 months gave time for the management teams to go through denial, anger, and so on, but usually arrive at commitment: a set of numbers they had proposed to the CEO which would typically be close to the “unreasonable targets”.   The process then continued throughout the next year with a relentless monitoring of performance within a culture of no excuses: the targets would be met.   I don’t have a visual for this process, but it produced remarkable performance for about 10 years and, if I did create a calendar it would need to be based on a two year process initiated every year.

Posted in Management system | Tagged , , | 2 Comments

High-level IT Blueprint

What does a project on a high-level operating model need to say about IT?  And what does it need to deliver to the IT architecture team?  This is the focus of this blog.   The detailed work on IT architecture and an operating model for the IT function will be done by the head of IT with support from an Enterprise Architect.  So the work that is done on a higher level operating model must take into account what the head of IT and his or her enterprise architect need.  I suggest the following

  1. The head of IT will need information about the strategy and the broader operating model that IT is supporting. This, of course, is the reason for creating an operating model in the first place.  It translates strategy into a high-level design for the operations and the organization, that can then be handed down to each function and each business unit, who will then do the next level of design.
  2. The head of IT needs to know who the business owner is for each important application.  With this information, the head of IT will know who to interact with, who to deliver value to and, hence, who are the prime customers of the IT architecture that will be created.
  3. The head of IT needs to know which of the software applications need to be part of an integrated enterprise system and which can standalone.  Since it is only IT that can mastermind the integration, it is important that IT knows which applications need to be integrated.  In this context, integration means that the applications can communicate seamlessly, that the data architecture and coding is the same in each application, etc.   Those applications that do not need to be integrated may not even need to be included in the remit of IT.  It is possible that the business owner can be responsible for sourcing, maintaining and running these applications, in the same way that employees are often responsible for their mobile telephones and the applications they have on them.  For example, an engineering team may have a CAD/CAM application supporting their design work which is sourced and maintained by the engineering team.
  4. The head of IT needs to know which software applications will need to be bespoke and whether IT will be expected to develop or commission these bespoke solutions.   Typically, the only applications that need to be bespoke are those that help create a competitive advantage for the company.  Hence, it is the operating model team, supported by the strategy people who are in the best place to identify where tailoring is likely to create advantage.  Everywhere else it is normally best to use a standard package and change the internal processes to fit the standard.  When dealing with business owners, IT needs to know whether to support or resist the special requirements that business owners are likely to request.

This list of four outputs from a high-level operating model project is all that needs to be done on information systems: everything else can be delegated to the IT steering committee – the next level of operating model design.  If you have a different view, please comment below.

Since I believe that operating model work should result in something visual – map, chart, table, etc – my co-authors and I (of the book Operating Model Canvas) have developed a high-level IT blueprint to capture these four points.  Lots of readers of this blog will have their own views about what the term “IT blueprint” means – and please feel free to comment.  This is a “high-level” IT blueprint, and it has been developed without much attention being given to the other forms of IT blueprint.

ch3-p12-it-blueprint-2slide1

The high-level IT blueprint is a table with the main steps in the value delivery chain listed along the top axis and the main organizational units listed down the side axis.   As Mikel Gutierrez likes to say, “when you match the organization against the processes, something magical happens”.  The magical thing that happens is that you are able to visualize the following design choices.

First, you can identify which organizational unit is involved in each of the steps of the value delivery chain.  So, in the example, the step “design product” involves customers/distributors, sales and specials unit: to design a specials product, the specials unit who will do the design must know what the customer or distributor wants and what the sales team has committed to the customer.

Second, you can decide whether this step requires a software application (or sometimes more than one).  The “design product” step does require software support.

Third, you can decide which organizational unit is the business owner of the application: it may be a committee of all of the units; it may be one unit; or it may be possible to sub-divide the application into two or more sub-applications and have multiple business owners.  In this case, the specials unit was the business owner.

Fourth, you can decide which software applications need to be integrated into the enterprise system (the pink boxes in the chart).  Typically these are the applications that touch multiple parts of the organization.  The software for designing specials did not need to be integrated into the enterprise system.

Fifth, based on your understanding of where, in the value delivery chain, competitive advantage is created, you can identify which applications are likely to need to be bespoke. The design application for specials was expected to be a source of advantage, hence it would need to be bespoke.

And, when you have made all of these choices, and recorded them on the table, you have produced  a high-level IT blueprint: a single page that delivers to IT the information that IT needs about the IT implications of the operating model.   Of course, you can rarely get it all on one page – mainly because you will typically have multiple value deliver chains.  However, you can normally produce a high-level IT blueprint with only a handful of pages.

Posted in IT Blueprint | Tagged , , , , , , | Leave a comment

Management systems and accountability

I have done work on the subject of accountability which has led me to the view that a person or unit is accountable when

“the stakeholders of that person/unit have the ability to reward the person for good work or create pain for the person/unit when the work is not good”.

Clearly this is best done directly by the stakeholder interacting with the person or unit, as for a business unit (if the customers are happy they buy more or unhappy they buy less; if the suppliers are happy they deliver on time, if unhappy they deliver late or deliver substandard service, etc). But accountability can also be achieved through the boss of the person or unit:  the stakeholder signals to the boss if things are going well or badly and the boss then administers the reward or pain.  This indirect mechanism is much less effective, because the boss often does not pass on the reward or pain, or amplifies it inappropriately or filters the signals based on the boss’s own views.

The wonder of accountable people/units is that they do not need much external managing.  The person or leader of the unit is plenty motivated to get it right.  Of course a mission for the person or unit that fits with strategy still needs to be agreed, performance still needs to be monitored, and, when the person or unit is failing, someone needs to be developed or changed.

So there is a tight link between management system – planning, budgeting, performance review, people review, risk management, continuous improvement, etc – and organization design.  If the organization has been structured into accountable units, the management system, particularly on the issue of performance review can be much lighter.

Before I continue, let me just back up and explain why I arrived at this view of accountability.   I run a research center at Ashridge Executive Education and we have some important stakeholders – executives who read our research, the larger school, member companies who give us money, participants on our courses, editors of journals, etc.   As I was thinking about accountability, I was recognizing that I feel very accountable and I was wondering why.  Also, I only meet my boss, the Dean, for about an hour every six months; so I was not feeling accountable because of the management system.  I realized that I was feeling accountable because each of these stakeholder has the power of reward or pain over me (I won’t go into the details – but it is because the research center is self-financing).

I also realized that success is about doing a sufficiently good job for each stakeholder so that the stakeholder remains engaged with the research center.  Of course one of the stakeholders is the mission stakeholder: for us executives of large organizations. For this stakeholder the objective is not “sufficiently good job” but something more ambitious.  For the other stakeholders we needed to think about the value we could give to keep them engaged – editors, course participants, member companies, central IT, etc.   It is much easier to solve this puzzle if the stakeholder has the ability to communicate directly and powerfully (through their behavior and choices).   So one of the difficult relationships has been with central IT.  They could create pain and reward for us.  But we had no way of delivering value to them so as to motivate them to reward us rather than create pain.

So what stimulated me to write this blog.  First, there are some important ideas here that should influence organization design and management system design.   Second, I came across this paragraph in a blog by Leon Tranter

“In Toyota car factories, this (the ability to ‘stop and fix’) is implemented via something called “Andon cords”. These are big cords that hang from the ceiling in the car factory. If there is a problem anywhere that needs attention, and cannot be quickly fixed by one person, they pull the cord. Pulling the cord shuts down the whole assembly line. Everyone stops working on whatever they are doing and comes over to help sort out the problem. This might sound insane, but it isn’t. This is Toyota we are talking about here, the most successful car business on the planet. They pretty much invented Lean and they know what they are dong. Andon cords encourage a culture where problems don’t lie around and take root. They get fix and fast. Which means the rest of the business can then restart and keep going.”

I don’t think the Andon cords actually stop the line, but they do signal to management and engineers that they should stop what they are doing and run to where the problem is.  This mechanism gives the worker the power to create pain for the engineers and managers.  It is this sort of mechanism that creates accountability.

In an article I wrote for McKinsey Quarterly, I suggested that one of the ways of stopping corporate headquarters in large companies from being a burden on business units would be to give managers in business units (maybe all managers) the equivalent of an Andon cord so that they could blow a “bureaucracy whistle” when activities by headquarters were time wasting or interfering and the “whistle”  would bring senior managers running to “fix the problem”.

Posted in Management system | Tagged , , | Leave a comment