IT4IT – Muillekin kuin arkkitehdeille

Mistä IT4IT:ssä on kyse?

Vapaamuotoisesti englannista kääntäen: “IT4IT on standardi referenssiarkkitehtuuri ja arvoketjuperusteinen operointimalli IT:n (busineksen) pyörittämiseen”. Kyse on siitä, että oli kyseessä organisaation sisäinen IT osasto tai IT palveluyritys, IT-organisaatio ottaa roolinsa palvelua tarjoavana yksikkönä ja varmistaa IT palveluiden ennustettavuuden liiketoiminnalle samalla tasolla kuin toimitusketjunhallinta (Supply Chain Management) on jo vuosia tehnyt.

Alla oleva kuva tiivistää IT4IT:n esittämän IT:n operointimallin.

Kompastuskivenä on siirtymät palveluelinkaaren vaiheiden välillä

Kävin vast’ikään keskustelun reilun tuhannen henkilön yrityksessä johtavassa tehtävässä työskentelevän tuttavani kanssa. Hän kertoi, että heidän organisaatiossaan kompastuskivenä on siirtymät palveluelinkaaren vaiheiden välillä. Esimerkkinä toimi infra- ja työasemapalveluiden ulkoistuskeissi, jonka kokonaiskestoksi oli sovittu useita vuosia ja hinnaksi miljoonia euroja.

Kuvaan alla tuttavani jakaman kokemuksen:

1. Myyntiprosessin aikana jaettiin palvelukuvaukset, pidettiin esitykset ja onnistunut henkilökohtaaminen johti lopulta sopimuksen solmimiseen. Sopimukseen kirjattiin käyttäjälähtöisesti suunniteltu palvelu, joka vastasi käyttäjän tarvetta ja huomioi tarjoajan liiketoiminnalliset realiteetit.
2. Sopimuksen solmimisen jälkeen aloitettiin sovitusti transitioprojekti, joka tähtäsi palveluiden yliheittoon ja käynnistämiseen. Transitioprojekti miehitettiin palveluasiantuntijoilla, jotka tuntevat asiakastoimitukset kuin omat taskunsa. Olivathan he jo vuosia transitioineet palveluita. Tässä kohtaa meni ensimmäisen kerran vikaan. Ei johtuen projektoinnin palveluasiantuntijoista, vaan siitä että se “jo vuosia transitioitu” palvelu ei ollutkaan sama kuin myyntiprosessin aikana kuvattu ja tarpeeseen vastannut palvelu. Transitioprojekti oli kuitenkin pitkä, niin kuin ne kompleksisuutensa vuoksi usein ovat, ja ongelmat saatiin pätevien yksilöiden toimesta korjatuksi. Käyttöönotettava palvelukokonaisuus muotoiltiin hyväksi kompromissiksi alkuperäisen tarpeen ja sopimusehtojen välillä. Kaksi kuukautta myöhässä.
3. Transitioprojektin päättyessä oli aika aloittaa palvelutuotanto ja kaikki oli näennäisen hyvin. ServiceDesk oli valmiina yhteydenottoihin, portaaliin oli viritetty tilauslomakkeita ja integraatio toimittajan järjestelmään oli testattu. Mutta käyttöönottopäivänä, ensimmäisten asiakasyhteydenottojen tullessa huomattiinkin, että operoivan henkilöstön koulutus ja toimintaohjeet eivät vastanneetkaan käyttöönotettua palvelua. Servicedesk ja toisen asteen tukitiimit tekivät ylitöitä johtuen väärin syötetystä palvelutiedosta, uudesta tuettavasta teknologiasta sekä muista pienistä teknisistä lapsen taudeista.
4. Palvelutuotannon käynnistyksen jälkeen tehtiin töitä noin vuoden verran, jotta käyttöön saatiin käyttäjälähtöisesti suunniteltu palvelu joka vastasi käyttäjän tarvetta ja huomioi tarjoajan liiketoiminnalliset realiteetit (pois lukien tietysti satojen tuhansien eurojen ylimääräiset kustannukset, joita syntyi vaiheissa 2 ja 3)

Surullinen, mutta tavallinen tarina. Tuttavani kuvasi hankkeen suurimmaksi ongelmaksi sen, että jokaisessa vaiheessa vaihtui palvelua tuottavat ihmiset (tämä on toki ihan normaalia) ja jokaisessa vaiheessa sudittiin melkoisesti. Edellisten vaiheiden tuottama informaatio ei siirtynyt riittävällä tasolla seuraavan vaiheen asiantuntijoille. Kuulostaa itsestään selvältä ongelmalta ja luulisi, että paremmalla projektijohtamisella onnistuttaisiin välttämään nämä sudenkuopat. Mutta ei se pelkästä projektijohtamisesta ole kiinni.

Miten tämä hanke olisi voitu hoitaa paremmin?

Sankarisuorituksilla lievennettiin tilannetta, mutta tässäkin keississä todellinen ongelma löytyy palveluelinkaaren hallinnan puutteesta.

