Eleven visuals that communicate an operating model.

As some of you may know, I am writing a book on operating models, which will probably be called “Operating Model Canvas” – to connect with the “Business Model Canvas”.  I am also making this the center piece of my course Designing Operating Models.   After all, one of the definitions for the word model is “a visual way of displaying how something works”.

So here is my current list – and a visual showing how all these visuals fit together! The visual in the middle is the operating model canvas.  I don’t yet have pictures of all the other visuals – but it is coming!

Comments please.

Slide1

  1. Stakeholder Map: this is helpful in clarifying what is inside the operating model and what is outside the operating model and the type of relationships that exist with those outside
  2. Value Chain Map: core visual that shows the operating work that needs to be done to deliver value to the beneficiaries of the operating model.  Vital tool for clarifying sources of excellence and problem areas.  Also vital for thinking about where similar activities/capabilities should be combined, linked or kept separate.  Helpful for thinking about in-sourcing and outsourcing, and hence good to link with the stakeholder map.
  3. Organization Model: converts the value chain map into an organization structure, and provides a framework for adding all the supporting functions and capabilities into one picture.
  4. Decision Grid: lists the ten or twenty major decisions that the organization makes and defines the role of each organization unit in making these decisions using RACI or RAPID
  5. People Models: outlines the people model (who we want, what we offer them, what career path, what culture) for each skill group that is critical to the organization’s success
  6. Process Ownership Table: combines the organization model and the value chain map into a table so that it is clear which operating processes touch multiple organizational units, where there are likely to be difficult working relationships between organizational units and which organizational unit(s) own(s) each process (or part of process).
  7. IT Blueprint: using the process ownership table, it is possible to mark on the table what applications are needed to support each process, whether the application is bespoke or a standard module and whether the application is owned by IT or the owner of the process.  There are many uses of the phrase IT Blueprint.  This is a particularly high level use of the term.
  8. Supplier Matrix: summarizes the outsourcing and in-sourcing choices and identifies which suppliers need to be treated as business partners rather than transactional suppliers
  9. Locations Footprint: displays the geographic locations or building layouts showing where work is done, why it is done in that location and what assets are needed to support the work
  10. Management Calendar: displays the annual (or periodic) rythm of strategic planning, budgeting, target setting, business reviews, people reviews, continuous improvement processes and other systems that run the organization.
  11. Scorecard: displays the tool that managers will use to assess progress. Typically includes vision, mission and values statements, a list of projects and a list of KPIs with red, orange and green lights against each item

What do you think?  Any thoughtful comments will be rewarded with “contributing author” status in my book!

Posted in Design tools, Operating Model Canvas, Operating model visuals | Tagged , , , , , , , , , , , | 1 Comment

From strategy to success: the role of operating models

I was looking at the Wilson Perumal website today.  This consulting company has some useful blogs … and thirteen on operating models.   I particularly liked one titled “Are you overlooking an essential part of your strategy”

The article states “When most people think of strategy, or the allocation of scarce resources, they focus on the external strategy—which customers to serve in what markets with what portfolio of products at what price points and with what supporting service levels. However, equally important, but often overlooked, is a company’s internal strategy or Operating Model—the coordinated collection of business & production capabilities, organization structure, assets, people, technology, partnerships and governance used to effectively deliver the market strategy.”

The article then includes an exhibit showing the role of an operating model in the journey from strategy to excellent outcomes.

Slide1

This exhibit got me thinking.  Is operational excellence all you need to turn “Sound Strategy” (a good market strategy and a good operating model) into “Leading performance”.    My conclusion is no.

My reasoning is as follows.  When you have a new strategy, you need to develop a new target operating model to deliver the strategy.   I agree that both of these are needed for a “Sound Strategy”.  I also agree that too little attention is given to the target operating model in most strategy processes.   But even with a “Sound Strategy” you still only have a set of ideas and plans on paper.  To create the target operating model, you need a transformation process, consisting of a set of projects that will convert your current operating model to the target.

Once you have implemented the new target design, you have not yet implemented the strategy.  All you have done is set the organisation up so that it has the structure and capabilities and processes and …. that it needs to implement the strategy.  You still need to run the organisation well (“Operational Excellence”) to deliver the strategy.

In other words,  I don’t think Wilson Perumal have got this quite right.  My equations would be

