Viime blogissani käsittelin kommunikointiin ja sen puuttumiseen liittyviä kohtia oheiselta Gartnerin sudenkuoppalistalta:
1. Vääränlaisen pääarkkitehdin palkkaaminen
2. Riittämätön sidosryhmien ymmärrys ja tuki
3. Unohdetaan (liike)toiminnan ihmiset
4. Tehdään arkkitehtuuria vain teknologia-alustoittain
5. Tehdään täydellinen nykytilan kokonaisarkkitehtuuri ensin
6. Arkkitehtiryhmä tekee kaiken työn
7. Arkkitehtuurin vaikutusta ei seurata eikä mitata
8. Tehdään siiloarkkitehtuuria
9. Ei luoda kokonaisarkkitehtuurin hallintaa ajoissa
10. Ei käytetä tarpeeksi aikaa kommunikointiin
Tässä kirjoituksessa keskityn erilaisiin vinoutuneisiin lähestymistapoihin.
Liian usein kokonaisarkkitehtuuri lähtee puhtaasti tietohallinnon teknisistä tarpeista – ja jääkin sitten siihen. Toki sovellusarkkitehtuurien kehittäminen tarvitsee ohjausta, muutenhan meillä on käsissämme kestämätön palapeli, jonka palaset eivät edes sovi toisiinsa. Mutta kokonaisarkkitehtuurin lähestymistapa on kokonaisvaltaisempi – ei vain tietty teknologia, vaan kaikki organisaatiossa sallitut. Ja entäpä kun eri teknologioiden päälle rakennettujen järjestelmien pitäisi keskustella keskenään? Silloin tarvitaan integraatioalustoja.
Tee strategiatason päätös, mitä teknologia-alustoja tuetaan. Usein päätökset tehdään tietohallintostrategiaa luotaessa. Pyri harmonisoimaan teknologia-alustoja ts. ettei olisi hurjaa litaniaa erilaisia alustoja, jotka kaikki vaativat tukea.
Kirjaa päätös arkkitehtuuripäätöksiin ja –linjauksiin. Kirjaa myös perustelut ja soveltamisohjeet. Tiedota päätöksistä kaikille arkkitehdeille ja projektipäälliköille. Ja ennen kaikkea valvo, että niitä noudatetaan!
Tokihan aina välillä tulee tilanteita, jolloin sovitut arkkitehtuurilinjaukset eivät sovikaan. Näitä tilanteita varten on syytä luoda muutoskäytäntö, jonka kautta kaikki halutut poikkeamat käsitellään. Ei siis jälkeenpäin, vaan etukäteen kuvataan, miksi poikkeava tapa tai teknologia tarvitaan ja mihin se vaikuttaa. Nämä poikkeamat linjauksista kirjataan myös osaksi kokonaisarkkitehtuuria – ovathan ne tietoisesti ja harkitusti tehtyjä. Ja voihan olla, että tällaisesta poikkeamasta tuleekin osa valtavirtaa – näin voi käydä varsinkin uuden teknologian kohdalla. Ei tarvitse mennä kuin reilu 10 vuotta taaksepäin, kun kännykät eivät olleet suinkaan jokaisen työntekijän käytettävissä. Ja nykyisin on vaikea kuvitella toimivansa ilman kännyä. Monista yrityksistä ovat lankapuhelimet jopa kadonneet tyystin.
Muista, että teknologia-arkkitehtuuri on vain yksi neljästä kokonaisarkkitehtuurin näkökulmasta. Se tarjoaa alustan liiketoimintaa tukeville järjestelmille. Eli aina on lähdettävä liikkeelle liiketoiminnasta tavoitetilaa suunniteltaessa, muuten voidaan tehdä jopa täysin vääriä teknologiaratkaisuja. Teknologia voi antaa myös ideoita uudelle liiketoiminnalle. Esimerkiksi mobiiliteknologian kehittyminen on avannut aivan uusia tapoja kontaktoida asiakkaita – kukapa ei olisi saanut tekstarimuistutusta lääkäriajasta tai viestiä tilatun tuotteen saapumisesta. Teknologia voi siis luoda uusia tapoja toimia ja aivan uutta liiketoimintaakin.
Niin TOGAF® kuin JHS 179:kin lähtee nykytilan kuvaamisesta. Mutta jos lähdemme kuvaamaan kaikkea täydellisesti, emme pääse ikinä tavoitetilaan! Lisäksi jos on kyse useamman organisaation yhteisen nykytilan kuvaamisesta, niin tässä vasta suohon juututaankin. Vajaa kymmenkunta vuotta sitten minulla oli prosessien mallintamisen kurssilla porukkaa yliopistoista. Silloin puuhattiin yliopistouudistusta, johon liittyi mm. tiettyjen prosessien yhtenäistäminen. Voitte kuvitella, millaista tuon työryhmän työskentely olisi ollut, jos olisin sanonut, että heidän pitää ensin kuvata nykytilan prosessit. Eihän työssä olisi päästy ollenkaan eteenpäin, niin paljon prosessit erosivat toisistaan eri yliopistoissa. Annoinkin neuvon lähteä pohtimaan yhdessä tavoitetilan prosesseja – siinä yhteydessä tulisi kyllä varmasti käytyä läpi nykytilaakin tarvittavassa määrin.
Kuvaa aluksi nykytilaa hyvin karkealla tasolla sen verran, että saat kokonaiskuvan. Selvitä ennen kaikkea toiminnan sidosryhmät ja asiakkaat sekä heidän tarpeensa – heitä vartenhan me olemme olemassa. Selvitä, mitä palveluja organisaatio tuottaa ja mitä se tarvitsee. Tunnista prosessit – älä siis lähde tässä vaiheessa vielä kuvaamaan niitä. Huomaatte, että keskityn toiminta-arkkitehtuuriin. Aloita sanaston (= terminologian) kerääminen, jotta puhuisimme samaa kieltä. Tunnista toiminnan kannalta keskeiset tietoryhmät ja missä niitä tarvitaan. Kerää tietojärjestelmät ja merkkaa, mitkä niistä vaatisivat isompaa kunnostusta tai alkaisivat olla elinkaarensa päässä. Tämä on siis organisaation ”omaisuuden” inventointia karkealla tasolla. Muista myös, ettei sinun tarvitse kuvata kaikkea uudestaan esim. JHS179:n kuvauspohjille. Jos kuvauksia löytyy, ne kelpaavat sellaisenaan – olettaen, että ne ovat riittävästi ajan tasalla. Kokoa ne kuitenkin yhteen paikkaan, jotta ne löytyvät jatkossakin.
Sen jälkeen tulisi valita, mistä lähdetään liikkeelle tavoitetilan suhteen. Kokonaisarkkitehtuuri on strategialähtöistä eli strategialinjauksista löydämme tavoitetilan painotuksia. Näitä täytyy vaan jalostaa eteenpäin konkreettisiksi organisaation kehittämiskohteiksi. Kun valitsemme ensimmäiselle kierrokselle sopivaa osajoukkoa, meitä tietysti kiinnostavat eniten ongelmapaikat, joiden ratkaisemisella on suurin vaikutus toiminnan sujuvuuteen. Kaikkea kun ei voi tehdä kerralla, eikä meillä ole varaa kaikkeen.
Esimiehet ja johtajat haluavat nähdä tuloksia. Jos vain kuvaamme ja kuvaamme, emme pääse ikinä toteutukseen, mistä hyödyt vasta tulevat. Jaa tavoitetila välietappeihin, jotka ovat sen verran pieniä, että kullekin tilikaudelle/budjetointikaudelle tulee jotain konkreettista, joka saadaan valmiiksi, ei siis vain suunniteltua.
Kun on valittu sopiva osa-alue tavoitetilan suunnittelua varten, voi olla tarpeen analysoida tarkemmin nykytilaa. Tässä kohtaa kuvataan joitakin osuuksia nykytilasta seikkaperäisemmin. Yleensä ainakin prosessien kuvaaminen konkretisoi asiaa. Nimittäin jos vain puhumme asioista, jokaisella keskusteluun osallistuvalla on oma ”kuvitelmansa” todellisuudesta. Vasta mallintaminen tuo meidät samalle kartalle.
Usein tietohallinto kaipaa seikkaperäisempää omaisuuden inventointia, kuten esim. mitä teknologioita on eri järjestelmissä käytetty, missä elinkaarensa vaiheessa järjestelmät ovat, mitä palvelimia ja laitteistoja löytyy, mikä on verkkojen tilanne. Tämä kaikki kerätään tulevien investointien selvittämistä varten. Rahanarvoinen tarkastelun paikka on erilaiset lisenssit ja niiden todellinen tarve. Ja jälleen on järkevintä pitää kuvaukset siellä, missä niitä oikeasti tarvitaan ja hyödynnetään.
Puhuin äsken tavoitetilan kehittämisestä palasissa. Myös esim. JHS 179 puhuu kehittämiskohteiden valitsemisesta. Molemmissa on sama idea – kaikkea kun ei voi tehdä kerralla. Tällöin on muistettava koko ajan pitää huolta kokonaisuudesta, muuten meillä on joukko osa-arkkitehtuureja, jotka pahimmillaan eivät toimi yhteen.
Toinen siiloarkkitehtuuriin johtava tilanne syntyy helposti, kun organisaation toiminnassa on selkeitä osakokonaisuuksia – liiketoiminta-alueita. On kovin houkuttelevaa lähteä rakentamaan kokonaisarkkitehtuuria liiketoiminta-alue kerrallaan. Vaan tuskinpa nämä liiketoiminta-alueet ovat täysin erillisiä, sillä taatusti esim. taloushallinto ja viestintä sivuavat kaikkia.
Eräänlaista siiloarkkitehtuuria tulee silloinkin, jos kokonaisarkkitehtuuria rakennetaan näkökulma kerrallaan. Tehdään ensin vaikka tietojärjestelmäarkkitehtuuri ja edetään sitten vaikka teknologiaan ja tietoarkkitehtuuriin. Pahimmassa tapauksessa unohdetaan toiminta-arkkitehtuuri kokonaan. Saamme joukon kuvauksia ja asioita, jotka välttämättä eivät sovi yhteen lainkaan. Itse asiassa tuohan kuulostaa juuri siltä nykytilalta, jossa iso osa yrityksiä ja organisaatioita on tänä päivänä…
Nykytilaa kartoitettaessa usein prosessikartat sisältävät vain joukon prosesseja, mikä on sinänsä ok. Mutta tämän lisäksi on syytä kuvata joko ns. päästä-päähän prosesseja tai ns. toimintamalleja, jotka molemmat sisältävät prosessien (tai aliprosessien) lisäksi niitä yhdistävät tieto- ja materiaalivirrat. Nimittäin nämä ovat prosessien välisiä rajapintoja ja kertovat prosessien integroitavuudesta. Yleensä ongelmat ovat juuri näissä saumakohdissa. Tämä on aivan vastaava asia kuin järjestelmien väliset liittymät, joissa on lähes aina ongelmia.
Jos lähdet rakentamaan tavoitetilaa palasissa tai osa-alueittain, pidä huoli siitä, että saumakohdat tulee tarkistettua ja otettua huomioon. Nimeä kullekin liiketoiminta-alueiden rajapinnalle vastuuhenkilö, jonka tehtävänä on tarkastella asiaa kummankin liiketoiminta-alueen kannalta. Sama juttu toimii muuten ratkaisuarkkitehtuurin puolella järjestelmiä tai järjestelmäkokonaisuuksia suunniteltaessa – testattu on! Jos vastuuhenkilöä ei ole nimetty, nämä raja-alueet tuppaavat olemaan ei-kenenkään-maata eli kukaan ei ota vastuuta niistä.
Kokonaisarkkitehtuuri syntyy näkökulmista JA niiden välisistä yhteyksistä. Tämän vuoksi kuvauspohjissa on näihin yhteyksiin liittyviä kuvauksia. Prosessit – tiedot: missä prosessissa tieto syntyy, missä sitä käytetään ja missä se kenties tuhotaan. Prosessit – tietojärjestelmät: missä prosesseissa käytetään mitäkin tietojärjestelmiä ja missä kaikkialla tätä tietojärjestelmää hyödynnetään. Ja niin edelleen. Näiden yhteyksien hyödyntämisestä saadaankin osa kokonaisarkkitehtuurin hyödyistä. Kun toimintaprosessi muuttuu, mihin kaikkiin järjestelmiin se vaikuttaa? Jos järjestelmä lakkaa toimimasta, mitkä liiketoiminnan osat kärsivät tai lakkaavat toimimasta?
Summa summarum, kokonaisarkkitehtuuri on kokonaisvaltaista kehittämistä, jossa kaikkien eri osa-alueiden ja näkökulmien pitää olla tasapainossa.
Lisätietoa näistä asioista saat Coalan kursseilta www.coala.fi/palvelut.