Workshop In recent weeks we’ve received plenty of meaty responses in roughly equal measures (positive and negative) to the questions posed in this workshop. For many, service management is seen as simply doing the job properly, regardless of the tools / politics / obtrusive management and so on. Others do what they do but really don’t care or think about what they do in terms of services.
Let's cut to the chase: if you don’t care or haven’t thought about it, why not? There could be very good reasons. For example, try as you might perhaps the business will never ‘get it’. Alternatively, maybe the business really does get all this service delivery stuff, in which case IT will continue to stand at odds with the rest of the business. Maybe thinking about services isn’t your job. But it should be someone’s shouldn’t it?
The really big question for IT management is how to get from component management to service management. It may be less of an upheaval than we think in terms of mindset and the kit we use. The mindset thing is at least easy to acknowledge, if harder to adopt. But it is easy to grasp the basic premise of aligning resources and capabilities with what the business actually needs - even if you never saw it written down this way before. Next is ‘OK, so how?’ There are a few things we do need in place to be able to do this.
First is some kind of measure of ‘user experience’, and second is a way of tracking problems that affect said experience, coupled to the ability to fix them. The stuff we have in place today does all that, it’s just very, very slow, so we don’t ever look like we are managing ‘a service’. We have all the right information, but it’s in lots of places. Nobody has the bird’s eye view needed to make changes as needed to limit the impact of a problem (or potential problem) from the point of view of the users *ongoing* experience.
Speed connects all this together . The ‘legacy of a fragmented past’ (hark!) is that it takes too long between someone’s application faltering, finding the problem, identifying the cause of the problem and fixing it. Perhaps in here somewhere we have a workable definition of service management for coalface IT: ‘if we can find and fix a problem before the user notices or cares about it, that’s [good] service management’.
The thing is, tools exist out there which claim to be able to help IT shops do this. They might not all be marketed as ‘BSM’ but they are aimed at helping you ‘manage business services’. We have no axe to grind about which tools you find are any good, but what we do want to hear about is how you, or those more senior to you are going about trying to improve things in this area. As usual we’d love to hear your views.