Hybridimalli vai yhtenäinen viitekehys palvelunhallinnassa keskisuuressa yrityksessä

Keskisuurissa yrityksissä IT-palveluiden hallinta ja liiketoiminnan kehittäminen törmäävät usein kysymykseen: pitäisikö organisaation palvelunhallinnassa nojata yhteen yhtenäiseen viitekehykseen vai hyödyntää useampaa viitekehystä rinnakkain eri liiketoiminta-alueilla? Perinteisesti monilla organisaatioilla on käytössä ITIL-viitekehys IT-palvelunhallinnassa, ja ITIL on vakiintunut de facto -standardiksi IT-palveluiden hallinnassa. ITIL:n laaja omaksuminen on tuonut mukanaan hyviä käytäntöjä, mutta samalla joissakin organisaatioissa sen soveltaminen on johtanut raskaaseen byrokratiaan ja kankeisiin prosesseihin. Tämä on ongelmallista erityisesti tilanteessa, jossa organisaation on uudistuttava ja omaksuttava uusia toimintatapoja digitalisaation mukana.

Nykytilanteessa monessa keskisuuressa yrityksessä mietitään, miten voidaan luoda pysyviä ratkaisuja organisaation toiminnan kehittämiseksi niin, ettei nykyinen ITIL-pohjainen IT-toiminta estä uudenlaista ajattelua. Vaihtoehtoina nähdään toisaalta yhtenäinen malli, jossa kaikki liiketoiminta-alueet sovitetaan samaan viitekehykseen (esim. ITIL), ja toisaalta hybridimalli, jossa eri alueilla hyödynnetään tarkoituksenmukaisesti erilaisia viitekehyksiä (esimerkkeinä ITIL, USM, Business Technology Standard). Tässä kirjoituksessa analysoidaan näiden vaihtoehtojen etuja ja haittoja keskisuurten yritysten kontekstissa. Ensin käydään läpi keskeiset palvelunhallinnan viitekehykset ja niiden vahvuudet ja heikkoudet, minkä jälkeen vertaillaan hybridimallia ja yhtenäistä mallia. Lopuksi tuodaan esiin esimerkkejä hybridilähestymistavan käytöstä sekä suosituksia organisaation uudistumisen näkökulmasta.

Palvelunhallinnan viitekehysten vaihtoehdot keskisuurissa yrityksissä

Keskisuuri yritys (tyypillisesti satoja työntekijöitä) tarvitsee hallittuja prosesseja palveluiden tuottamiseen, mutta samalla ketteryyttä ja kykyä innovoida. Suuryritysten laajat viitekehykset voivat tuntua keskisuurelle liian raskailta, mutta kokonaan ilman parhaita käytäntöjä toimiminen voi johtaa hallitsemattomuuteen. Itse asiassa monilla keskisuurilla yrityksillä on havaittu varovaisuutta raskaita IT-hallinnan projekteja kohtaan: ITIL:n ja COBIT:in kaltaisten jäsenneltyjen menetelmien käyttöönottoa on epäröity niiden kustannusten ja monimutkaisuuden vuoksi, mikä on voinut hidastaa uudistumista . Seuraavassa tarkastellaan kolmea keskeistä viitekehystä – ITIL, USM ja Business Technology Standard – ja arvioidaan niiden soveltuvuutta sekä vahvuuksia ja heikkouksia keskisuuressa organisaatiossa. Lisäksi huomioidaan lyhyesti myös ketterät menetelmät ja muut viitekehykset osana kokonaiskuvaa.

ITIL – perinteinen palveluhallinnan viitekehys

ITIL (Information Technology Infrastructure Library) on maailman tunnetuin ja laajimmin omaksuttu IT-palvelunhallinnan viitekehys . Se on kokoelma parhaita käytäntöjä, joka tarjoaa jäsennellyt prosessit IT-palveluiden suunnitteluun, tuottamiseen, tukeen ja kehittämiseen. ITIL:n vahvuutena on sen kattavuus ja vakiintuneisuus: organisaatioiden on helppo löytää osaajia, koulutusta, työkaluja ja yhteensopivia prosesseja ITIL:n ympärille . ITIL:n prosessikirjastosta löytyy ohjeita lähes kaikkiin IT-palvelun elinkaaren osa-alueisiin, ja se luo yhteisen kielen IT-organisaation sisälle sekä IT:n ja liiketoiminnan välille. Euroopassa ITIL on ollut erittäin suosittu, ja IT:stä vahvasti riippuvilla aloilla on saavutettu suuria hyötyjä ITIL:n käytöllä .

ITIL:n vahvuudet keskisuuressa yrityksessä:

• Laajalti hyväksytty: ITIL on de facto -standardi IT-palveluhallinnassa, joten sen käyttöönotto antaa organisaatiolle tunnetun viitekehyksen ja uskottavuutta sidosryhmien silmissä .

• Parhaat käytännöt: ITIL kokoaa yhteen hyväksi todettuja prosesseja ja toimintoja, joita voidaan soveltaa organisaation koosta riippumatta. Se keskittyy palveluiden tuottamiseen, hallintaan ja jatkuvaan parantamiseen systemaattisesti .

• Yhteinen kieli ja roolit: ITIL:n terminologia ja prosessimallit luovat yhteisen ymmärryksen esimerkiksi palvelutasojen hallinnasta, häiriöiden (incident) ja ongelmien (problem) hallinnasta sekä muutosten hallinnasta koko organisaatiossa. Tämä voi parantaa IT:n ja liiketoiminnan välistä kommunikointia, kun termit ja vastuut ovat selkeät .

• Jatkuva kehitys: Uusin ITIL 4 -versio on tuonut mukanaan joustavampia ohjaavia periaatteita ja viitekehyksen, joka huomioi mm. ketterät menetelmät, DevOpsin ja Lean-ajattelun paremmin osana palvelunhallintaa . Näin ITIL:ää voidaan soveltaa aiempaa paremmin nopeasti muuttuvissa ympäristöissä.

ITIL:n heikkoudet keskisuuressa yrityksessä:

• Raskaus ja byrokratia: ITIL on hyvin jäsennelty ja laaja, mikä tarkoittaa paljon erityisiä termejä, prosesseja ja rooleja. Sen monimutkaisuus ja tarkkuus luovat ylimääräisiä kustannuksia IT-tiimeille ja voivat tehdä käytännön toteutuksesta työlästä . Ylimmän johdon näkökulmasta ITIL:iä on jopa kuvattu liian työvaltaiseksi ja yksityiskohtaiseksi . Jos ITIL viedään organisaatioon ilman keventämistä, riskinä on byrokratian lisääntyminen, hitaus ja uudistuskyvyttömyys .

• Soveltamisen haasteet: ITIL:n periaate on “Adopt & Adapt” – omaksu ja sovita . Käytännössä monet keskisuuretkin organisaatiot kamppailevat sen kanssa, miten prosessit sovitetaan omiin tarpeisiin järkevästi. Ilman huolellista räätälöintiä ITIL-prosesseista saattaa tulla joko ylimitoitettuja tai jäädä vain osittain käyttöön, mikä syö hyötyjä.

• Keskittyminen IT:hen: Vaikka ITIL periaatteessa soveltuu myös muille palvelualueille, se on lähtökohtaisesti kehitetty IT-palvelujen tarpeisiin. Koko organisaation kattavana viitekehyksenä ITIL voi olla liian kapea – esimerkiksi liiketoiminnan kehitysprojekteissa tai HR:n ja taloushallinnon palveluissa puhtaasti ITIL-prosessien käyttö ei aina tunnu luontevalta. Tarvitaan soveltamista tai muita malleja rinnalle.

