I have recently had a most rewarding exchange with Mark Smalley, who is part of a group working on IT4IT (this includes an information architecture to help IT tools interact with each other and a reference model – “an IT value chain” – that will help leaders of IT functions create their IT operating models).  Of course, once my book on operating models – Operating Model Canvas – is available in March, IT leaders can use it instead!

The issue we were debating is whether a reference model should have one value chain or many (and if many – how many).  The IT4IT reference model only has one value chain – Strategy to portfolio (plan), Requirement to deploy (build), Request to fulfill (deliver), Detect to correct (run) – all aimed at one value proposition “efficiency and agility”.

Mark was explaining that this is a useful starting point for any IT team, who will then need to develop this value chain or define additional value chains as they work on their operating model.  I was expressing discomfort because I feel that a reference model for IT should show the model of a typical IT function, not a generic model that could be applied to any function that builds and runs solutions for organizational needs.  I suggested that the IT4IT reference model should have different value chains for the different categories of service that an IT function provides – ERP related, desk top related, communications related, etc.

This led Mark to ask a very difficult question.  If you go beyond one value chain, how do you know when to stop?  Do you create a separate value chain for every application?  “Revisiting your concern about IT4IT not distinguishing between IT’s different services, it seems a bit like saying that a publisher’s process model doesn’t distinguish between its different publications. Or Zara and its products. While the services and products differ, surely the process / value chain is more or less the same?”

Here is my response (with a few edits and improvements) – comments welcome.

“I also understand the point you make about Zara or a publisher.   But, it is here that my strategy knowledge is helpful.

If you take Ashridge Business School, there are multiple levels at which you can think about value chains

Highest level – market segment – open courses, tailored courses, qualifications courses, weddings, conferences, etc
Middle level – type of course – for example within open courses there are finance courses, strategy courses, marketing courses, etc
Lower level – type of session – for example within a course, there are sessions on different topics given by different lecturers

We could do value chains for all of these levels, or we could try to do just one value chain for the whole of Ashridge.  At the lowest level we would probably have over 1000 value chains.   So the issue is how do we decide what level is useful for helping translate strategy into operating model design?

The answer lies in the degree to which value chain activities need to be combined or kept separate organisationally for the purposes of delivering the value.  This in turn depends on the economies of scale from combining activities across value chains and the degree to which the value propositions for different services differ. We can easily see that you would not want the same people designing a wedding as designing a finance course.  We would probably not even want the same people doing the admin for both.  But we could probably have the same waiters for both.  In other areas, there are plenty of opportunities to combine without loss of unique value proposition: it will be OK to use the same marketing, admin staff and class room and even some lecturers on a finance course and an economics course.

With a knowledge of business schools, if I was doing a reference model for business schools, then I would distinguish between the value chains for executive open, executive tailored, MBA, undergraduate, conferences and community events.  Conveniently this is six value chains: a manageable number.  In my experience, it is usually helpful to start with a small number (but often more than one).  Why these six, because there is enough difference in the value propositions to cause large parts of the value chains to need to be kept organizationally separate (and the economies of scale are not large enough to demand combination).   I observe that one of the problems that many business schools have is a failure to distinguish organizationally between executive open and executive tailored, and I presume that this is because they have not done separate value chains for each and so do not fully understand the different skills involved.

As you can see the judgments I am making depend on a good deal of strategic knowledge about the differences between different value propositions, the skills required and the likely size of the benefits from economies of scale.  Unfortunately, I don’t think there is a way round this, and, as a strategist, I feel that trying to get round this will cause loss of connection with the business.

This is my point about a reference model for IT.  There is enough difference in the value propositions between, for example, ERP related, desk top related and communications related (and no dominating economies of scale) that these value chains should be  considered separately when translating IT strategy into an IT operating model (ITOM).  Not all IT teams will decide to keep them separate.  But many will, and it is important that the team thinks long and hard about whether to do so or not. The IT4IT reference model does not help them to do this.  In fact it infers that creating separate organizational units within IT to pursue separate value chains is probably not the right answer.”

Mark was gracious enough to respond: “Point taken Andrew, and I think that I’ll modify my ITOM presentation to accommodate this aspect. Thanks. I’ll also share it with the IT4IT forum”.

There is a lesson from this exchange that is relevant for any operating model.  Start by thinking about the customer segments and the value propositions.   Then develop value chains for each value proposition that you consider may be different enough to warrant some separation of delivery capabilities from the other value propositions. (But keep to a handful of value chains, at least to start with, because otherwise you will be come overwhelmed.) Only then think about what activities along the value chain to combine across value chains.  If it is obvious that all of the activities should be combined across the value chains you have defined because there are economies of scale and little difference in value proposition elements, then you are working at too low a level of detail.

What do you think?