Business Models and Operating Models

gistfile1.txt

Business Models and Operating Models
(This reading is assembled from blogs at ashridgeonoperatingmodels.com)

What is the difference between a business model and an operating model and who cares? First, I don’t think that it matters how you define terms like business model or operating model or business architecture. But it does help to be consistent. In this blog I will offer some definitions, not because I think they are more right than other definitions but because, in order to develop definitions, you need to think through all the moving parts.
For me a business model is the larger concept. An operating model is a part of a business model. An operating model is the engine at the heart of the business model that helps make the business model work.
A business model defines the following
- the stakeholders with whom the organisation will interact
- the offer or promise that the organisation is making to each stakeholder segment
(customers, employees, investors, suppliers, etc both internal and external)
- the contribution that each stakeholder segment is expected to make (work from employees, money from customers, etc)
- the resulting financial models (income statement and balance sheet) taking account of size and growth ambitions
- the operating model that makes it possible for the organisation to interact effectively with its stakeholders
An operating model defines
- the core work processes that are needed to create and deliver value to each stakeholder group
- the equipment and technology needed to execute these core processes
- the information systems needed to support these core processes
- other processes needed to support the core processes, such as financial processes or HR processes or governance processes
- the suppliers and supplier agreements needed to support the processes
- the people needed to do the work
- the organisation structure, decision rights, incentives and accountabilities and culture needed to ‘govern’, motivate and support the people
- the locations, buildings and ambiance where the core and support processes will be executed
Some people use the short hand of People, Process and Technology to describe an operating model. My own shorthand is PILOS – Process and equipment, Information and information systems, Location and property, Organisation, people and governance, Suppliers and business partners. 

More on Business Models and Operating Models
I recently came across Deloitte’s framework for business models and operating models (see exhibit below).   I was quite taken by the framework and began to think about what it is missing and why or whether my PILOS framework is better.   It is always good to keep challenging any framework you use because it can become a toxic influence on your work if it overlooks something or biases your thinking.
The first observation is that Deloitte uses the term business model to cover only the front end - the target customers, the channels and the product and service value propositions - whereas I use the term business model to cover the whole subject.  For me, the term business model is the big term – like strategy – everything else is a subset of business model.


However, Deloitte’s approach is similar to the approach in Enterprise Architecture.   The term Business Architecture refers to the front end of Enterprise Architecture.  Other components of Enterprise Architecture are Technology Architecture, Information Architecture and Applications Architecture.  I think Business Architecture also includes process architecture so it is not exactly the same definition as Deloitte.
Another difference is that Deloitte does not include people or people policies within its definition of operating model.  Deloitte has a separate concept: People Model.  At one level I like this idea because I think there are often some really interesting opportunities that come from re-thinking the people model.  For example, one IT services company set up its operating model to attract employees who were women working from home.  The company spotted that there is a lot of under-utilised talent in this people pool and designed a business to tap into it.  In the same way Eden McCallum developed a different kind of consulting company out of the observation that there are lots of capable people with portfolio careers. Mark Warner has built a business model around gap year students.
At another level, this separation of people model from organisation design feels odd to me.  I do not believe that organisation design should be done without taking account of the available people.  In other words the design will change depending on the people you have, particularly at senior levels.   So people and organisation are hard to think about separately.  Hence, I include both as part of my concept of operating model – although I like to encourage some separate focused thinking about the people dimension.
Deloitte’s framework is also missing some things that surprise me.   It does not include suppliers and business partners – for me a vital ingredient to the operating model.   It does not include intangibles, like brand and IP; which for me are also important (but I do not have a special place for them in the PILOS model either).  It does not include location, another significant part of the design challenge in my opinion.  Although, in Deloitte’s framework, location may be a subset of “physical assets”.  Possibly Deloitte also includes brand and IP under “physical assets”.
Finally, Deloitte’s framework does not include the financial model (nor does the PILOS framework!).   This maybe because Deloitte’s, being an accounting firm, see the financial aspect of the operating model as an integrated part of all the other choices – and hence all pervasive.  However, in my experience it is helpful to do some design work on the financial model as a separate step.   What are the ratios going to look like?  And, how do the ratios work so that there is a good profit margin and a good return on invested capital? 



The Open Group’s Business Reference Model