Palveluelinkaaren hallinta on ollut kaikille organisaatioille haastavaa, koska tarjolla ei ole ollut hyvää ja standardoitua kuvaustapaa. Vaatimukset, kyvykkyydet, politiikat, yritysarkkitehtuuri ja portfoliot on kyetty hallitsemaan vähintään siedettävällä tasolla, mutta niiden yhdistäminen reaalimaailman tekemiseen on ontunut. IT4IT tuo arvoketjun, referenssiarkkitehtuurin ja service model backbonen myötä tarjolle valikoiman työkaluja, joilla palvelu voidaan kuvata päästä-päähän siten että palvelun elinkaaren jokainen vaihe on seurattavissa ja loogisesti yhdistettävissä edelliseen vaiheeseen. Mainittakoon vielä, että IT4IT ei ole keksinyt koko pyörää uudelleen vaan uuden linjakkaamman rungon ja täydentää olemassa olevien viitekehysten ja standardien (esim. ITIL, COBIT, PMBOK, ISO20000) puutteita.

”Stategy to Portfolio” -arvovirta huolehtii liiketoiminnan tarpeista sekä kehittää ja dokumentoi palvelukonseptin (”conceptual service” uusista tai parannetuista palveluista. Palvelukonsepti listaa kaikki palvelukokonaisuuteen liityvät palvelut sekä liiketoiminnan että arkkitehtien ymmärtämällä tasolla. Aiempaan ulkoistuskeissiesimerkkiin peilaten tämä on siis se kohta (RFI/RFP), jossa ulkoistuspalvelutoimittajat käyvät asiakkaan kanssa läpi vakioidut palvelukuvaukset ja yhdessä pyrkivät muokkaamaan ne tarpeeseen sopivaksi.

”Requirement to Deploy” -arvovirta ottaa palvelukonseptimallin käsittelyyn, tarkentaa vaatimuksia sekä kuvaa ja kehittää niiden perusteella loogisen palvelumallin (”logical service model”). Tyypillisesti tätä on IT piireissä kutsuttu ratkaisuarkkitehtuuriksi tai järjestelmäarkkitehtuuriksi. Käytännössä kyse on pitkälti palveluiden saattamisesta palvelukatalogiin asiakkaiden saataville. Ja ylempänä kuvatussa esimerkkikeississä nämä temput olisi tehty transitioprojektin alkuvaiheessa.

”Request to Fulfill” -arvovirta sitten ottaa kopin loogisesta palvelumallista ja huolehtii että palvelupyynnöt löytävät oikeaan osoitteeseen ja loppukäyttäjä saa tilaamansa palvelut sovitun mallin mukaisesti. Osana arvovirtaa huolehditaan myös, että laskutus ja kustannustiedot pysyvät ajantasalla. Lopputuotoksena on käyttöönotettu (”realized service”) palvelu, joka on asianmukaisesti kuvattuna CMDB:ssä ja, mikä tärkeintä, on ylläpidettävissä ”Detect to Correct” -arvovirran toimesta. Esimerkkikeississä tämä olisi ollut tuotannollista vaihetta.

”Detect to Correct” -arvovirta. Ja kun tulee ongelmia ja jokin toimii vastoin odotuksia, ”Detect to Correct” hoitaa homman kotiin. Oli sitten kyse tiedonjanoisesta käyttäjästä tai hälyttävästä valvontajärjestelmästä. Tärkeinä yksityiskohtina ”Detect to Correct” sisältää myös muutoshallinnan, dokumentoinnin (CMDB) sekä palvelutasonhallinnan tehtäviä. Esimerkkikeississämme tämä olisi ollut tuotannollista vaihetta.

Seuraavassa kuvassa esitetään IT4IT arvoketjun ja service model backbonen eri abstraktiotasojen suhde toisiinsa.

Joillekin lukijoille saatan kuvata itsestään selviä asioita, mutta siinä tapauksessa suosittelen syventymään IT4IT:n yksityiskohtaisempiin arkkitehtuuritasoihin ja selvittämään miten service model backbone, prosessit, tietoluokat ja toiminnalliset komponentit liittyvät kokonaiskuvaan.

Yhteenvetona, IT4IT on muillekin kuin arkkitehdeille. Se on oiva työkalupakki palveluiden ja palveluiden elinakaaren e2e kuvaamiseen sekä liiketoiminnan että IT:n ymmärtämällä tavalla. Soveltamiskohteita on useita ja työskentelet sitten palveluntarjoajan tai -ostajan puolella, IT4IT:sta on sinulle varmasti iloa.

Mistä lisää tietoa?

Hyvää luettavaa IT4IT:sta löytyy osoitteesta: http://www.opengroup.org/IT4IT

• Niille, jotka eivät jaksa omatoimisesti kaikkea materiaalia kahlata läpi löytyy IT4IT Foundationkursseja täältä.
• Lisäksi, meidän oma poika Mikko Juola puhuu aiheesta Prosessipäivillä 2017 otsikolla ”Onko palveluiden kuvaaminen vaikeaa? IT4IT auttaa!”. Ilmoittaudu mukaan täältä.
• Ja tietysti, allekirjoittaneeseen saa olla aina yhteydessä

IT4IT™ is a trademark of The Open Group.

Julkaistu 02.03.2017