The following is stolen from a post by Peter Murchland in a discussion group in LinkeIn’s The Enterprise Architecture Network. Thank you Peter and apologies for the changes I have made to your insightful comments.

In a new organisation, the first sign of an operating model is usually the Chart of Accounts – a common structure understood across the enterprise for managing and organising the enterprise from a financial perspective. This is needed by the sole trader for tax purposes, and grows from there, to ensure consistent application of the categorisation of income and expenses. This is typically a top down effort.

The next sign of an operating model is usually the job specifications, which establish clarity of roles and responsibilities.   This normally starts as a bottom up process.  New hires want to know what their job boundaries are.  It may take some time before a  top down perspective in the form of an organisation chart is developed.  This is because the top team have probably been working well without a formal organisation chart and hence do not easily see the need for it.

The next sign of an operating model is likely to be some definition and documentation of critical or common processes, ensuring that people performing these processes attend to critical steps and that hand-offs are clear between steps in the process and between processes. This tends to be more bottom up than top down.  It becomes top down when the processes are identified as part of a process architecture or a capability map.  Many organisations never develop this top down perspective.

As the organisation gets more complex, a particular challenge arises with multiple IT systems.  Each IT system will have documentation in a bottom up sense, but a top down perspective becomes essential to record the portfolio of systems and the connections between them.

So the top down perspective of an operating model often starts in the finance function with the accounting structures and rules, and the definition of legal entities and profit centers.  It may be supported by an organisation chart and related job descriptions. It will probably be further enhanced by a document defining decision authorities of different people or different levels in the organisation chart.  But the main impetus for documenting the operating model is likely to come from the IT function as a result of the need to lay out the different IT systems and how they connect together.  It can also be driven by a business processes or operational effectiveness function as a result of the desire to lay out the process hierarchy.  But, since much process work is about improving individual processes rather than developing an overall model, process architectures are less common that one might expect.

This is why an operating model can be viewed through a number of lenses – the accounting and legal entity lens, the organisation chart lens, the process lens and the IT systems lens.  There are additional lenses also: the buildings and locations lens, the supplier and business partner lens (really an extension of the process lens) and the career paths and people development lens.  The danger with the Enterprise Architecture community is that most of them come at the problem primarily from the IT systems lens.  As a result, their work can be a bit lopsided.

John Tieso helped illustrate this more informal evolution of an operating model in the same discussion group.  Thank you John and again apologies for the edits.  “I did some work with a very small firm recently. The two principals believed in documenting their major processes, procedures, and practices so that, as they grew and their processes needed to evolve, they had the documentation ready to discuss change. In fact, every Friday over lunch and into the early afternoon, they dedicated time to reviewing how these process, procedures, and practices were working, and what they needed to change or re-document.

One of the principals had done some modeling as an analyst with another firm, so he was used to creating simple models to accompany the written documentation–nothing fancy, just workflows and data flows.

They asked me whether they needed an Enterprise Architecture (or in my (Andrew’s) language an operating model). Basically, I told them they had one.  They had a simple set of models–their major processes, their organization, their network, and their links to their clients. Each procedure and practice was documented and linked to the high-level models. At their level, they really didn’t need anything else. Their business plan gave them at least three years before they would begin to hire niche personnel, such as a CIO, HR lead or a business processes expert.  In the meanwhile, they could use their Friday quality time to maintain their operating model.  They  needed nothing more complex than this for success.”