Building a Service Catalogue

This blog is part of the coordinated service management blogging flashmob, with the idea to have a number of bloggers posting an article on the same agreed theme (at the same date/time). The theme for this first edition is ‘My Best Tip for building the Service Catalog’ (yes, American spelling).

I myself have had a bit of a love-hate relationship with the Service Catalogue.

In the beginning, during the dark ages of service management, or rather the 90s, I was spruiking the Service Catalogue as the best thing since sliced bread and an absolute starting point for anyone inspiring to do service management. After all in those days the concepts of service management, or even of a service, were relatively unknown and it seemed a logical starting point to define what your services actually are.

As, in essence, that is what the Service Catalogue is: a list of services. In its purest, simplest form it doesn't even need a lot of text, just a short description, so the customer knows what they can expect from the service provider. This is why a restaurant menu is so often used as an example/analogy for a Service Catalogue (which is wrong, but more about that later).

But then came ITIL v3 and the Service Catalogue obtained its own process, within the Service Design publication. The definition became: Service Catalogue (Service Design) - A database or structured Document with information about all Live IT Services, including those available for Deployment. The Service Catalogue is the only part of the Service Portfolio published to Customers, and is used to support the sale and delivery of IT Services. The Service Catalogue includes information about deliverables, prices, contact points, ordering and request Processes.

Not enough to really obtain an indication of the importance, or irrelevance, of the catalogue. More interesting is how the book describes the two different aspects (or better perhaps: ‘views’) of the Service Catalogue: the Business Service Catalogue and the Technical Service Catalogue. This is a great clarification of the vague reference in version 2 of a ‘hierarchical’ structure of services with some being ‘invisible’ to the Customer. The two newly defined aspects/views show the difference between the visible, outward facing catalogue (for the Customer) and an internal one which can be used for the development & management of systems and teams.

However, at the same time ITIL started confusing what the objective of the Service Catalogue is, and where/when it should be used. Not helped by (the usual ITIL) ambiguity of definitions and inconsistencies across the publications. The main one that bugs me is the distinct different uses of the Service Catalogue in Design (as part of Service Catalogue and Service Level Management), Operation (in Request Fulfilment) and in Service Strategy.

In 2010 I wrote an article (published in the itSMF-A Winter bulletin) on ‘Is the Service Catalogue really necessary?’ (leave comment if you'd like a copy). It concluded that the Service Catalogue has become a strategic document, in the ITIL Lifecycle, defining the Market and the Offerings as well as a structure for the delivery of those. It straddles the bridge between the Portfolio\Pipeline for the future and the ‘next’ Customer, leading to Service Level negotiations.

PS: This is also the main reason why the menu card is not the Service Catalogue of a restaurant: After all, the meals on the menu are merely the products delivered (comparable to an application). And it is not the product the customer wants, but the value he or she derives from this. For instance a bowl of chips is the same product whether it is obtained in the drive-through of a fast food restaurant -with screaming kids in the backseat-, in a pub during the Sunday-session -with mates and a beer-, or as part of a romantic dinner-for-two in a seaside a-la-carte restaurant; same product but the value is completely different (convenience, atmosphere, privacy, view, ...).

Thus the ‘real’ Service Catalogue of a restaurant is the style, location, opening hours, interior, ambience etc.etc. ... All those things that make someone decide to go to that particular restaurant in the first place, rather than pick a specific dish of the menu

So, now leading to my best Tip for building the Service Catalogue. I think the secret is in the diagram showing the Business & Technical Service Catalogue.

Based on Cabinet Office ITIL® material. Reproduced under licence from the Cabinet Office

The business side is showing a link between (business, customer-facing) services and business processes. These links form the bases for Service Level negotiations & Agreements (SLAs) and thus we need to define the utility that these services provide. And I think that is ‘easiest’ done by defining Patterns of Business Activity (PBAs as they are called in Demand Management). PBAs are often related to core business and revenue and thus define (too a large degree) the success of the business and by extension the value of the service.

If you could quantify these PBAs, they are going to be mighty helpful not only in defining the service for the Service Catalogue, but also negotiating the service levels, determining change impact, incident prioritisation etc.etc.

TIP 1: Define Patters of Business Activity, which will lead to utility and service definition

So, that is one half of the solution, on the other, technical side we see how those same services are linked to bits of technology. I think the picture is skipping a level here, as the technology is managed by ‘someone’ (a team, a provider, ...). These links represent the OLAs and Underpinning Contracts that need to be in place with these people (in order to deliver the SLA, customer-facing services above). 

So instead of technology, identify your functions, your teams and suppliers; and then define the (technical) services that each of those deliver. You'll find that these are probably more warranty-focused.

TIP 2: Identify teams that deliver technical, underpinning, supporting services

That's my tip(s): PBAs, utility & SLAs for the customer-facing services; and functions, technology & OLAs/UCs for the technical ones.

But if all else fails, one more tip: start with your applications!

Not all of them, and not in their technical appearance, name or version (no funny acronyms). But applications are the most visible part of a service for the customer, and they provide the utility to the customer and are thus closely related to the customer-facing service definition. 

This is not a perfect solution or (ITIL) theoretically correct, but you could do worse that to start here.

Good luck!

the ITIL Zealot
October 2013

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