Archive for the ‘IT Service Management’ Category

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 ?


Those historic words were the beginning of a thriller that lasted a couple of days and where process (and service) management beat the mathematical odds of life and death.

For those who have no clue what I’m talking about, see the classic movie (Apollo 13 featuring Tom Hanks and on VT4 this Friday).

And although ITIL, Service Management and the likes still had to be invented/discovered (this story happened in 1970 were ITIL came into play after the Falkland war in 1982), it is exactly the ITIL Foundations that saved those men (probably helped by a good guardian angel).

A dutch company (Gaming Works) has used this theme in a great simulation game for companies.

– The game is fun to play and experience learned me that even the most reluctant participant gets caught up in the action and is very soon deeply involved in making sure the astronauts are saved.

– The game is all about teamwork, communication learning and (process) improvement. This makes it the ideal combination between a team event (HR) and a training.

– Because it is a simulation, the people involved are drawn away from the day-to-day organization, hierarchical structures and sometimes even their own inhibitions. This often leads to open and profound discussions about processes and the way they are being followed/used. Of course this reflects the issues, frustrations, pitfalls and opportunities of the real world situation, making the game an excellent learning experience for the people involved and their management.

– The game introduces process and service thinking (ITIL V2 or V3, ISO 20000) without any need for prior knowledge or understanding of these frameworks. Hence it is an ideal ‘get everyone on the same page’ exercise to help overcome resistance when introducing Service Management in your organization.

– Oh and did I already mention that it is great fun !

If you are interested or want more info, do not hesitate to contact me.

ITIL is owned and registered by the British OGC
Apollo 13 an IT Service Management simulation game is owned and registered by Gaming works bv, The Netherlands.

Someone recently asked me : “What do you think the 3 most important and urgent challenges are for a CEO”

I replied: Service, Service and Service …

1 Service : Most Companies (not all, I will admit) no longer deliver products to the market, but they deliver a service, or at least the customer expects them to deliver a service. We are not buying a SIM card, we are buying the service of being able to communicate with our cell phones. I am not buying electricity, but I am buying ‘a continuous access to the energy (electricity) I need, when I need it,with availability and support guarantees included… I am not buying broadband, I am buying the ability to connect to the world (when, how and whatever I like).

2. This means the company providing the underlying product needs to build and maintain that service, set up customer helpdesk, make sure complaint handling is in place, take into account availability, capacity, performance of the service. Everyone in the organisation has to be thinking ‘How do I contribute to helping deliver the Service to our customers’, whether it is a janitor or a blue-collar, a financial operator, hr officer, to management staff, everyone.

3. To realize this the entire organization also needs modelling around Service Management. And since IT plays a part in most (all) of these business processes, IT itself will need to be organised to deliver that Service. Not only deliver IT services to the users (employees), but actually contribute to delivering the Service to the Customers.  And that is where IT Service Management comes in. But the first step (and the one most companies fail, in my opinion) is defining the services. Too often they are still focussed around technical services and not delivering/supporting/integrating with business processes.

A lot of confusion exists, when people talk about CMDB.

Firstly, and the previous ITIL versions caused this, too often people think the CMDB is one database. Although this was never meant nor literary expressed like this in the ITIL framework, it was often translated like this (even by consultants). This reflex almost immediately turned the CMDB into an assets database.
The V3 ITIL framework has resolved this and it is now becoming clear that the CMDB is a collection of data sources (and not just one database).

But and this is more important, in the everyday operations, you still run into some issues, when you look at the definitions of a Configuration Item.

Let me explain by using an example (pure fiction, but so real in many cases), starting with a question:

Is a USB stick a CI ?

A lot of people will answer: NO
Their reasoning will be that they aren’t unique (no serial number and not enough place to tag it with an identifier) and the cost doesn’t weigh up to the cost of maintaining it as a CI.

There is not a lot I can argue with, because their reasoning is correct.

The requests to get a USB stick are handled by the Helpdesk
I don’t want to give out 5 sticks to every employee, so I would like to know who has one
When they leave, I’d like them to return it (optional in the case of a USB stick, but sometimes important)
I’d like to do stock management on these USB sticks, so that I always have them available
I need a way to allocate the cost (maybe not in the case of a USB stick)
The tool that I’m using as my IT support tool gives me the opportunity to do all of the above (if I have the USB stick in there as a CI)

So do we make it a CI anyways ? and if you were only looking at the cost, how about something a little more expensive, say an external hard drive or a secondary power supply or a docking station (which, I know, often does have both a unique serial number and the space to tag it).

