Value Streams, Context Maps and Process Maps

I have just been reading a 2013 article by Mike Rosen of Wilton Consulting Group about “context maps”.   I don’t like the name, but the article does quite a good job of laying out a flow of analysis that is likely to be useful to most of us.

Mike Rosen starts with a “value stream” – which in my language is just a value chain – a high level list of the steps needed to deliver value to a customer.   In this context, customer can be external or internal.

The next step is to produce a “context map” – I think I would call it an “actors and interconnections map” or something like that.  The map involves defining all the actors involved in the value stream – customer, supplier, and different departments or people – as well as any systems that react when contacted (like a website or portal).   Then the interconnections are defined between each actor – who does what to whom?  These are drawn on the map as lines between actors with an arrow showing who has initiated and to who.  Against each line you can write the nature of the connection, often one person asking for input from another.  I have not been able to copy and paste the diagram in Mike’s article – so go to his article to see an example.  [I figured out how to copy the diagram – thank you to Mike]

Slide1

As Mike explains, the “actors and connections map” emerges as you follow the flow of activity from someone who starts it off.   You may not be able to define all the actors first, and then put in the connections.  You may find it better to follow the flow, adding actors and connections as they occur to you or those you are working with.

With this interconnections map, it is then much easier to draw a swim lanes process map: which shows how a process moves between different actors over time.  The interconnections map lists all the actors and shows the flows – so it is really little more than a translation from one to the other. (see below)

Slide1

In my thinking about operating models, I have tried to remain strategic and not get drawn into too much detail.  Clearly value streams, context maps and process maps are detail.   But, now that I am pretty clear about how to do the high level strategic stuff, I am getting more interested in the detail.

Posted in Design tools, Value chain | Tagged , , , , | 1 Comment

Value chain maps or capability maps?

Posted in Capabilities, Value chain | Tagged , , , , , , , , | 3 Comments

More on value chain maps

At the recent course I run, Designing Operating Models, Mark Lancelott and I put our views on the importance of value chains to the test.   We started the tools part of the course with the following exercise

1.  Choose a part of your business to focus on that has more than one product/market segment (or customer segment)

2. Identify the different segments – not more than 4 or 5, so that the analysis is doable in 3o minutes

3. Draw up the value chain for each segment – not more than 4 or 5 steps in the value chain, so that the analysis is doable

4.  Compare across the value chains looking for similar steps where there are economies of scale that mean the steps should be “aggregated”, or opportunities to standardise that mean the steps should be “linked” or opportunities to differentiate that mean the steps should be kept “separate”.

We used some different language on the course, but the meaning was the same.  The exercise was a big success and started a snowball of energy amongst the group for operating model tools and work.

It confirmed that value chains are the best way of starting work on operating models (at least for those not familiar with other ways such as that used by Enterprise Architects) – see example of a value chain map ..  I think, in this example, red meant “centralise”.

Value chain map 3

In another example we looked at a business in central Africa.  The business had four product segments and operated in five countries.  We tried doing the analysis for the four product segments and concluded that every step in the value chain should be “aggregated”: there were in our judgment important economies of scale in manufacturing, marketing, distribution and sales.  But this then raised the question of at what level to aggregate – at the country level, at the central Africa level, at the Africa level or at the world level.  So we did the analysis again across the four countries.  This time it made sense to aggregate some activities, like marketing, at the central Africa level or above.  But other activities, like sales, should only be aggregated at the country level.

A different group started by looking at three completely different product areas within one company.  They quickly concluded that all parts of the value chain should be separate.  This made them less enthusiastic about the analysis.  But then they tried a second example where it was clear that manufacturing should be centralised and sales should be separate and in other functions there were difficult judgments to make.   The two examples helped them see the power of the tool: sometimes the operating model is simple; often it is complex and requires difficult trade-offs.

This is pretty simple analysis – but powerful in its simplicity.  In 30 minutes a group of 6 people understood many of the operating model challenges of the businesses they analysed, just by doing a simple value chain map.

Try it on your business.

Of course an operating model is much more than a value chain map – but it is a great place to start.

 

 

Posted in Value chain | Tagged , , , , , , , | 4 Comments

The importance of starting with value chains

I am siting in Singapore overlooking the straights from Sentosa Island, about to contribute to a conference. (Sorry to boast but the view is … distracting)   But still time for a blog on operating models.

Singapore1

