Value chains, IT4IT and reference models

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?


About andrew campbell

Ashridge Strategic Management Centre Focus on strategy and organisation Currently working on group-level functions and group-level strategy
This entry was posted in Enterprise architects and operating models, Value chain, Value proposition and tagged , , , , , , , , , . Bookmark the permalink.

3 Responses to Value chains, IT4IT and reference models

  1. Peter Murchland says:

    One or many value chains?

    More than one value chain presents some interesting dilemmas as it introduces duplication of the support activities. What is the difference between one value chain with four value streams vs four value chains each with one value stream? Is it really a question of how many value streams more than value chains?

    Value chain vs reference model or both?

    IT4IT is a value chain reference model. It does not have an ERP related value stream because some organisations do not have ERP systems and therefore do not need ERP related services. A reference model will often require “customisation” for any particular enterprise.

    In addition, IT4IT is at a higher level than where an ERP related value stream would be visible.

    One of the values of value chains and capability models that I see is that they are agnostic of different dimensions – organisation, process, IT, etc – so any separation of value chains and capability models does not necessarily imply different organisational structures.

    • andrew campbell says:

      Thoughtful comments Peter – although I am not sure I follow your distinction between value chain and value stream. Is the latter just a value chain at a lower level of detail?

      Regarding ERP related, it is probably my clumsy language. I am referring to applications that need to be integrated into an enterprise system. There are few organizations who do not need this. But, I agree, there are some.

      I am not sure it is value chain versus reference model – it is just that I would prefer a reference model that recognized that there are multiple value chains, with the further recognition that this will typically lead to multiple organization units.

      Yes multiple value chains can lead to duplication; but where the duplication is excessively costly, the elements can still be combined if the loss of alignment along the value chain that results can be managed.

      As regards being agnostic, I am increasingly coming to the view that this is a disadvantage rather than an advantage. Ulrich’s HR reference model of expert functions, operational functions and business partners is not agnostic and is one of the more useful and most widely used reference models that I am familiar with. Admittedly it is sometimes followed slavishly and inappropriately, but more often it is a helpful stimulus for improvement. I think IT needs something more like this.

  2. Peter Murchland says:


    There are varying definitions and interpretations of value chain, value stream and value system. I was simply noting (as can be seen in the IT4IT value chain graphic) that the four elements you identified are labelled and named value streams by The Open Group. I have not checked the consistency of their use of “value stream” with broader definitions.

    However, it is important to note that the value adding activity occurs in each value stream, with value chain being the combination of the four value streams and the five support activities (which I interpret to correspond to primary and secondary activities in the general descriptions I have seen of “value chain”).

    Care also need to be taken in relation to “application” related activities as each of the streams have some connection with an “application” but entail quite different capabilities and value propositions – in much the same way as occurs in other asset based utilities (I have seen this in an electricity transmission enterprise, for example) – but that requires more explanation than is appropriate as comments on this blog item.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s