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.
1
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
2
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
3
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”.
4
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;
5
1. 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
2. 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 preexisting 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
6
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
7
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.
8
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
9
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’……”
10