ITSM and surgery

Kuva1I had my right eye operated last week. It was a new procedure where they remove some tissue from behind the eye and the surgeon operates through the eye. Scary stuff, especially as I was wide awake throughout the procedure. After the operation I have been thinking of the similarities of surgery and ITSM.

It is clear that surgery is a service, I receive the value (if the operation is successful) and the staff is paid to do the work. I have criticized the ITIL service definition as it requires a service to remove the specific risks. That doesn’t really work in IT and in my case. All real risk is mine, or hopefully was.

It is quite difficult to assess the value of the operation. Without it I might have lost my sight from the eye but this would have happened gradually. It will take time to know if this operation was successful. Of course if it is a failure, I will know sooner. (Here in Finland it is not possible to make money by suing the doctor.)

I am a customer, the operation costs me 107.30 € but that is not the real cost of the operation. I am a user in the sense that I do not make the contract between the hospital and the city of Helsinki who pays the rest. Neither of these terms really fit in this case.

There is no service catalog for me, I was told that I must undergo this operation and this procedure is new but less risky than the old option. Actually this was the first week when they started doing this procedure, which has been developed in the USA. The original inventor was still present monitoring the operation and assessing the results. I don’t fully understand what was done and what are the risks. There is no SLA. Of course I would like to have a promise of 100% success but it is not possible.

The hospital has processes for managing patients.  They seem fairly efficient but they are not very relevant to me. The service part is not very important. The surgeons are not very good at customer service, they are interested in my eye, not me. But that is ok, the only thing what matters to me also is the procedure itself.  Customer satisfaction is not a good concept in this case, it is quite difficult to be very satisfied with this type of operation. I still need to apply drops to my eye more than 20 times a day which irritates the eye and there was some bleeding which makes the eye a bit cloudy. It should become clear soon and the number of drops needed is going down.

Somehow I think that the ITSM concepts miss something which is highly important. It requires a lot of trust to let someone operate through your eye. What I want is that the team doing the operation is competent, motivated and professional. Process metrics are not relevant. In this case I know that the general level of health care in Finland is good and this Helsinki University hospital is the best in the country. Trusting them was not difficult for me. Providing relevant metrics would be difficult. The other hospitals in the country send their most difficult cases here

I think this is what the business also wants from the IT provider. There are technical areas where the business decision makers don’t understand the details and cannot really estimate the risks. In serious matters they should be able to trust their IT providers to be competent, motivated and professional.


Here is a bit more detail information in case you are interested. My disease is glaucoma, it has no symptoms in the early stages but in the long run it will damage the optical nerve. The usual treatment is medication but it does not work always and it is not a cure. It is a good idea to visit an ophthalmologist regularly. The hospital was



Waste of effort

IMG_1615I had an interesting discussion with Mark Smalley when he was visiting Helsinki. We discussed the value of data on the ferry to Suomenlinna island.

System architects like to create beautiful models of operations. The models are based on information that moves between components. The model runs like a clockwork, but the problem is that the data entry is manual. It is quite easy to make mistakes while entering the data and there is no mechanism that corrects the mistakes. Soon the system becomes tainted. As Mark put it, it is like mixing wine and dishwater. Adding a little wine to dishwater doesn’t change the nature of dishwater, but adding a little dishwater to wine certainly does.

There are two major activities that include a lot of manual data entry in ITSM: incident and configuration management. Both suffer from this data quality problem.

In incident management the staff typically add service and configuration information to the ticket. The problem is that in many cases they do not have the required information and therefore have to guess. The result is like dishwater in wine. Nobody trusts the incident data and the reports based on it are therefore generally worthless.

In configuration management all changes must be recorded in the CMDB. It takes a lot of effort to build and maintain the CMDB. Unfortunately, it takes very little effort to ruin the system. Imagine a person making an emergency change at 5 AM to solve a major system outage. After a successful operation, he goes home to sleep. The next day he updates the CMDB but makes a mistake or forgets something. Then people stop trusting the CMDB data, they realize that they need to check the actual situation to be sure. After that it becomes less important to record the changes.

%d bloggers like this: