Sourcing strategy – end-to-end or aligned

Reposted, original on the “IT Governance, the Kapteyn’s view” blog on Computerworld UK in October 2009

Some time ago I came across a question from Réal Rousseau on the itSMF Discussion Forum. After we discussed his initial question for a while we came down to the following underpinning issue: When you look at the IT Supply chain most services offered to the business are built by combining products and services from different organizations. For instance, a message service will combine at least a workstation service, a network service, a mail server service, WAN service, internet access service and maybe services like PDA/ Smartphone or mobile computing. These days no organization that I know will build, run and maintain all parts of this end-user service in-house (I do not think it would even by possible if you wanted to). So not only do different departments within the organization need to work together to create this business service, but there also has to be operational alignment with third parties. The question Réal and I were discussing is: In this complex, multi-organizational spaghetti would the ultimate goal be to create an end-end process model or just align the individual links. With one overarching (end-to-end) process model the designs of the internal operations of each link is adjusted to fit the tasks, activities and goals described by these end-to-end processes. The alternative would be to allow each organization in the chain to have their own internal operational process model and just ensure the operational alignment in the cooperation between these organizations. For alignment you ensure the output from each individual link matches the input requirements from the next link in the chain. In this case the way the output is created is not a topic of interest. The individual links are seen as just as many black-boxes. I have seen this discussion in different forms within different organizations.

But before we get further into this question, what does this have to do with (IT) sourcing strategies as the title suggests? You may have got the feeling from the opening paragraph that this article would turn into a highly technical discussion of different IT operating models and forms of process-cooperation, but that is not the point of the article.

An essential part of strategic thinking is to understand the consequences your choices of today will have for your options in the future. As I learned from the discussions with Réal and others there are pros and cons for creating one process model for the complete chain were each link just conforms and finds its place in the bigger picture. This is the same for the alternative where each link organizes its own (internal) processes – in this case, special attention should be paid to the alignment of the contact points between the individual links. If you are interested in discussing further, let me know and we can get a conversation started.

For most professionals, however, this discussion is completely academic. To be able to establish an end-to-end process framework for the complete supply chain you need to have one dominant link in the chain that can act as the “director” of the end-to-end model. If you look at the production supply chain from Dell or Wal-Mart, say, it is clear who is in the driving seat for the end-to-end chain. On the other hand, many organizations have a sourcing strategy that dictates that suppliers of equal size or stature are preferred. Since this will help to ensure adequate share of mind from the supplier (the supplier should not be much bigger) and stability (the supplier should not be much smaller) this is often a sound strategy. However if all links in the chain are of equal size it might be hard if not impossible to find the dominant link that can act as the director for an end-to-end process/operational model. For most of us the supplier portfolio is a given that you do not change in the short term.

So that’s the answer: Look at your current supplier portfolio. If you can identify a potential dominant link in the chain you might consider building an end-to-end operating framework, directed by this link. If you cannot find a clearly dominant link, each link should decide for itself how to organize its operation and each interaction point should be aligned by the parties involved with the individual contact. That sounds nice and responsive and is probably the only viable solution for most organizations. However, for organizations who want to be “master of their own destiny” and thus have decided that their (sourcing) strategy is important to be able to actively plot and navigate the course of the organization: Your IT Sourcing Strategy – more consequences than meets the eye!

IT Governance and IT Service Management, are they the same?

Reposted, original on the “IT Governance, the Kapteyn’s view” blog on Computerworld UK in May 2009

These days when I look at the information on the internet it seems that the disciplines of IT governance and IT service management are considered to be one and the same. Tools that used to be promoted as IT service management tools suddenly became IT governance tools. ITIL, which I will always regard as "the best practice for it service management", is mentioned frequently these days as an IT governance model.  These examples lead me to the following question: Are IT governance and IT service management one and the same thing? If not, what is the distinction between them, were does one end and the other begin?

To get different opinions for this article I visited the home of the IT Service Management Community: itSMF. On the discussion forum I started a conversation with the title “The difference between IT Governance & IT Service Management”. This sparked a healthy debate which left me with a number of observations. First of all, there is a strong association between ITIL and IT service management on the one hand, and CobiT and IT governance on the other. Very often people do not make the distinction between the field of expertise and the models used by the experts. This might lead to the conclusion: If you know ITIL you are an IT service management expert; if you know CobiT you may call yourself an IT governance expert. Needless to say I do not agree with any such conclusion. Secondly, I recognized a number of the people who got involved with the discussion from my dealings with ISACA. –Members of ISACA and its integrated research think tank ITGI represent many of the leading IT governance experts. The fact that I am not the only person who frequently visits these websites leads me to believe that there are others who consider both expert fields to be closely connected, if not partially overlapping.

The consensus in the discussion, however, was that these fields are not the same. Especially when looking at the focus of IT governance versus service management there seems be a difference. Where IT governance is primarily concerned with facilitating (strategic) decision making, IT service management is more focused on operational excellence of the IT function. The ultimate goal of both disciplines, however, is to maximize the organizational value creation by achieving better business – IT alignment. This is where the clarity ends; when trying to establish the split between day-to-day tasks, targets, goals etc. of those involved in the field of IT governance versus those working in the field of IT service management, any attempt to make a clear split seems to end in differences of opinion.

So far a nice theoretical discussion. However, if I have an organizational issue in my IT function, how does the above help me to decide if I should get help from an IT governance expert or if I should involve an IT service management expert? Clearly it doesn’t. Even more so, I believe the question should not even be raised. If I have a problem with my car, I ask a mechanic to fix it. I do not have to choose between an engine expert or a brake expert. In parallel I would advocate the introduction of IT organizational experts who have a sound knowledge of both IT governance and IT service management. Having a mechanic who can work on brakes and engines alike does not indicate engines and brakes are the same thing. Similarly having an expert who has knowledge of both IT governance and IT service management does accept the difference between them. However it does also recognize that both are part of the same ‘car’. If the car does not drive according to its full potential I do not want an engine expert exclusively looking at the engine; the quick win might be to fix the brake that got stuck.