The wax-on & wax-off of SLM

I am a great fan of analogies. I think it makes it so much easier for people to understand the service management theory if they can relate it to something already very familiar. My favourite one for describing the essence of a service (delivering value without the ownership of specific costs and risks) is public transport:

• You use the bus (or train) without worrying about the mechanics (bus-technology, maintenance, etc.)
• You pay a fixed-price every time (not related to variable fuel-prices, drivers-salaries etc.)
• It gets you where you want to go, in a certain time (=value)

Whilst there is still costs (the fare) and risks (you could have an accident), you don’t have to worry about these and can instead concentrate on other things during the journey (in my case angry birds).

I could go on-and-on about this and other analogies (and probably will, but in other blogs) but for this time I want to look at the one I use to explain the activities of the Service Level Management (SLM) process. In fact this is not so much an analogy, but a ‘depiction’ with a reference to pop-culture.

It is based on an old (v2) diagram showing the different activities in two circles. The first cycle is around the ‘define-document-&-agree’, the second ‘monitor-measure-&-report’. Originally these circles rotate similarly (clockwise), but in my depiction I have turned one around so they turn ‘into each other’. This way they become the wax-on and wax-off of SLM (the pop-culture reference to the Karate Kid, either the original or the half-hearted remake with Will Smith’s kid and Jackie Chan as Mr. Miagi).

Apart from (hopefully) a good laugh, and a great way of memorising the various activities, I think there is also a lot of benefit in this depiction:

The two circles represent two distinct activity-streams within Service Level Management. I have earlier retold how the perception of the Design (and Strategy) processes is not that of one with a single input and a linear set of activities leading to a single outcome\deliverable. But rather multiple activity streams based on several distinct inputs and outcomes.

‘Define-document-&-agree’ (wax-on) is the Design-stream, in which SLM negotiates with the Customers (and with the various technical functions and other design processes) to establish the Service Level Agreements (SLA), Operational Level Agreement (OLA) and Underpinning Contracts. These documents will form the basis of the further Service delivery (through Transition and into Operations) as they identify the service levels and targets to be achieved.

Those achievements are the basis for the ‘monitor-measure-&-report’ cycle (wax off) which occurs more in Operations. The operations processes (event & incident management, request fulfilment …) provide operational reports, which (together with those from the other processes such as change, capacity, availability … management) give an overview of the service delivery against the designed agreements.

The two cycles don’t operate independently: the output of the wax-on cycle (SLAs) forms the basis of the wax-off cycle. The output of the wax-off cycle (reports) are fed into the ‘review’ activity, which links this cycle back to the wax-on one: if the reports indicate a service shortfall, opportunity for improvement or and changed business requirement, we have to restart the wax-on of ‘define-document-agree’. The review activity therefor sits in the middle connecting the wax-on and wax-off.

Of course we can further detail this depiction by entering Service Improvement (and Quality) Plans into it, or linking it to complimentary processes, CSI in particular (but also some of the Strategy ones). But why complicate things when a ‘simple’ diagram can provide enough insight for a good understanding of the objective and activities of the SLM process.

I think simplicity is a key in teaching the ITIL basics\foundations. Simplicity without condescending, if we can clarify the complex concept of interrelated processes in terms of depictions and analogies, we can spread the understanding of service management to a much larger audience (zealots like myself, and probably you, can then further discuss the finer details!).

the ITIL Zealot
December 2012

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