Market Strategy + Target Operating Model = Sound Strategy

Sound Strategy + Excellent Transformation = Sound Organisation

Sound Organisation + Operational Excellence = Excellent Performance

What do you think?  Please comment.

 

 

Posted in change, Design Elements, operating model, Strategy, Uncategorized | Tagged , , , , | 7 Comments

When to do organisation design in operating model work

I was discussing my last post about capability maps with David Winders and we got into a discussion about the timing of work o organisation structure.  David was explaining that one of the benefits of capability maps is that it keeps the analysis and discussion away from organisational structure.   This makes it possible to engage all the senior people in the work without the inevitable posturing for power.

I pointed out that good value chain maps do the same job.  They focus people’s attention on the work that needs to be done not the organisational units who will do the work.

But, David then said that he likes to leave work on organisational structure to last in his operating model projects, whereas I like to do this thinking straight after value chain thinking.  So my model POLIST (son of PILOS) – has Processes first and Organisation second.   Interestingly, David’s model CCPPOLDAT (Customer, Channel, Product, Process, Organisation, Location, Data, Application, Technology) also has organisation after process.  But, in practice, he likes to leave work on organisation as late as possible to allow as much engagement as possible.

I am sharing this because I have not thought deeply about the order in which I do things.  Hence David’s comments caused me to stand back and wonder whether he is right.   I recognise the politics that surface as soon as you start talking about organisation.  But I have usually found that my organisation modelling tool and the 9 tests of good design are powerful enough to cut through the politics.  Also, “I” in POLIST, standing for IT and other Links, cannot be addressed fully without knowing what the organisation structure is: after all the links that need to be addressed are those that cut across the organisation structure.  So, the value of doing structure early is that these linkage issues are exposed early.

However, I could do work on Location and Suppliers and People Model (a part of organisation) and some IT issues before focusing on structure.  So I am interesting in trying this out.

Posted in Uncategorized | 3 Comments

Capability Maps vs Process Maps: Horses for courses

Those who have been following this blog will know that I have devoted four or five entries to the issue of capability maps. Mainly because I have not seen the need for them and because they can obscure the core operating processes and give too much prominence to the support processes.

So I thought I would share an excellent comment on this topic from David Winders. In 2009, he wrote an article “Capability Frameworks”  from which I have stolen some choice paragraphs and added some of my own text and edits. In other words the text in inverted commas is 85% David and 15% me. Apologies David, if I have inadvertently subverted your meaning, but I thought you were making some great points with two excellent examples (one of course is now no longer topical!)

“In nearly every encounter with fellow business architects the subject of capability frameworks seems to come up in discussion. In nearly every case, people are trying to establish their understanding of this approach and seeking to get further information or comfort from discussion with an outsider who might have the answer.

I have concluded that we need to recognise the differences between capability frameworks and process architectures and understand where they add value and where they don’t. We need to perhaps use more concise language that is business-focused and be aware that different disciplines use conflicting terms like “business services” creating unnecessary confusion. I would suggest that “business building block” is better than the ambiguous term “capability” to describe a portion of the business that delivers something, but with reference to the capability in the name of the building block.

Capabilities focus on outputs whilst processes are concerned with actions. In financial services a high-level process architecture often looks nigh on identical to a high-level capability model. Hence, in a process dominant sector like financial services, people look at capability models and say “what is the point?” Apart from a slightly different naming convention – process is verb-followed-by-noun (Make Payments) whilst capability is often noun-followed-by-verb, (Payment Making) – there is little difference between the two.

A possible reason for the convergence of process and capability models maybe due to reluctance to define capabilities. If you ask people in an organisation steeped in delivery, particularly in a high volume processing area, they are often more focused on what their department does day to day than what the department delivers to a customer. If you ask what the capabilities are, you universally will get a list of processes. It is quite difficult to ask people to forget how they do things, and think about what the deliverables are instead, and what the outputs mean to customers or the rest of the organisation’s value chain.

Military enterprise architectures MODAF/DODAF do give special focus to capability frameworks, as the military is more interested in what it can achieve than in designing repeatable activities in the form of processes; from an architecture perspective the capability of a platoon or a gun is more important than how it is deployed in the process of executing a particular battle (the process view).

A topical subject at the moment (2009) is the 65th anniversary of the allied DDay landings in Normandy, where the capabilities of “Fuel Supply” and “Stores and Provisions Supply” were provided through the technologies of pipeline under the ocean (PLUTO) and floating harbours (Mulberry Harbour). There was a process content in these “Overlord” capabilities: they were part of the DDay process.  But military people doing architecture work are interested in their capabilities to support and maintain mechanized divisions in the field of combat (for example gallons per day or tons per hour).

Like so many things, there is a danger that we get too intellectual about the techniques, tools and language we use. There are situations where the capability language and focus will be most helpful, and others where the process language is likely to be more useful. The only real guide is that it must be appropriate for the audience that receives it. It may well be academically interesting for us in business architecture to have these debates but what value does this add to the business that pays the bills?”

So maybe I should stop my agonising about capability maps?   But, there is some value in discussing tools.  If we use the best tools, we are likely to do good work.  David’s point is that it is horses for courses.   Tools should be chosen to suit the situation.

Posted in Capabilities, Design tools, Enterprise architects, Processes | Tagged , , , , , , , , | 15 Comments

Peter Murchland on Operating Models

I have just come across an article Peter Murchland wrote on LinkedIn giving his definition of an operating model.    I have copied chunks of his text because he provides a different perspective to my PILOS model (which is about to become POLIST!).  Peter takes more of a systems perspective and emphasizes elements like “resource management” and “development management” that I give little time to.   As you will see “operations management” is only one of four systems in Peter’s model, whereas I focus on operations management and treat the other systems as secondary issues.

As I have explained before, there is real value in exploring other people’s frameworks, because it helps make you less confident in your own framework and hence less likely to stick to it when circumstances call for something different.

“Purpose

The primary purpose of an operating model is to express the means by which an organisation:

  • pursues its enterprise
  • realises its goals and aspirations
  • achieves and sustains viable operation

Enterprise system

There are four key systems forming the expression of any enterprise-as-system that I consider:

  1. Operations management system
  2. Resource management system
  3. Governance and management system
  4. Development management system

For many years, I have only addressed systems 1 to 3.  Typically, I have not addressed the development management system, because:

  • I was usually part of this system
  • the development management system was usually embedded in the other systems

However, with the increasing degree of change, I am finding that more enterprises are recognising the development management system as a distinct system. This can be seen in John Kotter’s article – Accelerate! – where he outlines the case for a dual operating system.  It can also be seen in the increasing profile of Program Management in enterprises and in enterprises where they have established a Chief Operating Officer and a Chief Change Officer.

Operations system

This system is the core system which produces the products and/or services of the enterprise.  It is most commonly represented as a value stream, reflecting the core capabilities by which the enterprise transforms inputs into outputs and delivers value to its customers and consumers.

This system may also include support systems which are not part of the primary value stream.  These may be systems which require specialist capabilities and are required by different systems in the value stream and deliver internal products and services beyond those provided as part of resource management.

Resource management system

This system manages each of the resource types required for successful operation of the enterprise.  At a minimum, this will encompass:

  • Human resource management
  • Financial management
  • Information management

It may also include:

  • IT management
  • Asset management
  • Procurement, contract and materials management
  • Record management

Governance system

All enterprises require governance and management.

With respect to governance, I have drawn on the Tricker Model which is one of the models covered within the Company Directors Course run by the Australian Institute of Company Directors.  By drawing on this model, I know that there are many Directors and Boards who will be familiar with the model and therefore comfortable with the subsystems that I include:

  • Accountability and reporting
  • Strategy
  • Policy
  • Performance reporting
  • Strategic risk management

To date, I have not modeled the management system.  It seems to be adequately covered by the management embedded in each of the systems that I consider. I have included reference in this area – governance and management – to allow for inclusion of additional capabilities that become evident and require attention beyond those evident in all other areas.

Development system

This system supports the development of an enterprise and effects change in any of the systems.  Change may derive from strategy, as the means by which strategy is executed, or from individual systems as part of continuous improvement.  It includes:

  • Architecture management
  • Program management
  • Project management
  • Change management
  • Program and project support

I view change through a lifecycle lens taking change from idea to realisation. Key steps include:

  • Initiative formation
  • Investigation
  • Acquisition
  • Design, build and test
  • Implement
  • Review and close”

So what is my (Andrew Campbell’s) reaction to this “system view” of an operating model.   First, of course an operating model is a system, so aren’t all frameworks “system views”?  I was brought up on the 7S framework, which I think of as a “system view”.

Second,  I prefer to deal with the development system as an after thought.  It is hard enough designing a good operating system, let alone designing an operating system that is simultaneously evolving to something different.  I agree that organisations need the ability to redesign themselves, but, in practice this happens through transformation projects rather than through a development system (I write these words timidly because I am not very confident I am right).

Third,  I don’t find the idea of a resource management system very helpful.   Each step in the value chain will have resources and will need to manage them to execute its work.  So I see resource management as part of operations.   Also, Peter comments that the operating system can include support systems.   I consider HR and Finance and IT as support functions that run support systems rather than as resource managers.  I know that quite a few frameworks distinguish resources from processes or organisation, but I am not sure this is helpful.

Third, Governance is a topic that I subsume under “organisation”.  Interstingly, Peter does not place decision authorities under governance (in fact he does not seem to have a place for decisions authorities), which for me is the core of governance.  On the issue of performance management, I have found it necessary to add “Management Rhythm” to cover the planning, decision making and performance management processes used to run the organisation … which clearly has an overlap with governance.   But also has an overlap with the project management element of Peter’s “Development management system”.

Conclusion:  There are lots of ways of slicing the cake.  As long as you are aware of two or three ways in which people like Peter and me slice the cake, you should feel confident slicing it your own way because you are unlikely to miss out anything important.

 

Posted in Design Elements, operating model, What to design | Tagged , , , , | 4 Comments

What is functional alignment in an operating model

I have cut and pasted below a bit of an interview by Martha Heller of CIO with Jim BuBois, CIO Microsoft.  I hope I am not transgressing copyright!   But what Jim says is such a good example of IT being fully linked into the business operating model I could not miss the opportunity of adding to my blog.  Apologies for edits and comments.

“Martha Heller: How has your IT operating model changed during the last five years?

Jim DuBois: We used to think in terms of projects and applications, and now we think in terms of service offerings. Each service offering represents all of the technology investments that support an end-to-end business process, like lead generation or customer support. Conversations about IT used to be disconnected from conversations about our business. Now, we are able to talk about which investments will improve our service offerings.

Take marketing, [for example]. Marketing manages a lot of activities that generate demand for our products. Whether they are campaigns, events, or different ways to engage with customers, we can track those activities to learn which drive legitimate sales opportunities. All of the investments we make in marketing automation should, in some way, increase the volume or quality of (our marketing) leads.

We no longer ask, “How available is a particular application?” or “Was the project on time?” Now we measure, “Did we add capabilities that made the service offering better?” (Meaning, I think, did we add capabilities that made our marketing more effective?)

Heller: Moving from traditional IT to a service offering model requires a major mindset shift in IT. How did you make that happen?

DuBois: Historically, IT did what the business wanted (it) to do. But with analytics tools, and especially with big data, IT now sees end-to-end across the company more cleanly than most departments, so we are able to say, “I understand that you want to make this technology investment to make a process better, but this investment actually won’t help because of bottlenecks that are happening elsewhere in the company.” (Great example of IT seeing the whole operating model and help identify where investment will make a difference, rather than just serving its different functional customers.)

Because IT can see so much, it is our responsibility to influence investment priorities, not just execute on priorities set by our internal business partners. We used to reward IT employees based on whether they delivered a project on time and whether the business was happy with what IT did. But we found that making business partners happy did not always mean that we were doing the right thing at the company level (meaning the right thing at the level of the company’s overall operating model).

Back to the marketing example, my team now gets measured on whether they increased the volume and the quality of leads, not on whether they delivered what marketing asked them to do. That has been a real cultural change.”

These comments by DuBois provide a perfect illustration of the benefit of having an operating model that is shared by all the functions.  IT can then help decide what is most likely to improve the overall operating model.  HR and Finance can do the same.  Rather than each function working in its silo, responding to others so that it meets its own internal performance metrics.  All functions should be working off the same set of operating metrics for the overall operating model and trying to figure out what they can contribute to achieve these higher level metrics.