• Uudistumisen jarru? Jos organisaatio nojaa vahvasti vakiintuneisiin ITIL-prosesseihin, voi syntyä asenne, jossa uusia malleja (kuten DevOps tai ketterät käytännöt) jopa vieroksutaan. Tämä on kulttuurinen haaste: ITIL itsessään ei kiellä innovointia, mutta tiukasti prosessiohjautuva kulttuuri saattaa hidastaa ketteryyttä ja uudenlaisten ideoiden käyttöönottoa . On kuitenkin hyvä huomata, että ITIL 4 pyrkii hälventämään tätä vastakkainasettelua tuomalla esiin samankaltaisia arvoja kuin Agile (esim. yhteistyö, jatkuva parantaminen).

Yhteenvetona ITIL tarjoaa vakaan rungon palveluhallinnalle, mutta keskisuuren yrityksen on lähes välttämätöntä keventää ja soveltaa sitä omiin tarpeisiin. Osittainen käyttöönotto tai yhdistäminen ketterämpiin toimintamalleihin on yleistä: esimerkiksi ITIL-prosessien kurinalaisuus ja Agile/DevOpsin ketteryys voidaan yhdistää, jolloin saadaan molempien hyödyt . Tällaisessa hybridimallissa ITIL huolehtii perusinfrastruktuurin vakaudesta ja laadusta, kun taas ketterät menetelmät tuovat nopeutta ja innovaatiota kehitykseen.

USM – Unified Service Management -metodi

USM (Unified Service Management) on uudempi palvelunhallinnan lähestymistapa, joka eroaa ITIL:stä ja muista perinteisistä viitekehyksistä siten, että USM on menetelmä, ei yksittäinen best practice -kehys. USM pohjautuu systeemiajatteluun ja tarjoaa järjestelmällisen viitekehyksen, jolla palveluorganisaatio hallitsee ihmisiä, prosesseja, teknologiaa ja palvelujaan . Oleellista on, että USM yksinkertaistaa palvelunhallintaa määrittelemällä vain viisi ydinprosessia, jotka kattavat palveluorganisaation kaikki olennaiset työnkulut . USM toimii ikään kuin palvelunhallinnan perusta (fundamentti), jonka päälle erilaiset best practice -käytännöt (kuten ITIL-prosessit tai DevOps-toimintatavat) voidaan rakentaa .

USM:n taustalla on hollantilainen SURVUZ-säätiö, ja metodi on lisensoitu avoimesti hyödynnettäväksi. USM ei ole vielä yhtä laajalle levinnyt kuin ITIL, mutta sitä on alettu käyttää eri kokoisissa organisaatioissa (myös Suomessa) selkeyttämään ja keventämään palvelunhallintaa. Esimerkiksi DNA Oyj on hyödyntänyt USM:ää strategisena pohjana IT-palveluidensa parantamisessa vuodesta 2022 alkaen , ja Erillisverkot Oy otti USM:n käyttöön palvelunhallintajärjestelmänsä kehittämiseksi vuonna 2024 . Nämä tapaukset viittaavat siihen, että USM:ää käytetään juuri tilanteissa, joissa halutaan virtaviivaistaa olemassaolevia (tyypillisesti ITIL-pohjaisia) toimintamalleja ja tuoda niihin uutta ajattelua. USM tutustuminen kannattaa aloittaa USM portalista: https://usm-portal.com/?lang=en

USM:n vahvuudet keskisuuressa yrityksessä:

• Yksinkertaisuus ja selkeys: USM määrittelee vain viisi prosessia ja kahdeksan työnkulkua, mikä on huomattavasti yksinkertaisempi malli kuin ITIL:n kymmenet prosessit . Tämä selkeä ja yksinkertainen lähtökohta helpottaa menetelmän nopeaa omaksumista: organisaatio voi hallita palvelutyötään yhtenäisellä tavalla ilman raskasta prosessiviidakkoa.

• Keskittyminen periaatteisiin: USM perustuu liiketoiminnan periaatteisiin ja palvelunhallinnan arkkitehtuuriin, ei yksittäisiin käytäntöihin . Tämä tarkoittaa, että USM luo vahvan perustan, johon erilaiset käytännöt voivat tukeutua – aivan kuin talon perustus, johon voi rakentaa eri kerroksia. Vahva menetelmällinen perusta varmistaa, että organisaation palvelunhallinta pysyy johdonmukaisena, vaikka käytössä olisi eri tiimeillä erilaisia käytäntöjä .

• Yhteensopivuus muiden viitekehysten kanssa: USM on suunniteltu täydentämään muita viitekehyksiä eikä korvaamaan niitä. Se ei sulje pois ITIL:iä, COBITia, DevOpsia tai ISO-standardeja, vaan pikemminkin yhdistää niiden edut konkreettisella ja suoraviivaisella tavalla . Organisaatio voi siis edelleen hyödyntää esimerkiksi ITIL:n parhaita käytäntöjä, mutta USM:n avulla ne jalkautetaan hallitusti ja yhtenäisesti.

• Soveltuu ESM-käyttöön: Koska USM ei ole sidottu pelkästään IT:hen, vaan mihin tahansa palveluorganisaatioon, sitä voidaan käyttää Enterprise Service Management -hengessä koko yrityksen palveluiden hallintaan. USM:ää voidaan soveltaa myös vaikkapa HR- tai talouspalveluiden hallintaan samoin periaattein . Tämä on keskisuurille yrityksille hyödyllistä, jos halutaan laajentaa palveluajattelua IT:n ulkopuolelle ilman useita eri malleja.

USM:n heikkoudet keskisuuressa yrityksessä:

• Rajallinen tunnettuus: USM on suhteellisen uusi toimija palvelunhallinnan kentällä. ITIL:iin verrattuna sen ympärillä oleva ekosysteemi (koulutukset, työkalut, kokemusasiantuntijat) on pienempi. Organisaation täytyy panostaa henkilöstön kouluttamiseen USM:ään, mikä voi aluksi olla haaste, kun valmista osaamista ei löydy yhtä helposti työmarkkinoilta.

• Metodiajattelun omaksuminen: Koska USM on menetelmä- eikä prosessiviitekehys, se vaatii käyttäjiltä hieman erilaista ajattelutapaa. Johtamisessa on ymmärrettävä USM:n konsepti “perustana” ja erotettava se totutuista prosessimalleista. Tämä voi aiheuttaa alussa hämmennystä: osa sidosryhmistä saattaa kysyä, onko USM “kilpailija” ITIL:lle vai jotain muuta. Viestintä siitä, että USM toimii yhdessä olemassa olevien käytäntöjen kanssa eikä niitä vastaan, on tärkeää (USM-tiimi itse korostaa, että kyse on USM with ITIL, ei USM vs. ITIL ).

• Ei yksityiskohtaisia ohjeita kaikesta: USM antaa puitteet ja mallin, mutta se ei tarjoa samanlaista valmista “reseptikokoelmaa” kuin ITIL. Parhaat käytännöt täytyy edelleen ammentaa muista lähteistä tai organisaation omasta kokemuksesta ja istuttaa USM-kehikkoon. Jos organisaatiolla ei ole aiempia viitekehyksiä käytössä, USM kuitenkin sisältää kaikki tarvittavat palaset palveluhallintajärjestelmän luomiseen , mutta yksityiskohtien työstö jää organisaation vastuulle.

• Riippuvuus tuesta: USM:ää tukevia yhteisöjä ja materiaaleja on olemassa (SURVUZ-säätiön sivusto, wiki, ja esimerkiksi Suomessa itSMF on järjestänyt webinaareja aiheesta). Kuitenkin keskisuuri yritys saattaa tarvita ulkopuolista konsultointitukea USM:n käyttöönotossa etenkin, jos halutaan muuttaa olemassa olevia ITIL-prosesseja USM-lähestymistavan mukaisiksi. Tämän tuen saatavuus voi rajoittaa etenemisvauhtia.

