Haluaisitko laatia käytännöllisen IT-roadmapin?
Hyvä. Tulit oikeaan paikkaan.
Kerron tässä kirjoituksessa vastaukset seuraaviin kolmeen kysymykseen:
Mihin roadmapia tarvitaan?
Millainen on hyvä roadmap?
Miten roadmap kannattaa rakentaa?
Tämä kirjoitus on jatkoa kirjoitukselle, jossa käsittelin sitä, miten CIO, tietohallintojohtaja tai -päällikkö voi helpottaa elämäänsä ja samalla nostaa arvoaan organisaatiossa.
Käsittelin edellisessä artikkelissa sitä, kuinka määrämuotoiset keskustelut liiketoiminnan edustajien kanssa luovat pohjan IT-kehittämiselle ja yhdessä muun organisaation kanssa rakennetulle IT-roadmapille.
Löydät kirjoituksen täältä.
Jos haluaisit saada vastauksen näihin kysymyksiin, sinun kannattaa lukea tämä kirjoitus. Pyrin antamaan tässä kirjoituksessa käytännöllisiä vinkkejä roadmapin laatimiseksi.
On selvää, että roadmapin laatiminen voi olla työlästä. Sen vuoksi se jää helposti laatimatta.
Jotta olisit valmis raivaamaan kalenterista tilaa roadmap-projektille, pohditaan hetki sitä, mihin roadmapia oikein tarvitaan.
Sen jälkeen kerron, millainen roadmap voisi olla.
Mihin roadmapia tarvitaan?
Roadmap on käytännössä suunnitelma tavoitteeseen pääsemiseksi. Vaikka monesti suunnitelma on vain tekijöiden päässä ilman, että sitä on kirjoitettu auki, tässä kirjoituksessa roadmap tarkoittaa kirjallista suunnitelmaa.
Kun yritämme saada omassa elämässämme jotain aikaiseksi, kirjoitamme usein ylös tehtäviä, jotka pitää hoitaa. Vaikka kaikki eivät harrastakaan tehtävälistoja, moni kokee ne hyödylliseksi. Roadmap on eräänlainen toisiinsa liittyvien tehtävien muodostama lista.
Roadmap vai tehtävälista?
Roadmap on kuitenkin enemmän kuin vain tehtävälista. Roadmap laittaa tehtävät myös järjestykseen ja esittää tehtävien välisiä riippuvuuksia.
Sillä, missä järjestyksessä asioita tehdään, on väliä. Jos päätät lähteä rakentamaan taloa, et varmaan aloita rakentamista väliseinistä tai valitsemalla kylpyhuoneen laattoja. Vaikka suunnitteluvaiheessa varmasti mietit näitäkin asioita, ymmärrät tietysti, että talolle pitää rakentaa aluksi luja perustus.
Jostain syystä tällainen looginen ajattelu saattaa unohtua, kun aletaan puhua IT-ympäristöstä. Jos IT-ympäristö on jo olemassa, on helppo ajatella, että voidaan keskittyä "laattojen valitsemiseen" tai muihin näkyviin yksityiskohtiin. Kuitenkin perustukset voivat silti kaivata parantelua, jopa korjaamista. Tämä johtuu siitä, että toisin kuin asuintalossa, IT-ympäristössä ympäristön käyttötarkoitus voi sen elinkaaren aikana muuttua moneen kertaan.
Joka tapauksessa, mitä monimutkaisemmasta asiasta on kyse, sitä tärkeämpää on, että teemme kirjallisen suunnitelman sen toteuttamiseksi. Vaikka kyseessä olisi henkilökohtainen projekti, suunnitelman auki kirjoittaminen auttaa meitä itseämme hahmottamaan paremmin, mitä kaikkea sen toteuttamiseen liittyy.
Ilman kirjallista suunnitelmaa suunnitelmasta ei käytännössä pysty keskustelemaan. Koska IT-ympäristö on monimutkainen kokonaisuus, ja sen kehittämiseen osallistuu yleensä eri ihmisiä ja jopa eri organisaatioita, on hyödyllistä laatia suunnitelma ympäristön kehittämiseksi.
Hyvä, ehkä olet nyt samaa mieltä, että tarvitsette roadmapin.
Jatka lukemista, sillä seuraavaksi kerron, millainen on hyvä roadmap.
Millainen on hyvä roadmap?
Hyvä roadmap tukee oikeita tavoitteita. Tämä on tärkeää, koska muuten suunnitelma voi viedä kehitystä väärään suuntaan.
Tämän vuoksi kirjoitin edellisessä kirjoituksessa siitä, miksi on niin tärkeää laatia roadmap yhdessä muun organisaation kanssa. Muun organisaation tavoitteet antavat hyvää perspektiiviä sille, mitä organisaatiossa kaivataan.
Älä lähde teknisistä lähtökohdista
Yksi väärä tapa kehittää IT-ympäristöä on sen kehittäminen teknisistä lähtökohdista. Kun tulee uusia tuotteita tai uusia teknologioita, otetaan niitä käyttöön miettimättä, miksi niistä on hyötyä.
Teknisillä asiantuntijoilla on usein halu olla tekemisissä uusimpien tekniikoiden kanssa. Tämä voi olla tuhoisaa hyvän roadmapin kannalta.
Jos et ota muun organisaation tavoitteita huomioon, on vaarana, että keskityt liikaa teknisiin yksityiskohtiin tai asioihin, joita sinun pöydälläsi pyörii.
Organisaatiosta tulevat pyynnöt voivat ohjata väärään suuntaan
Monessa organisaatiossa IT-ympäristöä kehitetään sen mukaan, millaisia pyyntöjä muu organisaatio esittää. Tämä voi tuntua järkevältä. Oikeasti se on tapa, joka johtaa ongelmiin.
Pyynnöt nimittäin tulevat siinä vaiheessa, kun aikaa toteutukselle on hyvin vähän. Tämä johtaa ongelmiin, koska moni tilaajasta pieneltä tuntuva muutos tai parannus IT-ympäristössä voi oikeasti vaatia suuriakin muutoksia taustalla oleviin rakenteisiin.
Tässä lähestymisessä ongelmana on se, että pyyntöihin vastaamiseen ei ole riittävästi aikaa.
Ennakoi kehitystä
Hyvä roadmap ennakoi kehitystä ja tulevia tarpeita. Vaikka suunnitelmat ja tarpeet muuttuvat, roadmapin tekeminen ei mene hukkaan. Suuntaa vain aina tarpeen mukaan säädetään.
Hyvä roadmap siis tukee organisaation tavoitteita ja ennakoi tarpeita. Tämän vuoksi hyvässä roadmapissa nuo tavoitteet on kirjoitettu auki.
Riippuen omista tavoitteista roadmapin suhteen, tämä voi olla hyvin lyhyt yhteenveto tai sitten tarkempi selostus liiketoiminnan tavoitteista.
Käytännöllinen roadmap on myös riittävän konkreettinen.
Seuraavaksi kerron, miten voit rakentaa hyvän roadmapin.
1. Rajaa roadmapin sisältö
Ensimmäinen askel roadmapin laatimisessa on sen sisällön tai aihealueen rajaaminen. Miksi on tärkeää aloittaa aihealueen rajaamisesta? Eikö nimenomaan olisi parempi koota kaikki kehitysasiat samaan dokumenttiin?
Usko pois: kaiken kokoaminen yhteen dokumenttiin ei ole hyvä asia, ainakaan aluksi. Jos yrität kasata kaiken yhteen dokumenttiin, homma jää helposti kesken, koska kaiken mahdollisen huomioiminen on yksinkertaisesti liian vaikeaa. On parempi lähteä purkamaan yhtä aihealuetta kerrallaan.
Jos koet tarpeelliseksi, voit myöhemmin koota useamman eri aihealueen suunnitelmat yhteen. Niiden laatiminen kannattaa kuitenkin aloittaa erikseen.
Itse olen tyypillisesti mukana IT-infraan liittyvien roadmapien laatimisessa. Se luonnollisesti rajaa tekemistä. Tosin usein on hyvä tehdä vieläkin tiukempi rajaus. Hyvä rajaus on esimerkiksi rakentaa roadmap konesalin kehittämiseksi. Useinhan tässä kohtaa puhutaan pilviroadmapista.
Pysähdy siis hetkeksi.
Mieti hetki, mitä IT:n osa-aluetta haluat kehittää.
Hyvä. Oletetaan, että olet nyt tehnyt rajauksen.
Rajaus on nyt tehty. Se muuten kannattaa kirjoittaa dokumentin ensimmäiseen lukuun. Muuten homma alkaa leviämään, kun mieleen tulee asioita, jotka vain liittyvät varsinaiseen aiheeseen.
Lue eteenpäin, niin kerron, miten pääset liikkeelle varsinaisessa työssä.
2. Selvitä organisaation tavoitteet
Nyt on aika selvittää organisaation tavoitteet.
Miten ajattelit hoitaa sen?
Aivan.
Ehkä kannattaisi kysyä asiasta organisaatiolta. Sinulla on kaksi tai kolme vaihtoehtoa tähän.
Ensimmäinen vaihtoehto on haastatella esimerkiksi liiketoiminnasta vastaavia johtajia ja valittuja avainhenkilöitä.
Toinen vaihtoehto on järjestää työpaja, johon kutsut ne, joiden mielipiteen haluat kuulla.
Kolmas tapa on järjestää kysely, jossa kysyt kirjallisia vastauksia.
Kaikissa näissä tavoissa on puolensa. Olen käsitellyt kahta ensimmäistä hieman tarkemmin IT-strategia-oppaassa, jonka voit tilata tästä.
Oletetaan nyt, että olet kerännyt tietoa organisaation tavoitteista.
Dokumentoi tavoitteet
Nyt tavoitteet pitäisi dokumentoida. Voisin melkein lyödä vetoa, että tavoitteita ei ole kunnolla dokumentoitu ennen tätä tekemääsi kierrosta. Strategia varmasti löytyy kirjallisena, mutta yksiköt ovat harvoin tehneet kirjallisia suunnitelmia siitä, miten strategia ja operatiiviset asiat kohtaavat käytännössä. Juuri tämä tulkinta on nyt tärkeä.
Koosta siis tärkeimmät tavoitteet ja se, miten olet ne ymmärtänyt kalvoille tai Word-dokumentiksi.
Ei yhtään haittaa, jos tämän jälkeen lähetät osuuden tutustuttavaksi niille, jotka osallistuivat tavoitteiden kertomiseen. Usein tämä vaihe saa aikaan mielenkiintoista keskustelua. Siitä voi olla vaikka hyötyä organisaatiolle.
Nyt tavoitteet ovat selvillä. On aika siirtyä seuraavaan osaan, joka on IT-ympäristön nykytilan selvittäminen.
3. Selvitä IT-ympäristön nykytila
Seuraavaksi kerron, miten IT-ympäristön nykytila selvitetään, ja miksi tällainen vaihe tarvitaan.
Koska todennäköisesti ole tekemässä suunnitelmaa omaa ympäristöänne koskien, tunnet varmasti oman IT-ympäristönne.
Tässä kohtaa sinun tarvitsee vain vilkaista hienoja dokumentteja, joita olette ympäristöstä väkästäneet. Tai ehkä tilanne on se, että nyt niitä kuvauksia pitää alkaa kasaamaan.
Arkkitehtuurikuvien piirtäminen on vaikeaa
Huomaan aika usein, että varsinaisia arkkitehtuurikuvia ei ole piirretty, vaikka juuri niiden avulla olisi helppo käydä ympäristöä läpi eri osapuolien kanssa. Syykin tähän on minusta aika selvä.
Hyvän arkkitehtuurikuvan piirtäminen on vaikeaa. On yllättävän vaikeaa päättää, mitä yksityiskohtia sisällyttää kuvaan ja mitä jättää pois.
Hyvän arkkitehtuurikuvan piirtäminen on vaikeaa. On yllättävän vaikeaa päättää, mitä yksityiskohtia sisällyttää kuvaan ja mitä jättää pois.
Asiantuntijoista tuntuu usein pahalta karsia kuvista yksityiskohtia. Vaikka yksityiskohdat ovat tärkeitä toteutuksen kannalta, tässä kohtaa niistä on usein haittaa. Nyt siis pitäisi rakentaa yleisluontoinen kuvaus, jossa kuitenkin on tavoitteen kannalta oikeat yksityiskohdat mukana.
Nykytilan lisäksi on hyvä tehdä osuus, johon kootaan ongelmia, joita nykytilanteeseen liittyy. Näiden ei tarvitse välttämättä liittyä siihen, että tavoitteiden mukaiset asiat eivät onnistu.
Älä unohda käytännön ongelmia
Tässä kohtaa kannattaisi kerätä erilaisia käytännön ongelmia, joita IT-organisaatio on huomannut. Ne voivat olla teknisiä puutteita, joitain toiveita, joita IT-osastolla on jne.
Tämän listan tarkoitus on pitää huoli siitä, että vaikka nyt pyritään tekemään liiketoiminnan tavoitteisiin perustuvaa roadmapia, käytäntöä ei tietenkään haluta unohtaa.
Käytännön asioita voivat olla elinkaareen liittyvät asiat. Esimerkiksi levyjärjestelmän elinkaari on tulossa täyteen vuoden päästä, ja siihen pitäisi pystyä miettimään samalla ratkaisua.
Oletetaan, että nykytilan kuvaukset ja ongelmalistat on nyt tehty, ja on aika siirtyä seuraavaan vaiheeseen.
4. Kuvaa IT-ympäristön tavoitetila
Tämä vaihe on ehkä kaikkein hauskin koko projektissa. Nyt katsotaan tavoitteita ja tulkitaan niistä, mihin IT-ympäristön pitäisi pystyä.
Usein varsinaisen yksiselitteisen kuvan piirtäminen voi olla tässä kohtaa vaikeaa, koska erilaisia vaihtoehtoja voi olla paljon ja kaikkien huomioiminen kuvissa voi olla epäkäytännöllistä.
Kokeile sanallista kuvausta
Tavoitteiden kuvausta voi olla helpompi lähestyä sanallisella kuvauksella. Kokonaisarkkitehtuurityössä nyt laadittaisiin arkkitehtuuriperiaatteita, jotka ovat yleislinjauksia periaatteista, joita tavoiteympäristön pitäisi noudattaa.
Nämä tavoitteet, joita IT-ympäristön pitäisi toteuttaa ovat hyödyllisiä, koska tehtyjä suunnitelmaluonnoksia voidaan myöhemmin peilata näihin periaatteisiin. Näin voidaan nähdä, ollaanko tavoitteita saavuttamassa, vai onko jotain aivan olennaista ehkä unohtunut.
Seuraavaksi on aika siirtyä miettimään erilaisia toteutusvaihtoehtoja.
Oletko kiinnostunut kokonaisarkkitehtuurista? Lue tekemäni kattava artikkeli: Kokonaisarkkitehtuuri - kaikki mitä sinun pitää aiheesta tietää.
5. Kartoita arkkitehtuurivaihtoehtoja
Nyt kerron, miten arkkitehtuurivaihtoehtoja voi kartoittaa.
Erilaisia vaihtoehtoisia toteutustapoja voi olla paljonkin. Kuitenkin vain osa niistä on yleensä sellaisia, että niitä kannattaa miettiä tarkemmin.
Tämän vuoksi kannattaa päättää, mitä vaihtoehtoja tutkii tarkemmin, ja mitkä ovat selkeästi sellaisia, että ne voi hylätä.
Nyt pitäisi ymmärtää, mitä erilaiset arkkitehtuurivaihtoehdot oikeasti tarkoittavat.
Palastele arkkitehtuuri
Nyt kannattaa ottaa käsittelyyn infran osa-alue kerrallaan ja kuvata aiottu toteutusvaihtoehto lyhyesti. Tämän jälkeen on hyvä kirjoittaa auki, mitä hyvää ratkaisussa on ja mitä huonoa siinä on. Voi olla tarpeen erotella tekniset ja kaupalliset seikat toisistaan.
Tämä vaihe on keskeinen oikeiden valintojen tekemiseksi, koska nyt pitäisi ymmärtää, mitä erilaiset arkkitehtuurivaihtoehdot oikeasti tarkoittavat.
Esimerkiksi, jos mietitään erilaisia tapoja yhdistää toimipisteitä konesaliin, MPLS-verkon ja Internetin yli toteutetun VPN-ratkaisun osalta kannattaa miettiä, miten erilaiset vastuunrajaukset menevät käytännössä, ja miten tuki järjestetään missäkin ratkaisussa.
Kun tähän soppaan jossain vaiheessa yhdistetään toimittajien antamia hintoja, on helpompi tehdä päätöksiä parhaasta ratkaisusta.
Lopulta tutkimuksessa pitäisi päätyä johonkin konkreettiseen lopputulokseen. Teknisessä mielessä lopputulos voi olla eri kuin esimerkiksi tukipalveluita ajatellessa tai kustannuksia tuijotettaessa.
Palaa organisaation tavoitteisiin
Juuri nyt organisaation antamat tavoitteet nousevat arvoonsa. Ratkaisuvaihtoehtoja voi nyt arvioida näitä organisaation antamia tavoitteita vasten. Tämä antaa paljon paremman tuloksen kuin yksittäisiä teknisiä ominaisuuksia vertailemalla on mahdollista saada.
Usein tässä kohtaa käy niin, että huomataan jonkun teknisesti edistyneen ratkaisun olevan turha, koska se ei tue riittävän hyvin kokonaisuutta.
Nyt oletamme, että haluttu arkkitehtuuri on kohtuullisessa määrin selvillä. On aika laatia varsinainen roadmap.
6. Tunnista tarvittavat projektit ja laita ne järjestykseen
Kun pohjatyöt on tehty kunnolla, varsinaisen roadmapin laatiminen on helppoa. Tässä luvussa kerron, miten laadit roadmapin.
Koska nyt tiedetään, mistä lähdetään ja mihin ollaan matkalla, ei tarvittavien askeleiden tunnistaminen ole kovinkaan vaikeaa.
Tunnista kokonaisuudet
Nyt pitää pystyä tunnistamaan, millaisissa kokonaisuuksissa asioita kannattaa tehdä. Yksi tehtävä voi esimerkiksi olla tarjouspyyntöjen pyytäminen 3D-virtualisointiratkaisusta.
Toinen tehtävä voisi olla IP-osoitesuunnitelman päivittäminen. Kolmas voisi olla verkon reitityspisteen muuttaminen.
Kun projektit on tunnistettu, voi olla tarpeen arvioida niiden vaatimia työmääriä ja/tai kustannuksia. Tätä ei kuitenkaan suinkaan aina tehdä tässä vaiheessa.
Projektien tunnistamisen jälkeen pitäisi tunnistaa projektien riippuvuussuhteet: Mitä pitää tehdä ensin, jotta seuraava vaihe olisi mahdollinen.
Käytännön esimerkki:
Pihasuunnitelmasta roadmapiin
Sain asioiden oikeassa järjestyksessä tekemisestä itse kouriintuntuvan opetuksen, kun joskus kauan sitten teetimme pihasuunnitelman ostamamme omakotitalon pihaan. Näimme suunnitelmassa kaiken sen, mitä olimme toivoneet: perennoja, pensaita, puita, muurin ja laatoituksia.
Kun aloin toden teolla miettimään tehtävien töiden järjestystä, aloin tajuamaan, että hommahan piti aloittaa talon sadevesijärjestelmän parantelusta ja pihan salaojittamisesta. Se ei tuntunut yhtään hauskalta, koska olimme ajatelleet pääsevämme suoraan käsiksi hauskempiin työvaiheisiin.
Siinä ei kuitenkaan auttanut muu, kuin tarttua ikävältä tuntuviin perustustöihin, vaikka ne veivätkin rahat ja voimat pitkäksi aikaa. Se kuitenkin kannatti. Pihan perustukset tulivat kuntoon ja myöhempiä vaiheita oli paljon helpompi toteuttaa.
Sama logiikka pätee IT-infrankin suhteen. Usein ympäristön muuttaminen aidosti liiketoimintaa vastaavaksi voi vaatia perustavaa laatua olevia muutoksia, jotka eivät näy päälle päin.
Oma konesali voi osoittautua aivan liian heppoiseksi liiketoiminnan kriittisyyteen nähden. Usein muuten jatkuvuuteen liittyvät vaatimukset vaativat isojakin remontteja, jos katastrofaalisilta katkoilta halutaan suojautua.
Muutos voi koskea esimerkiksi verkon uusimista tai konttoreiden linjanopeuksien päivittämistä vastaamaan videoneuvottelujen vaatimuksia.
Aikatauluta projektit
Kun projektit ovat paikallaan, pitäisi niille keksiä aikataulut. Useinhan kyse on todella keksimisestä, koska tässä kohtaa roadmap on vain osakokonaisuus kaikesta työstä mitä ollaan tekemässä.
En kuitenkaan pidä tätä ongelmana, koska suunnitelmat elävät ja tarkentuvat, kun niistä keskustellaan, ja yksityiskohdat tarkentuvat. Tärkeintä on saada karkeakin suunnitelma ulos ja keskustelun alaiseksi.
7. Viimeistele roadmap
Kun teen konsulttina roadmap-projekteja, teen yleensä johdon yhteenvedon, johon kokoan kaikkein keskeisimmät havainnot ja suositukset.
Tämä on todella tervehdyttävä vaihe, koska se pakottaa miettimään, mitkä asiat ovat ehdottoman tärkeitä, ja mitkä ovat sellaisia, että ne olisi hyvä toteuttaa, mutta ei maailma niiden puuttumiseen lopu.
Tämä vaihe saattaa vielä muuttaa koko aikataulua tai projektien järjestystä, koska asioiden kriittinen tarkastelu saattaa paljastaa olennaisia puutteita suunnitelmassa.
Tarkista tavoitteet
Lopuksi on hyvä vielä tarkistaa tavoitteet ja niistä johdetut arkkitehtuuriperiaatteet. Syntynyttä tuotosta kannattaa vielä arvioida näitä tavoitteita ja periaatteita vasten. Täyttyvätkö tavoitteet vai tuliko suunnitelmasta aivan erilainen, mitä liiketoiminta odottaa?
Pahimmillaan suunnitelmaa pitää vielä muuttaa, jotta liiketoiminta todella ohjaisi ympäristön kehittämistä. Parhaimmillaan voit alkaa varailemaan palavereja, joissa esittelet syntynyttä suunnitelmaa.
Tässä kirjoituksessa kerroin, miten laadit käytännöllisen IT-roadmapin.
Käytännössä noudatimme arkkitehtuurityössä hyväksi havaittuja periaatteita. Asioita olisi voinut tehdä vielä paljon perusteellisemminkin ja ottaa mukaan enemmän yksityiskohtia. Uskon kuitenkin, että me kaikki olemme aika kiireisiä, eikä ylimääräisille vaiheille välttämättä ole aina tarvetta.
Käytä seuraavalla kerralla erilaista lähestymistä
Jos haluat saada aikaiseksi paremman suunnitelman, ota seuraavalla kerralla mukaan muita lähtötietoja, esimerkiksi sovellusympäristön arkkitehtuuria tai tietovirtoja, ja saat taas eri näkökulmasta rakennetun, entisestä tarkentuvan roadmapin.
Jos pidit blogista ja olet kiinnostunut lukemaan tuleviakin kirjoituksiani, tilaa blogini, niin saat ilmoituksen uusista kirjoituksista sähköpostiisi.