So IT should be thinking about what we can do to help generate more and better quality sales leads – maybe a new application for marketing, maybe a better link between sales and marketing or maybe a better way of measuring quality of sales lead or …   But HR should also be thinking about how to help generate more and better quality sales leads – maybe better training for marketing staff, maybe enabling career moves from sales to marketing and back, maybe changes to the recruitment processes for marketing staff or …   And Finance should also be thinking about how to help generate more and better quality sales leads – maybe supporting an increase in the budget of the marketing function, maybe changing the comparative benchmarks used to assess marketing effectiveness,  maybe providing marketing with more analytical support or …

If all functions understand the process for developing sales leads and its importance in the overall operating model, they can focus on their role in helping make this process effective …. then you really have a shared operating model and the sort of functional alignment that is missing in most organizations.

Posted in Alignment, Capabilities, operating model, Processes | Tagged , , , , , | Leave a comment

Tools for examining an existing or proposed operating model

Stimulated by Mark Lancelott of PA Consulting and Alan Crawley of Optima, I have been doing some thinking about how to examine or challenge or otherwise interrogate an existing or proposed operating model.   Assume therefore that there is an operating model – a value chain or capability chain map, an organisation model, a people model, a decision grid, a process and IT applications map, a locations map and a supplier map – the question is “What do you do next?”

  1. You cannot examine/analyse everything; so you need to focus your attention on places where there is an opportunity to make a difference
    1. Stakeholder offers: what is this operating model offering to each stakeholder and what is the stakeholder contributing in return.   Small changes in offer can have a significant impact on the operating model.
    2. Activities in a value chain map or boxes in an organisation chart that are or could be a significant source of advantage/excellence or disadvantage/poor performance
      1. Special capabilities or IP
      2. Major items of cost – an idea here may move the needle
      3. Fixed cost items – there are normally economies of scale
      4. Major assets – such as data or brand or location
      5. Major balance sheet items
      6. Inflexible activities – which activities are hard to change. These can become mill stones
    3. Problem areas – where things are not currently going well.
  1. Start by making intuitive operating model choices (to stick with the existing choice or to change to a different choice – see below) and then focus analysis on those choices that you are uncertain about.
    1. Process and Information Choices
      1. Centralise – Link – Separate (CLS)
      2. Insource – Outsource (IO)
      3. Increase – Decrease – Eliminate – Add (IDEA)
      4. Digitize – Automate – Mobilize – Analyze – Sensorize – Socialize (DAMASS)
      5. Agile – Fixed (AF)
    2. Location Choices
      1. Close to customer – Close to supplier – Attractive to other stakeholders (e.g. employees) – Offshore (CCAO)
    3. Organisation Choices
      1. For operating work: Value chain – Units – Matrix
      2. For support work: Policy – Champion – Shared Service – Core Resource
      3. Type of employee choices
      4. Incentives choices
      5. Career path choices
      6. KPI and performance management choices
      7. Controls and governance process choices
      8. Values choices
    4. Supplier Choices
      1. Transactional supplier – business partner – joint venture partner
  1. Where you are uncertain about your judgements, use tools to analyse the situation and stimulate your thinking
    1. Value disciplines triangle – good for thinking about separation/integration issues
    2. Detailed process mapping – good for process work
    3. 7 wastes – good for process analysis
    4. Stakeholder needs/wants analysis – good for process, location, organisation and supplier work
    5. Process ownership grid – good for centralise, link and separate choices
    6. IT applications blueprint – good for information choices
    7. Customer journey and customer touch points – good for process and location work
    8. 5 whys – good for clarifying objectives
    9. Sourcing matrix – good for sourcing and supplier choices
    10. Eight requirements of good collaboration – good for sourcing issues
    11. Route cause analysis – good for analysis of problems
    12. Financial cost/benefit analysis – good for process and location work
    13. Simulations – good for business case and for working on agility
    14. 9 tests of good organisation design – good for organisation work
    15. Organisation modelling – good for organisation work
    16. Decision grids – good for organisation work
    17. Accountability framework – good for governance and performance management issues
    18. Culture web – good for values choices
    19. Ashridge mission diamond – good for values choices

Please suggest additions and offer thoughts:  this is an early draft of my thinking.  I expect it to evolve and hopefully improve.

Posted in Design steps, Design tools, operating model, Operating model choices, Processes, stakeholders, What to design | Tagged , , , , , , , , , , , | Leave a comment