Palvelut ja yhteystiedot

Olen kokenut asiantuntija ja vuoden 2012 ITSM-henkilö. Erityisalueitani ovat IT palvelunhallinta, ISO 20000, service deskit, asiakastyytyväisyyden ja prosessien mittaaminen. Tarjoan konsultointia, koulutusta ja tutkimuspalveluja.

2011: PINK 11, Las Vegas, itSMF Finland  Espoo
2012 itSMF Russia, Moscow, itSMF UK, Lontoo, itSMF Estonia, Tallinn
2013 LeadIT (itSMF Australia), Canberra, itSMF Finland, Helsinki, itSM(F) Belarus, Minsk, itSMF Estonia, Tallinn, itSMF Sweden, video panel
2014: Service Desk Forum , Stockholm,  FUSION14 (itSMF USA), Washington DC 
2015: TiVI Service Desk, Helsinki, ISACA, TiVaKo 2015, Helsinki, Työkalupäivä, Helsinki
2016: TiVi Service Desk, ISACA TiVaKo 2016, Prosessipäivät  


Pohjoisviitta Oy, Alankotie 29, 00750 Helsinki
GSM +358 (o)5o-5544733
Twitter: @aalem

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.

What’s wrong with IT4IT?

IT4IT is a new standard and you can now get an IT4IT certificate by answering 40 questions in one hour. I.e. being an expert seems to require that you need to learn it by heart. While I don’t like this type of certifications, the main problem is that the standard is not ready.

The standard is a curious mix of a meta model for an IT ERP systems and best practices. The model shows the application components and the data interfaces. The best practices thinking appears in the CSF’s and KPI’s

There is good thinking behind the model. It has some clear definitions and a defined description language. At some other parts, it looks like the model construction has taken over the model content. The service customer, consumer or user has been treated a hot potato. According to Charles Betz, the concept of the customer does not belong to this description level. I can understand the idea. It is possible to describe the working of some high level system leaving out the connections to the outside world, but this is not the case with IT4IT. The customer links are there. Customer has Requirements, there is an ”Engagement Experience Portal” and the Detect-component should ”understand user issues”.

While user issues are not important enough to have a component, events are. Surprisingly events have even a lifecycle. This is strange. An event is a notification of something that has happened. For example, a user may have entered a wrong password or one disc unit may have failed. In both cases the event is not significant alone, hundreds of users make mistakes everyday and the disc system is built for redundancy. Events need to be analyzed but they do not have a lifecycle.


A critical success factor (CSF) for the Detect to Correct value stream is Achieve Operational Excellence. It looks like the IT4IT has misunderstood the term CSF. According to Wikipedia:

Critical success factor (CSF) is a management term for an element that is necessary for an organization or project to achieve its mission.

Critical success factors should not be confused with success criteria; the latter are outcomes of a project or achievements of an organization that are needed to consider the project a success or to esteem the organization successful.

The key performance indicators are strange too. These are KPI’s for event management.

Increase in breadth and depth of monitoring endpoints, reduction of escalated events (via filtering/correlation/ automated resolution), reduction of false positives, and reduction of the number of security events that cause business disruption.

How do you measure ”breadth and depth of monitoring endpoints” and why would it be good to reduce escalations? Why do they assume that ”false positives” are an issue generally, why not false negatives? It is quite difficult to see how these would indicate good performance.

The next CSF is ”Improve Customer Satisfaction”. Again this is clearly the outcome, not a factor. As a KPI there is ”Increase rate of first call resolution”. The IT4IT architects live still in the era of telephone support.

There is value in IT4IT but it is far from ready.

Itilin virheet

Juttuni itil-managereiden potkuista on herättänyt poikkeuksellisen paljon huomiota ja jopa keskustelua Pohjoisviitan sivuilla, joka on melko harvinaista. Viime perjantaista tuli uusi ennätyspäivä WordPressin liikennetilastojen mukaan. Huomautan, että minä en suositellut itil-managereiden erottamista, ainoastaan referoin mitä Charles Betz sanoi esityksessä, eikä hänkään suositellut sitä, hän vain kertoi mitä eräs pankki oli tehnyt.

Lupasin eräälle kommentoijalle tehdä yhteenvedon itilin virheistä. Ehkä voisin aloittaa sittenkin luettelemalla itilin hyötyjä. Itil on parempi kuin ei mitään, jokin kehikko on hyvä olla, sillä sen avulla on helpompi keskustella aiheesta ja on hyvä joutua pohtimaan it-palvelujen tuottamista. Prosesseilla voidaan saada asioita haltuun, on tärkeää priorisoida asioita ja muutoksia pitää hallita. Itil voi toimia, jos sen soveltamisessa käytetään paljon järkeä ja arvostelukykyä, osataan tehdä itsenäisiä ratkaisuja eikä jäädä väittelemään siitä mitä itil sanoo. Itil tarjoaa terminologian ja vaikka se on vähän horjuva, on se parempi kuin ei mitään.

No sitten luettelo itilin virheistä. En takaa, että tämä on kattava mutta yritän listata tärkeimmät.

  • Turhat prosessit. Itil kuvaa liikaa päällekkäisiä prosesseja. Lukuisten prosessien pyörittäminen johtaa helposti siiloutumiseen, jossa jokainen prosessi keskittyy oman alueensa hoitamiseen ja kokonaisuus kärsii. Turhat prosessit tuottavat taas turhaa työtä ja luovat keinotekoisia raja-aitoja.
  • Integraation puute. Kuten Jarkko Hedman kommentoi tätä, ”ITIL-kirjoja lukiessa kysyy itseltään, onkohan näitä tarkastettu koskaan ristiin.”
  • Toiminnot prosesseina. Itil kuvaa suuren joukon asioita prosesseina, vaikka ne eivät mitenkään omaa prosessin ominaisuuksia. Esimerkiksi saatavuuden ja jatkuvuuden varmistaminen ovat suunnittelua, joka vaatii osaamista. Prosessien kuvaaminen ja keinotekoisten tapahtumien kirjaaminen on turhaa työtä ja tuottaa turhia raportteja.
  • Sertifioidut asiantuntijat. Itil sertifikaatit hankitaan vastaamalla monivalintakysymyksiin, joissa oikean vaihtoehdon tietäminen perustuu muistiin. Kuulopuheiden mukaan osa kouluttajista antaa kysymykset etukäteen ja kertoo niiden oikeat vastaukset. Joka tapauksessa sertifikaatti ei kerro mitään omistajansa kyvyistä palveluhallinnan alueelta. Pahimmillaan sertifioitu asiantuntija ajaa järjettömiä ratkaisuja vedoten siihen, että itil sanoo näin, vaikka kyseessä on k.o. ”asiantuntijan” itse keksimä ja täysin virheellinen tulkinta siitä mitä itil ehdottaa.
  • Virheellinen palvelukäsite. Tämä on aika laaja aihe. Lue keskusteluni Akin kanssa.
  • Häiriöhallinta. Itilin suositus syöttää event managementin eli automaattisen valvonnan kautta tulleita häiriöilmoituksia asiakastuen kirjausten sekaan on järjettömyyden huippu. Asiakastuki on aivan eri asia kuin tekninen valvonta.
  • Ongelmanhallinta on rinnakkainen prosessi häiriönhallinnan kanssa. Saman asian tekeminen kahdessa eri vaiheessa on turhaa. Uusiutuva häiriö on liian aikaisin suljettu häiriö. Sotku johtuu siitä, että asiakastuki ja häiriönhallinta on nivottu yhteen.
  • Jatkuvan palvelunkehittämisen (CSI) mittaripainotteisuus on virhe. Painopiste on toiminnan tuloksellisuuden kehittämisessä, ei prosessien tehostamisessa.
  • En viitsi edes repostella turhien prosessien vikoja, sillä enemmistö itilin prosesseista on turhia.

