Posts Tagged ‘Service Catalog’

Everybody talks about Service Management ! The word of the day is Ownership ! The sentence is ‘We need to talk End to end responsability’ !

Yet, everyday operations speaks about first line and second line, about us and them (usually a vendor). They all have a product catalog (instead of a Service catalog). And the major driver in IT is still (as it has been for the last 3 decades) cost.

So why is that ? Is being (or becoming) a service oriented organization that hard ? What are the main reasons why a lot of organization fail their attempts ?

1  Complexity of IT

In most organizations IT has become way too complex. Systems have evolved and have grown to a level that they are not manageable anymore. The integration efforts done to get everything in one major systems have made these systems very expensive (to buy and maintain), very demanding (in means and resources), lacking performance and above all very restrictive to adapt to changing business needs.
You could argue that the ‘Peter principle’ holds up for IT systems… A good tool/system is expanded to take on new responsibilities over and over again until it becomes a poorly functioning tool.

An example of this is the famous ‘CMDB’ where lots of organisations are trying to force every catalog item (real and logical items) into one monster database, which becomes slow, inaccurate, and never exactly meets the requirements you want (and is also not what was intended by ITIL standards).
Say you have an external service provider who handles your entire mobile communications for you. The supplier makes sure the device are delivered, configured and operational. He also provides the subscriptions and has a support organisation for resolving incidents.
Why would my organization keep a database of all mobile phones ? or of the link between phones and SIM cards ? or even who has which phone ?
Of course I am involved in the decision process of which phones are on the standard list, but do I care whether employee X has the newest or the older model? No, I don’t… and if an occasion comes where I am interested in that info, I will just ask the supplier to list me that…because he needs to know that to be able to service the users.

2 focus on technology

Too many IT organization are technology driven (instead of solution or even better service driven). And in fact, the T in ‘IT’ has long become a commodity…if you need T, talk to one of your suppliers… It is the I (information) in ‘IT’ that makes all the difference. In literature they would now start talking about Value, ROI, utility and warranty and more terms which in my book fall under my previous point.
It is about common sense. A Rolls Royce is one of the most comfortable ways to drive from point A to B; however, if you live in the center of a major capital in Europe, it is a very poor solution to commute (unless if you can afford a driver so you don’t need a parking spot).

So how do we solve this? Where do we start ?Again, I advise to use common sense and start small… Think big, but act one step at a time.

Think what would be the easiest thing to turn into a true service to my end users? Standard examples are communication, workplace provisioning, print services. Don’t be tempted in using products as a Service (MSproject or SAP are not a service). Remember the definition of a service: ‘an organized system of labour and material aids used to supply the needs of the public’ (source: the World English Dictionary).
I also advise to take one that you have fully or partially outsourced to a vendor. That way you make sure your underlying contract reflects your service needs. You cannot guarantee availability if your vendor can’t…

Once established, build the service. What do we need to deliver this service. keep the life cycle in mind… We need to build and launch the service, then we need to make sure people can buy it and get it, we need to maintain it, we need to foresee changes, and at the end of the life cycle we will need to decommission the service. Each of these aspects should also be addressed in the SLA (service level agreement), representing how we will deliver the service, at what price, under what conditions, for whom, etc.
Don’t figure this out within the IT department, talk to the business, they are the buyers… Make some scenario’s, different levels of service at different prices. Explain them in terms they can understand and help them decide.

Say you are talking about availability for a system that processes digital images in a doctor’s office. 95%, 98 %, 99% or 99,5% availability is not going to make a lot of impression on the good doctor. Ask him what is acceptable, in terms of patients waiting, needing to reschedule, time lost, etc. This he will be able to answer and possibly also express it in monetary terms (which can than be used to weigh the different availability scenario’s and their costs).

Cross charge the service back to the business unit. Even if cross charging is not done in your organization, the only way you will make the business aware of what you are doing for them, is by reporting the costs incurred. It is also a very easily accepted way to put part of the ‘cost responsability’ with the business units itself (and hence out of your hands). So report on costs and advise on actions for efficiency improvement where possible.

Set up service improvement mechanism. Look at the incidents, look at the problems, look at the processes, review with the customers and use this as input for possible service improvements.

Et voila, your service organization is born. Now apply gradually to all services and you are done ! And don’t forget to keep the focus on the customer!
Sounds easy, doesn’t it ? So, what are you waiting for ?