Kaiken kaikkiaan USM tarjoaa keskisuurelle yritykselle kiinnostavan vaihtoehdon keventää ja yhdistää palvelunhallinnan käytäntöjä. Se voi toimia organisaation sisäisenä “kielenä”, jonka avulla ITIL, DevOps ja muut käytännöt saadaan puhumaan samaa kieltä. Esimerkiksi hollantilainen EuroSort on soveltanut USM:ää yhtenäisenä mallina useille toiminnoilleen (IT, HR, laatu, jatkuva parantaminen, toimitilat) yhdenmukaistaen näin palveluprosesseja yrityksen sisällä . Tämä osoittaa, että USM-hybridimallilla voidaan yhdistää organisaation eri palvelutoiminnot ilman useita erillisiä viitekehyksiä.

Business Technology Standard – liiketoimintalähtöinen kokonaismalli

Business Technology Standard (BT Standard) – suomeksi usein Bisnesteknologiamalli – on suomalaislähtöinen avoin viitekehys, jonka tavoitteena on yhdistää liiketoiminta ja teknologiajohtaminen. Toisin kuin puhtaasti IT-palvelunhallintaan keskittyvä ITIL, Business Technology Standard on kokonaisvaltainen johtamismalli, joka kattaa strategian, kehittämisen, palvelutuotannon ja hallinnon osa-alueet yhden yhtenäisen raamin alla . BT Standardin on kehittänyt Business Technology Forum yhdessä suomalaisten ja pohjoismaisten yritysten kanssa, ja se on open-source (vapaasti käytettävä) viitekehys. Jos haluat tutustua tarkemmin BT maaliin löydät lisää heidän sivuiltaan: https://www.managebt.org

BT Standardin ydinajatuksena on ratkaista ongelma, joka monissa yrityksissä on havaittu: Miten yhdistää perinteinen IT-operatiivinen toiminta ja uusi digitaalinen kehittäminen? Digitalisaatio vaatii nopeutta ja ketteryyttä, kun taas perinteinen IT-hallinto korostaa vakautta, hallintaa ja jatkuvuutta. Nämä kaksi “maailmaa” törmäävät, jos niitä johdetaan eri lähtökohdista . Business Technology Standard pyrkii luomaan yhteisen toimintamallin näiden välille niin, että organisaatio pystyy sekä hallitsemaan IT-palveluitaan kustannustehokkaasti että innovoimaan digitaalisia tuotteita nopeasti .

BT Standard koostuu mm. seuraavista elementeistä:

• Toimintamalli (Operating Model): Kuvaa yrityksen arvontuoton kannalta keskeiset prosessialueet (strategia & hallinto, hankinta & optimointi, kehittäminen, palvelut) sekä niiden väliset vuorovaikutukset .

• Kyvykkyysmalli (Capability Model): Määrittää tarkemmin kunkin alueen kyvykkyydet ja osaamisvaatimukset.

• Roolit ja vastuut -malli: Selkeyttää organisaation roolit (esim. liiketoimintavastaava, kehityspäällikkö, palvelupäällikkö) ja miten ne liittyvät eri toimintakokonaisuuksiin.

Tärkeää on, että BT Standard ei keksi pyörää uudelleen, vaan se yhdistelee olemassa olevia parhaita käytäntöjä yhtenäiseksi paketiksi. BT Standard yhdistää keskenään mm. ketterän kehityksen viitekehykset (Scaled Agile Framework, DevOps) ja palvelunhallinnan viitekehykset (ITIL, IT4IT) uudella tavalla . Toisin sanoen organisaatio, joka ottaa BT Standardin käyttöön, voi samanaikaisesti hyödyntää ITIL:iä palveluhallinnassa ja vaikkapa SAFe-mallia kehitysprojekteissa – BT Standard tarjoaa näille yhteisen viitekehyksen ja kielen. Tämä on eräänlainen hallittu hybridimalli itsessään.

Business Technology Standardin vahvuudet keskisuuressa yrityksessä:

• Holistinen lähestymistapa: BT Standard katsoo teknologiaa liiketoiminnan näkökulmasta eikä vain IT:n siilona. Se auttaa mieltämään IT:n, digitalisaation ja liiketoimintaprosessit yhtenä kokonaisuutena. Tämä yhtenäinen näkemys voi murtaa siiloja organisaatiossa ja luoda kaikille yhteisen suunnan. BT-standardin hyödyntäminen koko yrityksen informaatio- ja teknologiajohtamisen ohjekirjana takaa yhtenäisen ymmärryksen ja yhteisen kielen koko organisaatiolle .

• Yhdistää ketteryyden ja hallinnan: Malli sisältää sekä ketterien menetelmien että perinteisen ITIL-tyyppisen hallitun palvelunhallinnan parhaat palat. Näin keskisuuri yritys, joka kamppailee “vanhan ja uuden” yhdistämisen kanssa, saa käytännön ohjeita siihen, miten esimerkiksi DevOps-tiimien nopeus ja innovaatio voidaan sovittaa yhteen IT-osaston hallintaprosessien kanssa . BT Standard antaa pragmatistisia käytäntöjä hallita molempia yhtä aikaa.

• Avoimuus ja yhteisö: Koska BT Standard on avointa lähdekoodia (kuka tahansa voi ladata sen ohjekirjan) ja sen kehitystä ohjaa Business Technology Forum -yhteisö, organisaatiot voivat ottaa sen käyttöön ilman lisenssikustannuksia. Lisäksi malli on laajasti käytössä Pohjoismaissa (satoja yrityksiä, kymmeniä tuhansia käyttäjiä ), joten vertaistukea ja kokemuksia on saatavilla. Suurten yritysten lisäksi malli on relevantti myös keskisuurille , eikä sen käyttöönotto edellytä kallista konsultointia pakollisine sertifiointeineen kuten jotkin suljetut mallit.

• Innovoinnin mahdollistaminen: BT Standard kannustaa hyödyntämään digitaalisuuden tuomia mahdollisuuksia ja sisältää elementtejä, jotka auttavat nopeuttamaan uusien tuotteiden ja palveluiden kehitystä ilman että hallittavuus katoaa . Esimerkiksi arvovirta-ajattelu (Value streams) on sisäänrakennettu malliin auttamaan eritahtisten kehitystarpeiden hallintaa. Tämä on tärkeää keskisuurelle yritykselle, jonka on kyettävä uudistumaan pysyäkseen kilpailukykyisenä.

Business Technology Standardin heikkoudet keskisuuressa yrityksessä:

• Laajuus ja kompleksisuus: Vaikka BT Standard pyrkii selkeyteen, se on kuitenkin kattava malli, joka ulottuu strategisesta johtamisesta operatiiviseen toimintaan. Sen täysimääräinen käyttöönotto on merkittävä muutosprojekti. Keskisuurelle organisaatiolle voi olla haaste omaksua koko malli kerralla – vaarana on, että yritetään tehdä liikaa liian nopeasti. Onkin suositeltavaa vaiheistaa BT Standardin käyttöönotto ja keskittyä tärkeimpiin osiin ensin.

• Uuden oppiminen ja muutosvastarinta: Jos organisaation IT-osasto on tottunut ITIL-ajatteluun ja kehityspuoli erikseen omaan ketterään malliinsa, voi yhteinen BT-kieli aluksi aiheuttaa sekaannusta. Se vaatii muutosjohtamista ja koulutusta, että kaikki ymmärtävät mallin hyödyt. Ilman johdon vahvaa tukea BT Standardin käyttöönotto saattaa jäädä puolitiehen, jolloin vanhat toimintamallit jatkuvat rinnakkaisina ja hyödyt jäävät saavuttamatta.

• Riippuvuus best practice -integraatioista: BT Standard itsessään luottaa siihen, että organisaatio omaksuu sopivat käytännöt kuten ITIL, SAFe, DevOps. Se antaa raamit, mutta edellyttää, että organisaatiolla on tai hankkii kompetenssit noissa alakokonaisuuksissa. Esimerkiksi jos ITIL-osaaminen puuttuu, BT Standard ei itsessään kouluta palvelunhallinnan käytäntöihin vaan olettaa niiden tulevan mukaan. Keskisuurelle yritykselle tämä tarkoittaa, että voi joutua samanaikaisesti panostamaan usean osa-alueen kyvykkyyksien kehittämiseen.

