I have just come across an article Peter Murchland wrote on LinkedIn giving his definition of an operating model. I have copied chunks of his text because he provides a different perspective to my PILOS model (which is about to become POLIST!). Peter takes more of a systems perspective and emphasizes elements like “resource management” and “development management” that I give little time to. As you will see “operations management” is only one of four systems in Peter’s model, whereas I focus on operations management and treat the other systems as secondary issues.
As I have explained before, there is real value in exploring other people’s frameworks, because it helps make you less confident in your own framework and hence less likely to stick to it when circumstances call for something different.
The primary purpose of an operating model is to express the means by which an organisation:
- pursues its enterprise
- realises its goals and aspirations
- achieves and sustains viable operation
There are four key systems forming the expression of any enterprise-as-system that I consider:
- Operations management system
- Resource management system
- Governance and management system
- Development management system
For many years, I have only addressed systems 1 to 3. Typically, I have not addressed the development management system, because:
- I was usually part of this system
- the development management system was usually embedded in the other systems
However, with the increasing degree of change, I am finding that more enterprises are recognising the development management system as a distinct system. This can be seen in John Kotter’s article – Accelerate! – where he outlines the case for a dual operating system. It can also be seen in the increasing profile of Program Management in enterprises and in enterprises where they have established a Chief Operating Officer and a Chief Change Officer.
This system is the core system which produces the products and/or services of the enterprise. It is most commonly represented as a value stream, reflecting the core capabilities by which the enterprise transforms inputs into outputs and delivers value to its customers and consumers.
This system may also include support systems which are not part of the primary value stream. These may be systems which require specialist capabilities and are required by different systems in the value stream and deliver internal products and services beyond those provided as part of resource management.
Resource management system
This system manages each of the resource types required for successful operation of the enterprise. At a minimum, this will encompass:
- Human resource management
- Financial management
- Information management
It may also include:
- IT management
- Asset management
- Procurement, contract and materials management
- Record management
All enterprises require governance and management.
With respect to governance, I have drawn on the Tricker Model which is one of the models covered within the Company Directors Course run by the Australian Institute of Company Directors. By drawing on this model, I know that there are many Directors and Boards who will be familiar with the model and therefore comfortable with the subsystems that I include:
- Accountability and reporting
- Performance reporting
- Strategic risk management
To date, I have not modeled the management system. It seems to be adequately covered by the management embedded in each of the systems that I consider. I have included reference in this area – governance and management – to allow for inclusion of additional capabilities that become evident and require attention beyond those evident in all other areas.
This system supports the development of an enterprise and effects change in any of the systems. Change may derive from strategy, as the means by which strategy is executed, or from individual systems as part of continuous improvement. It includes:
- Architecture management
- Program management
- Project management
- Change management
- Program and project support
I view change through a lifecycle lens taking change from idea to realisation. Key steps include:
- Initiative formation
- Design, build and test
- Review and close”
So what is my (Andrew Campbell’s) reaction to this “system view” of an operating model. First, of course an operating model is a system, so aren’t all frameworks “system views”? I was brought up on the 7S framework, which I think of as a “system view”.
Second, I prefer to deal with the development system as an after thought. It is hard enough designing a good operating system, let alone designing an operating system that is simultaneously evolving to something different. I agree that organisations need the ability to redesign themselves, but, in practice this happens through transformation projects rather than through a development system (I write these words timidly because I am not very confident I am right).
Third, I don’t find the idea of a resource management system very helpful. Each step in the value chain will have resources and will need to manage them to execute its work. So I see resource management as part of operations. Also, Peter comments that the operating system can include support systems. I consider HR and Finance and IT as support functions that run support systems rather than as resource managers. I know that quite a few frameworks distinguish resources from processes or organisation, but I am not sure this is helpful.
Third, Governance is a topic that I subsume under “organisation”. Interstingly, Peter does not place decision authorities under governance (in fact he does not seem to have a place for decisions authorities), which for me is the core of governance. On the issue of performance management, I have found it necessary to add “Management Rhythm” to cover the planning, decision making and performance management processes used to run the organisation … which clearly has an overlap with governance. But also has an overlap with the project management element of Peter’s “Development management system”.
Conclusion: There are lots of ways of slicing the cake. As long as you are aware of two or three ways in which people like Peter and me slice the cake, you should feel confident slicing it your own way because you are unlikely to miss out anything important.
Thanks for your review and feedback on my way of slicing the cake. It has prompted me to elaborate further on a couple of aspects – and I have started by outlining the thinking behind the “development system”. The short version is that my conception of the development system is that it includes the development and delivery of transformation programs.
Thanks Peter. My concern with this conception is that you are giving equal billing to “the process of identifying and running transformation programs” as you are to “the process of creating and delivering value for customers”. This feels wrong. The process of delivering value surely is centre stage and all the other activities/processes are add ons. So for me it is a matter of relative importance.
Andrew – a couple of different angles on the model and viewpoint I have offered.
a) There is nothing that says all enterprise systems must have equal billing. That is an inference you are applying that is not inherent in the viewpoint that I have outlined.
b) Relative importance depends on the context and criterion in play. When considering market differentiation, then customer value will always override transformational capability. When considering enterprise performance both will be important – as the enterprise will not succeed by delivering products / services which are not valued, but it will also not succeed if it cannot successfully transform to deliver the required products / services – unvalued visions / service offerings are no better than undeliverable visions
c) The nature of business model and operating model is such that they can be applied to any level of system – enterprise-as-system or operations system – so I am quite comfortable with holding either view – one just needs to be aware of which is the intended scope in any discussion or document. Perhaps, this is one point of different between operating model design and enterprise architecture – you are focused predominantly on the operations system, I am focused on the entire enterprise?
Thanks Peter. I think we are both focused on the entire enterprise. So it seems to be more of a levels issue. At what level do you start focusing on transformation or governance. For me, the first level is operations with only a limited amount of attention given to things like transformation and governance. After all I am doing the operating model work to see if any transformation is needed, so it feels odd to have transformation processes at the first level of analysis.
Then at a second or third level of analysis, I would bring in the detailed thinking about a Transformation Function or governance processes.
So we do not disagree, other than in the best way to present the topic. I prefer to focus on operations because this is what I think that senior executives are most concerned about. Of course sometimes they are worrying about IT or HR or Transformation and then I would do a focused operating model for this activity (having done a rough operating model at the higher level first … in order to make sure I understand the operating system context).
Thank you for contributing – I learn every time I am forced to explain why I do something – either I understand better my own thinking or I discover I am making some inappropriate presumption. Here I think it is just a matter of preference and audience.