Idwell on Service Management

Thoughts on how to design and implement IT Service Management

Paul Leenards


Leave a comment

The Starbucks View on the Service Catalog

I recently read an interesting book on economics (that is possible) called The Undercover Economist by Tim Harford. In this book he describes how Starbucks manipulates (by lack of a better word) their customers. They offer regular coffee for a nearly justifiable price and a whole range of products for a premium price. These whole range of products are mostly regular coffee with a little add-on, like cream, chocolate-powder or vanilla-syrup. Sometimes they are also treated in a slightly different matter, like blending regular coffee with ice-cubes. Of course, these premium products are marketed in such a way that it justifies the much higher prices. A strategy that is called price-targeting. It only works when there are people willing to pay the price: the followers of fashion and the people who do not care about their money.

In a way this principle can work in IT as well. As long as the IT department is willing to take a risk. A regular standard desktop will costs a reasonable price covering the costs of maintaining the desktop by the IT department. And there is also so much more choice. For instance, the IT department can market the IPhone for double the cost as a device only for marketing executives. Or the Extra Wide double LCD Monitors for the controllers, for which they have to pay three times as much. It is all about marketing. How the IT deparment sells the specials the Starbucks way.

The great thing is, that the IT department doesn’t have to do a lot extra in work, it is all about the feel of the product. Supporting an Iphone or extra wide LCD Monitors are not more difficult and do not take more time than supporting the standard desktop. But the customer will gladly pay more, financing product and service innovation. No doubt.

Paul Leenards


Leave a comment

Alerts and Incidents

When I read the Event Management Process chapter in the Service Operations book I had a feeling of approval. Finally, they are getting it. But then I was confronted with the Incident Definition and I realized that they still didn’t get it. Let me explain.

The definition of an incident, according to the glossary, is: “A unplanned interruption to an IT service or reduction in the quality of an IT Service”. That part I’m 100% in agreement with. But the definition continues: “Failure of an configuration item that has not yet effected Service is also an incident. For example Failure of one disk from a mirror set”. A failure of one disk from a mirror set clearly will not be an interruption of an IT Service and will also no lead to a reduction in the quality of the IT Service. There will only be an higher risk of an interruption when the other disk fails. So in the definition for incident they added an extra exception. Making a clear definition debatable. BTW since when is an hard disk of a mirror set an configuration item?

OK, you need to address the disk failure and some administrator should look into this. There should be a workorder created: replace hard disk in mirror set and check if the mirror is restored. Incident Management should be only about solving service interruptions urgently. That is why we’ve taken out the non-urgent requests. And that is why in the Event Management process there is the notion of the Alert (p. 41 of the Service Operations book). “The purpose of the alert is to ensure that the person with the skill appropriate to deal with the event is notified”. Interesting enough there is no definition for Alert in the glossary.

The nice aspect of Alert is that you can use it to schedule corrective actions, taking the urgency and subsequent rushing out of the equation. The next day an operator with sufficient skills, documented workinstructions and access rights takes the work order list and replaces the hard disk. Without being rushed, without interrupting the service and within a reasonable time (within 24 hours). If you would have followed the book you would have created an incident with a low priority, thus low on the list, and somewhere between 4 hours and 4 days the hard disk might have been replaced. Since Incident Management is always dealing with new incidents with a possible higher impact you would never know for sure that these low impact incidents will be performed in time. Plus you have to explain to your customer the higher number of incidents that they can not relate to, since they have not experienced the service interruption (since there wasn’t any).

Paul Leenards


Leave a comment

Silo’s are doomed

Today we had a discussion on Servicedesk and Incident Management and how we could improve the efficiency. The incident manager of our client is dealing with the internal hierarchy and has found that he has insufficient authority to escalate in case an incident has to be solved by staff from multiple departments. Both his service management system and the IT organization can not deal with this situation. A solution would be to minimize the number of solution groups and have an incident manager would has also hierarchical responsibility over the support staff (all of them). That will mean no more Server management departments, network management departments, SAP solution teams, etc. No more silo’s. In a whitepaper on the ISCO model of Gartner from some years ago they predicted the future of these silo’s: they were doomed. From Servicedesk/Support efficiency perspective I can not agree more with them.