Loosely Coupled Sourcing & Closely Collaborative Sourcing

Introduction

In my IT Management Consultancy practice I've recently noticed that organizations are struggling with dividing the IT Service Supply Chain into parts that can either be outsourced or given to an internal depart to perform. This paper explores the underlying sourcing principles.

The difficulty is in how activities can be divided into packets of activities that can then be delegated to internal or external departments and how these departments are going to interact.  This didn't used to be much of a problem – you'd usually settle for a division between Business Information Management on the demand side and Application Management on the supply side, with Infrastructure Management behind Application Management, supplying the environments (production, acceptance, test and development/maintenance) that Application Management had specified. So why are people currently struggling, what's changed? I'm going to explore the demand-supply divide another time and now focus on the division of labour within the IT Service Supply Chain. 

Conclusion

As IT landscapes are breaking down into more discrete components and IT Service Providers are specializing in their own sweetspots and becoming agnostic artists, organizing the IT Supply Chain (or Network) is becoming increasingly important. This is reflected in the changes that were implemented in the second version of ASL with the introduction of the processes Supplier Definition, Supplier Management and Operations Management, covering governance and management of suppliers; and the repositioning and renaming of Service Level Management into Contract Management, reflecting that an Application Management provider not only can be engaged directly by Business Information Management in the demand side, but also as a subcontractor by another Application Management provider on the supply side.

The guidance in this area is to critically re-examine how the chain is organized and determine whether it is still an effective instrument. So when you're making sourcing decisions about complex landscapes, please analyse the gray areas and decide on the division between labour based on your evaluation of the need for close collaboration and mutual adjustment and the ability of suppliers to perform in this area. Nowadays sourcing strategy is more about creating a network of loosely coupled interactions than anything else. Just like the organizational design principle of 'decentralised if possible, otherwise centralized', here it's 'loosely coupled sourcing if possible, closely collaborative if not'.

Details: please mail me if you're interested in the paper from which this is an abstract.

Wisdom is a verb

I like the definition that data is about raw facts and observations about things and that information is data that is selected and presented in a way that is comprehendible by the receiver: 'meaningful data'. Meaningful, but not necessarily useful: "Changcheng was founded in 1976 and is one of about 50 domestic Chinese car manufacturers who made 8 million units in 2009". Knowledge is information that is worthwhile remembering: "China makes lots of cars". Where data, information and knowledge are artifacts, I treat understanding and wisdom primarily as verbs. Understanding is the process of taking information and knowledge and figuring out the 'why', resulting in more information and maybe knowledge: "Cars manufacturing is important for China's economic development". Similarly, wisdom is the process of putting a value on information and knowledge: "Good for China".

Agnostic Artists and Intelligent Integrators

Surely I'm not the only one to notice it. IT organizations are dividing themselves up into two groups. We're all aware of the standard solutions that the clouds are starting to provide, e.g. Google Docs and SalesForce.com, and a multitude of apps for smartphones. This gives us an interesting outsourcing challenge.

These solutions are provided by clever companies that do not know their individual customers. The market, yes; customers, no. I call them agnostic artists. Agnostic because they don't know their individual customers; artists because they make great products. If you buy one of these products it's up to you to fit it into your application landscape and provide the necessary interfacing with other systems. You've also got to monitor – particularly with smaller companies – the supplier's continuity. And whether their product isn't being overtaken by another agnostic artist's product. Another challenge is managing agnostic artists. You haven't got the classic customer-supplier relationship with contracts and service level agreements . Do you have a SLA with Google about use of Google Maps? Yes you have, you clicked on "I agree" didn't you? That's it. But it isn't what you're used to dealing with. And Google won't allow itself to be managed like you manage a regular supplier. The familiar 'command & control'  management paradigm won't work. 'Communicate & colloborate' will. For instance using Twitter to muster up other users of Google Maps and use community pressure. That'll work. The roles that I've just described – architect, interface manager, supplier manager, market monitor, contractor, coordinator – are part of the other kind of IT organization that I see. These I call them intelligent integrators. Where agnostic artists have a one to very many relationship with their clients, the intelligent integrators have one to one relationships. They're often slimmed down internal IT departments.

Now we have a fascinating sourcing dilemma: what part of this integration function do you want to do yourself and what part do you want to outsource? What's the validity of the old statement that you should own the 'what' and can outsource the 'how'?  In other words, are you prepared to let an external partner decide whether cloud computing is going to be used? Some things are too important to outsource but other things are too important to do yourself. So have a think about how important these choices are to you.