• Vielä kehittyvä kansainvälinen tuki: BT Standard on lähtöisin Suomesta ja yleistyy kansainvälisesti, mutta se ei ole (ainakaan vielä) yhtä tunnettu globaalisti kuin vaikkapa ITIL. Jos keskisuuri yritys toimii kansainvälisesti, sen ulkomaisten yksiköiden voi olla vaikeampi saada paikallista koulutusta tai kumppaniverkostoa BT Standardin osalta. Tämä tosin on muuttumassa mallin yleistyessä maailmalla , mutta on huomionarvoinen seikka.

BT Standard soveltuu erityisesti organisaatiolle, joka haluaa tasapainottaa standardoinnin ja innovoinnin. Se on tavallaan hallittu hybridimalli itsessään: se sallii useiden eri viitekehysten rinnakkaisen käytön, mutta varmistaa että ne toimivat yhteen ja tukevat liiketoiminnan tavoitteita . Keskisuuressa yrityksessä BT Standard voi toimia sateenvarjona, jonka alla ITIL-pohjainen palvelutoiminta ja uudet ketterät kehityshankkeet elävät rinnakkain ilman että kumpikaan tukahduttaa toista.

Muut viitekehykset ja lähestymistavat

Edellä mainittujen viitekehysten lisäksi on olemassa muita, jotka voivat tulla kyseeseen, etenkin hybridimallissa täydentävinä palasina:

• DevOps ja ketterät menetelmät: Nämä eivät ole palvelunhallinnan viitekehyksiä sinänsä, vaan ohjelmistokehityksen ja IT-toimituksen kulttuurillisia ja menetelmällisiä periaatteita. DevOps korostaa kehityksen ja operoinnin yhteistyötä, automaatiota ja jatkuvaa toimitusta, ja Agile/Scrum tuovat iteratiivista kehitysmallia. Moni organisaatio on havainnut, että ITIL:n perinteinen muutoshallinta ei aina pysy DevOpsin julkaisutiheyden perässä. Siksi ITIL ja DevOps yhdistetään käytännössä: kriittisimmät muutokset kulkevat yhä ITIL:n hallitun prosessin kautta, mutta kehitystiimit toimivat ketterästi jatkuvan integraation mallilla. Kuten Atlassianin oppaassa todetaan, DevOps ja ITIL eivät ole toisiaan poissulkevia, vaan tuovat kumpikin omat hyötynsä ja voivat täydentää toisiaan . Tämä alleviivaa hybridiajattelun tarvetta nykyaikana.

• COBIT: IT-hallinnon ja -hallintotavan (governance) viitekehys COBIT on joskus yhdistetty ITIL:n kanssa siten, että COBIT antaa puitteet johdon näkökulmasta ja ITIL operatiiviset prosessit. COBIT on keskisuuressa firmassa harvemmin täysin omaksuttu, mutta tietyt kontrollit (esim. tietoturvan, riskienhallinnan alalta) voivat tulla sieltä. Hybridimallissa voidaan sanoa, että ITIL keskittyy palveluiden optimointiin kun taas COBIT tuo varmistusta sääntelyyn ja kontrolliin, ja näitä yhdistämällä voidaan saavuttaa tasapaino .

• VeriSM, SIAM, Lean IT, ISO 20000: Myös muita viitekehyksiä on. VeriSM ja ISO 20000 pyrkivät olemaan meta-malleja, joihin ITIL sopii sisään; SIAM keskittyy monitoimittajaympäristön hallintaan (voisi olla relevantti jos ulkoistuksia paljon, yhdistettävissä ITIL:iin). Lean IT tuo jatkuvan parantamisen filosofiaa. Nämä kaikki voivat täydentää organisaation omaa palvelunhallinnan mallia. Keskisuuri yritys harvoin ottaa näitä kaikkia erikseen käyttöön, mutta hybridimallissa saatetaan poimia ideoita useista: esimerkiksi lean-ajatuksia palveluprosessien tehostamiseen tai SIAM-periaatteita, jos IT-palveluja ostetaan usealta toimittajalta.

Yhteenvetona: viitekehysten kirjo on laaja, eikä yksikään malli yksinään kata täydellisesti kaikkia tarpeita tilanteessa, jossa digitaalinen transformaatio on käynnissä. Seuraavaksi tarkastellaan kahta lähestymistapaa – hybridimalli ja yhdenmukainen malli – ja niiden etuja sekä haasteita keskisuuren organisaation uudistumisessa.

Hybridimalli vs. yhden viitekehyksen malli

Organisaatio voi lähestyä palvelunhallintaa kahdella perustavalla tavalla:

1. Yhden viitekehyksen malli: Kaikki (tai suurin osa) organisaation liiketoiminta-alueista ja tiimeistä noudattaa samaa palvelunhallinnan viitekehystä. Esimerkiksi koko yritys standardoi palveluprosessinsa ITIL:n mukaisiksi, ei vain IT-osasto vaan myös muut tukitoiminnot soveltavat samoja periaatteita.

2. Hybridimalli: Eri liiketoiminta-alueilla hyödynnetään erilaisia viitekehyksiä sen mukaan, mikä parhaiten sopii kunkin alueen luonteeseen. Esimerkiksi IT-osasto jatkaa ITIL-painotteisesti, ohjelmistokehitysyksikkö käyttää ketterää DevOps-mallia, ja vaikkapa yrityksen sisäiset palvelut (HR, talous) ottavat käyttöön USM-menetelmän tai kevyen ITSM-variantin. Hybridimalli voi tarkoittaa myös sitä, että organisaation sisällä yhdistellään viitekehysten elementtejä (ei välttämättä puhtaasti eroteltuna yksiköittäin).

Tärkeää on huomata, etteivät nämä vaihtoehdot ole täysin mustavalkoisia. Usein todellisuus on jossain välimaastossa: saattaa olla yhteinen yläviitekehys (kuten Business Technology Standard), jonka alla käytetään monia käytäntöjä – tai päinvastoin pääosin ITIL-pohjainen toimintamalli, jota täydennetään tietyillä hybridielementeillä (kuten ketterillä käytännöillä). Alla analysoidaan ensin hybridimallin etuja ja haasteita, sitten yhdenmukaisen mallin etuja ja haasteita.

Hybridimallin hyödyt

• Parhaiden käytäntöjen yhdistäminen: Hybridimalli mahdollistaa organisaation poimivan useiden viitekehysten vahvuudet käyttöönsä. Jokaisella viitekehyksellä on omat vahvuutensa – esimerkiksi ITIL tarjoaa prosessidisipliiniä ja laatua, DevOps tuo nopeutta ja jatkuvaa toimitusta, COBIT varmistaa hallinnon ja compliancea. Yhdistämällä elementtejä voidaan vastata samanaikaisesti erilaisiin tarpeisiin, kuten hallintoon, nopeuteen ja palvelun laatuun . Kukin tiimi tai toiminto voi hyödyntää sitä, mikä sille toimii, menettämättä kokonaan muiden mallien tuomia hyötyjä.

• Joustavuus ja ketteryys: Eri liiketoiminta-alueilla on erilainen rytmi ja vaatimukset. Hybridimalli antaa mahdollisuuden räätälöidä toimintatapoja paikallisesti. Esimerkiksi liiketoiminnan digitaalinen innovaatioyksikkö voi toimia hyvinkin ketterästi (vähemmän byrokratiaa, omaa mallia), kun taas operatiivinen tuotannon IT voi nojata vakaampaan prosessiin. Tämä joustavuus voi olla kilpailuetu keskisuurelle yritykselle: pystytään reagoimaan markkinoiden muutoksiin nopeammin niissä toiminnoissa, joissa se on tärkeintä, ilman että koko organisaation täytyy omaksua yhtä muutostahtia.