Mark Lancelott of PA Consulting and I were together recently to discuss two things – how to turn strategy into something that is useful for designing operating models and what are the steps in the design process.   This blog is about the second of these two issues.

We are both of the view that you (we all) should start with value chain analysis (see recent blog on this).   For those who are not sure what I mean by value chain – then I am using Michael Porter’s concept – which is just a high level process map.  But the key is that the focus is on the prime operational steps needed to deliver value.  (There are a couple of other blogs on value chains – look under “categories”)

Value chain analysis however is best done after you are clear about some things.   First, the product/market segments you are trying to serve.  This comes from strategy.  Second, the basis of advantage that you are trying to exploit or build.  This also comes from strategy.  Third, design criteria or design principles (see previous blog).  So more about these thoughts in future blogs.

In theory, one should define the value chain needed to deliver value to each of the product/market segments.  Unilever apparently has 300,000 product market segments – so, if it takes 10 minutes to do each value chain, the analysis would take nearly three years of work.  Hence I say, in theory!   In practice it is usually possible to bundle product/market segments to a manageable number.  But, always be ready to go into more detail.

So, lets assume there are 6 product/market segments with enough difference to be worth drawing a separate value chain for each.   Lay out these six value chains and look for value chain elements in common, elements where economies of scale are possible and elements where similar work is being done that could be standardised.  So the next step in the analysis is to decide where similar elements could be combined into one (centralised) or done in the same way (standarised) or linked in some way (linked).  These choices are really strategy choices.  So it is important to refer back all the time to the “basis of competitive advantage”, and to check whether any decision that is being taken is likely to reinforce (good) or undermine (bad to the point of don’t do it) the basis of competitive advantage.

Having worked through these centralise, standardise or link elements, the next step in the analysis is to assemble the elements into an organisation model, with reporting lines and, if needed, matrix structures.  There will be a number of different ways of doing this.  So the process is one of laying out the options and then choosing the best, given the design principles that you have developed as one of the outputs of “strategy”.

Initially the organisation model will only have the operating work defined. It is then helpful to add into the organisation model the supporting functions that will be needed – finance, HR, IT, linking functions, standardising functions, etc – as well as the governance committees and decision powers.

After this, proceed as per my earlier blog – describe each box on the chart as a capability (best to do this when laying out the value chains).   Think through what is needed to deliver each capability – people, process, technology, buildings, locations, IT systems, culture, governance, etc.  Start with whichever of these is most important to the work you are doing – but remember that they all need to align.  So just focusing on IT systems for example may leave your thinking unbalanced.

And, hopefully in less than three years of work, you will have a target operating model …. simples! (for those familiar with the meerkat advertisement)

Posted in Design principles, Design steps, Value chain | Tagged , , , , , | 1 Comment

Change operating model or business model?

I just had to share this post with you, by famous author Geoffrey Moore (remember Crossing the Chasm?).   I am not sure I agree with it, and my definition of business model and operating model may be a little different from his, but I was challenged to think hard by the following (apologies for my edits Geoffrey – see original here):

  1. It is a good thing to disrupt your operating model whenever next-generation technology can help you unlock trapped value in outmoded business processes.
  2. It is a bad thing to disrupt your business model, even when your sector is under direct attack by a new entrant who is doing just that and eating your lunch!

The first of these two changes can contain some bitter medicine that gives you grief and certainly entails execution risk, but at the end of the day it makes you a better, stronger company. The second is simply toxic. Here’s why.

All established enterprises leverage their ecosystem of partners to complete their whole product and amplify their market reach. The net result is a micro-economy in which each company helps create opportunity and value for every other company in the mix.

Changing a business model mounts a direct attack on this ecosystem.

So what? Well, it turns out that most of your company power is invested in that ecosystem. Without it, frankly, your value to your customer base is much less than you might be assuming. Even if you keep your customers from churning, you will find yourself having to field service requests that never used to come to you. And at the same time, you will be asked to perform with excellence against the standards of the new model, standards you did not invent, are not familiar with, and probably lack the talent to execute productively.

The key point here is that business, regardless of sector or vertical industry, is much more of a team sport than we normally acknowledge.  Business consultants who advise companies to embrace business model disruption are staggeringly naïve.

The disrupters may be getting a big advantage out of the new model.  But there is nothing here for an established enterprise to grab hold of without sacrificing its own crown jewels.”

