CxO:n blogi

Sumuinen arkkitehtuuri?

Torstai 15.6.2017 - Tuottavuusaktivisti Reino Myllymäki

Sumuinen_Suomenlinna_720x405.jpg

Viime perjantain Kaivopuiston lentonäytöksen aamua varjosti sankka sumu. Jotkut olivat pelästyneitäkin. Vakuutin, että sumu lähtee pois keskipäivään mennessä. Otin muutamia valokuvia Suomenlinnaan päin.

Jälkikäteen kuvia katsoessani ja seuraavaa webinaaria miettiessäni tuli mieleeni, että ovatko organisaatiokulttuurin kuuluvat perusolettamukset ja uskomukset ikään kuin sumu, joka estää meitä näkemästä kokonaisarkkitehtuuria. Vähän kuin sumu tuossa kuvassa estää meitä näkemästä Suomenlinnaa ja sen rakennuksia tarkasti.

Kun sumu vaivaa, ei näe tarkasti. Ei voi tähdätä tarkasti, on lähdettävä siitä, että ei tiedä kaikkea varmasti. On jätettävä pelivaraa tai hyödynnettävä sumeaa ajattelua.

Jalkimaailma_720_px_levea.jpg

Suomenlinnaan päästyäni kävin Kuninkaanportissa. Sinnehän August Ehrensvärd kiinnitytti tauluja, jossa on historiaan jääneitä tekstejä kultakirjaimin. Yhdessä taulussa on teksti (ruotsiksi): "Erämaista on nämä Susisaaret muutettu Viaporiksi". Sen alla on kuuluisa ns. Jälkimaailma-lause: "Jälkimaailma, seiso täällä omalla pohjallasi äläkä luota vieraaseen apuun".

En tiedä, mistä Ehrensvärd ajatuksen nappasi, mutta lause on viisaus. Koko Suomenlinna taulun ympärillä uhkuu tänäkin päivänä riippumattomuutta muusta maailmasta - kuinkahan paljon se teki sitä 1700-luvun ruotsalaiselle, joita mekin silloin olimme? Viisaus tuli tutuksi myös 1930-luvun lopussa, jolloin jäimme suurinpiirtein yksin taistelemaan suurvaltaa vastaan.

Hakkauttamalla lauseen kivitauluun Ehrensvärd teki ajatuksestaan näkyvän. Ilman sitä aistisimme sitä vain Kuninkaanportin miljööstä tai Suomenlinnan sijainnista, jyhkeistä muureista, muurien ampuma-aukoista tai valtavista tykeistä. Ehrensvärd teki Suomenlinnan rakentamisen taustoista näkyviä ja tunnistettavia, hän teki uskomuksesta kirjatun arvon.

Organisaatiokulttuurisumua voi siis hälventää kirjaamalla perusolettamuksia ylös. Ylös kirjoitettuna meidän on helpompi keskustella niistä ja päättää, mitkä arvot kuuluvat meidän tulevaisuuteemme ja mitkä ovat vanhentuneita ja siksi hylättävä.

Kuuntele Reino Myllymäen maksuton webinaaritallenne aiheesta tästä.

Kommentoi kirjoitusta. Avainsanat: johtaminen, kehittäminen, kokonaisarkkitehtuuri, organisaatiokulttuuri

Organisaatiokulttuuri - vahvuus vai riesa?

Tiistai 13.6.2017 - Tuottavuusaktivisti Reino Myllymäki

Hammennys_720x405.jpg

Organisaatiokulttuurista puhuttaessa tulee usein mieleen synkkä, vaikeasti hahmotettava ja ymmärrettävä tai jopa uhkaava asia, joka varsinkin muutostilanteessa koetaan haittatekijänä. Näin ei tarvitse olla. Itse asiassa organisaatiokulttuuri on voimavara, joka auttaa selviytymisessä.

Nuorelta yritykseltä organisaatiokulttuuri puuttuu. Esimerkiksi Talvivaaran kohdalla organisaatiokulttuurin kehittymättömyys on ollut heikentävä tekijä, toteavat Markku Kuisma ja Pekka Seppänen kirjassaan Suomen pahimmat bisnesmokat.

Organisaatiokulttuuri koostuu kolmen luokan asioista: artefakteista ("meillä on aina ollut tehdas kosken partaalla!"), arvoista ("jokainen työntekijä on tärkeä") ja perusolettamuksista ("myynti lisää liikevaihtoa"). Artefaktit ovat organisaatiokulttuurin hahmotettavia kulmakiviä, esimerkiksi patentit tai "kauhugalleriaan" kootut johtajien muotokuvat ovat artefakteja. Arvot ovat organisaation kirjattuja uskomuksia, ohjenuoria, joita on hyvä noudattaa, kun ohjesäännöt puuttuvat. Perusolettamukset ovat uskomuksia, joita ei juuri koskaan ole kirjoitettu ylös ja virallisesti tunnustettu. Silti niitä noudatetaan ja ne saattavat olla organisaation voimavara tai riesa.

Kun kokonaisarkkitehtuuria vähän pureksii, törmää usein sen siistimpään synonyymiin "periaatteet ja valinnat". Valinnat ovat kohtuu kovia asioita: näitä teknologioita käytetään, keskitetty, ei hajautusta jne. Periaatteet ovat jo hyhmäisempiä ohjenuoria ja siten lähellä arvoja, perusolettamuksia ja uskomuksia.

Näistä kulmista katsottuna organisaatiokulttuuri ja kokonaisarkkitehtuuri ovatkin itse asiassa aika lähellä toisiaan... Vaan kuinka ottaa organisaatiokulttuuri huomioon kokonaisarkkitehtuurissa? Kuuntele Reino Myllymäen maksuton webinaaritallenne aiheesta tästä.

En lupaa valmiita vastauksia, koska tämä kohta maailmankaikkeudesta on vielä jäsentymätön. Mitä lupaan? Ajatuksia siitä, miksi organisaatiokulttuurin ottaminen huomioon muutosjohtamisessa on tärkeää ja siitä, miten organisaatiokulttuuria voi tutkia ja sisällyttää kokonaisarkkitehtuuriin. Tervetuloa!

Kommentoi kirjoitusta. Avainsanat: kehittäminen, muutosjohtaminen, uskomukset, kokonaisarkkitehtuuri, digitalisaatio

Kaatuuko kehityshanke kulttuurikysymyksiin?

Torstai 8.6.2017 - Tuottavuusaktivisti Reino Myllymäki

Organisaatiokulttuuri_720x405.jpg

Kehittämisen sekä erityisesti uusien tietojärjestelmien ja toimintatapojen käyttöönoton yhteydessä nousee muutosvastarinta merkittäväksi onnistumista häiritseväksi tekijäksi. Näin on helppo todeta, mutta onko se totta?

Muutosvastarinta on oikeasti suurelta osin oppimisahdistusta ja vähemmässä määrin perusteetonta tai omaa etua ajavaa jarruttamista. Oli kysymys kummasta tahansa, nille on lääkkeet muutosjohtamisessa. Käännänkin siksi asian toisinpäin: jos muutosvastarinta vaivaa, syy on puutteellisessa tai olemattomassa muutosjohtamisessa, ei vastustajissa.

Niinpä minkä tahansa muutoksen - uuden tietojärjestelmän tai toimintatavan käyttöönoton - yhteydessä on otettava huomioon myös muita kuin kovia asioita. Kun kokonaisarkkitehtuuri on käyttökelpoisin organisaation toiminnan mallintamismenetelmä, olen alkanut etsiä keinoja organisaatiokulttuurin - artefaktien, arvojen ja perusolettamusten - ottamiseksi huomioon kokonaisarkkitehtuurissa.