• Uudistumiskyky ja innovaatio: Hybridimalli tukee uudenlaista ajattelua, koska se ei pakota kaikkia noudattamaan vanhoja kaavoja. Organisaation sisällä voi kokeilla uusia menetelmiä yhdessä yksikössä pelkäämättä, että rikkoo koko yrityksen standardia. On ikään kuin “turvallisia hiekkalaatikoita” innovaatioille. Esimerkkinä, jos yritys haluaa kokeilla USM-menetelmää, se voi pilotoida sitä tietyssä palvelutiimissä pitämättä pakolla koko muuta organisaatiota mukana aluksi. Onnistuneita uusia toimintamalleja voidaan sitten laajentaa. Tämä inkrementaalinen lähestymistapa edistää pysyvien, hyvin toimivien ratkaisujen löytymistä.

• Soveltuvuus erilaisiin tiimikulttuureihin: Yhtenä ainoana mallina toimiminen voi törmätä siihen, ettei malli istu kaikkien tiimien kulttuuriin. Hybridimalli sallii esimerkiksi kehittäjäyhteisön toimia heille luontevalla Agile-mentaliteetilla samalla kun asiakaspalvelun Service Desk noudattaa ITIL-prosessia. Kun työntekijät saavat käyttää heille mielekkäitä tapoja, se voi parantaa sitoutumista ja työn mielekkyyttä.

• Esimerkkejä onnistuneista hybrideistä: Useat organisaatiot ovat raportoineet hyötyvänsä yhdistelmästä. Tyypillinen nykyaikainen malli on ITIL + Agile/DevOps – ITIL luo rakenteen, Agile tuo joustavuutta. Tällöin ITIL:n jäsennelty muotoilu ei tukahduta kehitystä, vaan molemmat lähestymistavat täydentävät toisiaan . Samoin ITIL + COBITyhdistelmää käytetään, kun halutaan tasapainottaa palvelunhallinta ja tiukka hallinnointi . Yksi konkreettinen esimerkki hybridistä on suuren suomalaisen finanssitalon tapaus, jossa konsernin IT palveluhallinta toimi ITIL:n mukaisesti, mutta liiketoimintayksiköiden digitaalisten tuotteiden kehitystiimit noudattivat Lean-Agile-periaatteita; yhteispeli varmistettiin erillisellä “service integration” -toiminnolla, joka yhdisti prosessit. Tuloksena pystyttiin tuomaan uusia digipalveluita markkinoille nopeasti ilman, että asiakkaiden tukea ja tuotantoa laiminlyötiin – molempia lähestymisiä tarvittiin yhtäaikaisesti. (Tämä esimerkki kuvastaa monia vastaavia tilanteita teollisuudessa.)

Hybridimallin haasteet

• Yhteisen suunnan ja kielen puute: Suurin riski hybridimallissa on, että organisaation osat alkavat vetää eri suuntiin. Jos jokainen yksikkö optimoi vain omaa toimintaansa omalla mallillaan, voi syntyä siiloja ja yhteentoimimattomuutta. Esimerkiksi, jos IT ja liiketoiminta käyttävät täysin eri viitekehyksiä vailla yhdistäviä tekijöitä, he voivat tarkoittaa eri asioita “palvelulla” tai mittaavat onnistumista eri metriikoin. Yhdenmukainen ymmärrys voi hämärtyä, ellei ole mitään yhteistä nimittäjää. Tästä syystä monet hybridimalleja käyttävät organisaatiot ottavat jonkin kevyen yhteisen viitekehyksen pohjalle (kuten juuri BT Standardin tai USM:n) varmistamaan yhteisen rakenteen.

• Integraation ja rajapintojen monimutkaisuus: Eri viitekehysten yhteensovittaminen vaatii työtä. Prosessien rajapinnoissa on määriteltävä, miten vaikkapa ketterän kehitystiimin tuotokset luovutetaan ITIL:n mukaiseen käyttöönottoprosessiin, tai miten HR:n palvelupyyntöjärjestelmä kytkeytyy IT:n tukijärjestelmään. Jos jokaisella on eri työkulut, niiden yhteispeli pitää erikseen suunnitella. Tämä lisää hallinnollista monimutkaisuutta, jota varten voi joutua perustamaan erillisiä koordinaatiorooleja (esim. ESM-arkkitehti tai prosessinomistajat, jotka varmistavat yhteensopivuuden).

• Koulutus ja osaaminen: Hybridimalli saattaa edellyttää henkilöstöltä laajempaa osaamista useasta tavasta toimia. Työntekijät voivat joutua omaksumaan useamman “kielen”: esimerkiksi projektipäällikön pitää ymmärtää sekä organisaation käyttämää ketterää kehitysprosessia että ITIL:n muutoksenhallintaprosessia. Oppimiskäyrä voi olla jyrkkä, ja yrityksen on panostettava koulutukseen.

• Johdon ohjattavuus: Ylimmälle johdolle hybridimalli voi näyttäytyä sekavana, jos mittaristo ja raportointi ei ole harmonisoitu. Kun yksi yksikkö raportoi toimintaansa DevOps-metriikoin (deployment frequency, lead time) ja toinen ITIL-metriikoin (esim. SLA-toteumat, incidentien lukumäärä), johtoryhmän voi olla vaikea saada kokonaiskuvaa. Riskinä on myös, että jokin tärkeä asia “putoaa väliin” koska jokainen luulee toisen hoitavan – esimerkiksi jatkuva parantaminen voi jäädä vajaaksi, jos ei ole yhteistä mekanismia jakaa oppeja eri tiimien välillä.

• Ylläpitokustannukset: Useiden erilaisten prosessimallien ylläpito rinnakkain voi pidemmän päälle olla kallista ja tehottomaa, jos synergiaa ei löydy. Eri viitekehykset saattavat vaatia erilliset työkalut tai modifioinnit samaan työkaluun, dokumentaatiota on enemmän, auditointeja mahdollisesti erikseen (jos haetaan sertifiointeja, esim. ISO 20000 yhdelle osalle, ja toinen osa ei kuulu siihen).

• Esimerkkitapauksia haasteista: Jotkut organisaatiot ovat kertoneet hybridimallin johtaneen siihen, että parhaat käytännöt jäävät jakamatta: yksikkö A teki hienon parannuksen prosessiinsa Lean-metodilla, mutta yksikkö B, jolla on eri malli, ei koskaan kuullut asiasta tai kokenut sitä omakseen. Toinen esimerkki: kansainvälisessä keskisuuren yrityksen tytäryhtiössä otettiin käyttöön ketterä palvelunhallintamalli, kun emoyhtiö pysyi ITIL:ssä – tästä seurasi kitkaa palvelutasojen hallinnassa, kun kummallakin oli eri käsitys vastuista. Nämä tilanteet on kuitenkin ratkaistavissa kommunikaatiolla ja mahdollisesti rajaamalla, missä määrin heterogeenisyyttä sallitaan. Juuri ristiin eri viitekehysten käyttö vaatii pelisääntöjä: mitä yhteistä on pakko noudattaa koko organisaatiossa ja missä on vapautta.

Yhden viitekehyksen (yhtenäisen mallin) hyödyt

• Yhtenäisyys ja selkeys: Kun kaikilla organisaation osilla on sama viitekehys, syntyy yhteinen kieli ja toimintakulttuuri. Prosessien termit, roolit ja vaiheet tunnetaan laajasti samalla tavalla. Tämä vähentää väärinymmärryksiä ja helpottaa yhteistyötä yli tiimirajojen. Esimerkiksi jos koko yritys käyttää ITIL-pohjaista palvelunhallintaa, niin asiakaspalvelusta taloushallintoon asti kaikki ymmärtävät, mitä tarkoitetaan vaikkapa muutospyynnöllä tai palvelutasosopimuksella. Yhtenäisen mallin etuna on, että se luo koko organisaatiolle yhden suunnan: kaikki optimoivat samoilla pelisäännöillä kohti samoja tavoitteita.