I have observed the difficulty that incumbents have in reacting to new business models.  I have observed the distraction costs that they face: when they try to do new things, their core business often suffers.  But I have never thought of it in terms of destroying the value that has been built up in the existing ecosystem.  I don’t think Geoffrey’s advice is right for  all situations.  But it is something to think about … hard.  Thank you Geoffrey Moore

Posted in Business model | Leave a comment

Building up an operating model

Mark and I had a really strong group for our operating models course last week.   So we learnt as much as they did.  We had the chief executive of a business, a consultant from Capgemini, another from Grant Thornton, a business architect, a head of HR services, a head of organisation and operating model design and so on.

The experience caused my mind to go into overdrive …. and I think I may have solved something that I have been wrestling with for years (well for 18 months!).  The issue is about the sequencing of operating model work.   My thoughts are much stimulated by Jonathan Hammond from Knadel, who made a presentation to the group towards the end of the first day.  My idea is this.

Start with a value chain map – that shows the core work of the organisation and whether it is one value chain or multiple value chains, and, if it is multiple value chains, where there are overlaps and common steps.

Then create an organisation model: an organisation chart with relationship information on it, laid out in a particular format.  See article at www.ashridge.org.uk/aod.

Then expand the organisation model into a “capability map” or “work to be done map” by identifying the work to be done in each box of the organisation chart.   Initially start at quite a high level of detail, but more detail may have to be added as you get to the next step.

Then overlay onto this map the software applications that are needed to support the “work to be done” and draw on the data flows between software applications.   It is usually useful to add onto the map the suppliers and customers and any other stakeholders to whom or from whom there are data flows.

This final map then contains, at a high level, value chain thinking, organisation structure thinking and software applications thinking.  Jonathan showed us an example of this, which keeps coming into my mind.  Of course it is much too complex for an executive committee – but it did seem to capture most of the important stuff.

From here the work can focus on a variety of things.  It could focus on people: what sort of people are needed, how will they be motivated and developed, etc.  It could focus on locations and assets: where will the work be done, what infrastructure or other assets are needed to support the work. It could focus on suppliers and business partners: who will the suppliers be, what will we do and what will they do and what terms will be in the contracts with them.

If you are doing an “as is” or a “to be” operating model, getting to the final map should take weeks rather than months.   At a very high level, it should be possible to complete the value chain map, organisation model, organisation/capabilities model and capabilities/applications model in a day, if you have the right people in the room.  As you add more detail, start to wrestle with differences of opinion and seek to gain the involvement and understanding of a larger group, the time grows exponentially.  So it may take three months to get down to the fourth or fifth level of detail.

So then my remaining issue is how to represent the operating model to an executive committee.  This is where the Operating Model Canvas comes in.   I blogged about this some months ago, but have done very little work on it since.   The benefit of the OMC is that it captures the value chain map (under “activities”) and the organisation model (under “organisation”) and still has space for thoughts about people, IT systems, locations, buildings, other assets and suppliers.

I feel as though the holy grail is within sight!   But I need to blog on how to convert strategy into something useful for those doing operating model work and the Operating Model Canvas.

Posted in Design steps | 6 Comments

Hoshin Kanri and Operating Models

This blog gives a link to a presentation on Hoshin Kanri, Balance Score Card and Value Disciplines and on how they all link to operating models.   In particular the presentation shows how companies with different operating models will have different “breakthrough objectives”.

The presentation is by BMGI a consulting company focused on implementing strategy.  The sound is a little fuzzy – and I have not yet found this presentation on YouTube.   If you like it, you may be able to find it on their website.

Why am I sharing this with you?   Because I like to see how other people put together their ideas …. and I think you ought to also want to know how others think.   I am interested by the link that is made between value disciplines and generic operating models.   This is a link that I make on both my organisation design course and my operating models course.

The presentation also shows how strategic planning and transformation and “daily management” link together.  At one level, this process is little more than “management by objectives”, but Hoshin Kanri has lots of followers, so it is worth understanding how it works.

The presentation also weaves in the balanced scorecard and shows how the four views of the balanced score card can help understand differences between operating models.

Unfortunately it is delivered at a fast pace and is not always fully clear – but still worth viewing.

http://www.bmgi.org/training/webinars/aligning-your-operating-model-and-breakthrough-objectives

Posted in Design tools, Strategy | Tagged , , , , , | Leave a comment

BCG’s approach to operating models

The Boston Consulting Group recently produced a report on the asset management industry.   The report has all sorts of insights about this industry, but it also has interesting material on BCG’s approach to operating model thinking.  I include a couple of BCG’s exhibits below.

BCG operating model exhibit

This first one lists the 12 elements of an operating model that BCG thinks are important.  I am always interested in how other academics and consultants think about this issue, partly to see if I have missed anything, partly to see if they have missed anything and partly to challenge my own thinking about the relative importance of different aspects.   For example, BCG has an item “coaching and enablment” that is rather unusual and intriguing.   So I must try to find out more about their thinking on this …. you will be the first to hear if I find out anything!

I also find their grouping of some items under “work structure” is unusual.  Footprint is I think the equivalent of my “locations and buildings”.  The shared services issue, which is important, comes under my organisation modeling tool that also deals with structure.  I am not sure what is meant by “workload balancing”.  Another topic I need to follow up on.

I quite like the idea of putting processes and technology together because they are often highly intertwined: many processes are being delivered by technology.  But I am not sure about having “process redesign” as one of the twelve elements of an operating model.  Feels to me more part of the process of designing an operating model.

The way you think about an operating model influences the factors you focus on and the way you analyse.  So it is an important factor – as can be seen by their next exhibit

BCG operating model asset mgt

The issues that BCG have chosen to focus on are influenced by their belief that asset management activities can be usefully divided into front office, middle and back office and data, as well as by their split between processes, work structure and organisation.

My experience tells me that you need to develop these frameworks to suit the situation rather than use a standard framework for every situation.   Since the framework biases your thinking, you are better with one that emerges out of the situation than one that you impose on it.  This means that you should have your own starting framework, like my PILOS model,  but be enough aware of the many other frameworks that exist to be able to tailor one for the situation you are in.  This is definitely a black belt skill rather than a beginner’s skill; but I do meet very experienced people who insist on arguing that there model is best.

Finally BCG offer some alternative types of operating models.   I like the intention here.  It is really useful to have some archetypes to help you think about the situation.  But I don’t find these easy to get my mind around or understand the differences.   I would encourage anyone designing a TOM to do this thinking – lay out some of the alternatives – just as you would when doing an organisation structure project.  But note that this is not easy work – especially when trying to communicate with others not involved in developing the alternatives.

BCG asset mgt 2

Posted in Design tools | Tagged , , , , , | 1 Comment

Business process hierarchy and operating models

Here are three charts that I have stolen from Paul Harmon’s blog at BP Trends.   Paul I have not asked permission, but if you object, I will take them out and just refer people to your site.   So please go to Paul’s site to find out more.  In fact you need to go to Paul’s site to see the charts properly because they are a bit blurred here.

The first chart is about the levels of processes that exist in an organisation.   It is such a simple chart, but powerful for its simplicity.

Slide1

As Paul points out, process work often starts at level 4 or level 5 (you may not be able to see, but level 6 is activities within level 5 processes).   Starting at this level makes it hard to see the connection to higher levels.  “The key thing is that we begin with a top-level overview, not a specific, low level process.  Starting at the bottom can work if you are trying to improve or automate a specific set of low level activities, but if you start there, its very hard to work upwards to tie the specific low-level process to the goals and KPIs  of the organization.”  So Paul likes to start with the high level picture and work down.

This brings us to Chart 2: the high level picture that Paul might use with a senior executive.  For me, this is a high level operating model.

Slide1

What I then like is Chart 3.  Paul likes to take each value chain and do an operating model sketch of this value chain with the stakeholders on the chart.  I am particularly keen about the benefit of listing all the stakeholders.  I am slightly less enthusiastic about the specifics of Paul’s chart, but the idea is right.  It would be more useful if he had kept the same example going throughout all three charts.  But they are still good charts.  As Paul explains “For each major stakeholder-value chain relationship we define, we go on to define the process that supports that stakeholder.  We also define what the stakeholder expects from the value chain.  These expectations, in tern, translate into measures that we will use to evaluate the value chain, and to later evaluate the effectiveness of any changes we make.  Management values ROI on capital.  Customers value quality of product and good service, while employees value career opportunities, and so forth.”

Slide1

Posted in Design tools, Lean, Op Excellence and Op Model, Levels of design, Value chain | Tagged , , , , , , | 3 Comments

More on Business Models and Business Architecture

I thought it would be helpful to add some of the further comment from the LinkedIn thread on diagrams for operating models. This is for those interested in the issue of language.  See the first blog on this.