Mielestäni tässä on aivan riittävästi syitä hylätä suurin osa itilistä.  Mitä sitten tilalle? Se on vaikea kysymys. Olen nähnyt lukuisia vaihtoehto-tarjokkaita, mutta mikään niistä ei ole vakuuttanut. Olen myös osallistunut useampaan yritykseen luoda jotain vaihtoehtoista, mutta kaikki hankkeet ovat luovuttaneet.

ITIL managereille potkut

Pidin viisi vuotta sitten esitelmän ”Unlearning ITIL” Espoossa (eri nimellä), Lontoossa ja Canberrassa. Sen keskeinen sanoma oli, että ITILissä on vaarallisia vikoja ja ihmisten pitäisi torjua ITIL suurelta osin, unohtaa kurssilla opitut asiat. Esitys herätti aikalailla vastustusta, mutta sain myös paljon kiitoksia kuulijoilta. Olen jatkanut saman viestin kertomista osana useimpia esityksiäni sen jälkeen. Nyt viimeinkin alkaa näyttää siltä, että myös päättäjät ovat heränneet näkemään ITILin ja muiden raskaiden ja byrokraattisten menetelmien haitat.

Charles Betzt puhui eilen Hollannissa Service Manager konferenssissa ja kertoi uutisia USAsta.

potkut itil

Tulkintaa lyhenteistä: PMO Project Management Office, BRM, Business Relationship Managers, BA, lienee Business Administration, COE Center Of Excellence.

Ilmeisesti DevOps on nyt uusi hopealuoti ja lienee varmaa että myös sen tuloksiin tullaan pettymään. Joka tapauksessa ITILin tulevaisuus näyttää olevan vaarassa. Nyt viimeistään kannattaa ottaa kovalla työllä hankitut ITIL sertifikaatit pois näkyvistä.

Discussion: Definition of Service and Service Catalogs


This is a discussion between Aale Roos and Aki Lähteenmäki. We met some time ago and we discussed ITSM matters. We got to know each other many years ago when Aki attended ITIL Service Manager course where Aale was the a trainer. Aki has worked previously in his career in tool & process consultancy roles in various companies. In 2014 Aki started a consulting company with his colleagues. Aale is internationally recognized expert on ITSM and Service Desks. Aale has his own consultancy company

We share a common view that ITSM is yet quite immature and there is a lot of work ahead in improving models and practices. Our different backgrounds give us different viewpoints on possible solutions.

We decided to have a written dialog about some areas where we see major problems in current practices but are not quite sure what would be the right approach. We do this in English in the hope that other people might find this approach useful


The subject of this blog discussion is the Service Catalog for the internal IT. It is a key concept in ITIL and in IT service management but there is silly problem in it. ITIL books state that service is A means of delivering value to customers by facilitating outcomes customers want to achieve, but without the ownership of specific costs and risks.

 That is obviously not true for most IT organizations. A typical corporate IT is part of the corporation which is the customer, so it definitely does not free the customer of the ownership of the risks and costs of the IT infrastructure it owns.

So this leaves us with two choices:

  • either the concept of service is right and then internal IT is not a service provider
  • or the definition is wrong,

The first choice is quite interesting but not very useful for our discussion.

I have come to the conclusion that it would be better to stop talking about service and assuming that everybody understands it the same way. It is a better idea to split the term in three parts: promise, act and system.

  • Service promise is what we promise to do, it is not necessary very detailed
  • Service systems are all the systems we operate or buy on behalf of the customer. Service systems may contain hardware, software, processes, people, resources etc.
  • Service acts are what the customer gets. They fulfill the promises and they are the results of the service system working.

What do you think about this model, Aki?

Aki 1

I agree with you that ITIL definition is applicable only for certain cases and therefore it is not good way to describe what generic term “service” means.

I have used to understand term “service” as generic term for something which brings value for service consumer. In this context consumer can be service end user, other company, service provider’s organization or even service organization itself.

Depending on the case, service can be “pure” service like IT Service desk which provides support for service users or it can be combination of services and products. For example “Workspace service” can contain certain set of available/orderable products like workstations, mobile devices or software. Same service can contain services like service desk, control desk (monitoring), etc.

So therefore there is different kind of services and maybe we should make definitions for those instead of trying to resolve service definition problem?