• Synergia ja skaalaedut: Yksi viitekehys tarkoittaa yleensä myös yhtenäisiä työkaluja ja prosesseja, mikä voi tuoda tehokkuutta. Esimerkiksi yksi keskitetty palvelunhallintajärjestelmä (ITSM-työkalu) voidaan konfiguroida tukemaan sovittua prosessimallia ja palvelemaan kaikkia yksiköitä. Koulutus voidaan keskittää siihen yhteen malliin, jolloin osaaminen syvenee siinä eikä hajaannu. Myös jatkuva parantaminen hyötyy: kun yksi tiimi parantaa prosessia, sama parannus voidaan ottaa koko organisaation laajuisesti käyttöön.

• Hallittavuus ja compliance: Johdon näkökulmasta yksi yhtenäinen malli on helpompi kontrolloida. Riskienhallinta ja vaatimustenmukaisuus (esim. laatu- tai tietoturvastandardit) voidaan varmistaa yhdessä viitekehyksessä systemaattisesti. Esimerkiksi jos yritys haluaa sertifioida toimintansa ISO 20000 -standardin mukaisesti, on suoraviivaisempaa, jos koko organisaation palveluprosessit on rakennettu yhdenmukaisesti (ISO 20000 perustuu pitkälti ITIL:n prosesseihin) . Yhtenäinen malli minimoi tilanteet, jossa jokin osa organisaatiota ei ole mukana kontrollimenettelyissä.

• Nopeampi päätöksenteko prosessimuutoksissa: Kun ei tarvitse neuvotella eri viitekehysten kannattajien kesken, prosessien kehitys ja päätöksenteko voi olla nopeampaa. Jos halutaan tehdä organisaatiotason muutos toimintatapaan, tiedetään mihin viitekehykseen se kohdistuu. Esimerkiksi päätös siirtyä ITIL v3:sta ITIL 4:ään organisaation laajuisesti on iso, mutta yksiselitteinen projekti, verrattuna hybridimallin mahdollisesti lukuisiin rinnakkaisiin muutoksiin.

• Tiedon ja osaajien liikkuvuus: Henkilöstön kannalta yksi malli helpottaa siirtymistä tehtävästä toiseen organisaation sisällä. Jos kaikki tiimit noudattavat samaa periaatteistoa, työntekijä voi vaihtaa yksikköä ilman että koko tapa toimia vaihtuu. Tämä voi joustavoittaa resurssien käyttöä – esimerkiksi ruuhkatilanteessa työntekijöitä voidaan lainata tiimistä toiseen, kun prosessit ovat samanlaiset.

• Esimerkkejä yhtenäisestä mallista: Julkishallinnossa on joitakin esimerkkejä, joissa organisaatio on päättänyt standardoida palvelunhallinnan yhteen malliin: esimerkiksi eräs Pohjoismainen ministeriö rakensi kokonaan uuden IT-organisaationsa USM-menetelmän pohjalta kaikille yksiköilleen, jolloin viiden prosessin malli koski kaikkia (tapaus Utrecht, Alankomaat) . Toisaalta monissa keskisuurissa yrityksissä on käytännössä toteutettu “kaikki ITIL:ään” -strategia ITSM-järjestelmän käyttöönoton yhteydessä: Kaikki sisäiset tukipalvelut (IT, HR, hallinto) on viety yhden palveluportaalin ja ITIL-prosessirungon alle, jolloin työntekijät näkevät yhdenmukaisesti palvelupyynnöt, tiketit ja niiden elinkaaren. Tällaisissa tapauksissa raportoidaan usein asiakastyytyväisyyden parantuneen sisäisissä palveluissa, kun pyynnöt eivät enää huku moniin järjestelmiin ja prosesseihin . Yhteinen malli on tuonut selkeyttä.

Yhden viitekehyksen mallin haasteet

• ”One size fits all” -riski: Kaikki toiminnot eivät välttämättä sovi täydellisesti yhteen malliin. Jos viitekehys valitaan väärin tai sitä sovelletaan jäykästi, se voi jarruttaa joidenkin yksiköiden toimintaa. Esimerkiksi puhtaasti ITIL-pohjainen malli koko organisaatiossa saattaa tehdä tuotekehityksestä liian hidasta, jos samat muutoshallintaprosessit pakotetaan päälle. Ylimmän johdon onkin varmistettava, että valittu malli on tarpeeksi joustava kattamaan erilaiset tarpeet – tai sitten sallittava joustoja mallin sisällä. ITIL 4 toki tarjoaa joustoa enemmän kuin edeltäjänsä, mutta silti väärin sovellettuna mikä tahansa yksi malli voi muodostua korsetiksi.

• Uudistumiskyvyn rajoittaminen: Jos organisaatio naulataan yhteen kehykseen, se voi ehkäistä uusien ideoiden kokeilua. Kun kaikki prosessit on tiukasti määritelty keskitetysti, paikallistasolla voi olla kynnys poiketa kaavasta edes kokeilumielessä. Tämä kulttuurillinen vaikutus voi olla pahin este innovaatioille. Ketterien menetelmien henki on usein “mieluummin anteeksiantoa kuin lupa” – mutta jos yhteinen malli on liian sanktioiva, työntekijät eivät uskalla kokeilla mitään, mikä ei ole mallin mukaista. Organisaatio voi jämähtää paikoilleen.

• Skalaariongelmat: Yhteinen viitekehys kehitetään usein organisaation kokoon suhteutettuna. Jos malli on optimoitu vaikkapa IT-osaston tarpeisiin, sen laajentaminen kaikkiin liiketoimintayksiköihin voi tuoda esiin skaalaushaasteita. Prosessi, joka toimii 50 hengen IT-osastolla, ei välttämättä suju 5 hengen HR-tiimissä tai 200 hengen tuotekehitysyksikössä. On vaarana, että pienemmät yksiköt hukkuvat byrokratiaan tai isommat kokevat mallin naiiviin yksinkertaiseksi.

• Muutosjohtamisen tarve: Jos organisaatio päättää vaihtaa yhdestä viitekehyksestä toiseen yhtenäiseen malliin, muutos on yleensä suuri. Esimerkiksi päätös siirtää kaikki yksiköt ITIL:stä Business Technology Standardiin vaatii laajaa koulutusta, prosessien uudelleenmäärittelyä ja mahdollisesti roolien uudelleenjakoa. Muutosvastarinta voi olla merkittävä, koska henkilöt, jotka pitivät aiemmasta tavasta työskennellä, voivat kokea uuden mallin vieraaksi. Tarvitaan selkeä visio ja viestintä miksi muutos tehdään, muuten yhtenäinen malli jää paperille ja käytännössä kukin jatkaa omiaan (jolloin menetetään sekä yhtenäisyyden että hybridin hyödyt!).

• Teknologian rajoitteet: Jos koko organisaatio laitetaan yhden työkalun ja prosessin varaan, riippuvuus siitä kasvaa. Mikäli valittu työkalu (esim. ITSM-järjestelmä) ei taivu tukemaan jotain erityistarvetta, kyseinen tarve jää helposti toteuttamatta. Hybridimallissa jokin tiimi voisi ottaa käyttöön erikoistyökalun itselleen, mutta yhtenäisessä mallissa sitä ei sallita, jotta standardi ei rikkoudu. Tämä voi johtaa suboptimaalisiin työtapoihin joissain nurkissa organisaatiota.

Hybridimallien käytön esimerkkejä ja kokemuksia

Edellä on jo viitattu useisiin esimerkkitilanteisiin hybridi- ja yhtenäismallien osalta. Summataan vielä muutama selkeä case-esimerkki erityisesti hybridimalleista keskisuurissa organisaatioissa, niiden eduista ja haasteista:

• Case: ITIL + DevOps hybridimalli ohjelmistoyrityksessä. Keskikokoinen ohjelmistoyritys, noin 500 työntekijää, päätti modernisoida palvelunhallintaa. Perinteinen tukiorganisaatio toimi ITIL v3 -prosessien mukaisesti, ja tämä oli toiminut hyvin asiakaspalvelun laadun kannalta. Uudet SaaS-tuotetiimit halusivat kuitenkin omaksua DevOps-käytännöt: jatkuvat julkaisut, infrastruktuuri koodina, nopea palautteen käsittely. Yritys valitsi hybridilähestymistavan: ITIL-prosessit (incident, problem, change) säilytettiin, mutta niitä kevennettiin ja automatisoitiin niin, että ne integroitiin DevOps-työkaluketjuun (CI/CD). DevOps-tiimit saivat toimia vapaasti kehitysvaiheessa, mutta tuotantoon vienti kytkettiin kevyesti muutoksenhallintaan (automatisoidut hyväksynnät tietyin kriteerein). Tämän hybridin tuloksena palvelun laatu pysyi korkeana (häiriöt hallinnassa) ja liiketoiminta hyödynsi nopeampaa julkaisutahtia. Johtoryhmäkin oli tyytyväinen, koska riskit oli hallittu, eikä kokonaiskuva sirpaloitunut. Hybridi onnistui, koska organisaatio tunnisti selkeästi, mitä osia ITIL:stä tarvittiin ja mitä voitiin korvata ketterämmillä menetelmillä – ja toi nämä yhteen yhtenäisessä kehitys-toimitusputkessa. Haasteena tässä matkassa oli yhteensovittaa kulttuurit: IT-tuen henkilöstö piti aluksi DevOps-tiimien toimintaa kurittomana, ja DevOps-tiimit pitivät ITIL-porukkaa byrokraattina. Vasta kun johto fasilitoi yhteisiä työpajoja ja rakensi luottamusta, alkoi molemminpuolinen ymmärrys, että ollaan saman tavoitteen äärellä (hyvä asiakaskokemus). Tämä alleviivaa, että hybridimalli vaatii ihmisten johtamista, ei pelkkää prosessidesignia.

• Case: USM-metodi osana hybridimallia palveluyrityksessä. Eräs noin 300 hengen palveluyritys Suomessa, joka tuottaa sekä IT-palveluja että liiketoimintakonsultointia, koki että sen ITIL-pohjaiset prosessit olivat liian raskaita nopeasti kasvavassa konsultointiyksikössä. He päätyivät ottamaan käyttöön USM-menetelmän koko yrityksen palvelunhallinnan “selkärangaksi”, mutta eivät hylänneet ITIL:ää kokonaan. USM:n viisi prosessia määriteltiin ja dokumentoitiin, ja jokainen tiimi koulutettiin ymmärtämään tämä malli. Tämän jälkeen IT-tiimi jatkoi tuttujen ITIL-käytäntöjen soveltamista (esim. käyttötuki ja ongelmanhallinta) mutta kevyemmin USM:n viitearkkitehtuurissa, kun taas konsultointiyksikön tukipalvelut muotoiltiin lähes puhtaalta pöydältä USM:n avulla. Tämä on esimerkki hybridistä, jossa USM toimi yhdistävänä tekijänä, mutta eri osastot painottivat eri käytäntöjä. Projektin raportoitiin tuottaneen nopeita parannuksia: prosessien määrä väheni, päällekkäisyydet saatiin pois ja kaikki ymmärsivät paremmin toistensa roolit palvelun tuottamisessa . Haasteena mainittiin, että USM oli uusi asia monelle, ja alussa esiintyi epäilystä onko tämä vain “uusi muotihullutus”. Kuitenkin nähtyään konkreettiset tulokset – kuten SLA-viidakon selkiytyminen ja palvelupyyntöjen käsittelyajan lyheneminen – skeptikotkin vakuuttuivat. Tämä tapaus osoittaa, että hybridimalli voi tarkoittaa myös uuden menetelmän tuomista vanhan rinnalle ja asteittaista siirtymistä kohti kevyempää yhteistä mallia.

• Case: Yhdenmukaistettu ESM keskisuuressa konsernissa. Eräs kansainväliseen konserniin kuuluva keskisuuri tytäryhtiö (n. 800 hlöä) päätti ottaa käyttöön Business Technology Standardin ohjatakseen yrityksen kaikkea IT- ja digitoimintaa. Käytännössä he standardoivat projektinhallinnan ja kehityksen SAFe-malliin ja palveluhallinnan ITIL 4 -malliin, mutta siten että BT Standardin governance-malli toi kaiken yhteen. Tämä oli askel pois puhtaasti ITIL-vetoisesta ajattelusta, jossa aiemmin IT-osasto oli toiminut. Tuloksena koko yrityksellä (ml. liiketoimintajohto) oli näkyvyys teknologiahankkeisiin ja palveluihin BT-johtamisfoorumeissa, ja dialogi parani (aikaisemmin ITIL-termejä ei ymmärretty liiketoiminnassa). Tämä yhtenäistämisprojekti vähensi päällekkäisiä prosesseja ja lopetti erilliset “varjoprosessit” joita joillakin liiketoimintayksiköillä oli ollut. Haasteena oli BT Standardin laajuus: alkuvaiheessa työntekijät kokivat infon määrän raskaaksi. Onnistus tekijä oli, että johto priorisoi kriittiset osat ensin (palveluportfoliohallinta ja kehityksen hallintamalli), ja muu kyvykkyyskehikko tuotiin mukaan myöhemmin. Vaikka tämä esimerkki on lähempänä yhtenäistä mallia, se on hybridinen siinä mielessä, että se salli erilaisten menetelmien rinnakkaiselon BT-kehyksen sisällä – ja juuri tämä on BT Standardin idea.

Näistä esimerkeistä voidaan päätellä, että hybridimallin onnistunut hyödyntäminen edellyttää tietoista suunnittelua: on päätettävä mitä yhdistetään ja miten, sekä varmistettava jokin yhteinen nimittäjä (olkoon se sitten organisaation oma “toimintamalli”, USM:n kaltainen menetelmä tai BT Standard). Ilman yhteistä viitekehystä hybridiorganisaatio voi ajautua hajanaisuuteen. Parhaimmillaan hybridi tuo joustavuutta ja uusia ratkaisuja talon sisälle, pahimmillaan se luo sekavuutta – kaikki riippuu toteutuksesta ja johtamisesta.

Johtopäätökset ja suositukset

Analyysin perusteella keskisuuren yrityksen ei välttämättä tarvitse valita täysin ääripäiden – puhdas yhdenmukaisuus vs. täysi hybridi – välillä, vaan löytyy yhdistelmä, joka tukee parhaiten organisaation uudistumista ja pysyvien parannusten aikaansaamista. Keskeiset huomiot ja suositukset ovat:

• Yksi viitekehys ei yksinään yleensä riitä kattamaan kaikkia tarpeita. ITIL yksinään voi olla liian jäykkä nopeasti kehittyville liiketoiminta-alueille, kun taas pelkkä ketteryys ilman prosessikuria voi heikentää palvelun laatua. Asiantuntijoiden mukaan mikään yksittäinen käytäntö ei ole universaalisti paras, ja hybridilähestymistavat tuottavat usein parhaat lopputulokset . Tämä pätee erityisesti keskisuuriin yrityksiin, joiden on yhtä aikaa huolehdittava tehokkaasta perustoiminnasta ja kilpailtava innovaatioilla isompia ja pienempiä toimijoita vastaan.