Kävin läpi Miksi tietojärjestelmäprojekti epäonnistuu -kirjaa varten keräämäni ja myöhemmin täydentämäni aineiston ja löysin viisi tarinaa, joissa jokin organisaatiokulttuuriin liittyvä asia oli yksi epäonnistumisen syy. Viisi vajaasta sadasta ei ole paljon, mutta epäilen, että kulttuurilliset asioiden merkitys on todellisuudessa suurempi. Nämä asiat eivät vain nouse esiin, kun epäonnistumisia puidaan julkisuudessa.

Lupaan käydä nämä viisi tarinaa läpi ilmaisessa CxO Webinaarissa, jossa aiheena on Organisaatiokulttuuri ja kokonaisarkkitehtuuri. Niiden lisäksi käyn läpi organisaatiokulttuurin sisällyttämistä kokonaisarkkitehtuuriin ja kerron ideoita organisaatiokulttuurin tutkimiseen. Näitä asioita olen käsitellyt myös tuoreessa Muutosjohtamisen opas -kirjassani. Kuuntele Reino Myllymäen maksuton webinaaritallenne aiheesta tästä.

Kommentoi kirjoitusta. Avainsanat: kehittäminen, muutosjohtaminen, uskomukset, kokonaisarkkitehtuuri, digitalisaatio

Kelle kuuluu kokonaisarkkitehtuuri?

Torstai 27.4.2017 - Tuottavuusaktivisti Reino Myllymäki

Kokonaisarkkitehtuuri_vastuu_2012-2017.png

Maalis-huhtikuussa 2012 tein useampiosaisen kyselyn, jonka avulla kartoitin hankesalkun hallintaa, projektitoimiston toimintaa ja kokonaisarkkitehtuurityötä osana suomalaisten organisaatioiden kehittämistoimintaa. Nyt oli aika kaivaa tutkimustulokset esiin uudelleen.

7.4.2017 nimittäin kokonaisarkkitehtuuria johtamisessa käsitelleen webinaarin yhteydessä tein kyselyn kokonaisarkkitehtuurin vastuuttamisesta. Vastausmäärä molemmissa tutkimuksissa on toki pieni, erityisesti webinaarin yhteydessä, mutta tuloksia kannattaa silti hetki pohtia.

Vuoden 2012 tutkimuksessa suurin kokonaisarkkitehtuurityön vastuunkantaja oli tietohallinto (65 %). Sen vahvin kilpailija oli hajautettu vastuu (24 %), loput jakautuivat lähinnä teollisuuden ja rahoitus- ja vakuutustoiminnan kehitysyksiköille ja erillisille kokonaisarkkitehtuuriyksiköille. Tuoreessa kyselyssä vastuu oli useimmiten hajautettu (45 %), asiasta ei vastannut kukaan (36 %) tai sitten siitä vastasi tietohallinto (18 %). Ensi näkemältä vastaukset ovat tyystin erilaiset, tarkemmin katsottuna ei niinkään.

Tietohallinto kokonaisarkkitehtuurin vastuunkantajana on se perinteisin ja kokonaisarkkitehtuuri mielletäänkin usein IT-asiaksi. Tietohallinto kuitenkin usein kantaa vastuuta vain arkkitehtuurin alimmista tasoista eli teknologia-, järjestelmä- ja tietoarkkitehtuureista. Niinpä yhtä oikea vastaus voisi olla hajautettu vastuu. Ainakin siinä tapauksessa, että ylimpien tasojen asiat ovat ylipäätänsä jollekin vastuutettu.

Tulkitsenkin niin, että kun vastaus on hajautettu vastuu, tietohallinto vastaa arkkitehtuurin alimmista tasoista ja joku muu, toimitusjohtaja tai joku hänen lähimmistä johdettavistaan, ylimmistä tasoista. Ratkaisu on luonteva niille organisaatioille, jotka eivät aio kulkea digitalisaation eturintamassa tai joissa tietohallinnon rahkeet eivät syystä tai toisesta riitä vastuun kantamiseen koko kokonaisarkkitehtuurista. Haasteena tässä on kuitenkin ylempien ja alempien tasojen yhteensovittaminen. Jos se ei onnistu, se on riski.

Jos yrityksessä on liiketoiminnan kehitysyksikkö tai erillinen kokonaisarkkitehtuuriyksikkö, ne ovat luonnollisia kokonaisarkkitehtuurin vastuunkantoyksiköitä. Ratkaisu ei ole sovelias kovin pienille organisaatioille.

Tilanne, jossa kukaan ei vastaa kokonaisarkkitehtuurista, on se kaikkein vähiten toivottava. Silloin on vaarana, että kokonaisarkkitehtuurista tulee johtamattomana asiana monimutkainen, mikä merkitsee kustannusten kohoamista ja kehityksen hidastumista.

Lopuksi palaan vielä tietohallintoon ja heitän peliin ajatuksen: kun kerran tietohallinto on suurin vastuunkantaja kokonaisarkkitehtuuriasioissa, voisiko se ottaa kokonaisvastuun kokonaisarkkitehtuurista ja samalla lisää vastuuta kehittämisestä? Olisiko kysymyksessä luonteva askel digitalisoituvassa maailmassa? Tiedän, että se vaatisi uusia osaamisia tietohallintoon ja tietohallinnon siirtämistä organisaatiossa lähemmäs toimitusjohtajaa. Jos aika on kypsä, ota yhteyttä!

Linkkejä:

Vuoden 2012 tutkimus

CxO Webinaari 7.4.2017 Kokonaisarkkitehtuuri johtamisessa -tallenne

Kommentoi kirjoitusta. Avainsanat: johtaminen, kehittäminen, kokonaisarkkitehtuuri

Onko kokonaisarkkitehtuurista mihinkään?

Tiistai 4.4.2017 - Tuottavuusaktivisti Reino Myllymäki

Arkkitehtuuri_II_720x405.jpg

Olen ollut kokonaisarkkitehtuurin kanssa tekemisissä kymmenisen vuotta, oikeastaan enemmänkin. Silloin emme käyttäneet nimitystä "kokonaisarkkitehtuuri", vaan puhuimme linjauksista, politiikoista ja ohjeista. Kerran 90-luvun lopulla käyttäessäni arkkitehtuuri-sanaa minua pyydettiin puhumaan vaikkapa valinnoista. Rakennusliikkeessä kun arkkitehtuurilla tarkoitetaan primääristi rakennustaidetta.

Ihan piruuttani jatkoin kuvituslinjalla ja laitoin kuvan kirjoituksen alkuun delftiläisestä ylätason arkkitehtuurista. Ihan kirkontornista otetusta.

Mutta kysymykseen "Onko kokonaisarkkitehtuurista mihinkään?" Kyllä on. Moneenkin hyödylliseen johtamisasiaan.

Ensinnäkin, pelkkä nykytilan kuvaaminen on hyödyllistä. Se nostaa esiin moninaiset vaihtoehtoiset ratkaisut, joita olemme organisaatioomme hankkineet ja joista emme ole syystä tai toisesta luopuneet. Monimutkaiset rakenteet ovat syynä kehittämisen hitauteen ja korkeisiin kustannuksiin, totesivat Bain Companyn tutkijat jo kymmenen vuotta sitten.

