Heti aluksi haluan sanoa, että edustan palvelunhallintaa ja olen uuden vahvan ITILin ja palvelutuotannon puolestapuhuja. ITIL on ollut loistava keksintö kaoottiseen tilanteeseen, joka on ollut enemmän sääntö kuin poikkeus IT-organisaatiossa. Edelleenkin ITIListä löytyy perustekemiset siihen mitä IT:tä hyödyntävän lopputuloksen aikaansaaminen vaatii. ITILin asiat ovat täällä pysyäkseen.
Moni ketteryyden nimiin vannova saattoi voida pahoin äskeisestä tunnustuksesta. Huoli pois! Vaikka ITILin asiat ovat tulleet jäädäkseen, niiden muoto muuttuu ja pitää muuttua maailman muuttuessa. Ratkaisut muuttuvat, mutta myös kysymykset muuttuvat. Kun tilanne on kaaos, ratkaisu on järjestys. Se lienee tilanne, johon ITILin ideat sellaisena kuin on tähän asti kuvattu vastaavat hyvin. Kun järjestys on saavutettu, kysymykset muuttuvat. Oikea kysymys voi olla enemmän ketteryyttä tai tarkempia käytäntöjä ITILinkin kuvaamissa alueissa. Sen takia uudet viitekehykset ja parhaat käytännöt ovat tervetulleita, hyödyllisiä ja ehdottomasti tutustumisen arvoisia, mutta eivät poista ITILin tarvetta sinänsä.
Esimerkiksi voisin ottaa vaikka DevOpsin. Siinä ideana on kehittää ja viedä tuotantoon muutoksia nopeasti ja ketterästi laaja-alaista osaamista omaavalla tiimillä. DevOpsin syntyyn on varmasti vaikuttanut teknologian kehittyminen, Agile Manifeston kaltainen antiteesi prosessien tuomalle byrokratialle (erityisesti kehityksen ja tuotantoonsiirron kesken), uudempien kehittäjäsukupolvien hierarkiaa karsastava maailmankatsomus ja ohjelmistokehityksen ominaispiirteet verrattuna muunlaiseen IT:n kehittämiseen ja tuotantoonsiirtoon. DevOpsin ideat ovat hyviä ja suosittelen lämpimästi niihin tutustumista esim. DevOps Fundamentals –kurssilla. Moni organisaatio hakee DevOpsin näkökulmasta tulevaa konsultaatiota avuksi organisaatioon palvelunhallinnan ketteryyden lisäämiseen. Mielestäni hyvä, mutta rajoittunut näkökulma.
DevOpsin ja monen muun ketterän viitekehyksen heikkous on siinä, että ne jättävät huomioimatta asiat, jotka eivät ole muuttuneet. Näitä ovat suuren organisaatioon palveluiden ja ihmisten määrään liittyvä kompleksisuus, jonka hallitsemiseen tarvitaan yhtenäisiä sovittua rakennetta ja toimintatapoja. Siinä missä ketterä tiimi omine työtapoineen end-to-end toimii hyvin yksittäisen palvelun kehittämiseen ja tuotantoon siirron kontekstissa, 800 erilaista organisoitumistapaa ja erilaista (esim. muutoksenhallinnan) prosessia toimii huonosti kokonaisuutena.
Pelkkä ketteryys ei siis ratkaise palvelunhallinnan ongelmia, mutta myönnän, että ketterät periaatteet sovitussa organisaatiokohtaisessa kontekstissa ovat parempia kuin pelkkä stabiili kontrolli. Rakennetta voi ja pitää kehittää ketterästi ja rakenteen pitää jättää tilaa toimia ketterästi rakenteen sovituissa rajoissa. Asiassa ei ole ristiriitaa: eri ketterät viitekehykset ovat yhteneväisiä siinä, että onnistunut ketterä toimintatapa vaatii systematiikkaa. Ja juuri systematiikka yhdistää ketterät ja vähemmän ketterät näkökulmat.
Tilanteet ovat erilaisia ja erilaisiin tilanteisiin pätevät paremmin eri näkökulmat. Nykyiset ketterät menetelmät lähtevät usein (ohjelmisto)kehittäjien näkökulmasta. Tapahtuu kuitenkin paljon asioita ennen kuin idea päättyy kehittäjille ja vielä enemmän asioita sen jälkeen kun kehittäjät ovat tehneet osuutensa. Vaikka strategia, suunnittelu ja kehitys –osuudet on jotenkin huomioitu palvelukohtaisesti ketterien menetelmien viitekehyksissä (SAFe, SCRUM, DevOps), niin noissa tuotanto toimittamisineen ja tukemisineen jää vähälle huomiolle. Tarvitsemme siis useampia näkökulmia hallitaksemme kokonaisuutta.
Olisiko ensi vuosi sellainen, että näkisit asiat uudesta näkökulmasta? Tervetuloa Oppia.fi –kursseille!
Kirjoittaja on työskennellyt prosessien ja toiminnan kehittämisen ja arvioinnin alueella yli 10 vuotta. Päätoimisesti IT-palveluiden prosessien määrittelyn, kehittämisen ja johtamisen alueella hän on toiminut vuodesta 2005. Hän on konsultoinut ja valmentanut useita suomalaisia ja kansainvälisiä yrityksiä ja organisaatioita ITIL/ITSM prosessien määrittelyihin, käyttöönottoon ja kehittämiseen liittyen. Lari on myös Suomen ensimmäinen sertifioitu ITIL Practitioner -kouluttaja.
1 Pingback