Today I was asked an interesting question. How can one engage senior managers in the importance of doing operating model work? My answer was that this is the wrong question, and I gave the analogy of a carpenter. If someone needs the help of a carpenter, they do not want the carpenter to try to persuade them of the importance of understanding the grain of the wood or the importance of measuring twice and cutting once, or even of the superiority of a tungsten tipped chisel versus a normal chisel. They want the carpenter to fix the door or make the cabinet.
So, what does this mean for someone who is good at operating model work, who is approached by, for example an operations director for some help.
First, I would try to understand what help the operations director thinks he (or she) needs (if any). How does he perceive his problems or challenges or opportunities? From his perspective what is he trying to do; what does he think is getting in the way; and why does he think he needs some help?
Lets say that the answer to this is that he wants to review the degree of centralisation of powers (decision rights and controls) and of certain capabilities because he thinks it might save cost and raise quality.
I would then construct a work plan including some diagnostic and some facilitation and some analysis of options designed to help him answer the question he wants answered.
However, as part of my diagnostic, I would put together the current operating model for his area – a stakeholder analysis, the value propositions for his core stakeholders, the value chains that deliver these value propositions, a value chain map, an organisation model and an Operating Model Canvas. This might be no more than one day’s work laying it out at a high level, but is likely to take some elapsed time to collect the information needed. I would then use this understanding of the current operating model to think about the changes that he is trying to make and the ambitions he has, and note how many different parts of the Operating Model Canvas any changes are likely to need to “touch”. In other words, I would try to understand and consider the whole system.
I would then work up some options that address his primary concern. I would then engage him (and others in Operations) to see which options they think will be effective and why. At this point, I might start to feed in some of my thoughts about other parts of the operating model that might need to change in order to make each option work.
Assuming there is a favoured option, I would then try redesigning the whole operating model (so far as I think it needs to be changed) to ensure that the whole system will support the proposed change.
Then I would make a recommendation that, alongside the change he is focusing on (e.g. greater centralisation of engineering), he should probably also be thinking about other changes that will support it (such as, changes in structure, changes in people models, changes in location, involvement of new suppliers, additional IT systems, changes in the management processes he uses to run the function).
In other words, I would not try to get him to define the brief as an operating model project unless he wants to; and I would not try to get him to define the phrase “operating model” along the lines of my definition unless he wants to; but I would use my knowledge of operating models and my toolbox to ensure that the final recommendation involves all the changes needed in the system he is running to give the best chance of achieving what he is trying to achieve.
I would hope that the experience would help him (or her) see the benefit of thinking about and communicating his operating model – rather than just focusing on some part of the whole that needs to change.