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 demistifying 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;

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.

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.
• 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 – give us more!).  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 (Yes please!)”

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.