I have just come across the Open Group’s new white paper “World Class EA: Business Reference Model”.  EA stands for Enterprise Architecture.
I have not been able to extract the visual in their paper to share with you, so I will try to explain what this is about and give some comments.  The following is their text
“The BRM (Business Reference Model) is intended to facilitate description of a business model through five perspectives: 
• The Environment perspective addresses the context within which an organization must operate. It describes the external factors, such as the competitors, regulation, and customers for an organization, in addition to the overall strategy possessed by the organization for market positioning. This perspective is intended to describe why an organization is motivated to undertake particular courses of action. 
• The Value Proposition perspective describes the offering produced by the organization in terms of products, services, brand, and shareholder value. This perspective is intended to describe what impact an organization wishes to generate and how that will generate value for stakeholders. 
• The Operating Model perspective describes the resources at the disposal of the organization that will be deployed to generate the value proposition. This perspective is intended to describe how an organization will be able to deliver on its value proposition. Capabilities can be thought of as combinations of people, process, information, and technology that can be internally or externally sourced. 
• The Risk perspective identifies the uncertainties that may surround an organization in its delivery of the value proposition. This perspective is intended to describe the threats that face an organization from within and without. 
• The Compliance perspective represents the set of criteria that the organization must adhere to in order to assure that the value proposition is delivered using an acceptable standard of business practice. This perspective is intended to describe the constraints that prevent an organization from acting in negative, destructive, or inappropriate ways and the corresponding opportunities that can be exploited from a differentiated compliance position.”
The visual is five boxes with arrows between them.  The operating model box is in the middle.  Each of the five boxes contain more boxes.  The operating model box, for example, has six boxes in it – value chain, capabilities, governance, partners & ecosystem, finance and assets.   Compare this to my PILOS model (processes, information systems, locations and buildings, organisation and people, suppliers and business partners) and you get some differences.  The Open Group’s model gets at processes through “value chain”, information and organisation and more detailed processes are contained in “capabilities”.   Locations and buildings may come under “assets”.   “Ecosystem” is an interesting descriptor, but has some overlap with suppliers and business partners.   “Finance” for me is the result of the operating model and the value propositions, so is better considered outside the operating model concept.  “Governance” is a separate box in the EA framework, but for me is part of organisation and people.
So the Business Reference Model is another attempt to define what is meant by the terms business model and operating model.
There are a couple of other elements here that are worthy of comment – the risk perspective and the compliance perspective.   The risk perspective includes four boxes – financial, operational, strategic and controls.   It is not clear to me how this overlaps with or is separate from “governance” within the operating model box.   Risk is important.  Operating models deal with risk by controlling some decisions and imposing policies and constraints.  From my perspective Risk is a subset of “governance”.
Compliance contains five boxes – commercial, legal & regulatory, quality, safety and social responsibility.  Interestingly “ethical” risk/compliance (getting people to behave with integrity and avoiding the reputation damage that can be caused by sexual harassment or inappropriate sourcing) does not appear in either list.  Since I have just been involved in some research on “Tone from the Top”, I am rather sensitive to this compliance and risk issue.   It also demonstrates that there is a good deal of overlap between compliance and risk.  There also seems to be some overlap between environment and these two, since the law is part of the environment.
Having nibbled away at the five perspectives view, I do, however, think that the Open Group may be surfacing some perspectives that get too little attention in normal operating model work.   So my thought is this – compliance issues should surface when you take a full stakeholder view of the business.  Compliance is about living by rules set by stakeholders.  In fact a typical value proposition between a company and society is that the company will be compliant with the meaning of the law, not just the letter, and with normal good practice: this is part of getting a license to operate.
Risk is about uncertainties.  Maybe an operating model needs to be “risk tested”: define some typical uncertainties, consider what the range of possibilities is on each, and see if the operating model still works at the extremes of these uncertainties.


Operating Model Diagrammes
Not many people write simply about a subject like operating models.   So I am reproducing here a blog by Jonathan Hammond of Knadel.  Jonathan does a great job of demystifying the task of generating a good diagram of your operating model or TOM.  Thank you Jonathan, apologies for a few small edits. Unfortunately he does not provide any examples – maybe in his next blog.
“The objective of documenting the operating model is to communicate how the business works, or will work, both operationally and technically.  A good operating model diagram will also serve to identify operational bottlenecks; uncover responsibility gaps or risks; or highlight fragmentation of data management, systems or functions.
Many of Knadel’s projects involve documenting a business’s operating model; typically the target operating model (TOM), normally the current model and frequently both, with a number of stages in between.  Invariably we tend to use our own standards for documenting models and over the years our presentation has evolved and matured.
However, we do this with one eye on potential modelling standards and I’ve often trawled the internet to find a definition of an operating model diagram, and have regularly been disappointed (Me too Jonathan!).   I find myself inspecting example diagrams that fall into one of two camps;
extremely high-level diagrams where the information contained within the diagram (usually a functional decomposition) could equally apply to any business in that market segment, or
highly-specialised enterprise architecture diagramming techniques such as TOGAF, ARIS or Zachman; or BPMN for business process modelling.
Whilst these standards work well for their intended frame of reference e.g. a technical architecture or a business process hierarchy, I believe there still remains a gap in articulating the interrelationship between business functions, organisational design, technical architecture and data management. It is this interrelationship that standard diagrams seem to miss. In a company, functional decompositions, organisational charts and systems architectures often abound but rarely share the same underlying model or terminology or support for each other.  (This thought is the reason that I launched the Designing Operating Models workshop!)
Unfortunately no single diagram can communicate the full complexity of an operating model. Our approach is to provide a suite of related diagrams usually augmenting pre-existing organisational charts and systems architecture diagrams. These diagrams answer a number of questions using the same language and underlying model.
Who is responsible for what [function]? This is typically a Functional Responsibility diagram. A Functional Responsibility diagram apportions a business’s functions and activities either to internal parties (e.g. departments) or to external providers. It’s important to realise that in such a diagram functions may be split/duplicated and thus scope of responsibility must also be represented. Outlining functional responsibility is particularly useful when measured against a Capability Map i.e. who is capable of undertaking functions and what’s their capacity to do so. In sophisticated cases functional responsibility diagrams have a temporal aspect i.e. who is responsible for what and when. (Jonathan, I think you are talking hear about something that is a mix between an organisation structure and a value chain map?)
What functions are supported by which systems (and by inference which functions are not supported)? In the absence of a better term this is an Operating Diagram. An Operating Diagram is usually focused on a distinct business cycle over an extended period (e.g. a trading cycle, a reporting cycle etc) and covers all the functions involved, the systems that support each function, and the data used. This is clearly a complicated diagram and must be targeted to maintain legibility.
Where is data mastered, managed and distributed? Mention data diagrams and this usually conjures up images of technical database diagrams. These modelling languages show how data is structured within a system and are too low level for operating models. We endeavour to show how data is sourced, managed and distributed across systems. We typically refer to this as the Data Management diagram. Stylistically it is closely related to a systems architecture diagram but extends to functions not supported by automation. We also show data flows on Operating diagrams.
These are but a few of the diagrams that we use and I fear I may be leaving you with a whetted appetite, unsatisfied that I have alluded to diagramming methods without sharing them (Yes Jonathan – which is why I have asked you to come and speak on the course!)  For the time being the message is ‘if you’re interested then get in touch’. Otherwise it’s watch this space for more information as we’ll share more in the future”.
While I don’t think that Jonathan’s three types of diagrams cover the full waterfront – what about geographic maps, what about stakeholder maps, what about process hierarchies, etc – I like the humble yet practical tone.

Business Models and Business Architecture
In a recent LinkedIn discussion within the LinkedIn group “Operating Models” there has been a good thread about ways to draw operating models, methods used to draw operating models and the definition of what is an operating model.  I recommend the thread.
In this blog I want to share one response to a proposal I made that we interpret the term Business Architecture as meaning the same as the term Business Model.  In my understanding, both terms include as one of their elements, the operating model.   This response from Steve Kerzman provides a lucid alternative view.   Thank you Steve: as always apologies for the edits.
“I don’t agree with you Andrew.  I would argue that Business Model and Business Architecture are two different things, although I have seen some people include the former under the latter.
My experience of the term Business Model is that it is most often used to describe the strategy for how a business will make its money; e.g. we’ll sell razor blade handles cheaply at little profit and then make our money on the supply of the blades to our ‘captive’ market of customers owning our handles that are incompatible with other blade suppliers. As such I see it including a strategic definition of things like markets, customers, channels, products/services, pricing, etc.
In my version of model hierarchies, a business architecture takes these and other statements of strategic intent as inputs and interprets them in terms of what operational business capabilities and value chain(s) will therefore be required to successfully achieve the vision/strategy.  Business architecture deals with a number of dimensions such as processes, metrics, organisation structure, technology, etc. As such I tend to see business architecture and target operating model as largely synonymous concepts….although I’m sure others may see it somewhat differently. [So Steve is suggesting that the term business architecture is similar to the term target operating model and that its starting point is a business model/strategy.  Whereas I see business architecture covering business model as well ... in fact I consider an operating model to be one of the parts of a business model]
“Continuing down the hierarchy, I see detailed business processes, ways of working and the like, which may have been defined using value stream mapping, BPR and other analytical assessment and redesign techniques, underpinned by what-ever management philosophy and tool-set is most appropriate or preferred (e.g. Lean Six Sigma and DMAIC). These most often are accomplished in a programme of related projects, each of which will implement their portion of the relevant procedures, systems and other artefacts, all of which are made coherent by the overarching business architecture or target operating model. [I think we agree here - the broad business processes are defined using tools like value stream mapping and then the detail is worked out in projects that should be part of a bigger programme.  The bigger programme is kept aligned by the overall model]
The business architecture in turn also provides the upwards assurance that the delivery of project outputs will collectively correspond and add up to the outcomes defined by the original statement(s) of strategic intent. These are often expressed as elements in a business case.  These elements are part of the terms of reference of each project as administered by the programme.
I also agree that the term ‘architecture’ is generally poorly received and understood by most management team members who tend instinctively to place anyone using it in a sort of ‘techie nerd’ pigeon hole. Their next reaction then often being to shunt said person off to talk to the IT guys…..and that ‘labelling’ unfortunately frequently also has the related effect of reducing that person’s ‘business’ credibility with the board and other senior management. [We agree here, although things may be improving]”
What I like about this contribution is that it illustrates well the language and definition confusion that we are in.   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;
- to deliver this strategy you need capabilities;
- the capabilities involve processes, people, technology, locations, buildings, machinery, working capital, brands, suppliers, etc;
- finally the people require organising into structures, governing, motivating, performance managing and ennobling with values.
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.
What we all find difficult is to develop a set of words for describing this stuff that is not obscured by jargon or so constraining that it gets in the way of innovation and uniqueness.

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.  
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. 
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’……”