When the IT department is 'just another supplier'

The shift from centralised IT to core business systems team

The traditional approach to IT within the average company is to have a central group that manages the technology and applications. This makes perfect sense, in principle: the underpinning technology has always been complex and has required a certain skill level in order to keep it running, patched and up to date.

But things have changed radically in recent years. IT isn't the hideously complex beast it once was and that means reliance on the centralised IT team is beginning to fade away. we're already starting to see the change.

The IT department as a supplier

The IT team has always been a service industry: its customers are the users around the company. Most importantly, it used to be a monopoly - but it isn't any more. Departments are able these days to consider the IT department as "just another supplier” for many of the functions it provides - and are free to use someone else in many cases.

Let's take an example. If you want some software written you don't necessarily have to use the in-house development team. You could take on your own developers or perhaps use contractors on a per-project basis.

A more recent innovation has been the rent-a-developer concept from the likes of oDesk or Elance. Services such as these cost a fraction of the price of employing your own team, and if you're diligent about your requirements there's no significant compromise in quality.

The growth of the Cloud has done the same for server provision. If you want a server these days, one of three things could happen:

• First, the IT department might say: “OK, we need to procure a server” and place an order.
• Second, they might say: “No problem”, and run you up a new virtual server in their VMware or Hyper-V environment.
• Third, you might log onto Amazon or Azure and run yourself up a new VM.

The only chance your IT department has of its server team surviving is for the second of these three options to be the chosen one.

Is the IT department cost-effective?

Continuing this concept of the IT department being your service provider, what actually is the cost of it? Some companies have tried the idea of allowing the IT department to charge for its services (generally in the form of “wooden dollars” - internal budget recharges that reflect the cost of providing each service to its user). But in reality what this generally demonstrates is that it can't be done cost-effectively.

So it's always going to be cheaper to, say, run the corporate email via Office 365 than to have internal servers, storage and Exchange specialists. Trying to make the IT department into an ostensible “profit centre” will simply result in its excessive cost being more visible than before.

This isn't a new concept

Of course, putting the choice in the hands of the end user isn't a new thing in general. Back in the early 1990s I used to get a quarterly bollocking from my employer's procurement department because I went direct to my Apple supplier instead of using the central purchasing team.

And my boss would always fight my corner because the purchasing team's “special” agreement with its vendor wasn't all that special (our direct approach was cheaper and had shorter lead times). Just as negotiating a good price didn't need a degree in procurement science in those days, implementing IT systems no longer needs a degree in computer science.

So is it dead?

For services such as software development and equipment supply, centralised IT is losing the battle. The point is that it doesn't need a centralised service as departments can do it themselves more cheaply and with their own resource instead of having to compete for shared central developers.

Even with corporate applications that are used across the business (email, the finance system and the like) it's increasingly common for departments to have “power users” who have some form of training in the applications and can answer their colleagues questions instead of having to raise a ticket with the IT service desk.

There are, however, some functions that are likely to remain centralised – primarily because it's the most economic way to run those functions.

The services that will remain central

The core services on which everyone relies work best when they're centralised. A single corporate email system makes sense, because you need integrated address books, calendars, room lists and the like - to split the function would make it less efficient and harder to use. This doesn't mean it needs to run on in-house kit, though: it could perfectly easily sit in the cloud.

Similarly the core procurement, HR and finance systems - which could have all three functions fulfilled by a single product or might equally be separate applications. Again these need to be centralised because splitting the data, the business rules and the processing would be hideously inefficient to do as compartmentalised setups.

So although we no longer have the old central monopoly, we're not splitting absolutely everything up.

So where is decentralisation going?

Decentralisation is, quite simply, taking all the IT functions that don't absolutely need to be central and based on a company-wide system and moving them out. In some cases the IT department plays its own part in decentralisation, by shifting core applications to the cloud.

The greatest level of decentralisation, though, is the individual departments using their own ways and means (and funds) to go out and do stuff like development and equipment procurement themselves because it's quicker and cheaper.

The central IT function as we remember it from the old days will be no more in a couple of years' time. But we will retain a core “business systems” team whose focus is on providing and supporting the centralised applications, and defining standards. Because decentralisation can lead to unsupportable chaos if loads of departments go off and buy different brands of kit and write their own software in different languages and on different platforms.

So the sensible IT department will already be engaging with the business teams asking them what they're going to do, and encouraging them to work together and agree a manageable set of underlying platforms. After all, you can no longer dictate it so you need to change focus and head for engagement and consensus instead. ®