Nykytilan kuvaaminen - niin kivaa kuin se onkin - ei ole kuitenkaan itsetarkoitus, vaan siitä kannattaa irroittautua ja siirtyä miettimään tavoitetilan kuvaamista. Parhaimmillaan tavoitetilan arkkitehtuuri on organisaation strategiasta johdettua. Kokonaisarkkitehtuuria työkaluna käyttäen tarvittava muutos saadaan esille laaja-alaisesti. Koko muutoksen laajuus selviää, jolloin tiedetään, millainen kehittämishaaste ollaan ottamassa.

Strategiakausi on kuitenkin lyhyt, usein paljon lyhyempi kuin visio ja usein myös lyhyempi kuin jo tehtyjen valintojen elinkaari. Lisäksi on muistettava, että strategiakin on kevyttä kamaa organisaatikulttuurin rinnalla; organisaatiokulttuurin kun sanotaan syövän strategian aamupalaksi. Organisaatiokulttuurikysymysten sisällyttäminen kokonaisarkkitehtuuriin onkin sitten toinen tarina.

Siihen toiseen tarinaan samoin kuin kokonaisarkkitehtuurin käyttämiseen johtamisessa kirjoittaja palaa  CxO Webinaarissa jonka voit katsoa tästä.

Kommentoi kirjoitusta. Avainsanat: enterprise architecture, EA, kokonaisarkkitehtuuri, kehittäminen, johtaminen, muutosjohtaminen

Mikä hiton kokonainen arkkitehtuuri?

Torstai 30.3.2017 - Tuottavuusaktivisti Reino Myllymäki

Arkkitehtuuri_720x450.jpg

Ylläolevan kaltaisia kuvia on tullut tavaksi laittaa mukaan kokonaisarkkitehtuuria käsitteleviin esityksiin, joten miksi minä tekisin toisin? Mutta päin vastoin kuin usein esitetään, minusta tämä sinänsä söpö amsterdamilainen miljöö ei edusta hyvää kokonaisarkkitehtuuria, vaan pikemminkin talot ovat täyttäneet käytettävissä olevaan tilaan kuin olisivat kokonaisvaltaisen suunnittelun tulosta. Lisäksi ne nojailevat sivusuunnassa toisiinsa sen lisäksi, että ovat toki perustustensa varassa.

Kokonaisarkkitehtuuri ei ole rakennustaidetta, mutta se ei myöskään ole mikään IT-juttu. Kokonaisarkkitehtuuri on kokonaisvaltaista organisaation johtamiseksi tarvittavien asioiden huomioon ottamista. Joissakin yrityksissä sanan "kokonaisarkkitehtuuri" sijaan puhutaan "periaatteista ja valinnoista", joka kuvaa paremmin asian ydintä. Ikävä juttu, että yleisesti ymmärrettävää sanaa ei asialle ole löytynyt.

IT-väki suurinpiirtein ensimmäisenä ymmärsi, mihin kokonaisarkkitehtuuria voi käyttää: immateriaalisten ja käsitteellisten asioiden havainnollistamiseen. Niinpä monessa organisaatiossa on yleisesti neljätasoisena esitetyn kokonaisarkkitehtuurikuvauksen kolmen alimman tason (teknologia-, järjestelmä- ja tietoarkkitehtuuri) käsittävä "kolme neljäsosaa -arkkitehtuuri, joka on tietohallinnon vastuulla.

Kokonaisarkkitehtuurin ylimmät tasot on varattu liiketoiminnan asioille. Yritystoiminnassa siitä käytetään nimitystä yritysarkkitehtuuri tai liiketoiminta-arkkitehtuuri; kumpikaan ei kelpaa julkishallinnolle, joka käyttää nimitystä toiminta-arkkitehtuuri. Tälle tasolle ei ole oikein vakiintunut kuvaustapaa eikä oikein sisältöäkään, mutta yleisesti ottaen tälle tasolle tungetaan prosessit, toiminnot, organisaatio, toimipisteverkko, tuotteet ja palvelut, strategia, arvot ja aika monta muuta juttua.

Veikkaan, että menee vielä muutama vuosi, ennenkuin tuo taso saadaan järjestykseen ja ymmärrettävään kuntoon. Syytä olisi, sillä kokonaisarkkitehtuuri kokonaisena arkkitehtuurina on erittäin käyttökelpoinen organisaation kehittämisen ja johtamisen väline. Se auttaa ottamaan huomioon asioita, joita ehkä muuten emme muistaisi ottaa muutoshankkeissamme huomioon. Kokonaisarkkitehtuuri kuuluukin siis yrityksen johdon tai kehittämistoiminnon vastuulle ja käyttöön. Jos organisaation kehittäminen kuuluu tietohallinnon, kokonaisarkkitehtuuri on jo oikeassa paikassa ;-)

Kokonaisarkkitehtuuri on varsinkin liiketoiminta-arkkitehtuurin osalta sen verran lapsenkengissään, että tämän blogikirjoituksen tekijä uskaltaa pistää näppinsä asiaan yhden webinaarin verran. Kuuntele veloitukseton CxO Webinaari tästä.

Kommentoi kirjoitusta. Avainsanat: enterprise architecture, EA, kokonaisarkkitehtuuri, kehittäminen, johtaminen, muutosjohtaminen

Unohtuuko uskomukset muutoksessa?

Tiistai 14.3.2017 - Tuottavuusaktivisti Reino Myllymäki

Muutosjohtaminen_720x405.jpg

Peter F. Drucker on joskus kirjoittanut: "Organisaatiokultturi syö strategian aamupalaksi". Tällä hän tarkoitti sitä, että organisaatiokulttuuri on strategiaa vahvempi tekijä. Johtaja, joka ei ota huomioon muutosjohtamisessaan organisaatiokulttuuria, huomaa hyvin pian johtavansa strategiaa, joka ei tule toteutumaan.

Harva strategia sisältää ajatuksen, että hoidetaan asioita niin kuin ennenkin. Yleensä strategiat pitävät sisällään tavoitteita, joiden toteutuminen edellyttää muutoksia esimerkiksi toimintatapoihin. Muutosten toteuttaminen taas edellyttää muutoksen johtamista, muutosjohtamista.

Muutos voi jäädä toteutumatta monesta syystä. Yksi vähän tutkittu epäonnistumisen syy on organisaatiokulttuuriin kuuluvien uskomusten huomiotta jättäminen. Muutos sotii jotain ylös kirjaamatonta mutta vahvaa uskomusta vastaan. Kun uskomusta ei oteta muutosjohtamisen kohteeksi, se voittaa ja tavoitteet jäävät saavuttamatta.

Miksi tietojärjestelmäprojekti epäonnistuu? -kirjamme tutkimusaineistosta löytyy esimerkki, joka löytyy myös julkisesta lähteestä, nimittäin Vesa Tiirikaisen kirjasta IT ja parempi bisnes:

"Noin yhdeksän kuukautta käyttöönoton jälkeenyrityksen johto hämmästyi: yhtään ainoaa uuden järjestelmän mahdollistamaa uutta ja asiakkaille selvästi parempaavakuutusta ei ollut myyty. Sen sijaan vanhojen vakuutusten vuoksi käytössä olevan järjestelmän tukemia vanhoja vakuutuksia oli myyty ihan tyydyttävästi. Hämmästyttävän havainnon jälkeen selvitettiin nopeasti, miksi myyjät olivat menetelleet näin. Syy oli bonusjärjestelmässä.

Vanhoihin vakuutuksiin sovellettiin edelleen niiden aikana käytössä ollutta myyjän palkkiomallia, jossa vuosittain maksettavan bonuksen suuruus määräytyi vakuutuksista saatavasta kokonaismaksutulosta. Uusiin vakuutuksiin taas sovellettiin uutta palkkiomallia, jossa vuosibonuksen suuruus määräytyi kolmen edellisvuoden kokonaiskatteen perusteella. Jokainen myyjä päätteli saavansa vanhoista vakuutuksista täysin itse ennakoitavissa olevan vuosipalkkion heti myyntivuoden päättyessä. Oli siis aivan turha sitoa itseään uusiin vakuutuksiin ja sitä kautta uuteen bonusmalliin odottamaan kolme vuotta, että olisi saanut jonkin vaikeasti arvioitavan vuosipalkkion."

Tuotteet ja niihin liittyvät palkkiomallit kuuluvat yrityksen johtamisjärjestelmään. Uskomus, jonka mukaan "parempi pyy pivossa kuin kymmenen oksalla" taas on kansanviisaus, jota esimerkkitapauksessa saattoi vielä voimistaa epäluottamus johtoa kohtaan ja vakuutusmyyjien nopea kierto. Lisäksi vakuutusmyyjien uskomuksissa oli ajatusvirhe, jota kutsutaan hyberboliseksi diskonttaukseksi. Tuohon lankeaa useampikin suomalainen, joka ottaa mieluummin kaksi tonnia heti kuin kolme vuoden päästä - vaikka vuoden odottamalla saisi 50 % koron pääomalle!

Strategia, johtamisjärjestelmä sekä organisaatiokulttuuri arvoineen ja uskomuksineen kuuluvat kaikki organisaation toiminta-arkkitehtuuriin, jota liike-elämän puolella kutsutaan kokonaisarkkitehtuurin ylimmäksi tasoksi eli liiketoiminta-arkkitehtuuriksi.

Liiketoiminta-arkkitehtuuri on vielä jäsentymätön kokonaisarkkitehtuurin osa. Sopivasti haasteita saatuani olen pyrkinyt hahmottamaan mitä kaikkea sinne tarvitaan ja miten kokonaisarkkitehtuuria voi hyödyntää muutosjohtamisessa. Palataan asiaan ensi perjantaina klo 8!

Tuottavuusaktivisti Reino Myllymäki puhuu muutosjohtamisesta ilmaisessa CxO Webinaarissa, katso tästä.

Kommentoi kirjoitusta. Avainsanat: kehittäminen, muutosjohtaminen, uskomukset, kokonaisarkkitehtuuri, digitalisaatio

Onnistumistakin on monenlaista

Torstai 11.8.2016 - Tuottavuusaktivisti Reino Myllymäki

Rikottu_lasi_vaalea_720_px.jpg

Kehityshankkeiden epäonnistuminen on yleistä. Kirjoittaessani kirjaa Miksi tietojärjestelmäprojekti epäonnistuu? päädyin noin 70 prosentin tasoon, sillä pelkästään ERP-projektien budjetit näyttävät ylittyvän 60 prosentissa projekteista.

Tänään olen kuitenkin valmis pohtimaan onnistumisia ja epäonnistumisia useammastakin näkökulmasta.

Projektinäkökulma

Perinteisesti kehityshankkeiden ja tietojärjestelmäprojektien onnistumista on tarkasteltu projektin itsensä näkökulmasta. Esimerkiksi The Standish Group on Chaos-raporteissaan lähtenyt liikkeelle kolmesta näkökulmasta: raha, aika ja toiminnallisuus. Heidän logiikkansa mukaan projekti epäonnistui, jos sen budjetti (raha tai aika) ylittyi vähintään viisi prosenttia tai projektin käynnistyksessä luvatusta toiminnallisuudesta jäi toteuttamatta vähintään viisi prosenttia.

Raha on kyllä tärkeä onnistumisen mittari, sillä hallinnasta ryöstäytyneet kustannukset saattavat romuttaa panos-hyöty-suhteen ja mikä vielä pahempaa, suistaa koko yrityksen konkurssiin. Aikataulujen ylittymisellä on korrelaatio kustannusten ylittymiseen, samalla aikataulujen pettäminen johtaa takaisinmaksun siirtymiseen ja yhdessä kustannusten kohoamisen kautta takaisinmaksun päättyminen siirtyy vielä enemmäs kun itse takaisinmaksuaika pitenee.

Tuotetulla toiminnallisuudella on vaikutusta projektin tuloksista saataviin hyötyihin. Jos toiminnallisuus jää vajaaksi, hyödyt alenevat ja panos-hyöty-suhteen hyötypuolen pieneneminen pidentää takaisinmaksuaikaa pahimmillaan äärettömäksi.

Kokonaisarkkitehtuurinäkökulma

Kehityshankkeen tulos on digitalisaation myötä yhä useammin tietojärjestelmä, uusi tai parannettu, taikka useamman tietojärjestelmän muodostama kokonaisuus, johon uudet tai korjatut toimintatavat ja -prosessit liittyvät.

Projektin onnistumisen näkökulmasta arkkitehtuurinäkökulmia on itse asiassa kaksi: Miten kehitettävä kokonaisuus istuu ympäröivään kokonaisuuteen? Miten kehitettävän kokonaisuuden osat istuvat yhteen?

Sinänsä onnistuneena pidetty projekti saattaa tuottaa ongelmallisen arkkitehtuurin, joka estää tai hidastaa kehittämistä, tekee sen kalliiksi tai sitoo yhteen toimittajaan tai ratkaisuun. Kokonaisarkkitehtuuriongelmat voivat näkyä myös tehottomina prosesseina ja ylläpidon työläytenä. Molemmat mitataan myöhemmin rahassa, kasvaneina kustannuksina ja alentuneina hyötyinä.

Liiketoimintanäkökulma

Projekti voi projektina epäonnistua ja kokonaisarkkitehtuurinkin ongelmat voivat jäädä piiloon, jos kehityshanke onnistuu liiketoiminnallisesti. Hanke maksaa riittävän vähän, ei myöhästy ratkaisevasti ja tuottaa riittävästi toiminnallisuutta liiketoiminnallisen ongelman ratkaisemiseksi.

Toisin päin käännettynä kustannus- ja aikatauluylitykset sekä vajaatoiminnallisuus voivat tuhota aiemmin esitetyistä syistä panos-hyöty-suhteen.  Ne voivat tuhota projektin hyödyt myös sillä tavalla, että yritys menettää kilpailuedun - kilpailija ehtii ensiksi, tarjoaa parempaa asiakaspalvelua tai halvemmilla hinnoilla.

Voi myös käydä niin, että käyttöönotto myöhästyy liiketoiminnallisesta aikaikkunasta ja siirtyy vuodella eteenpäin; moni yritys pyrkii ottamaan - oli siinä järkeä tai ei - talouden järjestelmänsä vuoden alusta.

Muut näkökulmat

Kehityshankkeiden onnistumisilla on merkitystä myös kollektiivisen itsetunnon kanssa. Onnistuneen kehityshankkeen läpivienyt yritys uskaltaa lähteä uusiin kehityshaasteisiin, epäonnistuneen kokenut puolestaan pahimmillaan jättää kehittämisen sikseen vuosiksi ja tuhoutuu.

Projektien ristiriidat voivat myös repiä henkilösuhteet ja esimerkiksi liiketoiminnan ja tietohallinnon suhteet piloille pitkiksi ajoiksi. Hyvin menevät hankkeet puolestaan lujittavat yhteistyötä ja synergioita.

Tämän kirjoituksen tarkoituksena ei ole peloitella ketään luopumaan kehittämisestä. Päinvastoin! Tietotekniikka ja sen käyttöönotto ovat merkittävin tuottavuutta parantava teknologia tällä hetkellä ja ilman projekteja sen hyödyntäminen on mahdotonta. Mutta onnistunut projekti rakennetaan realismille, ei toiveajattelulle tai ylioptimismille. On oikein ymmärtää, mitkä ovat reunaehdot ja riskit, ja suunnitella projekti sen mukaan.

CxO Professional Oy tuottaa palveluja kehityshankkeiden onnistumisen parantamiseen. Olemme erikoistuneet valmistelun terveystarkastuksiin ja tukemiseen. Esikoiskirjamme Miksi tietojärjestelmäprojekti epäonnistuu? Tositarinoita tuhon teiltä ja onnistumisen siemeniä on erikoistarjouksessa CxO Shopissa elokuun 2016 loppuun.

Kommentoi kirjoitusta. Avainsanat: projekti, projektityö, onnistuminen, epäonnistuminen, kokonaisarkkitehtuuri, liiketoiminta, kollektiivinen itseluottamus

Pari villiä ideaa

Tiistai 5.1.2016 - Tuottavuusaktivisti Reino Myllymäki

Digitalisaatio on sana, joka tupsahti arkiseen kielenkäyttöömme vuonna 2015, kiitos hallituksen sekä eräiden IT-palveluntarjoajien. Vähän samaan tapaan kuin iterointi- ja vatulointi-sanat.

Joku toivoi Keski-Uusimaa-lehden yleisönpalstalla vuonna 2015, että digitalisaatio voitaisiin peruuttaa. Valitettavasti ei voi, se alkoi jo vuonna 1995. Kai Koskela sanoi Tuusulan Tietokirjapäivässä 28.11.2015, että digitalisaatio etenee, halusimmepa sitä tai emme. Joku yleisöstä oli eri mieltä. Olen samaa mieltä sekä Kain että vastaväittäjän kanssa. Tietotekniikan hyödyntämisessä on siirrytty globaalisti nopeaan vaiheeseen, jossa Suomen ja sen yritysten merkitys on pieni. Silti kansallisella tasolla voimme vaikuttaa siihen, miten digitalisaatio menee eteenpäin ja miten sen haittavaikutukset minimoidaan.

Joku saattoi ajatella, että digitalisaatio oli vuoden 2015 juttu. Niin se olikin. Mutta vielä enemmän vuoden 2016 juttu. Sitä ei peruttu eikä se mennyt ohitse. Digitalisaation hyödyt tulevat - eivät valtavirtaan hyppäämällä eikä härpäkkeitä ostamalla - vaan turhia manuaalivaiheita toiminnasta poistamalla. Ja siinä on tietotekniikalla oma vissi paikkansa!

Joululomalla sai muotonsa pari villiä ajatusta, jotka tosin ovat saaneet alkunsa osin IT Forumin vuosien 2014-2015 toiminnan, osin asiakastyön yhteydessä.

Kokonaisarkkitehtuuri (Enterprise Architecture)

Kokonaisarkkitehtuuri mielletään usein tietohallinnon jutuksi. Oikeasti se ei sitä ole. Kokonaisarkkitehtuuri on organisaation kehittämisen selkäranka, joka lähtee liikkeelle organisaation strategiasta.

Veikkaan, että organisaatiot, jotka hiffaavat tämän, saavat kilpailuedun.

Palvelunhallinta (Service Management)

IT Service Management eli IT-palvelunhallinta on arkipäivää sekä kaupallisille IT-yrityksille että organisaatioiden sisäisille IT-yksiköille.

Digitalisaatio muuttaa kaikkia organisaatioita tietointensiivisempään suuntaan, kohti IT-organisaatioita. Prosessit muuttuvat kasvavassa määrin tietotekniikkaan perustuviksi.

Koska tietointensiivisten organisaatioiden paras palvelunhallintamenetelmä on ITSM, voisiko olla niin, että siitä poistetaan kirjaimet "IT" ja hyväksytään loppuosa sekä sisältö käyttöön?

Veikkaan, että ei-IT-organisaatiot, jotka ottavat IT Service Managementin käyttöön, saavat kilpailuedun.

Ideat on tarkoitettu vapaasti käytettäviksi!

Kommentoi kirjoitusta. Avainsanat: johtaminen, kehittäminen, IT, tietotekniikka, digitalisaatio, kokonaisarkkitehtuuri, Service Management

Miltä tuntuisi, jos työvoimakustannusten vaadittaisiin olevan nolla?

Perjantai 13.2.2015 - Reino Myllymäki

Liiketoiminnan ja tietohallinnon välinen yhteistyö on viime vuosina kehittynyt oikeaan suuntaan. Vaikka kehitysharppaukset ovatkin organisaatiokohtaisia, yleisestikin ottaen pienikin oikean suuntainen kehitys vie asioita eteenpäin, kun tarkastelujaksoksi otetaan pidempi aika kuin yksi vuosi.

Silti löytyy asioita, jotka yhteistyössä mättävät sekä liiketoiminnan että tietohallinnon näkökulmista. Yritän nostaa lähiviikkoina muutaman kissan pöydälle näiden blogikirjoitusten kautta.

Moni tietohallintojohtaja kipuilee esimerkiksi IT-kustannusten kanssa. Liiketoiminta kun tahtoisi niiden olevan nolla.

Kun asiaa katsoo toisesta suunnasta, huomaa, että tietohallinnolla on tuskin yhtäkään sovellusta hoidossaan, joka olisi tietohallinnolle itselleen tarkoitettu. Kaikki tai lähes kaikki on suoraan tai epäsuoraan liiketoimintaa palvelevaa ja liiketoiminnan tarpeiden vuoksi hankittu, käyttöönotettu, ylläpidetty ja palveltu.

Yhä useamman yrityksen liiketoiminta makaa tietotekniikan varassa. Tietotekniikan päivittäisestä toimivuudesta ja edistyksellisyydestä on kiinni liiketoiminnan jatkuvuus suurelta osin. Kuinka moni vaatii jonkin muun vastaavan hyödykkeen olevan ilmaista? Olisihan se kivaa, jos esimerkiksi sähkö olisi ilmaista mutta katsoessaan vaikkapa kuvia ydinvoimalasta tai sähkönsiirtolinjoista toteaa, ettei se mitenkään voi olla.

Entä kuinka moni liiketoimintajohtaja sanoo HR-johtajalle, että työvoimakustannusten pitää olla nolla?

Näitä asioita on toki helppo pyöritellä ja tuskassa kieriskellä. Mutta mikä lääkkeeksi? Nostan esiin pari, joilla oman kokemukseni mukaan on saatu aikaan parannusta: palvelujen hinnoittelu ja kokonaisarkkitehtuurityö.

Kaikkien IT-kustannustusten selvittäminen ja niiden kohdistaminen palveluille helpottaa liiketoimintaa muodostamaan käsityksen siitä, mistä niiden tietotekniikkakustannukset muodostuvat. Huomio kohdistuu oikeisiin asioihin. Kokemukseni mukaan liiketoiminnan johtajat alkavat miettiä, mitä kaikkea liiketoiminta ihan oikeasti tarvitsee.

Kokonaisarkkitehtuurityöllä puolestaan paljastuu kaikki rinnakkaiset ja päällekkäiset ratkaisut, joista voi lähteä liikkeelle hedelmällisiä keskusteluja liiketoiminnan ja tietohallinnon kesken. Optimaalisessa arkkitehtuurissa kun ei ole samaa asiaa ratkaistu kuin kertaalleen.

Kokonaisarkkiitehtuuri on kuitenkin vaarallinen tai ainakin arveluttava sana. Se viittaa joidenkin mielestä liikaa tietotekniikkaan, vaikka oikeasti onkin organisaation kehittämisen väline. Joissain organisaatioissa on menestyksellisesti kokonaisarkkitehtuuri korvattu sanaparilla "periaatteet ja valinnat".

Kommentoi kirjoitusta. Avainsanat: tietohallinto, liiketoiminta, yhteistyö, kokonaisarkkitehtuuri, IT-palvelu, hinnoittelu, ammattimentorointi

Monkey see, monkey want!

Perjantai 19.9.2014 - Reino Myllymäki

Muistan takavuosilta yhden henkilön, joka soitti minulle ja kysyi, että pitääkö hänen tosiaan lähettää sähköpostit kännykän modeemin välityksellä vaikka käytettävissä olisi neljä kertaa nopeampi lankaliittymän modeemi. Sanoin, että hän voi aivan hyvin käyttää lankamodeemia.

Mistä tällainen kysymys juonsi juurensa? Käyttäjän esimies tai varmaankin esimiehen esimiehen esimies oli paasannut mobiilisuuden ihanuuksista ja markkinoinut kännykän käyttöä, ilmeisesti myös sähköpostiviestien yhteydessä. Aikaa tuosta puhelinsoitosta on ainakin 10, luultavasti 15 vuotta.

Ilmiötä kutsutaan tietohallintojohdon piirissä monkey see, monkey want -ilmiöksi. Johtaja näkee jossain jotain hienoa ja hänen pitää saada se heti. Vähän kuin lapsi päivittäistavarakaupassa. Paitsi, että kysymyksessä on suuremmat asiat ja vaikutuksetkin laajemmat, tässä tapauksessa ulottuen alaisiin monta organisaatioporrasta alaspäin.

Lukeudun palveluväyläskeptikkoihin. En tykkää ollenkaan tavasta, jolla palveluväylää viedään eteenpäin. Keskustelu on vähäistä eikä epäilijöitä suvaita. Koko palveluväylähurmos vaikuttaa minun mielestäni uskonnolta, senhän yksi määritelmä on "luja luottamus siihen, mitä toivotaan, ojentautuminen sen mukaan, mikä ei näy". Eräs asiantuntija sanoikin, että Viron X-Road saatiin Suomeen seuraavan päättelyketjun seurauksena: 1. Suomessa ei terveystiedot liiku. 2. Virossa liikkuu. 3. Virolla on X-Road. 4. Suomen pitää saada X-Road.

Sen lisäksi, että Suomeen tuodaan väkisin 13 vuotta vanhaa tekniikkaa, myös palveluväylän toiminta-aluetta on tarpeettomasti laajennettu avoimeen dataan ja perustietovarantoihin. Todennäköisesti järki voittaa lopulta (tämäkin on yksi tietohallintojohdon piirissä omaksuttu viisaus) ja palveluväylän johonkin myöhempään versioon tulee nykyaikainen tekniikka ja käytännöllinen soveltamisalue.

Minulla ei myöskään ole mitään sitä vastaan, että palveluväyläpilotit onnistuvat. Terveydenhuoltoon tarvitaan toimiva tietojenvälitys. Mutta hurmoksesta ja tavasta, jolla asiaa on viety eteenpäin en siis tykkää. Niin ja rahantuhlauksesta en tykkää myöskään.

Palveluväylän ympäriltä on alkanut kuulua myös tavoitteista, joiden mukaan jotain näyttävää näytettävää pitää syntyä ennen ensi kevään eduskuntavaaleja. Ongelma on, että jos näyttävää ei saada järkevästi aikaan, sitä tehdään järjettömästi. Silloin näyttävä tulos voi olla yhtä kuin ei-tarpeellinen tulos. Ja taas rahaa tuhlataan.

ICT Leaders Finland ry suunnittelee yleisötilaisuutta tammikuulle 2015 juuri tämän palveluväylä-teeman ympärille. Tarkoitus on päästää ääneen myös skeptikot. Toivottavasti tämä toteutuu.

Kommentoi kirjoitusta. Avainsanat: palveluväylä, kokonaisarkkitehtuuri, johtaminen, kehittäminen, ammattimentorointi

Kokoa kokonaisarkkitehtuuritiimi

Keskiviikko 2.5.2012 - Reino Myllymäki

Jeanne Rossin artikkelista Maturity Matters: How Firms Generate Value From Enterprise Architecture löytyy joukko neuvoja arkkitehtuurin ja arkkitehtuurityön kehittämiseen niin, että niistä saa eniten hyötyä irti. Tämä on Jeannen viimeinen neuvo ja lienee 18. ja on siis viimeiseltä eli neljänneltä portaalta ja kuuluu: a full-time enterprise architecture team.

Jeanne kehoittaa siis pystyttämään täysipäiväisen arkkitehtuuritiimin. Neuvo ei ehkä sovi pienille yrityksille mutta aika nopeasti organisaation kasvaessa hommasta tulee kuitenkin yhden tai useamman asiantuntijan päätyö.

Karsastan tilannetta, jonka olen kuullut olevan yhdessä jos toisessakin organisaatiossa nykytilana: projektit jumiutuvat kokonaisarkkitehdin pöydälle odottamaan arkkitehtuurilausuntoa. Ei vetele. Arkkitehtuurityön pitää olla palvelua. Jos arkkitehtuurilausunto ei irtoa pieneen projektiin viikossa ja isoon kahdessa niin hommassa on mätää!

Eräässä yrityksessä siirryttiin hiljan keskitetystä arkkitehtuuritiimistä hajautettuun, siis virtuaaliorganisaatioon. Arkkitehtuurilausuntojen - vaikka ne siis tehdään edelleenkin useamman hemmon yhteistyönä - toimitusaika lyheni ja laatu parani. Keskittämisellä luodaan papistoja, jotka pitävät arkkitehtuuria luomistyön huipentumana ja puhuvat toisilleen togaffia. Ei vetele edelleenkään.

On jokseenkin selvää, että arkkitehtuuria pitää johtaa ja kehittää. Sellainen kuuluu kyllä tietohallinnon vastuulle tai sitten tietohallinnon ja IT-palvelujen kehittämisosaston rajapintaan lähelle PMO:ta. Kaikkia arkkitehtejä ei tarvitse kaataa samaan yksikköön mutta arkkitehdeistä pitää kuitenkin koota jonkinlainen virtuaalinen osaamiskeskittymä, competence centre englanniksi ja competency center amerikaksi.

Tähän loppui Jeanne Rossin neuvojen käpistely tällä erää.

Kommentoi kirjoitusta. Avainsanat: kokonaisarkkitehtuuri, EA, organisointi

Tutkiminen ja valintojen tekeminenkin tarvitsevat prosessinsa

Maanantai 30.4.2012 - Reino Myllymäki

Jeanne Rossin artikkelista Maturity Matters: How Firms Generate Value From Enterprise Architecture löytyy joukko neuvoja, joilla todellista arvoa saa arkkitehtuurityöstä parhaiten irti. Jeannen 17. neuvo on viimeiseltä eli neljänneltä portaalta ja kuuluu: a formal research and adoption process.

Kollega takavuosina kielsi johtoryhmässä puhumasta arkkitehtuurista ja kehotti puhumaan valinnoista. Tuntui silloinkin järkevältä ja niin on nykyäänkin. Asiaa mystifioidaan tarpeettomasti kutsumalla valintojen kokonaisuutta arkkitehtuuriksi.

Kokonaisarkkitehtuuri on siis valintoja, monenlaisia valintoja eri tasoilla. Ei ole yhdentekevää, mitä on valittu ja niinpä ei ole yhdentekevää sekään, miten valintoja otetaan mukaan arkkitehtuuriin tai vanha valinta korvataan uudella.

Siispä luo menettelyjä ja muotovaatimuksia sille työlle, jonka yhteydessä tutkitaan uusia tuotteita ja teknologioita sen arvioimiseksi, ratkaisisivatko ne oman organisaation ongelmia esimerkiksi yksinkertaistamalla arkkitehtuuria tai tekemällä siitä aikaisempaa tehokkaamman tai halvemman.

Valinnat synnyttävät lähes poikkeuksetta kumminkin polemiikkia ja siltä on paras suojautua tutkimalla asiat kunnolla, vertailemalla vaihtoehtoja ja perustelemalla valinnat - sekä dokumentoimalla tämä kaikki.

Kommentoi kirjoitusta. Avainsanat: kokonaisarkkitehtuuri, EA, kehittäminen

Projekteille jälkiarviointi

Perjantai 27.4.2012 - Reino Myllymäki

Jeanne Rossin artikkelista Maturity Matters: How Firms Generate Value From Enterprise Architecture löytyy joukko neuvoja, jotka koskevat sitä, miten arkkitehtuurityöstä voi ulosmitata parhaiten arvoa. Jeannen 16. neuvo on viimeiseltä eli neljänneltä portaalta ja kuuluu: post-implementation assessment.

Projektin jälkiarvio kuuluu monen organisaation projektikäsikirjaan ja/tai projektisalkun hallinnan menettelyihin. Ainakin periaatteessa. Käytännössä jälkiarviot jäävät tekemättä tai ne tehdään liian pian projektin jälkeen.

Jälkiarviossa pitäisi käsitellä esimerkiksi projektin toimintaa. Siinä suhteessa raportointi pian projektin päättymisen jälkeen on paikallaan. Toisaalta raportissa pitäisi käsitellä myös projektin tavoitteita ja niiden toteutumista sekä projektin tuloksista konkretisoituneita hyötyjä. Siihen ei kyetä, jos jälkiarvio pitää tehdä heti projektin päättymisen jälkeen.

On näet niin, että käyttöönoton jälkeinen 3...6...12 kuukautta on vielä käytön opettelua, eikä hyödyt ole ehtineet kaikilta osin realisoitua lyhyemmässä ajassa.

Joka tapauksessa jälkiarvio tulee tehdä, jotta opitaan, miten arvioidut hyödyt ja kustannukset realisoituvat ja projektien kokemukset voidaan ottaa huomioon projektitoimintaa ja -kulttuuria kehitettäessä.

Kommentoi kirjoitusta. Avainsanat: kokonaisarkkitehtuuri, EA, projektityö, jälkiarviointi

Yhden kuvan visio

Torstai 26.4.2012 - Reino Myllymäki

Jeanne Rossin 15. neuvo artikkelista Maturity Matters: How Firms Generate Value From Enterprise Architecture koskee organisaation vision esittämistä: a one-page graphic for communicating an enterprise vision. Neuvo on ensimmäinen kypsyysportaikon neljännellä ja viimeisellä portaalla.

Turhan monissa yrityksissä strategiatyö päättyy strategian valmistumiseen. Hei, siitähän se vasta alkaa! Strategiat unohdetaan hyllylle pölyttymään - pölyn kerääminen on itse asiassa ainoa asia, jonka strategia itsekseen kykenee tekemään.

Strategia pitää jalkauttaa. Se ei jalkaudu itsekseen. Joukkue jalkautuu traktorin lavalta kyllä itsekseen, mutta strategia ei. Strategian jalkauttaminen on suurelta osin viestintää mutta myös johtamista.

Jeanne Rossin ajatus yhdestä keskeisestä kuvasta - tai kalvosta - joka kertoisi siitä, minne ollaan menossa, on hyvä. Niin hyvä, että itse asiassa CxO on juuri ottanut sen käyttöön. Kuva jakaantuu kolmeen osaan:

  • Missio: Miksi olemme olemassa?
  • Visio: Minne olemme menossa?
  • Kehitysportaat: Miten sinne päästään?
Kuva voidaan laittaa vaikka jokaisen neuvottelu- ja kahvihuoneen seinälle.... Jos haluat nähdä kuvan, ota yhteyttä!

Kommentoi kirjoitusta. Avainsanat: kokonaisarkkitehtuuri, EA, visio, missio, strategia

Projekteja pitää orkestroida

Keskiviikko 25.4.2012 - Reino Myllymäki

Jeanne Rossin artikkelista Maturity Matters: How Firms Generate Value From Enterprise Architecture otettujen arkkitehtuurineuvojen 14. neuvo koskee tietoteknisten hankkeiden johtamista: IT program managers.

Neuvo ei ainakaan itselleni avaudu yksiselitteisenä. Jos näkemykseni on ristiriidassa jonkun toisen kanssa, toivoisin palautetta...

Tyypillistä on, että yhtä aikaa vedetään lukuisaa joukkoa liiketoiminnan ja tietotekniikan kehityshankkeita, siis kehityshankkeita, jotka suoraan tai epäsuoraan kehittävät liiketoimintaa. Projekteilla on riippuvuussuhteita toisiinsa ja niipä projektiparven keskinäisten riippuvuuksien, aikataulujen, resurssien ja vaikutusten perään on katsottava. Projektit tarvitsevat siis hankejohtamista.

14. neuvo päätti kolmannen askelman Rossin 4-askelmaisessa kokonaisarkkitehtuurin kypsyysportaikossa.

Kommentoi kirjoitusta. Avainsanat: kokonaisarkkitehtuuri, projektityö, hanke

Ylin johto katsomaan arkkitehtuurihankkeiden perään

Tiistai 24.4.2012 - Reino Myllymäki

Jeanne Rossin 13. neuvo koskien hänen artikkeliaan Maturity Matters: How Firms Generate Value From Enterprise Architecture koskee ylimmän johdon roolia kokonaisarkkitehtuurityössä: senior executive oversight of architecture initiatives.

Kokonaisarkkitehtuuri kuvaa organisaatiota ja sen toimintaa. Erityisesti sen ylimmät tasot - lähinnä hyhmäinen liiketoiminta-arkkitehtuuri - ovat hyvin liiketoimintaintensiivisiä.  Liiketoiminnan vaikutus vähenee kohti alempia tasoja: tietoarkkitehtuurissa se on hyvin suuri, järjestelmäarkkitehtuurissa suuri ja infrassa enää vähäinen.

Niinpä ylimmän johdonkin kiinnostuksen pitäisi kohdistua kokonaisarkkitehtuurin ylimpiin tasoihin, eikä muutoksia tai ponnistuksia sillä alueella pitäisi tehdä ilman heidän valvovaa silmäänsä.

Kerron esimerkin. Takavuosien työnantajallani tapahtui suuri organisaatiomuutos. Pian sen jälkeen aloimme integraatioarkkitehtuurin laadinnan. Parin liiketoiminnan edustajan mielestä integraatiot pitäisi jakaa kolmeen pilveen, kun nyt on tehty tämä jako kolmeen toimialaan. Tietohallinto-osaston väki - minä mukana - olimme ratketa naurusta. Olimme nähneet vuosien kuluessa niin monta organisointia, että tiesimme, ettei tämä jää pysyväksi. Pian myytiin verkkopalvelut pois ja loput toimialasta yhdistettiin toiseen toimialaan. Kolmas toimiala jaettiin kahteen osaan. Kuinkas olisi käynytkään kolmelle pilvelle - päädyimme näet pitämään kaiken yhdessä pilvessä.

Ongelma on oikean keskustelutason saavuttaminen ja ylläpitäminen tietohallinnon ja liiketoiminnan sekä ylimmän johdon välillä. Ylin johto ei välttämättä ollenkaan ymmärrä päätöstensä vaikutuksia tietojärjestelmiin tai arkkitehtuuriin. Onnellista olisi, jos ylimmästä johdosta löytyisi riittävän IT-orientoitunut kehitys- tai yrityssuunnittelujohtaja, joka ottaisi huomioon sekä liiketoiminnan että tietotekniikan.

Kommentoi kirjoitusta. Avainsanat: kokonaisarkkitehtuuri, johtaminen

Liiketoimintajohto vetäköön projekteja

Maanantai 23.4.2012 - Reino Myllymäki

Jeanne Rossin 12. neuvo artikkelista Maturity Matters: How Firms Generate Value From Enterprise Architecture koskee liiketoimintaa ja projekteja: business leadership of project teams.

CxO:n kokemusten mukaan liiketoiminnan projektien delegoiminen tietohallinnolle paitsi huonotaa projektien onnistumisen todennäköisyyttä, myös kaataa tietohallinnon niskaan liikaa vastuuta liiketoiminnasta.

Vaikka suositeltavaa on, että projektipäällikkö on liiketoiminnan ammattilainen, vielä suositeltavampaa on, että hän on projektitoiminnan ammattilainen riippumatta siitä, tuleeko hän liiketoiminnasta, tietohallinnosta vai kolmannelta osapuolelta. Tämä ei saa kuitenkaan tarkoittaa johtajuuden luovuttamista pois liiketoiminnasta.

Projektin omistajan on oltava liiketoiminnan johtaja ja vieläpä sellainen, jolle projektin epäonnistuminen tekee oikeasti kipeää. Myös projektin ohjausryhmään tulee nimetä sellaisia liiketoiminnan, tietohallinnon että konsernitason henkilöitä, joilla on projektin onnistumisen tiellä olevien esteiden raivaamiseen tarvittavaa päätöksentekokykyä ja -halua.

Liiketoiminnan osallistuminen tai pikemminkin osallistumattomuus on ollut usein yksi epäonnistumisen syy. Olenkin karrikoinut, että liiketoiminnan osallistumisesta esitetyt henkilölistat ovat toivelistoja henkilöistä, jotka tarvittaisiin projektiin. Mutta ei saada. Liiketoiminnan avainhenkilöitä ja -osaamista tarvitaan projektitiimeihin.

Kommentoi kirjoitusta. Avainsanat: kokonaisarkkitehtuuri, projektityö, liiketoimintajohto

Määritä kokonaisarkkitehtuurin asema

Perjantai 20.4.2012 - Reino Myllymäki

Määritä kokonaisarkkitehtuurin asema

Jeanne Rossin kokonaisarkkitehtuurineuvosetin kymmenes neuvo on kypsyysportaikon portaalta 3 ja liittyy kokonaisarkkitehtuurin ohjaavaan asemaan: a statement of enterprise architecture guiding principles.

Jo kokonaisarkkitehtuurin määritteleminen on arvokas asia. Arkkitehtuurissahan tehdään valintoja, joilla rajoitetaan sovellettavien vaihtoehtojen määrää ja sillä tavoin vähennetään monimutkaisuutta, helpotetaan hyödyntämistä ja säästetään rahaa.

Siitä huolimatta kokonaisarkkitehtuuri sinänsä ei tee mitään. Paitsi jos se on dokumentoitu paperille niin paperinippu vaakasuoraan asentoon jätettynä kerää pölyä. Kokonaisarkkitehtuuri ei hyppää hyllystä ja ala toteuttamaan itseään.

Kokonaisarkkitehtuurin asema toimintaa ja erityisesti kehittämistä ohjaavana tekijänä pitää määritellä. Onko se pakottava, vahvasti ohjeellinen vai pelkästään ohjeellinen? Miten sitä muutetaan? Jne.

Kokonaisarkkitehtuuri sinänsä kuuluu IT-strategiasettiä täydentäviin kokonaisuuksiin, kuten IT-linjauksiin ja -politiikkoihin. Niiden erityispiirre on, että ne ovat yleensä strategiakautta pitkäjänteisempiä asioita. Siksi arkkitehtuurin asema pitää selvästi ilmaista näissä linjauksissa, ja kannanotto pitää sopivin sanankääntein vahvistaa mm. IT-strategiassa.

Kommentoi kirjoitusta. Avainsanat: kokonaisarkkitehtuuri, EA, IT-linjaukset

Prosesseille omistajat

Torstai 19.4.2012 - Reino Myllymäki

Prosesseille omistajat

Jeanne Ross on antanyt mielestäni hyviä neuvoja kokonaisarkkitehtuurin ympäriltä alunperin vuonna 2004 ilmestyneessä artikkelissaan Maturity Matters: How Firms Generate Value From Enterprise Architecture. Olen purkanut niitä jo nyt kahdeksan postauksen verran. Rossin yhdeksäs neuvo on ensimmäinen neuvo kypsyysportaikon portaalla 3 ja se liittyy prosessien omistamiseen: enterprise-wide process owners.

CxO:n tutkimuksen mukaan prosessien omistajien puute oli yksi suurimmista liiketoiminnan ja tietohallinnon yhteistoiminnan esteistä.

Organisaatioiden kannattaisi tunnistaa prosessinsa ja nimittää prosesseille omistajat. Tämä ei kuitenkaan riitä: prosessien omistajien pitää tietää, että heidät on nimitetty tähän tehtävään ja yhtä tärkeää on, että he ja kaikki muutkin tietävät, mitä tehtävään kuuluu.

Tietojärjestelmät tukevat tukevat tyypillisesti yhtä tai useampaa prosessia. Siksi tietojärjestelmäprojektin onnistumisen kannalta on olennaista, että projektiin saadaan mukaan prosessien omistajat, joilla on kykyä ja valtaa tehdä päätöksiä.

Pienemmissä yleensä yhden toimialan yrityksissä prosessien määrittäminen ja vastuuttaminen on vielä suhteellisen yksinkertaista. Suuremmissa monen toimialan yrityksissä vaikeusaste kasvaa. Koko organisaation laajuudella toimivien prosessien omistajien nimittäminen voi olla vaikeaa ja jos onnistuukin, on todennäköistä, että omistajan tehtäväkenttä jää olennaisesti kapeammaksi kuin pienemmissä ympäristöissä.

Kommentoi kirjoitusta. Avainsanat: Kokonaisarkkitehtuuri, EA, prosessit, prosessin omistajat

Vanhemmat kirjoitukset »