Whenever we put the word ‘service’ into the title of an article to do with IT delivery or management, we can almost guarantee a lower than average click rate. Phrases such as ‘service management’ and ‘service assurance’ are just not grabbers.
Some of this has to do with the pervasiveness of the word ‘service’, which is used and misused in IT-speak to refer to many different things, so is often associated with industry noise. But when used in the context of IT operations, it really is important to take notice of it. As you’ll appreciate by the end of this article, all IT departments are judged on the basis of service delivery, whether they work that way explicitly or not.
But embracing the concept of services proactively when it comes to IT operations has many advantages. Here, for example, is just one of many proof-points illustrating a direct correlation between the adoption of a service-centric approach to IT delivery, and the degree to which IT activities are viewed to be aligned with business priorities.
(The full report from which this chart was extracted can be downloaded here)
If you browse www.freeformdynamics.com, you’ll find reference to this services view of the world in many of our reports. Indeed we now consider it one of our standard segmentation criteria when analysing data, as service-centric IT delivery is generally a good proxy for progressive behaviour and better performance in many areas.
So why is this?
Well some of it has to do with the services view enabling better performance as a result of encouraging an end-to-end approach to operations. Rather than focusing exclusively on monitoring and managing individual components, the idea is that you spend at least as much time and effort on ensuring that everything works together to provide something valuable and appropriate to the end-user. By ‘everything’ here, we mean all relevant parts of the IT and communications chain, including both internal and external components and resources.
As an example, a traditional IT operations approach might include looking after the resilience and uptime of an ‘email system’, and separately managing the uptime and performance of the network. Those taking a service-centric view, however, would be considering the availability and performance of the ‘email service’, as experienced by users at the point of consumption. In our simple example, this obviously needs to take both the email system and the network into account, as the service is dependent on both working acceptably.
It’s at this point that some IT people start to get a bit defensive.
The objection we often hear is that it’s just too onerous to deviate from the component or system based view. The performance of our email service in reality, for example, is actually dependent on a lot of things if you really pull it apart – the PC on the desk or mobile in the hand, the email client software being used, the network (or networks) that transport messages back and forth, the email server environment itself, and the storage devices underpinning it. Pick any other application or ‘service’ and it’s likely to be equally if not more complicated in terms of underlying components and dependencies.
The fear is that it is a short step from adopting an end-to-end services approach and business people starting to judge IT simply on what happens at their screen and keyboard, without taking into account how complicated things are behind the scenes. IT then gets lumbered with a whole bunch of service level commitments and/or expectations that, it is perceived, are a lot harder to manage. It won’t any longer be possible to make the case that you were mostly doing your job well because 99.9 per cent of the infrastructure was working fine, and that major outage was caused by a single component failure that was beyond your control.
But let’s be honest with ourselves here. Users have never really bought into that kind of defence when things have not worked as they should. They have always been pretty much exclusively concerned with what they are able to do (or not do) at the end point of the IT delivery chain. If you ask any user or stakeholder how well they think IT is performing or supporting their area of the business, the language they use is inherently service-centric.
When they talk about email, they focus on the number of times it has been down recently or has been running really slowly. Even if it has been explained to them that the issues have been caused by a comms provider not meeting their obligations, they are not really that interested. They just want you, i.e. the IT department, to make the problem go away.
And it works the other way around too. Business people might well acknowledge how well the call centre system has been running recently, but do they care when you tell them about that major switch failure and the heroic and creative efforts of the network team to re-route traffic and avoid a major outage? The chances are, they’ll probably just shrug, on the basis that it’s your job to keep things running properly, so what’s the big deal?
Adopting a more explicit service-centric approach to IT delivery means you accept these things, and once you do this, you can start to take control. You realise that there is no point in trying to define how well IT is doing in terms of how many green lights are lit within the infrastructure. However good the internal IT view looks, you’ll still ultimately be judged on the basis of what’s delivered to users. If you define and manage expectations and commitments based on this, life actually becomes easier, not harder, as you avoid all of the problems that stem from users defining what is ‘acceptable’ unilaterally, and often in a very subjective manner.
The bottom line is that IT from a business user perspective is all about service consumption whether anyone defines it formally or explicitly in this way or not, so thinking in terms of service delivery within the IT department should really be a no-brainer.
0 comments:
Post a Comment