How do I solve this? And this is how I advise it to the clients I work for:

Create a generic CI : USB Stick 2GB
You can, as you would with other CI’s, fill in details about brand, supplier and any other attribute that makes sense. Also, if your tool will allow it, put in the number you have purchased (my tool calls this max. number of installations)
Now register any demand for a USB stick as a service request (remember a service request is actually a pre-approved change with minimal impact and where every step to be taken is known and documented). Every time the request is fulfilled you add (link) the user to the CI.

With this we achieve a lot of different things that we want, without turning the USB device itself into a CI:
– The USB stick offering can be placed under a (sub)service (e.g. provide consumables for a standard work platform)
– The demand can be easily processed (and registered) by the Helpdesk
– Usage (who has one, how many requests, even charging if that is applicable) can easily be tracked and reported on
– Stock can be managed (e.g. create alert if available quantity falls under 10)
– When it is decided to switch to 8gb sticks, a new CI will be created, and hence a more formal change will need to be processed, making room for supplier management (purchasing: still the correct supplier at the correct price), release (testing and documenting) and config mgt (updating CMDB, update catalog: possible making old stick unavailable, adding new stick, updating service request, adjusting reporting, etc…)

The number of things you can add in this way and track and manage through the Helpdesk and helpdesk tool extends even further than IT. I’ve seen this system used in smaller companies to track and manage books on loan, confidential documents, keys, credit cards, etc… Of course if you HR is tracking this, there is no need to duplicate…

And than again, the question so often asked in configuration management/cmdb discussion is, where is the cut-off point? where do I stop registering them as a generic, and start identifying as a CI?
And again the answer is : IT depends! Where does the need start to have a formal change process when it changes, that is where you would identify them as individual CI’s.

Let’s take laptop as another example. I know that in most companies they are registered as a CI (sometimes/often bundled with consumables).

But look at this example: a large company which has outsourced its entire HW to an external company. Next to that the helpdesk too is outsourced.
This company approached a laptop from their point of view in the change management process and concluded that they would not perform change management on individual laptops (that was the outsourcer’s problem). However they do want to control what that standard laptop is and who has one.

It could make perfect sense to them, to register a generic workstation setup (e.g. standard laptop), with as it’s attributes what they understand under that (e.g. dell latitude E6400, 160GB, 2MB RAM, etc…) and only track who has one. The service request (at the outsourcer) holds one approval (direct manager, known to the system and the approval process is automated).
Now, of course the outsourcer will have a CMDB where the laptops are obviously treated as CI’s. The only thing remaining is set up a reporting, so that if needed, decision makers in the company can get info on laptops from the outsourcer, end of story.











Maybe not perfect…but this is how I see the interaction between project and the support processes. There shouldn’t really be a conflict or issue… it is possible to align them neatly.

These days, most companies rely on IT and IT infrastructure to support part or all of their business. Therefore the need to fix major incidents is becoming more and more pressing, since companies tend to lose money when services are down.

Most companies also have change and release control in place, which balances stability vs flexibility in their organisation.

Emrgency changes and the emergency change process (ECP) are then what reconciles the urgent need for an immediate fix (read change) versus the control and management required for normal change.

In an outsourced environment there are some more parameters that will complicate the matter. Who will authorise the emergency change? how is it charged?

I’ve seen several companies that have defined the ECP as ‘fix now, do all change steps later’. This (almost) always is a certain path to disaster. Furthermore there is no framework or best practice that tells you to do this… And you are opening the door for a specialist to change the IT environment whenever he feels like it, (ab)using the Emergency change as the means to get things done.

So, how to cope with this?
The easiest way to deal with this is formalize the Emergency change Process for each critical service or system. This ECP will list the criteria to invoke it, who will be on the crisis team (including a contact list with backup/escalation), and what the steps to be taken are (eg. minimal testing requirements). Defining these is usually done with the release of a new service or system.
The biggest advantage is that there is little room for discussion…The rules are set (and agreed with the business).

After the change has been implemented, a formal handover to the CAB of the change needs to be done, in order to ensure that:
– Everyone is aware of what exactly was changed
– What the impact is of the implemented change on other systems and/or services
– what the impact is of the implemented change on other ongoing changes/releases
– we know what could have been done to avoid this (lessons learned)
– make sure we know what the current version/state of the production environment is
– asses the need for the emergency change

I also advice to launch a problem (after the implementation) to make sure the RCA of the incident has really been handled.