• Hybridimalli on suositeltava, mutta hallitusti. Hybridimallin tuomat hyödyt – joustavuus, parhaiden puolien yhdistäminen, innovaatioiden mahdollistaminen – ovat merkittäviä, kun organisaatio tavoittelee uudenlaista ajattelua eikä halua jäädä vanhoihin kaavoihin kiinni. Kuitenkin hybridi on suunniteltava niin, että erilaiset lähestymistavat täydentävät toisiaan eivätkä ole ristiriidassa keskenään . Käytännössä suositus on luoda yhteinen viitearkkitehtuuripalvelunhallinnalle (esim. prosessipuut tai palvelumalli), jonka puitteissa eri viitekehysten käytännöt voivat elää. USM-menetelmä tai Business Technology Standard ovat esimerkkejä tällaisista “meta-malleista”, jotka voivat toimia liimana. Organisaation kannattaa harkita jonkin kevyen yhteisen palvelumallin määrittämistä – vaikkapa sopia viisi ydinkomponenttia palveluiden hallintaan – ja sallia variaatiota sen alla.

• Varmista johdon tuki ja yhteinen kieli. Olipa valinta mikä tahansa, ylimmän johdon tulee olla aktiivisesti tukemassa ja viestimässä, että uusi toimintatapa (hybridinä tai yhtenäisenä) on strategisesti tärkeä. Johdon tulee myös varmistaa, että koko organisaatio ymmärtää tavoitteet: palvelunhallinnan viitekehys ei ole itseisarvo, vaan keino parantaa liiketoimintaa, asiakastyytyväisyyttä ja tehokkuutta. Yhteinen kieli – esimerkiksi BT Standardin omaksuminen terminologiana – voi merkittävästi parantaa eri yksiköiden yhteistyötä .

• Kulttuurin ja osaamisen kehitys etusijalle. Uudenlaista ajattelua ei synny pelkästään viitekehystä vaihtamalla. On panostettava kulttuuriin: kannustettava kokeiluihin, poistettava pelko epäonnistumisesta, rohkaistava jakamaan oppeja yli tiimirajojen. Koulutus on tärkeää: ITIL-osaajille voi pitää kursseja DevOpsin periaatteista ja vice versa, jotta syntyy keskinäistä ymmärrystä. Kun ihmiset osaavat useampaa “kieltä”, hybridimallikin toimii kitkattomammin. Esimerkiksi itSMF:n kaltaiset foorumit ja yrityksen sisäiset yhteiset työpajat auttavat luomaan tätä osaamista ja kulttuuria.

• Säilytä asiakasarvo keskiössä. Viitekehysten tarkoitus on palvella liiketoimintaa ja asiakkaita. Päätöstä hybridistä tai yhtenäisestä mallista arvioitaessa on hyvä kysyä: kuinka tämä parantaa palveluidemme arvoa asiakkaalle? USM-kurssin motto “tuo asiakkaan arvo palvelun keskiöön” on hyvä muistutus . Jos nykyinen ITIL-pohjainen malli tuntuu estävän nopeiden asiakasarvoa tuottavien ratkaisujen syntyä, on vahva peruste lisätä ketteryyttä (hybridillä). Toisaalta, jos täysin kirjavia käytäntöjä käyttäen asiakas kokee palvelun epätasalaatuiseksi, on peruste yhtenäistää.

• Käytännön aloittaminen: pilotti ja laajennus. Suositeltava tapa edetä on kokeilla hybridimallia rajatusti: valitse yksi liiketoiminta-alue tai prosessi, jossa sovellet useampaa viitekehystä rinnakkain tai uutta viitekehystä, ja arvioi tulokset. Esimerkiksi käynnistä kokeilu, jossa ITIL-raameja kevennetään USM:llä tietyssä tiimissä, tai ota BT Standardin palvelumalli koekäyttöön yhden tuotelinjan ohjauksessa. Mittaa vaikutukset (nopeutuiko toimitus, parantuiko palvelun laatu, mitä mieltä tiimit ovat). Onnistuneen pilotin jälkeen laajenna käytäntöjä muualle. Tämä vähentää riskiä ja antaa konkreettista evidenssiä päätöksenteon tueksi.

• Yhtenäisen mallin tapauksessa: valitse moderni ja joustava kehys. Jos organisaatio kuitenkin päätyy siihen, että yksi yhteinen malli on oikea tie (esimerkiksi organisaation koon ja kulttuurin vuoksi), on tärkeää valita viitekehys, joka ei sulje pois uudistumista. Käytännössä tämä tarkoittaa nykyaikaista lähestymistä: ITIL 4 yhtenäisenä mallina on huomattavasti dynaamisempi kuin vanhat versiot ja voi sisältää ketteryyden elementtejä. Tai valitaan suoraan Business Technology Standard, joka jo itsessään kannustaa monipuolisuuteen. Yhtenäinen malli ei saa tarkoittaa paluuta siiloihin ja jäykkyyteen, vaan senkin on elettävä ajassa.

Lopuksi: On muistettava, ettei kysymys ole siitä, onko ITIL “hyvä” ja USM “huono” tai päinvastoin – vaan siitä, miten ne palvelevat organisaation tarpeita. Kuten eräässä blogissa todettiin, ei tarvitse valita mustavalkoisesti ITIL:n ja DevOpsin välillä; oikea ratkaisu voi olla sopiva sekoitus . Tärkeintä on, että palvelunhallinnan malli tukee organisaation strategiaa ja mahdollistaa jatkuvan parantamisen. Keskisuuren yrityksen kannattaa rohkeasti hyödyntää hybridiajattelua, kuitenkaan unohtamatta sitä punaista lankaa, joka pitää kokonaisuuden koossa. Hyvin johdettuna hybridimalli voi tuoda sekä prosessien kurinalaisuuden että innovoinnin vapauden – juuri sen yhdistelmän, mitä organisaation uudistaminen ja tulevaisuuden kilpailukyky edellyttävät .

Lähteet: Tämä kirjoitus on koottu ajantasaisesta kirjallisuudesta ja asiantuntijalähteistä, mukaan lukien viittaukset ITIL-viitekehyksen dokumentaatioihin ja tutkimuksiin, USM-menetelmän kuvausta tarjoaviin materiaaleihin sekä Business Technology Standardin julkaisuihin. Esitetyt esimerkit pohjautuvat julkaistuihin tapauskuvauksiin ja kirjallisuudessa esiin tuotuihin käytäntöihin.

• ITIL
• AXELOS (2019). ITIL Foundation: ITIL 4 Edition. AXELOS Limited.
• AXELOS (2020). ITIL 4 Managing Professional: Create, Deliver and Support. AXELOS Limited.
• AXELOS (2020). ITIL 4 Managing Professional: Direct, Plan and Improve. AXELOS Limited.
• ITSMF UK & AXELOS (2020). ITIL 4 Practice Guides. AXELOS Limited.

USM (Unified Service Management)

• SURVUZ Foundation (2022). USM – Unified Service Management: Systematic Service Management. SURVUZ Foundation. Saatavilla osoitteesta: https://usm-portal.com
• SURVUZ Foundation (2023). The USM Method Explained. SURVUZ Foundation Wiki. https://wiki.usm-portal.com
• SURVUZ Foundation (2023). Case studies USM. https://usm-portal.com/cases/
• SURVUZ Foundation (2023). Whitepapers ja materiaalit USM:n käyttöönotosta. https://usm-portal.com/downloads/

Business Technology Standard

• Business Technology Forum (2020). Business Technology Standard – Open-Source Management Framework.Business Technology Forum. Saatavilla osoitteesta: https://www.managebt.org
• Business Technology Forum (2022). Business Technology Standard – Operating Model (version 4.5).https://www.managebt.org/bt-standard/download/
• Business Technology Forum (2022). Case examples of Business Technology Standard.https://www.managebt.org/cases/

Hybridimallit ja muut lähteet

• Atlassian (2022). ITIL vs DevOps: Can they coexist? Atlassian whitepaper. https://www.atlassian.com/itsm/devops
• ISACA (2018). COBIT 2019 Framework: Governance and Management Objectives. ISACA.
• ISO/IEC 20000-1:2018 – Information Technology – Service Management – Part 1: Service Management System Requirements. International Organization for Standardization (ISO).
• VeriSM Foundation (2020). VeriSM – Unwrapped and Applied. IFDC.