Mitä olen oppinut. Osa 2. Yksinkertaista

Yksinkertaisuus on äärimmäinen hienostuneisuus” – Leonardo Da Vinci.

Kirjoitin ensimmäisessä osassa asioiden ymmärtämisen tärkeydestä. Epäselvien käsitteiden lisäksi ymmärrystä vähentää tarpeeton monimutkaisuus. Monimutkainen näyttää hienommalta, paksu dokumentti vaikuttaa arvokkaammalta kuin ohut jne. Usein yritetään tehdä liian hienoa, varaudutaan kaikkiin mahdollisiin poikkeustapauksiin ja tuloksena on liikaa detaljeja. Yksinkertaistaminen ei ole helppoa, on kyettävä näkemään olennainen ja uskallettava karsia turhat elementit pois.

Kuka lukee 50-sivuista prosessikuvausta? Prosessikuvaus on todennäköisesti laadittu leikkaa-liimaa -tekniikalla, se on täydentynyt vuosien varrella. Konsultti on muokannut sitä asiakkaiden toivomusten mukaan, mutta ei ole poistanut mitään. Kukaan ei lue sitä ja kukaan ei toimi sen mukaan, mikä on oikeastaan hyvä, koska paksu prosessikuvaus on melko varmasti epälooginen ja sisäisesti ristiriitainen.

Hyvä prosessikuvaus on lyhyt, korkeintaan muutaman sivun mittainen ja sen kuvista näkee nopeasti, miten prosessi toimii. Käytetyt termit on määritelty selkeästi. Prosessikaaviot näyttävät olennaiset vaiheet, kuvaus ei takerru yksittäisten poikkeustapausten käsittelyyn.

Sama koskee raportteja. Hyvä raportti on lyhyt ja selkeä ja se nostaa esille tärkeimmät havainnot. Huono raportti on uuvuttavan pitkä, eikä siitä jää mitään selkeää kuvaa asioiden tilasta ja kehityksestä.

On monta asiaa, jotka vaikeuttavat yksinkertaistamista. Ryhmätyöskentelyssä on helpointa hyväksyä kaikkien ehdotukset, kuin noudattaa tiukkaa linjaa. Monimutkaisuus tuo töitä konsulteille ja kouluttajille. Tulosten laajuus luo mielikuvan tehokkuudesta ja tuottavuudesta.

Mitä olen oppinut. Osa1. Selkeät käsitteet

Mitä olen oppinut.

Olen jäämässä eläkkeelle ja päätin kirjoittaa lyhyen sarjan niistä asioista, joita olen oppinut it-palvelutoiminnasta näiden vuosien aikana. Oma urani alkoi jo 70-luvulla. Olen koodannut vähän, auttanut muita tietokoneen käyttämisessä, vetänyt asiakaspalveluyksikköä, mutta ennen kaikkea olen konsultoinut it-päättäjiä toiminnan kehittämisessä. Matkan varrelle mahtuu paljon onnistumisia, mutta toki myös epäonnistuneita hankkeita.

Osa 1.  Selkeät käsitteet

Asioiden ymmärtäminen on tärkeää ja sitä varten pitää olla selkeät käsitteet, joiden avulla asioista voi puhua ymmärrettävästi. Tämä ei ole aina kaikkien tavoite, sillä epäselvyyden avulla voi häivyttää monia asioita. Vaikeaselkoisuus luo mielikuvan osaamisesta, asiantuntija vaikuttaa pätevältä, kun hänen esitystään on vaikea ymmärtää. Joskus vaikeaselkoisuudella peitellään omia tarkoitusperiä, esimerkiksi monimutkaisten sijoitustuotteiden perimmäinen tarkoitus on tehdä rahaa niiden myyjille. Ostaja luulee hankkivansa voittoja nerokkaalla tavalla, ymmärtämättä tuotteiden riskejä.

It-palveluhallinta on vaikea ala. Se on monimutkaista ja siitä on vaikea saada otetta. On aito tarve saada selkeä kuva toiminnasta, jotta sitä voi ohjata ja kehittää. Toiminnan kuvaamiseen on kehitetty erilaisia malleja, joiden tulisi auttaa ja joiden avulla voisi kuvata hyviä käytäntöjä. Valitettavasti malleilla on taipumuksena kasvaa ja monimutkaistua. Monimutkaiset mallit tekevät hallinnan vain entistä vaikeammaksi.

Hyvä esimerkki epäselvästä termistä on palvelun käsite. Palvelu on vaikeasti määriteltävä asia ja puhe palvelusta jää helposti epämääräiseksi. ITIL määrittelee palvelun lähinnä vuokraamisena tai liisaamisena. Asiakas saa haluamansa hyödyn ilman omistamiseen liittyviä erityisiä kustannuksia ja riskejä. Määritelmä on huono, se ei sovi it-palveluihin kuin aika harvinaisissa tapauksissa.

Palvelusta on helpompi puhua, jos sen jakaa keskeisiin komponentteihin: palvelulupaus, palvelujärjestelmä ja palvelutapahtuma.

  • Palvelulupaus on palvelutuote. Se kuvaa palvelun toiminnan pääpiirteissään ja korostaa asiakkaan saama hyötyä. Palvelulupaukset voivat olla asiakaskohtaisia tai tuotteistettuja.
  • Palvelujärjestelmä on tietotekniikasta, ihmisistä, prosesseista, ohjeista jne. koostuva toiminto, joka tuottaa palvelulupauksen edellyttämiä asioita.
  • Palvelutapahtuma on asiakkaan transaktio palvelujärjestelmän kanssa.

Tämä kolmijako on hyvin keskeinen asia palveluhallinnassa, jo jos sitä ei ymmärrä, on pihalla.

Huvipuisto on palvelu, joka tuottaa nimensä mukaisesti huvia asiakkailleen. Huvipuistossa on runsaasti palvelujärjestelmiä, kuten siivous, ylläpito, vartiointi, vesi- ja viemäröinti, laitehankinnat jne. Lisäksi siellä on tietysti paljon laiteita. Asiakkaan näkökulma palveluihin on aika erilainen kuin huvipuistoa pyörittävän organisaation. Asiakas näkee pinnan ja hänelle tärkeät asiat. Henkilökunta työskentelee pinnan alla.

On hämmentävää puhua vaikkapa palveluluettelosta, jos ei täsmennä puhuuko lupauksista, järjestelmistä vaiko tapahtumista. Esimerkiksi it-palvelutoimittaja voi myydä it-järjestelmiä palveluna asiakkaille, jotka ovat itsekin it-ammattilaisia. Liiketoiminta taas on vähemmän kiinnostunut teknisistä it-järjestelmistä, vaan puhuu mieluummin palvelutapahtumista.

Toinen vastaava esimerkki epäselvistä käsitteistä ovat insidentti ja ongelma. Insidentin- ja ongelmanhallinta ovat pohjimmiltaan samoja asioita ja niiden käsittely erillään luo turhaa hämmennystä. Insidentti on häiriö ja ongelma sen aiheuttaja. Joskus näitä voi käsitellä erillään, mutta usein insidentin ratkaiseminen vaatii sen syyn tunnistamista. Jos sulake laukeaa, kannattaa selvittää laukeamisen syy, ennen kuin kytkee virran uudestaan päälle.

Kun laitan leivänpaahtimen päälle, se välähtää ja keittiön valot sammuvat. Valot sammuvat koska sulake on lauennut ja syyllinen on leivänpaahdin, joka haisee palaneelta. Onko sulakkeen laukeaminen insidentti ja onko leivänpaahdin ongelma? Laitanko vain sulakkeen takaisin päälle? Viisainta olisi vain laittaa leivänpaahdin kierrätykseen ja hankkia uusi.

On parempi lähteä liikkeelle asiakkaasta ja kuvata asiakkaan palvelutapahtumia. Asiakas voi tarvita neuvoa, haluta tilata jotain täydennystä tai sitten asiakkaalla on ongelma. Toinen näkökulma on palvelujärjestelmän kannalta järjestelmän viat ja häiriöt, joita pitää korjata. Epäselvien käsitteiden ansiosta nämä asiat menevät helposti solmuun.

Monet konsultit rakastavat vaikeita termejä, he pyrkivät luomaan mielikuvaa ylivertaisesta osaamisestaan. Olen nähnyt liian usein, kuinka konsultit puhuvat asioista, joita he eivät itse kunnolla ymmärrä (olen tietysti syyllistynyt siihen itsekin). Tämän hetken muotisanoja ovat esim. SIAM ja DevOps.  Kannattaa kysyä ns. tyhmiä kysymyksiä. Esimerkiksi:

  • Mitä tuo sana oikeastaan tarkoittaa, voisitko avata sen lyhyesti?
  • Milloin olet itse soveltanut tätä menetelmää?
  • Mitä se merkitsee meille?

Asiansa osaava kykenee avaamaan termit, kertomaan omista kokemuksistaan ja osaa soveltaa niitä asiakkaan tilanteeseen.

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 http://www.hus.fi/en/about-hus/Pages/default.aspx

 

 

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.

CSF and KPI

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.

IT4IT kiinnostaa

Tammikuu 2016 on ehkä (kuukautta on vielä jäljellä muutama päivä) kaikkien aikojen vilkkain kuukausi Pohjoisviitan sivuilla ja syynä on IT4IT. Kirjoittamani juttu on kiinnostanut lukijoita Suomessa ja maailmalla, kävijöitä on 61 maasta.

Jos haluat kuulla lisää asiasta, tule Prosessipäiville kuuntelemaan 19.-20.4.

There is only one customer

The concept of internal customer is an idea to increase quality by motivating people to serve other internal teams as they were their customers. In the model the various units form a chain or network of service providers who serve each other. The internal service model allows all employees to have some direct customers. Companies or organizations usually have a customer for their services or products. They work for the customer who pays the costs. Some of the work is indirectly related to the customer and in some cases the link is complicated.

IT used to have a distant connection to business. Data was entered via punched cards and input from IT to business or customers was via printouts, reports, invoices etc.  It was natural to see IT as an internal service unit. In ITSM the concept of internal customers has been adopted very thoroughly. Instead of just using the internal service model for motivating staff, the ITIL books suggest that one needs to have a service strategy for creating and managing a service portfolio, as if the internal customers were real. An IT unit which follows the ITIL model acts like it is an independent business which can decide its own strategy. If that is right, then the corporation should check whether the IT service unit is competitive. If it isn’t, the corporation can switch to an outside vendor, if it is then the corporation can spin off the IT part as an independent business.

Most large corporations have several internal support functions: finance, human resources, legal, marketing and IT. It is common that directors of finance and legal are board members and it is relatively easy to become a CEO from those positions. CIO’s are much less likely to be included in the top management team. The reason for this is that finance and legal are involved in the business while IT can be seen as just a technical service.

Stephen Mann wrote a blog about how one should not limit ITSM models just to IT. http://allthingsitsm.com/enterprise-service-management-not-just-itsm/. I agree up to a point. The concept of internal customer is not harmful if applied with sense. It is a good idea that for example the service desk staff treat the people who ask for help as customers. It is a natural model in that situation. And the service desk model can be applied to many other situations. The ITSM tools can be applied to many other business processes. I disagree with the idea that the whole internal service model should be copied to other services. It is a better idea to move to the opposite direction.

It has become quite common that outside customers have a direct connection to the IT systems. A customer may check current information about availability, delivery times etc., they can enter their orders and update their information. The role of IT has changed or should change from internal service provider to a partner of the business.

There is only one real customer and there is only one real strategy. This means that a lot of the elements of the internal customer service model are unnecessary. There is no need for a comprehensive service catalog, service strategy, service level agreements for example. Instead of IT services to the business there are business services to the customer. This means that there is very little need for IT centered best practice models, instead IT needs to apply the business models.

New view on service catalogs

I have been thinking about the practical implications of breaking down the concept of service. One obvious case is the re-thinking of the service catalog. Writing a good service catalog is not easy. There are books and training about it but good examples are rare. I have come to the conclusion that talking about service in general in ITSM is actually a waste of time.

A service promise or proposal is about the outcomes the customer want. These may be specific or general, all depends on the customer needs. There is a major difference between internal IT and external IT. External IT must sell its services and there is usually competition. It is not easy to make good service proposal, it is a business skill and I will not cover it in detail. Internal IT is in a different position; it has a monopoly position which it should use wisely or it will lose it. It needs to be able to deliver the IT services the business wants. The business owns it and can decide what the IT does. Internal IT needs to make and keep a service promise which satisfies the customer.

A service system is a combination of people, processes, hardware, software etc. Usually there is a collection of service systems to fulfill the service promise. Typical service systems are: an application, network, servers, service desk etc. Service systems can be outsourced or internal. Some service systems are visible and recognizable to the customer; other systems are hidden or uninteresting from the customer’s point of view.

When service systems operate, they may perform service acts. Service acts are touch points between the service system and the customer and the service promise is fulfilled by the service acts.

This model leads to three different ”service catalogs”, which are much easier to design than the current model:

  • A list of service promises contains the promises IT has made to the customer. They need not be very detailed but the customer may require exact details of some important service systems.
  • A list of service systems describes all the components of the whole service system. This is just a breakdown of the whole machinery to smaller components. The customer may be interested in some elements of it but not at all interested in some other elements. The list would be identical with the list of higher level configuration items.
  • A list of service acts describes in detail what the customer can get from the service provider.

The discussions with the customers should concentrate on the list of promises and the list of acts. It is possible that the customer is interested in the details of some specific service system but hardly ever interested in all of them.

Consider an amusement park. It has a simple service proposal: you and your family will have fun. It may add information about the number of rides, restaurants etc. It may describe some technical details about selected rides like maximum speeds but there will not be exact details of all rides. The service proposal will contain exact information of the available price options and their benefits.

 All the rides and restaurants are service systems, but there are other systems like security, cleaning, maintenance etc.

 There will be a detailed list and map of all the rides and other service facilities and that is the most interesting list for the users.

 There are usually no SLAs.

A service promise might ideally look like this:

The IT departments supports business units by providing the business with up to date tools and ensuring that the IT systems work well. The goal is to have no events that cause business losses and to make sure that the staff will lose very little time due to IT technical problems.

The list of available services would be on the support portal and would include things like:

  • order a computer
  • order an application
  • new employee
  • etc.

Stuart Rance wrote recently a blog about why one should not define applications as services. I agree with that, but you could have customers who want to specify some important IT application and require an SLA for it. The problem with this is that the IT and the customer won’t mean the same thing. The application can be outsourced from vendor A and it runs on platforms provided by vendor B. It needs data from other applications. In worst case different business units own the contracts or the applications. The application might be running 100 % ok but some other system might not be providing the necessary data.

The solution this would to make a service promise about the application. This can be a problem if there is no overall responsibility for it. Then there are two options: 1) the customer negotiates SLAs with each vendor via the business unit which owns the contract. 2) some party takes the role of a service integrator.

The second option is most likely much better for all parties, which explains the current popularity of SIAM.

%d bloggers like this: