Ensimmäinen oli, että muutosjohtaminen vaatii paljon johtamistaitoja, joita on vaikea oppia muuten kuin tekemällä, kokemalla ja kuuntelemalla. Toinen teema oli, että erilaiset ohjelmistotuotteet, jotka ratkaisevat identiteettien ja käyttövaltuuksien hallinnan ongelmia, tulevat parhaiten hyödynnetyksi kun ne otetaan käyttöön tavalla, joka on yhteensopiva organisaation muutoskyvyn ja -edellytysten kanssa.

Olen saanut eri tahoilta palautetta, joka viittaa siihen, että jälkimmäinen teema ei ole selkeästi argumentoitu ja olen samaa mieltä. Tästä syystä ajattelinkin, että edellinen merkintä ansaitsee jatko-osan. Maalaisjärjellä selitettynä ajatus on aivan selvä: Ei kannata ottaa käyttöön tuotetta joka on suunniteltu ratkaisemaan yksinkertaisempaa ongelmaa kuin mitä IAM-hankkeessa vaatimusten nojalla tulisi ratkaista. Niin ikään ei kannata alkaa ratkaista vaikeampaa ongelmaa jos vaatimusten ja analyysin mukaan näyttää, että vähempikin riittäisi. Jos hanke tekee eri asioita kuin se viestii ulospäin, hankkeen ympärillä oleva suunnittelu vaikeutuu.

Maalaisjärjessä on kuitenkin se ongelma, että se ei kovin usein toimi kaupallisten ja poliittisten voimien puristuksissa joita jokainen organisaatio ja hanke on pullollaan. Tästä syystä selitykseksi ei riitä edellinen argumentti vaan vaaditaan jotain määrämuotoisempaa ja konkreettisempaa.

Esitin Management Eventsin IAM-seminaarissa syyskuussa Crowne Plazassa erään ajatusmallin, joka voisi toimia konkretisoivana mallina ja haluaisinkin jatkaa keskustelua tämän mallin tiimoilta muiden ammattilaisten kanssa, joten tervetuloa kommentoimaan. Malli lähtee siitä, että pyrkisimme ymmärtämään IAM-hankkeen luomasta muutostilanteesta määrämuotoisesti seuraavan kuvan esittämiä suhteita.

Malli väittää seuraavia asioita:

1. Yrityskulttuurilla on vaikutussuhde organisaation tekemiin teknologiavalintoihin. Dynaaminen haastajayritys, joka haluaa olla edelläkävijä ja myös investoi tähän asemaan rahaa ja aikaa, valitsee todennäköisemmin teknologioita joilla on paljon potentiaalia vaikka kaikelle ei voisi laskeakkaan heti business casea. Edelläkävijäyrityksiä myös leimaa usein rohkeus tehdä päätöksiä perustuen enemmän intuitioon kuin tarkasti analysoituihin vaihtoehtoihin. Toisaalta taas yritys, jonka kulttuuri on henkeen ja vereen välttää kaikkia riskejä, tulee todennäköisesti tekemään teknologiavalintoja sen suhteen, mikä on aikaisemmin toiminut mutta ei välttämättä tue uusimpia mahdollisuuksia, etenkään niitä joita on vaikea argumentoida.
2. Teknologiavalinnat puolestaan vaikuttavat (triviaalisti) teknisiin rajoitteisiin, eli siihen, mitä ylipäätään on mahdollista. Jos esimerkiksi valitaan suljetun lähdekoodin tuote ilman laajennusmahdollisuuksia, on joko elettävä tämän tuotteen kanssa tai sitten vaihdettava koko tuote.
3. Tekniset rajoitteet ovat jotain, mitä pitää ajatella luonnonvakioina projektinäkökulmasta. Jos jokin asia ei ole käytettävissä olevien resurssien puitteissa mahdollista, se vain ei ole mahdollista. Organisaatiomuutoksen ja teknisten rajoitteiden välinen nuoli kuvaa tätä suhdetta. Muutokseen tähtäävä projekti ei voi luoda edellytyksiä organisaatiomuutokselle, jos jokin tekninen asia konkreettisesti estää muutoksen toteutumisen. Esimerkkinä tästä voidaan ottaa erään yrityksen hanke, missä yhdistettiin yritysostojen tuloksena syntynyttä toimintoryvästä. Tässä hankkeessa otettiin teemaksi toimitamallien yhtenäistäminen, joka oli tavoite numero yksi. Ei liene mitenkään yllättävää, että toimintamallien muutos osoittautui kalliiksi ja hankalaksi, siellä jokaisessa ostetussa yrityksessä käytettiin eri tavoilla toimivia ohjemistoratkaisuja liiketoimintojen pyörittämiseen. Jälkiviisaus tästä oli se, että hanketta ei kannata brändätä vain toimintamallien yhdistämiseksi jos kyseessä on oikeasti järjestelmien konsolidaatio ja käyttäjien uudelleenkoulutus.
4. Viimeinen nuoli mallissa (organisaatiomuutoksesta yrityskulttuuriin) puhuu tilanteesta, missä hanke on saatu valmiiksi ja organisaatiomuutos jalkautuu osaksi yrityskulttuuria. Tämä tapahtuu joka tapauksessa, ja onnellisesti päättyvissä tapauksissa tämä jalkautuminen on hallittu toimenpide. Huonosti muutosjohdetuissa tapauksissa tämä on kaoottinen luonnonvalinta joka ei ole kenenkään hallinnassa. Esimerkki jälkimmäisestä tapauksesta on erään toimijan SAP-migraatio, missä hanke saatiin maaliin maalin määritelmiä jatkuvasti muuttamalla ilman, että muutoksilla oli mitään vaikutuksia ymäristöön. Lopullinen jalkautuminen tapahtui, kun henkilöstö- ja asiakashallinnan prosessit muuttuivat joka päivä kallispalkkaisten konsulttien integroidessa kiireellä keskenään epäyhteensopivia järjestelmiä SAP-alustaan.

Tätä dynamiikkaa ymmärtämällä voidaan etukäteen pyrkiä hallitsemaan lopullista organisaatiomuutosta ja sen jalkautumista yrityskulttuuriin. Tyypillisellä IAM-hankkeella on etupäässä vaikutusmahdollisuuksia teknologiavalintoihin ja niiden aiheuttamiin teknisiin rajoitteisiin. Me Trusteqilla pyrimme siihen, että homma hoidetaan kunnolla loppuun asti ja teknisen työn ohella avustamme asiakkaitamme hallitsemaan tuotteiden luomien teknisten rajoitteiden ja mahdollisuuksien vaikutuksia organisaatioon ja sen muutokseen.

Tässä ensimmäisessä kirjoituksessa käyn läpi sitä, mitä roolitieto on ja mihin sitä käytetään, sekä miksi sen haltuunottoon lähdetään usein väärästä päästä, eli softatuotteen ostamisesta.

Käytännönläheisen tekijäfirman, kuten Trusteqin, kannalta asia on erittäin mielenkiintoinen, mutta minusta perusymmärryksen haltuunotto on suositeltavaa kaikille tietoturvasta kiinnostuneille, sillä kuten kaikki tiedämme, on olemassa oikeaa tietoturvaa ja sitten valitettavasti paljon valohoitoa, jolla ei välttämättä ole tietoturvan kanssa mitään tekemistä.

Niinikään minusta on hieman epämiellyttävä ajatus, että toistaiseksi yksikään roolienhallintaan käytettävän ohjelmistotuotteen edustaja ole juurikaan ymmärtänyt mistä olen heille puhunut kun avaan keskustelua roolitiedonhallinnasta. Tässä asiassa ostajan on helppo olla myyjää fiksumpi ja näin saada itselleen onnistunut hanke.

Tiedonhallintamielessä asia on minusta päivänselvä. Roolitietoa tarvitaan kaikissa organisaation osissa ja kaikkien organisaation osien olisi hyvä ymmärtää roolitieto samalla tavalla, oli sitten kyse ihmisistä tai tietojärjestelmästä. Mitä sitten tämä roolitieto on? No, kaikissa organisaatioissa esitetään jatkuvasti seuraavia kysymyksiä osana yrityksen jokapäivästä toimintaa:

• Kuka on kenenkin esimies?
• Mikä osasto on vastuussa mistäkin?
• Mikä on työntekijän A toimenkuva?
• Mihin järjestelmiin pitäisi A:n päästä toimenkuvansa puolesta?

Roolitieto siis toimii tienviittana, kun organisaatiossa jaetaan vastuita ja velvollisuuksia. Ja näiden vastuiden ja velvollisuuksien toisaalta pitäisi kohtuullisen tarkasti heijastella pääsyä tietojärjestelmiin, jotta voidaan puhua hallitusta ja turvallisesta järjestelmästä. Roolitieto kuvaa siis osaltaan sitä loogista rakennetta, mitä organisaatio on ja mitä sen sisällä tulisi tapahtua vastuumielessä kun jotain työtä tehdään.

Eli meillä on tietoa, joka toisaalta pitäisi ymmärtää samalla tavalla joka puolella organisaatiota ja joka toisaalta pistäisi olla jotenkin hallittu siten, että sekä liiketoiminta että IT-järjestelmät voisivat toimia yhteen tehokkaalla tavalla. Mitä tämä tieto siis tiedonhallinnallisesti on?  Tämä on se kysymys mihin roolienhallintasovellusten valmistajat minusta eivät ymmärrä vastata oikein. Aivan oikein, kysymys on organisaation master datasta. Keskimäärin kuitenkaan role management-hanke ei ole lähelläkään master data management-hanketta lähestymistavan, resursoinnin tai käytettyjen menetelmien kannalta katsottuna.

Olen myös synkkänä päivänä miettinyt, että voiko tämän melko itsestäänselvän havainnon sivuuttaminen olla tarkoitusellista? Jokainen master data- tai data management hankkeita läpikäynyt tietää, että kyseessä ei ole helppo homma. Ensimmäinen tapa mokata ko. hanke on ostaa softatuote, jonka sitten toivotaan ratkaisevan ongelman. Roolien hallinta, kuten data management yleensäkin, on lopulta hyvin prosessi- ja ajatusintensiivistä puuhaa johon toki tarvitaan työkaluja, mutta itse ongelma ei työkaluilla ratkea.

Jos ajatellaan vaikkapa tietoa joka on yleisesti hyväksytty master dataksi, huomataan miksi näin on. Valitaan esimerkiksi tuotedata, eli mitä tuotteita yritys myy ja mitä tietoa näihin liittyy (versioriippuvuudet, dokumentaatio, hinta, vastuullinen osasto jne). Uskooko joku, että on olemassa ohjelmistotuote, joka automaattisesti selvittää mitä tuotteita yritys valmistaa ja keräilee näistä kaiken niihin liittyvän tiedon? Ei varmasti. Toisin sanoen, tarvitaan ihmisiä muokkaamaan dataa informaatioksi, joka sitten syötetään tietojärjestelmään, joka toimii tuotetiedon master-järjestelmänä.

Tilanne ei muutu juuri mitenkään kun tuotetieto vaihdetaan roolitiedoksi. Edelleenkään softa ei sitä automaattisesti muodosta, vaan roolitiedon hallintahankkeeseen tarvitaan mukaan osaavia ihmisiä, jotka tutkimalla organisaatiota ja tallennettua tietoa selvittävät, mitä rooleja firmassa oikeasti on ja miten nämä parhaiten organisoidaan rooleiksi.

Toinen, jopa ehkä vahvempi argumentti sen puolesta, miksi roolienhallinta tulisi tehdä ennemmin tiedonhallintahankkeena on, että roolit muuttuvat organisaation muuttuessa ja niiden luonti, muutos ja poisto tulisi tehdä osana jotain ei-teknistä (esim. HR) prosessia ennemmin kuin IT-osaston toimesta. Loogisella tasolla tiedonhallinta on lähempänä business arkkitehtuuria kuin IT-arkkitehtuuria ja prosessien mallinnus on osa business arkkitehtuuria eikä niinkään IT-työ. Varsinaiset vastuut prosessien ja informaation mallintamisesta toki vaihtelevat yrityksittäin, joten tätä on vaikeampi perustella. Tärkeää kuitenkin on, että oikean alan osaajat tekevät työn ja prosessien pyörittämisen vastuu luovutetaan sinne, missä se parhaiten pystytään hoitamaan.

Loppuyhteenvetona: Roolitieto, eli mitä kenenkin on tarkoitus tehdä firmassa ja kuka kantaa vastuun, on minusta selvästi organisaation master dataa. Tästä syystä roolienhallintahankkeita, jotka usein ovat osana IAM-hanketta, tulisi suunnitella, johtaa ja toteuttaa tiedonhallintahankkeina. Kun roolitieto on muodostettu ja hallittu oikein organisaatiossa, IAM-hankkeessa on suhteellisen helppo muodostaa näistä pääsynvalvonnan kannalta merkityksellisiä järjestelmärooleja, jotka sitten edelleen myöntävät oikeuksia eri tietojärjestelmiin.

Seuraavassa kirjoituksessa ajattelin pureutua tarkemmin siihen, miten roolitiedon mallinnus sitten oikeastaan pitää sisällään. Jatketaan harjoituksia pian!

Vaikka esitetty vertaus ei pitäisikään sataprosenttisesti paikkaansa, kaikki jotka ovat olleet mukana käynnistämässä ja muotoilemassa keskivertoa suurempia IT-hankkeita voivat varmasti allekirjoittaa havainnon siitä, että organisaation rakenteen ja organisaatiossa työskentelevien ihmisten välisen dynamiikan ymmärtäminen on yksi hankkeen tärkeimpiä menestystekijöitä. Ihmisiä ei vaan voi sokeasti laittaa lokeroihin ja toivoa, että homma toimii. Muita tällaisia menestystekijöitä ovat luonnollisesti budjetin, kalenteriajan ja työn oikean rajauksen realistinen suhde ja johdon sitoutuminen hankkeeseen. Kirjoitetun tiedon määrä siitä, miten näiden ja muiden vastaavien muuttujien paineessa synnytetään hanke, joka onnistuu, on valtava.

En millään muotoa väheksy kirjatietoa ja jokaisella pitää olla perusymmärrys koulutuksen kautta työhönsä, mutta väitän, että meissä kaikissa on sisäänrakennettuna muutamia ominaisuuksia, joita emme saisi koulutuksemme ja kokemuksemme myötä unohtaa. Kun opiskelemme joko työn tai koulutuksen kautta jotain asiaa, vaikkapa projektin suunnittelua, käy usein niin, että näitä viimeisimpänä opittuja asioita aletaan preferoimaan toimintamalleina vain siksi, että ne ovat uusimpina ja tuoreimpina aivoissamme.

Kykyjä, joita olemme monesti saaneet jo lapsena hiekkalaatikolla usein väheksytään, sillä niitä ei voi kirjoittaa kovin eksaktisti CV:hen ja toisaalta monet C-luokan julkkikset ovat tehokkaasti mustamaalanneet näitä ominaisuuksia. Esimerkiksi eduskuntaan pyritään pitkästyttävän usein peruskoulun jälkeen (pahimmassa tapauksessa reality-tv:ssä) hankitulla “tunneälyllä, positiivisuudella ja ihmisläheisyydellä”.

Hienoimmat menestystarinat mitä olen asiakasorganisaatioissa nähnyt, on rakennettu yhdistämällä määrätietoisesti oikeaan tiimiin, oikeissa ihmisissä ja oikeassa suhteessa rooliin nähden, sekä näitä pehmeitä kykyjä, että toisaalta kovan luokan substanssiosaamista. Niinikään poikkeuksetta ison hankkeen osatavoitteiden saavuttamiseen ei riitä vain kommunikaation tai esimerkiksi tekniikan painottaminen.

Kirjapinon korkeus on oire tästä. Ihmismielen ja motivaation monimutkaisuutta yritetään sovittaa johonkin tiedetyillä muuttujilla ennustettavasti käyttäytyvään kehykseen, joka voidaan yksinkertaistaa lukijalle niin, että lukija kokee oppineensa jotain. Toisaalta taas koulutusinvestointi ei kanna oikeasti hedelmää sen jälkeen kun kirja on luettu tai kurssi käyty, vaan hyöty syntyy vasta siinä vaiheessa kun opittua päästään rauhassa soveltamaan oikeassa hankkeessa, ja tällä aikavälillä tieto jäsentyy ja osittain unohtuu ihmisen päässä. Tämä vaikuttaa siihen mitä valintoja jokapäiväisessä työssä preferoidaan.

Kaikki IAM-alueen ohjelmistotuotteet esimerkiksi toimivat aina jonkin kehysajatuksen mukaan. Jos tuotetta käytetään tätä ajatusta vastaan, tästä seuraa perustavaa laatua olevaa tehottomuutta. Tuotteet itsessään pyritään kouluttamaan niin, että niiden käyttäjät seuraisivat työssään tuotteen ajattelumallia. Tätä kuitenkaan harvoin sanotaan koulutuksessa ääneen, ja tämä johtaa siihen, että koulutetut asiantuntijat soveltavat tietämättään tuotteen toimintamallia IAM-hankkessaan ja levittävät sitä ympärilleen ainoana totuutena. Tämä malli on harvoin, jos koskaan, yksi yhteen sen kanssa, miten IAM-hankkeen ympärillä toimiva organisaatio toimii ja tuottaa tietoa. Jonkun täytyy siis muuttua, jotta tehottomuudelta vältytään ja homma saadaan pakettiin.

Organisaation toimintamallia pystytään muuttamaan, kunhan tämä muutos ymmärretään ja sitä osataan johtaa. Ymmärrys yksittäisen organisaation toiminnasta on puolestaan tyypillisesti jotain sellaista mitä opitaan etupäässä hiekkalaatikolla hankituilla pehmeillä kyvyillä ja pitämällä silmät ja korvat auki. On harvoin niin, että se henkilö, joka tuntee IAM-tuotteen ja sen ajattelumallin, on se henkilö joka on kovin kiinnostunut johtamaan organisaatiomuutosta (muuten kuin ehkä teknisestä näkökulmasta). Tämä varsin triviaali havainto selittää hyvin usein sen miksi IAM-hankkeissa monesti aletaan joko kustomoimaan identiteetinhallintatuotetta vastaamaan organisaatiota tavalla joka luo tehottomuutta tai vaihtoehtoisesti ei vaan yksinkertaisesti päästä mihinkään.

IAM-hanke on organisaation toiminnan muutos, etenkin jos identiteetinhallinta ja pääsynvalvonta ei ole ollut aikaisemmin kovin kypsällä tasolla. Tällä blogikirjoituksella haluaisin vaan muistuttaa, että sitä pitää johtaa sellaisena.