Service Management basics

Happy New Year

Somehow I thought I would be able to write my blogs ahead, and then release them fortnightly (or at least two-a-month). Reality has taken over and I now find myself in January without any pre-prepared blogs. So, with this in mind and as we’re starting a new year, I thought perhaps I should go back to the basics.

As an ITIL zealot, I of course am strongly inclined to see ITIL as the one true way of ‘implementing’ service management. But I am certainly not that myopic not to recognise that there are some excellent ‘other’ frameworks around which offer complimentary and sometimes even superior advice (I am particular enarmoured with COBIT5 and may devote a future blog to that).

But more than any specific methodology I find that recently I am spending more time (in ITIL training etc.) explaining to people the basic concept of Service Management (and then how ITIL fits in). So, the basic concept of service management is the management of services (yes, sometimes things are THAT simple). A service, in turn, is the value we deliver to the business, which is not related to any specific technology used (but rather the utility and warranty, which are a great set of concepts, although ITIL could have used them better and more consistent).

So, my first and possibly most basic teaching is that we (i.e. all ‘IT-people’) need to focus on our deliverable\value rather than our delivery\technology. This is most evident in a process like Incident Management that deals with break-fix. ITIL provides a great objective-statement for this process which is ‘to restore normal service as quickly as possible, and minimise impact on the business’.

I always highlight three key parts in this statement, the first being ‘restore’. Incident Management is not about fixing, improving or anything permanent\long-term, but merely about restoring the normal\working situation, sometimes using workarounds (the equivalent of taking an aspirin …). The second highlighted part is ‘as quickly as possible’, which then leads to the priority-setting (impact and urgency), which is driven by the customer, business or at least the service targets of the SLA.

The last part of the Incident Management objective that is of importance is ‘minimising impact to the business’, which brings us back to the core of service management: delivering value. If a user can’t email, then it is important of us to restore this service (and for future purpose perhaps do a root cause analysis). But of immediate importance is the business process which was trying to communicate (the value), something that perhaps can be achieved otherwise (print & fax, phone, …). A good service desk agent will think with the user, about the business and not restrict themselves to the service levels in place and/or the technology used.

Once you grasp that the basic meaning of a service is the value delivered, then the next\second basic concept is that of the ‘management’ part: the value has to be delivered repeatable & guaranteed. This is where ITIL (or your favourite methodology) plays its part as it provides the structure that allows providers to deliver services repeatable, manageable & guaranteed. 

In ITIL this is done through the processes which provide ‘structured activities’. This is why a good methodology is also known as ‘commons sense, written down’ as those activities are common sense and most people would do them anyway, most of the time (I sometimes joke that there are yet undiscovered tribes in the amazon who are using Incident Management). The structure of a process makes sure that everyone does the activities, all of the time and thus establishes repeatability. By documenting a process (procedure manuals, work instructions etc.) and measuring activities (and outcomes) we make the delivery manageable, repeatable & guaranteed.

But … remember that it was not about the delivery, and thus not about the process, but rather the outcome\value\service that is being delivered. Processes\ITIL are merely a means to an end (even though sometimes zealots like myself get lost in the intricacies of the means, thus forgetting the end)!

Focusing too much on process is the equivalent of declaring the operation a success, even though the patient has died! (but look at the stitching ... textbook).

So, these are the basics of Service Management: it is about delivering value in a repeatable & guaranteed way. Ultimately (or ideally) a service is a fixed-price, blackbox ‘thing’: as a user\customer I don’t care how it happens, as long as I get the value, every time I need it!

Best wishes for 2013.

the ITIL Zealot
January 2013

Technology vs. value

A former colleague of mine used to deduce that service management ultimately would lead IT to become a commodity: simply a device that would provide functionality without any worry (guaranteed, repeatable, measured, managed, fixed-price, … sound familiar?). His example was the telephone: how often do you pick up the telephone and wonder whether you are going to hear a dial-tone, or a get a connection … not often (if ever); it truly is a commodity service.

I am not convinced IT will ever reach this level of commoditisation or standardisation. Or at least not in the short term (measuring on an industrial revolution scale, so another 5-10 years). For one there is the apparent inability of IT to standardise. Partially as technology develops at a rapid pace so new standards are constantly being developed (for instance wireless a, b, g, n … bluetooth, USB etc.). Even with 'downwards' compatability this still creates the issue that ‘older’ devices suddenly are no longer able to seamlessly provide functionality (when combined with other devices using a newer, incompatible technology).

And then there is the fact that in IT we have become very territorial were it is almost a badge of honour to do something different (with its own benefits and drawbacks) … can anybody say Apple, iPhone\iPad?

And this possessiveness or preference for a particular technology even permeates through to the users (and sometimes the customer). The result of this is that IT as a service provider is no longer asked to provide a service (or value, outcome, functionality) but instead to provide a particular technology. The obvious example here is that users do not want a mobile phone, they want a iPhone!

On this topic, I have for a long time exclaimed that I was yet to see a valid business case for an iPhone. What was it that makes a iPhone provide more value to the business than a Blackberry (or Windows Mobile at the time). Most people shrugged and failed to find an answer, until one manager posed that by providing iPhones they would instill a better loyalty in their staff. So, not a direct business, functionality of performance benefit, but a more longer term staff satisfaction, staff turnover and/or recruiting one. What a great way of assessing the service-value!

PS: I think this staff loyalty, Gen-Y benefit is also the key driver behind BYOD, not cost-savings.

So, there may be a very good reason why users want a particular bit of technology: maybe it does something (provides certain functionality) that no other ‘thing’ does, or maybe they are aware of its perceived quality (warranty). However, often the users do not have the full picture of utility & warranty nor of the alternatives available and thus they are not in a position to request a piece of technology (but instead should identify value required).

I have heard more than one story of how IT was told (by often high-ranking Customers) to ‘make iPhones happen’, thereby scrapping a well-researched, designed and managed Blackberry solution with all the (potential) security consequences that come with it. Given time I am sure IT could have provided an ‘iPhone’ service with similar utility & warranty, but apart from customer saying that they want that, they normally follow this by saying they want it NOW.

Ultimately this is the customers right and decision as they will wear the risk and negative outcome (although IT will normally get the blame, see my blog on the Bermuda triangle between customers, users and IT), but it does de-value the role of IT as a service provider, as subject matter expert and a trusted partner of the business\customer. And this situation will only be intensified with the rise of BYOD (Bring-Your-Own-Device) and cloud.

 

That does not mean that we can’t do BYOD within service management, but it does mean we need to be ahead of the curve. And it does mean we do have to negotiate, agree and enforce certain standards. This as that way we can still provide a guaranteed level of utility and warranty.

For instance: you can BYOD your mobile, as long as it is iOS 5+, Android 3+ or Window Phone 7+. So not just anything, but freedom within the defined boundaries. BYOD laptops, as long as they can run a certain application (Citrix client for instance). And tablets can be viewed as either large phones or small laptops.

The trick is now to make sure that the ‘boundaries’ of the BYOD encompass the most popular devices, which brings us back to one of the earlier points, which is that technology is changing rapidly. IT needs to be ahead of the curve, so they can offer new technology (safely, guaranteed, …) when, or perhaps before, it becomes mainstream.

BYOD posses further challenges in our service management world, but as long as we keep the business value (, outcomes, …) in mind it is possible to incorporate this into your service model.

the ITIL Zealot
August 2012