Many of our 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. I’m guessing that much of the traffic to this page will be seeking similar information. On my own digital expeditions 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 I believe there still remains a gap that articulates the interrelationship between business functions, organisational design, technical architecture and data management. It is this interrelationship that standard diagrams seem to miss. Functional decompositions, organisational charts and systems architectures abound but few share the same underlying model or terminology and very rarely do they convey support for each other.
Fundamentally, the diagrams need to articulate a complex model and no single diagram can achieve this. Our approach is to provide a suite of related diagrams usually augmenting pre-existing organisational charts and systems architecture diagrams. Our operating model diagrams bridge the gaps and are designed to answer a number of questions using the same language and underlying model.
- Who is responsible for what [function]?This is typically a Functional Responsibility 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 focussed 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 (ERD) 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 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. We continue to watch for developments in the standards for documenting operating models but in the absence of any endeavour to develop our own. 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.
Note: This opinion piece was first published by Knadel Limited prior to the Catalyst-Sionic merger