In the LinkedIn discussion I upgraded my summary of what we are talking about in response to some challenge from a participant called JD.  The summary was my attempt to be jargon free!

I think everyone is talking about the same stuff:

* you have a strategy that focuses you on certain products and markets and channels and pricing and value proposition(s);

* to deliver this strategy you need capabilities (bit of a jargon word);

* the capabilities involve processes, people, technology, information, locations, buildings, machinery, working capital, brands, suppliers, etc;

* many of the above elements need organising further. So processes need to be organised into a hierarchy or model, people need to be organised into structures, informaton needs to be organised into data models, etc.

All of this thinking needs to be done at a high level and at increasing levels of detail until you get down to the lowest level of detail such as sentences in job descriptions or code in software applications or terms in contracts with suppliers.”

First a comment by Steve Kerzman (with an edit or two),

“Having read your blog post I would agree that most of us are probably talking about (mostly) the same stuff but that the definitions, naming conventions and resultant hierarchies are fluid and can sound quite different. As I guess might be expected in a fairly nascent discipline.

But of course that does us all no favours with clients who just ‘hear’ complications and confusions between various practitioners. As non-cognoscenti clients generally don’t see it as ‘all the same stuff’ really (why would they) and can be forgiven for thinking we are all just spouting management techno-babble.

For my part I am reasonably ambivalent about whether business model is part of business architecture (or operating model), or encompasses it, or is something else…..the concepts involved just have to live somewhere in some form of appropriate and coherent framework. In my earlier post I was simply expressing the split I have most often come across and hence have come to use myself (based also on my experiences of what has worked best) in the absence of any firm agreement on terms and definitions. As ever the mileage of others may vary 🙂 ”

Here is a comment from Fiona Lamb (I have cut out bits that are not focused on the main thread in this blog) – thanks Fiona.

“Agree with Steve K that I’m reasonably ambivalent about whether a business model is part of business architecture (or operating model). What is appropriate & coherent to a particular organisation is what is important.  It’s not necessarily valuable to agree hierarchies etc to a low level of detail in a developing science (& art!). However, I do not agree that a business model = strategy.  The time frame of these views is usually different, strategic pictures being an evolving thing whereas a business model can be very exact indeed. Also, very much agree with Steve K that each construct forms part of a translational bridge for the organisation (usually described as a transformation programme).

What we are doing, any of us working in this sphere, is helping to structure the thinking of organisations at a given point in time by giving tangibility to things we can’t see.   To that end I don’t think we should get too hung up on terminology & maybe it helps to focus on the generics of the science in this field & not forget some artistry is needed too, to create a scaffold for each organisation to help them to clarify their thinking at any particular point in time.” [I like the scaffold term!]

These comments contrast with one by JD Beckingham who is much more committed to a particular set of definitions (comments in square brackets are added by me)

“The reality is that Business Models and Operating Models are intended to address different things and serve different purposes. (We can avoid any “whose reality” questions by accepting that there is a very extensive literature on both business and operating models.) [Yes but it is very extensively confusing!]

In my opinion, there is no practical way that an operating model could be considered a subset of a business model. The best one could say is that an operating model is a superset of a business model.

Business models do not include actionable Business Strategy in any detailed sense. And yet, it is the business strategy which the operating model operationalizes. [This is where I got lost]

The operating model is, literally, a model of how we operate and contains all the information necessary to describe ‘how we operate’. Included in this information might be (in my opinion should be) links back to the business strategy indicating which aspects of the strategy are implemented/supported by the various operating model components.”

Then a calming thought from Steve Kerzman

“It seems to me that we all broadly understand what we are trying to help our clients do – enable them to achieve their desired outcomes by helping them structure their thinking and actions effectively. We probably also have a fairly common understanding of all the ‘atoms’ in the mix – products, channels, customers, processes, metrics, systems, data, security, etc and the place and use of approaches like lean six sigma, project management, etc. We would probably also agree on the broad sequence of activities in a transformation programme.

Where the wheels seem to come off the wagon….and I admit I am simplifying for clarity here…..is how we all define, cluster, order and arrange meta-concepts like operating model, business model, business capabilities, the various ‘architectures’ and so forth. Or am I being too simplistic? In a sense I guess I am broadly agreeing with Andrew. We all have a sense of what we are doing as per his bullet points…..we just don’t seem to agree on the ‘table seating plan’…… “

Posted in Business model, Enterprise architects and operating models | Tagged , , , , , | 4 Comments