For example: We could have definition for:

Service package (containing different services and/or products)

Customer facing service (service visible for customer, can contain service package(s) and defines e.g. SLA for the specific customer)

Supporting service (IT providers internal service which is not visible for service consumers but is necessary, critical enabler for service delivery, e.g. service platform backup or monitoring service)


What comes to your idea about those three dimensions; promise, act and system, I like it. But what does it mean in practice, from service definition point of view, Aale?

Aale 2

Writing a service definition is hard. The problem is that all the different service definitions you described still contain the word service. It is difficult to avoid it.

The split in three elements makes it a bit easier. For example, I would say that a Service Desk is three things:

  • a promise to help in all kinds of problems and questions regarding the IT infrastructure
  • a system with people, processes and tools
  • an act of responding to a customer and finding a solution to the customer’s problem

I think the benefits come when you create service catalogs. While there would be three of them, they should be easier to create. Could you try this approach just as a thought experiment, Aki?

Aki 2

I think I understand what you mean by this “PSA” model. If I try to combine your approach and portfolio thinking I have used to use, I can find at least two options to mix those:

PSA service model:

a promise -> Customer facing service which defines agreed price/costs elements, SLAs, other service content and commitments (between service provider and service consumer)

a system -> Supporting service, containing all necessary people, processes, knowledge and tools to deliver services.

an act -> can be process activity or CI/Asset fulfilling the promise defined in customer facing service.


Or PSA model as service modelling matrix:

For me that is the perfect match! What do you think Aale?

Aale 2

Aki, I think we are pretty close. But remember that all customer facing services are based on service systems too. The difference is that some service systems are visible to the customer and some become visible only if they fail. There are usually many service systems behind one promise. There can be also many acts.

Aki 3

Well in my mind service system is system of people, processes, tools and knowledge which will produce and deliver tasks, activities and service assets like business applications, servers, workstations, workstation software, etc. But I think tools & technology used as a part of service systems should be part of the supporting services (service system).


How does that sound, Aale?

I also started to wonder where in this picture external vendor’s are? For example software/hardware vendors or outsourcing partners? Can supporting service describe external actor’s service as well?

Aale 4

I like your picture Aki. I had never thought that an asset like a laptop would be a service act but of course it is.

Let’s take an example. The IT provides workstations including laptops, tablets etc. to the corporate customers. This service has a price list and a promises of service quality. For example, customers are guaranteed that if their device is broken, it will be replaced within two hours.

IT outsources the procurement, installation, delivery and maintenance of all devices to vendor ZZZ. The IT provides service desk, network, email, backups etc.

Now there are several customer facing service systems within one promise. The service desk and the device delivery are service systems under the service promise. Then there are also many supporting service systems like network, backup servers, device and software procurement which are not usually visible to the customer.

Aki 4

Good! So it looks like that it is possible to mix your PSA model and service portfolio modelling thinking successfully. PSA model provides nice framework to identify service type and purpose in service ecosystem. Service portfolio modelling enables concrete understanding how services can be defined in support tool as a configuration items or other service records.

Don’t try to compare ITSM metrics.

It is a waste of time to try to compare typical ITSM metrics. All depends on the definitions and these can vary a lot. Here are a few examples where the same reality but different interpretation.

Number of incidents:

Case A: All user calls are logged as incidents. There are of 10.000 incidents per month.

Case B: Service requests and incidents are logged separately. There are 7.000 service requests and 3.000 incidents per month.

Case C: Some events are logged as incidents. Event management generates 10.000 incidents per month. There are 7.000 service requests and 13.000 incidents per month (or no service requests and 20.000 incidents).


Successful changes:

Company has 200 components which it decides to upgrade. The components are in 10 locations in racks of 20 components. It turns out that four new components fail and need to be replaced.

Case A: There are 200 changes with 98% success rate as each component is considered to be a separate change.

Case B: There are 10 changes with 60% success rate as each rack is considered to be a separate change and all failures occur in different racks.


Get every new post delivered to your Inbox.

Liity 1 809 muun seuraajan joukkoon

%d bloggers like this: