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.

ITIL V4 is born

Unfortunately, both the father and mother probably deny this so there will be no party.

The Open Group has published the IT4IT™ Reference Architecture, Version 2.0, an Open Group Standard. http://pubs.opengroup.org/it4it/refarch20/index.html

IT4IT is a real architecture model, it is well defined with logical elements and definitions of Functional Components and their relationships. It is based on four value streams:

  • Strategy to Portfolio (S2P)
  • Requirement to Deploy (R2D)
  • Request to Fulfill (R2F)
  • Detect to Correct (D2C)

There are also supporting functions within the value chain model such as Supplier Management, Asset Management, Human Resource Management, Legal, and IT Financial Management.

IT4IT

 

It has taken the basic structure of ITIL and made an architectural framework of it. The components are well defined, there is data model and relationship structure. It clearly at significantly higher lever of abstraction and sophistication than what the ITIL literature offers.

The architecture is independent of vendors, processes etc. The authors claims that it works as well in agile environment as the in traditional waterfall style development. It is really not meant to be the next version of ITIL but it looks like it very much. The authors say that it is not a best practice model, but it follows ITIL very closely. In some places the text looks like it has been copy pasted from ITIL (for example Incident).

The architecture seems to be aimed to an internal IT service provider, just like ITIL. It assumes that the service provider has a high degree of independence and can execute its own strategy. It does describe a provider/broker model where IT acts as a service broker between the business and various vendors, but it does not cover situations where either the IT is an external service provider or where the IT is just one service provider, but not a broker. When business takes more responsibility of its IT solutions, there is less need for a centralized IT department between the vendors and the business. The authors clearly oppose this development so the IT4IT model can be seen as an attempt to boost the position of the CIO. Running IT as a business seems to be the goal and I disagree with it. If you can run IT as a business, then you should become an external vendor and test your competitiveness against other vendors. It is too easy to be a business within a monopoly situation.

It is interesting to see that there seems to be a consensus within the Open Group that attempts to use ITIL generally fails. The authors write: The absence of a service-centric IT operating model in the past helps explain why all the time and money invested in best practice process frameworks like ITIL and COBIT, working with consultants to optimize IT organizational structure, and investments in IT automation have fallen short of expectations. IT4IT is offered as a new solution to this evident problem.

My estimate is that IT4IT can be quite valuable for any organization that plans to use ITIL. It is much more structured and logical. Nobody should implement any ITIL process tools without studying the IT4IT data model. In that sense IT4IT can replace ITIL if the Open Group creates trainings and certifications.

Unfortunately, IT4IT copies many of ITIL’s core problems. I have written a lot about the problems of ITIL and I will not cover all those as most of them have been entered in IT4IT but I’ll mention one. There is no customer service and support. Users can either request services or call to report incidents. Incidents fall in the same stream as events. Very technology centric. Fresh ideas from the 1980´s.

Parempi laatu, pienemmät kustannukset

Turhan työn poistaminen on avain laadun kehittämiseen kustannuksia vähentämällä. Olen koonnut tähän joukon ideoita, mistä voit löytää hyviä kohteita turhan työn vähentämiselle. Nämä ovat ideoita ja niiden soveltaminen pitää tehdä harkiten. Organisaatiosta varmaan löytyy henkilöitä, jotka vastustavat näitä ehdotuksia. Pyydä vastustajia esittämään saavutetut hyödyt ja tarkista kaikkien osapuolten näkemys. Hyvin toimivia käytäntöjä ei tietenkään kannata purkaa, jos ne toimivat hyvin kaikkien osapuolten mielestä. Asiakkaan mielipide on aina tärkeä.

  1. Unohda palveluluettelo, jos se ei tunnu toimivan. Olen nähnyt lähinnä vain huonoja ja hyödyttömiä palveluluetteloja, joita puolustavat vain niiden kehittäjät. Kaikkea IT-toimintaa ei tarvitse kuvata palveluna. Monissa tapauksissa liiketoiminta ja asiakkaat tekevät yhdessä asioita, ja IT-väen tehtävänä on tarjota asiantuntemusta, osaamista ja tekemistä yhteisten tavoitteiden eteen. Yhteistyö ja palvelu ovat eri asioita.
  2. Unohda SLAt. Keinotekoiset palvelutasot eivät takaa laadukasta palvelua, mutta työllistävät paljon. Kaikkea ei voi mitata hyvin ja huonot mittarit ovat turhia.
  3. Unohda CMDB. Sen rakentaminen ja ylläpitäminen on työlästä. Oletko varma, että siitä saadaan todellista hyötyä. On mahdollista, että CMDB:tä ylläpidetään, koska johto on niin määrännyt mutta kaikki tietävät, ettei sen tietoihin voi luottaa.
  4. Poista turhat tiketit. Automaattivalvonnan hälytyksistä on turha avata tikettejä. Asiat pitää hoitaa mahdollisimman vähillä vaiheilla. Tiketin avaaminen ja sulkeminen ovat turhia työvaiheita.
  5. Poista turhat kentät tiketeistä. Keskity olennaiseen. Palveluluettelon ja CMDB:n poistaminen auttaa, mutta vaikka et poistaisi niitä, on silti turhaa kytkeä kaikkia ongelmia johonkin tiettyyn palveluun tai konfiguraation osaan. Usein niiden määrittely on vaikeaa tai mahdotonta. Pakolliset luokittelut tuottavat roskatietoa.
  6. Unohda turhat prosessit. Prosessi on hyvä apuväline toistuvien rutiinien pyörittämiseen, mutta se ei sovellu kaikkeen tekemiseen.
  7. Unohda turhat mittarit. Prosessiajattelu luo helposti paljon prosessimittareita, joilla ei ole oikeasti mitään järjellistä käyttöä. Älä mittaa aktiviteetteja ja älä ainakaan aseta niille tavoitteita. Keskity tuloksiin, ei puuhasteluun.
  8. Rakenna asiakkaille palvelupisteitä, joissa heitä autetaan tietotekniikan kanssa. Yksi vierailu voi ratkaista monta ongelmaa ja säästää aikaa sekä asiakkailta, että asiakastuelta.
  9. Ole mukana sosiaalisessa mediassa, jos asiakkaasi ovat siellä. Yritä luoda keskusteluforumeita, joissa asiakkaat voivat keskustella palveluihin liittyvistä asioista. Yksi hyvä keskustelu voi ratkaista monen asiakkaan pulman.
  10. Kuuntele asiakkaiden mielipiteitä, mutta älä kiusaa heitä turhilla ja huonoilla kyselyillä.
%d bloggers like this: