Digital Identity Solutions

Älä varo hyvin toteutettuja master data -projekteja!

2012-02-17T08:03:41Z

Master Data on saanut julkishallinnon hankkeissa suomennoksekseen ’ydintieto’. Kerrankin kuvaava ja ytimekäs käännös tietohallinnon käsitteistä. ’Master Data’ –termi ohjaa ajatukset ehkä liian helposti tietojärjestelmälähtöiselle polulle, vaikka kyse on ennemmin siitä miten yritys tai yhteisö kuvaa omien reaalimaailman toimintojensa virtuaalisia vastineita.

Ydintieto koostuu yrityksen liiketoimintaprosessejaan varten ylläpitämästä tiedosta. Tieto voi olla pysyväisluontoista, kuten organisaatio-, sijainti-, asiakas- ja henkilöstötiedot, tai sitten muuttuvaa, kuten tuotantoon, myyntiin tai ostoihin liittyvät tapahtumatiedot. Oleellista on, että ydintiedolle on määriteltävissä lähdejärjestelmä jossa tieto tuotetaan ja ylläpidetään, ja jolle voidaan määritellä vastuulliset omistajat. Omistajuus ja vastuu määräytyvät aina liiketoimintaprosessin, ei tietojärjestelmän, kautta.

Resurssinhallinta liittyy moneen liiketoimintaprosessiin, ja varsinkin henkilöstöresurssien hallinta on kriittisessä roolissa yrityksen liiketoiminnan kannalta. Henkilöstönhallinnan kannalta vastuu ydintiedosta on yksiselitteisesti määriteltävissä. Henkilöstötoimi vastaa siitä, että tiedot syötetään ja ylläpidetään henkilöstönhallinnan järjestelmiin. Henkilöstönhallinnan järjestelmien pääasiallinen tehtävä ei ole tuottaa henkilöstöraportteja sidosryhmille, vaan vastata siitä että ydintieto yrityksen arvokkaimmasta voimavarasta, työntekijöistä, on ajantasaista ja muiden liiketoimintaprosessien käytettävissä.

Työntekijöihin liittyvä ydintieto saattaa olla organisaatiorakenteesta riippuen hajallaan yrityksen eri yksiköissä ja eri järjestelmissä. Työntekijätiedon yksi oleellinen merkitys, eli tieto siitä mihin liiketoimintaprosessiin työtekijä oman tehtäväroolinsa kautta kuuluu, on kuitenkin melko yksinkertaista esittää tietojärjestelmissä. Roolitietoa voidaan helposti harmonisoida yli organisaatiorajojen sillä tasolla, että sen perusteella voidaan tehdä yleisellä tasolla johtopäätöksiä työntekijöiden omassa työtehtävässään suoriutumisen edellytyksistä.

Jos halutaan esimerkki onnistuneesta Master Data projektista, henkilöresurssien ydintiedoista on hyvä aloittaa. Kun henkilöstön ydintietojen laatu saadaan hallintaan ja prosessia voidaan tukea keskitetyllä tietojärjestelmällä, tuottavuutta voidaan lisätä monella eri tavalla:

Tehtäväroolissa tarvittavat työnteon edellytykset saadaan varmistettua ennen työsuhteen alkua
Liiketoimintaprosessit saavat tarvitsemansa tiedon käytettävissä olevista resursseista
Yrityksellä on selvä kuva resursseista ja niiden sijainnista
Työnteko tehostuu, kun tarvittavat välineet, tiedot ja oikeudet on käytettävissä tehtäväroolin mukaan
Työvälineiden käyttö tehostuu, kun vain tarvittavat välineet, tiedot ja oikeudet on käytettävissä kullakin tehtäväroolilla

Kirjoittanut Harri Heinonen 14.2.2012

Arkkitehti vai rakennusmestari – mistä portaalisi ponnistaa?

2011-03-22T13:24:10Z

Kun aletaan suunnittelemaan rakennusta, jolla pyritään sekä toiminnallisesti että ulkonäöllisesti laadukkaaseen ratkaisuun, hommaa tuskin annetaan naapurin rakennusmestarille. Arkkitehtuurin määritelmään Wikipedian mukaan taas kuuluu että: ”Arkkitehtuurissa täytyy aina huomioida monia keskenään ristiriitaisia näkökulmia – arkkitehtonista teosta suunniteltaessa arkkitehdin täytyy yhteistyössä erityissuunnittelijoiden kanssa löytää hyväksyttävissä oleva tasapaino ainakin toiminnalliselta, tekniseltä, taloudelliselta, esteettiseltä, juridiselta ja yhteiskunnalliselta kannalta”. Hyvin puhuttu. Ja Wikipedia vielä lisää että ”metaforana arkkitehtuurin voidaan ymmärtää käsittelevän minkä tahansa systeemin rakennetta”. Aivan ja niinhän sitä käytetäänkin myös ohjelmistojen ja järjestelmien osalla.

Vaan kuinka usein tuo yllä oleva määritelmä tasapainon löytämisestä keskenään ristiriitaisten näkökulmien osalla toteutuu? Mietitään organisaatioita ja ohjelmistoarkkitehtuurin suunnittelua. Ei liene kovin uskaliasta sanoa että paino nykyarkkitehdeillä on tuossa teknisessä puolessa. Talous toki on realiteetti jota ei voi jättää huomioimatta mutta toiminnallinen, juridinen ja (hieman soveltaen) toiminta- tai kilpailuympäristön ymmärtäminen saattaakin sitten olla jos huonommissa kantimissa. Yliarkkitehdin viittaa voidaan pukea myös CIOn harteille ja tuon viitan alle onkin vaatimuksia viime aikoina kasaantunut. Itse haaste lienee kuitenkin moniulotteisempi. Meiltä yksinkertaisesti puuttuu henkilöitä (ja mahdollisesti myös koulutus) joissa yhdistyisi määrittelyn mukainen arkkitehtoninen kokonaisosaaminen. Tai vaihtoehtoisesti kulttuuri jossa luotetut ulkoiset arkkitehdit yhdessä yrityksen oman osaamisen kanssa muodostavat suunnitteluryhmän ytimen koko rakennuksen elinkaaren ajalla. Toimintaympäristö järjestelmien ja arvoketjussa toimijoiden osalla muuttuu niin nopeasti että pelkkä perässä pysyminen on erittäin haasteellista. Tasapainosta voidaan siis suurelta osin vain uneksia. Uusilla portaaleilla pitäisi rakentaa liiketoimintaa, itsepalvelua ja monenmoista lisäarvoa sidosryhmille. Uudet organisaation ulkopuoliset toimijat pitäisi päästää prosesseihin ja samaan aikaan tietoturva käy entistä haasteellisemmaksi perinteisissäkin ympäristöissä. Puhumattakaan lainsäädännön ja tarkastuksen luomista paineista joihin vastaaminen on enemmän tai vähemmän pakollista.

Pyörittelimme yrityksemme lähipiirissä tätä samaa asiaan portaalien näkökulmasta ja haasteita tuntuu löytyvän aivan perusteista lähtien. Liiketoiminnallisilla portaaleilla, joissa sisällöllä ja sähköisillä palveluilla pyritään luomaan kassavirtaa on paljon mietittävää. Miten muuttaa maksuttomat palvelut maksulliseksi ilman että käyttäjät katoavat ja vievät vaivalla hankitut mainostulot mennessään? Tai miten ylipäätään rakentaa maksullisia palveluita, joiden hinnoittelumallit ovat riittävän ketteriä taipuakseen jaloillaan herkästi äänestävien asiakkaiden ajatusmaailmaan? Ja tämän kaiken pitää tuottaa käyttäjäkokemus joka tuo asiakkaan takaisin kerta toisensa jälkeen. Helppoa ratkaisua ei ole olemassa mutta periaatteessa monessa asiassa on kysymys käyttöoikeuksista ja niiden hallinnasta. Siitä miten monipuolisesti pystymme luomaan oikeuksia asiakkaan tarpeen mukaisesti. Jos hän kirjautumisen jälkeen haluaa ostaa yhdestä palvelusta dokumentin, toisesta 20 minuuttia käyttöaikaa ja kolmannesta muuttaa profiilinsa itsepalveluksi saaden samalla kuukausimaksusta 2,5 % alennuksen mutta sisällöstä 10 %? Tai miten palkita asiakkaita jokaisesta kerrasta kun he ovat käyttäytyneet prosesseissa haluamallamme tavalla. Kehittynyt oikeuksien hallinta ratkaisee paljon mutta sekään ei ilman kehittynyttä masterdatan hallintaa pitkälle johda.

Täysin saman tyyppisiin ongelmiin tärmäämme prosessilähtöisissä portaaleissa joissa kassavirran rakentaminen on pienemmällä painoarvolla. Sen sijaan pyritään prosessien kehittämiseen, läpimenoaikojen lyhentämiseen ja vaikka asiakastyytyväisyyden parantamiseen. Hyvin usein on kysymys itsepalvelusta; jonkin toiminnon siirtämisestä kumppanin tai asiakkaan hoidettavaksi. Mitä syvemmälle omiin toimintaprosesseihin mennään sen haastellisemmaksi tulee asioiden hallinta. Täydellisessä maailmassa voisimme suunnitella arvoketjun vapaasti ja jakaa toiminto toiminnolta tehtävät sille kenelle ne parhaiten sopivat. Sitten täytyy rakentaa motivaatiota ja seurantaa jotta näemme miten asiat kehittyvät. Aktiivisille toimijoille jaetaan palkintoja ja heistä rakennetaan profiileja joilla markkinointia voidaan kohdentaa. Asiakastieto rikastuu portaalien kautta ja identiteettien hyödyntäminen lähestyy maailmaa jossa asiakkuuden hallinta onkin jotain muuta kuin pelkkä akronyymi.

Talon rakentaminen alkaa perustuksista ja aivan samaan tapaan joudumme siis rakentamaan portaalien arkkitehtuurille vahvan perustan jotta saamme kaiken toimimaan. Tämä on investointi identiteettien ja masterdatan haltuunottoon. Meidän tulee syvällisesti ymmärtää miten liiketoiminnaliset vaatimukset ajavat identiteettien ja masterdatan rakennetta nyt ja tulevaisuudessa - oli sitten kysymyksessä palveluiden, sisällön tai tiedon luokitteluun liittyvä masterdata. Samalla kun olemme rakentamassa monimutkaista mallia kaiken ratkaisemiseksi on syytä ymmärtää ettei kaikkea voi tehdä kerralla. Aivan kuten nykyaikaisissa rakennushankkeissa on tässäkin syytä edetä siten että suljemme matkan varrella pois mahdollisimman vähän muuntelumahdollisuuksia. Suunnittelemme älykkään rakenteen jossa yksityiskohdat pystytään ratkaisemaan vasta siinä vaiheessa kun ne ovat käsillä. Vaihdamme sujuvasti perspektiiviä sammakosta helikopteriin ilman hankkeen pysäyttämistä. Ja lopulta etenemme vaiheittaiseen käyttöönottoon, ensivaihe on valmis ja lisätarpeet tyydytetään jatkoprojekteilla. Näitä eivät rakennusmestarit suunnittele – siihen tarvitaan arkkitehtiä.

Ovatko kunnat identiteetinhallinnan kriisissä?

2011-02-09T08:20:13Z

Kuntien haasteet identiteetinhallinnassa alkavat konkretisoitua lähitulevaisuudessa eri suunnista tulevien paineiden siivittämänä. Haasteita ollaan ratkaisemassa monien eri tahojen ja yhteenliittymien kautta. Ja välillä ihan ominkin voimin. Yhteistä näille ilmeisesti on ettei erityisen valmiita ja pitkälle mietittyjä ratkaisumalleja ole toistaiseksi syntynyt. Haasteista sentään ollaan melko tavalla yhtä mieltä vaikka niitä ei tärkeysjärjestykseen saataisikaan. Kuntien haasteet tuntuvat konkretisoituvan lähinnä osaamiseen, hankkeiden pelättyihin kustannuksiin, omiin henkilöresursseihin ja aikatauluihin. Keskustelu ratkaisujen osalla tuntuu taas olevan hyvin järjestelmälähtöistä ja asian toivotaan ratkeavan kun käyttövaltuuksien operointi saadaan automatisoitua. Tehokkaasti kilpailutettuna.

Jos asiaa mietitään keskikokoisen kunnan näkökulmasta, ottaen aluksi huomioon pelkästään sisäiset käyttäjät, niin jotain seuraavan kaltaista voisi pinnan alta löytyä. Keskikokoisessa kunnassa voidaan arvioida olevan vajaat puolentuhatta sisäisiin käyttöoikeuksiin liittyvää tapahtumaa vuodessa (uudet työntekijät, poistuvat, muutokset jne.). Periaatteessa tapahtumia siis riittäisi reilut pari vuoden jokaiselle työpäivälle. Järjestelmiä toki voi pahimmillaan olla jopa muutama sata mutta noista vain pieni osa on yleisemmässä käytössä. Onko automaatio siis oikea tapa ratkaista ensivaiheen ongelmia vai pitäisikö roadmappi rakentaa toisesta suunnasta? Raskasta integraatiota ei kuitenkaan kovin useisiin järjestelmiin kannata käydä rakentamaan.

Joillakin kuntien toimialoilla käytetään paljon ulkopuolista työvoimaa ja tyypillistä näille virkamiehiin verrattuna on nopeampi vaihtuvuus. Käyttövaltuushallinnan tapahtumia on siis suhteessa enemmän vaikka ne olisivatkin yksinkertaisempia. Vaatimukset läpimenoaikojen osalla saattavat olla haasteellisia. Esimerkiksi sijaislääkärin henkilöllisyys saattaa selvitä vasta kun henkilö marssii sisään terveyskeskukseen. Ulkoisen käytön osalta, eli kuntalaisten ja omana ryhmänään oppilaiden osalta tulee haasteita jo prosessin kokokin huomioiden. Tämä näkökulma vahvistuu tulevaisuudessa kun vaatimukset kuntalaisten sähköisten palveluiden suhteen kehittyvät. Oppilaiden osalla pääosa tapahtumista kohdistuu muutamaan ajankohtaan ja voidaan hyvin ratkaista myös ilman suurempaa automaatiota mutta prosessia sekä roolinhallintaa pitänee kuitenkin miettiä. Automaatio on siis varmasti jatkossa yksi osa ratkaisua mutta onko se kaikissa käyttötapauksissa tai kunnissa edes kustannustehokas vaihtoehto, sitä sopii epäillä.

Pienten ja keskisuurten kuntien haasteiden ratkaisemisessa ei voi jäädä miettimään vanhojen kaavojen mukaisia järjestelmäratkaisuja vaan on ajateltava laatikon ulkopuollella. Tässä vaaditaan uusia ajatuksia mutta yhtä kaikki maalaisjärkeä jolla ratkaisut toteutetaan. Ongelma usein on että pienemmillä kunnilla itsellään ei ole osaamista jossa yhdistyisi sekä tietojärjestelmät, toimialojen ja niiden prosessien sekä kunnan strategisen kehittämisen taso. Mutta mitä sieltä laatikon ulkopuolelta sitten voisi löytyä? Voisivatko kunnat esimerkiksi vaatia toimittajiltaan että he järjestävät käyttöoikeuksien hallinnan väliaikaisen henkilöstön osalla? Lieneekö tuo vain yksi lisävaatimus kilpailutuksissa? Tai voisiko Väestörekisterikeskus tuoda lisäarvoa ulkoisten käyttäjien osalla sillä kuntalaisten masterdata heillä on jo hallussaan? Pakataan se palveluksi tunnistamisen kanssa ja myydään eteenpäin. Erilaisia ratkaisuja löytynee ja edelleen epäillä jaksan ettei suuressa osassa tapauksia pelkkä kilpailuttamisen tehostaminen asioita helpota. Ratkaisuja täytyisi etsiä ihan jostain muulta.

Vaaranpaikkoja identiteetinhallinnan kehittämisessä

2011-02-01T13:43:57Z

Viime vuoden aikana keskusteluissa tietohallintojohdon kanssa on noussut usein esille identiteetinhallinnan kehittämiseen liittyvät uhkat ja niiden mitigointi. Varsin usein IDM kehityshankkeisiin liittyvät pelot olivat lähtöisin viidakkorumpujen kertomista epäonnistuneista IDM projekteista; nämä projektit ovat olleet merkittävästi myöhässä tai budjetti oli moninkertaisesti ylittynyt – ja IDM ratkaisulle asetetut tavoitteet ovat jääneet pääosin saavuttamatta. Yhdenkään tietohallintojohtajan ei ole helppoa mennä pieleen menneen projektin jälkeen johtoryhmän eteen pyytämään lisää rahaa kehityshankkeen seuraaviin vaiheisiin.

Täytyy sanoa, että hävettää kuinka usein erityisesti suuret kansainväliset IT-palvelutalot ovat epäonnistuneet näissä projekteissa uudestaan ja uudestaan. Onko niin, että myyntijoukot ovat olleet myymässä jotain, mitä he eivät voi toimittaa tai ovatko asiakkaat olleet ostamassa jotain mitä he eivät yksinkertaisesti ymmärrä vai ovatko molemmat yhtä ymmällä IDM kehittämisen osalta? Toiveissa olisi, että IDM järjestelmiä myyvät ja ostavat tahot pyrkisivät varmistamaan paremmin onnistumisen edellytykset ja kummankin osapuolen valmiudet edetä. En usko, että kukaan on erityisen halukas kuulemaan enempää epäonnistuneista IDM projekteista. Ne kaivavat maata jalkojen alta myös niiltä toimittajilta ja asiakkailta, jotka osaavat ja ymmärtävät miten edetä.

Ymmärrys IDM alueella on kaikki kaikessa. Samalla tulee ymmärtää, että kun käyttövaltuushallinnan kehityshankkeet koostuvat liiketoiminnan, hyvän hallinnointitavan, tietoturvapolitiikan, prosessien, masterdatan, arkkitehtuurien, teknologioiden ja useiden muiden vaatimusten kokonaisuudesta niin eteneminen ei ole aina kovin suoraviivaista. Alkuun hommassa pitää ottaa kokonaisvaltainen ote ja lähestymiskulma, jossa edellä mainitut osa-alueet tulisi huomioida. Alkuun aina analysoiden missä olemme, mitä haluamme ja kuinka etenemme. Tuon paketin kanssa, ja vertaillen sitä parhaisiin käytäntöihin, voimme kenties asettaa enemmän realistiset tavoitteet ja laskea systemaattisemmin business casen IDM kehityshankkeelle. Samalla pystymme paremmin arvioimaan meille soveltuvia IDM toimittajia ja teknologioita.

Yksi asiakkaan kardinaalivirhe on jättää IDM -järjestelmälle asetettujen avainvaatimusten todentaminen tekemättä (proof-of-concept, POC) ennen hankintapäätöksen tekemistä. Se tulisi tehdä sekä teknologian soveltuvuuden että toimittajan toimituskyvyn ja ymmärryksen osalta. Olen itse useita kertoja törmännyt tilanteeseen, jossa ykköseksi rankattu toimittaja ei ole selviytynyt POC -vaiheesta mitenkään hyväksyttäväksi ja kakkosvaihtoehto on osoittautunut merkittävästi paremmaksi, vaikka tarjouksessa ja tarjouspyynnön vastauksissa kaikki on näyttänyt toisinpäin erityisen hyvältä. IDM ratkaisun todellisuus tulee siksi varmistaa ja POC tulisi tehdä aina kahdelle toimittajalle ennen minkäänlaista sopimusta jatkosta. Ratkaisuehdotus paperilla demon kera yksinkertaisesti ei yksin riitä. POC on vakuutuksesi ja voi pelastaa identiteetinhallinnan kehityshankkeesi.

IDM toteutusprojektien riskilista on pitkä, mutta se ei koske vain toimittajia. Asiakasorganisaatiossa tulee asettaa täydessä laajuudessa myös sisäinen projekti, jolla on enemmän tai vähemmän täysipäiväinen projektipäällikkö. Mikäli asiakasorganisaation oma osaaminen käyttövaltuushallinnan saralla ei ole riittävä, mikä tyypillisesti on tilanne, niin kannattaa käyttää osaavaa ulkopuolista IDM -asiantuntijaa tukemaan sisäistä projektia ja samalla varmistamaan, että toimittajaprojekteissa tehdään oikeita asioita oikeaan suuntaan. Sisäisessä projektissa tulisi varmistaa myös hyvissä ajoin tarvittavat henkilöt määritysten katselmointiin sekä erityisesti hyväksymistestaukseen, roolien täsmäytykseen, pilotointiin ja rollout –vaiheeseen. Lisäksi prosessimuutokset koskien HR- ja CRM -toiminnallisuutta, tietoteknistä infrastruktuuria, tukipalveluita ja palveluhallintaa vaativat omat osaavat resurssinsa. Tämän kaiken kasassa pitäminen vaatii hyvää koordinointia, kommunikaatiota ja henkilöstön koulutusta.

Välillä ongelman aiheuttaa se, että IDM ei ole yksin IDM. Identiteetinhallinnan järjestelmä integroidaan tyypillisesti useisiin järjestelmiin sekä prosesseihin ja arkkitehtuurissa on yleensä mukana myös pääsynhallinnan sekä tietoturvainformaation hallinnan elementtejä. Varsin usein asiakasorganisaatiossa on käynnissä samaan aikaan muitakin järjestelmä- tai prosessien kehitysprojekteja, joilla ovat riippuvuussuhde IDM -projektiin. Nämä liikkuvat hevoset aiheuttavat itsessään riskejä IDM -kehityshankkeelle ja jouduttaessa kriittisellä polulla niin IDM -projektiin riippuvuussuhteessa olevan kehitysprojektin aikataulun pettäminen voi pahimmillaan viivyttää IDM -projektin etenemistä merkittävästi.

Tärkeä huomioitava asia IDM -kehityshankkeissa on, että identiteetinhallinta ja sen käyttöönotto tuovat viimeistään näkyville ne puutteet jotka asiakasorganisaatiossa on masterdatassa ja sen hallinnassa. Mikäli masterdatan hallinnan prosessit eivät ole riittävän reaaliaikaisia ja vakiintuneita, eikä tiedon puhdistamisen metodiikka ole kunnossa, organisaatio tulee kohtaamaan IDM -järjestelmän käyttöönotossa ja käytössä ongelmia. Olisi parempi investoida masterdataan ja sen hallinnan kehittämiseen etukäteen, mutta viimeistään kun identiteetinhallinnan kehityshanke on käynnistymässä.

Ymmärrys on käyttövaltuushallinnan kehittämisessä kaikki kaikessa. Kannattaa panostaa kokonaisuuden ymmärtämiseen ja nostaa valmiudet onnistumiselle kohdalleen - ja edetä systemaattisesti. Me kaipaamme enemmän onnellisia IDM -tarinoita.

Pitfalls in Identity Management Development

2011-02-01T12:24:23Z

I’ve had many discussions with CIOs within last year concerning identity management (IDM) project nightmares and how to avoid them. Fears are mostly generated from the fact that there have been too many unsuccessful IDM projects in the market; either project schedule or budget is doubled, even tripled - and still the delivered IDM solutions are only partly fulfilling the customer’s need. It’s not easy for a CIO to show a ruined business case to board members and ask more money in order to implement next steps of the IDM program.

It’s shame to see even global IT companies that were doing it time and again. Is it so that sales and pre-sales guys were just selling something they were not really able to implement or are customers buying something they didn’t understand? Or were they both just lost in the IDM reality? Please, don’t sell or buy IDM projects if you really don’t know the laws of the nature in IDM. We prefer not to have any more unsuccessful stories in this area.

Understanding is everything, also when it comes to IDM. But because IDM development program consists of business, governance, policy, process, master data, architecture, technology and many other required areas of knowledge it is not simple to implement. First we need to have a holistic approach. All issues mentioned above should be covered when analyzing where we are, what we are aiming towards and how we’re going to get there. Based on such information package and benchmarking we are able to set realistic expectations and develop a business case for the IDM program. Also, we will be able to evaluate more systematically possible IDM vendors and technologies.

One big mistake organizations can do is missing a proof of concept (POC) phase in the IDM system acquisition process of evaluating IDM technology vendors and integrators. It is essential to get proof of major IDM requirements and functionality - and also vendors’ ability to implement the required features. I’ve seen several times when vendor that is ranked first will not complete POC at an acceptable level. Do the reality check. It will at times save your IDM program. Also, do it for two vendors before making any decision about technology and integrator.

IDM implementation projects have long list of risks, but it’s not only vendor related. There is much work to be done by customer organization and there should be a full-scale internal project established, having a more or less full-time project manager. In case identity management is not your company’s core competence or your maturity level is high, please use a competent external IDM advisor to support your project. Also you should allocate enough internal resources for specification reviews, but especially for acceptance testing, role mining, piloting and rollout – and for process change management including HR, CRM, IT infrastructure, support and service management areas. All this cannot be done without good coordination and training.

Sometimes problem is also that IDM is not only IDM. Identity management system has many interfaces to other processes and systems by it’s nature, including also access management and security information management. Quite often there is also going on same time other projects concerning those systems or processes having interfaces to IDM system and it can cause dependency risk for the IDM program.

IDM will also show us master data information that is missing or inaccurate. In case you don’t have stabilized and real-time processes for master data management and data cleanup processes in place you could be in trouble. It is better to invest in master data management in advance or at least when starting the first part of your IDM program. Otherwise all of those problems will be faced in the production phase and business may suffer.

Understanding is everything. Please, analyze areas around IDM systematically and don’t rush into pitfalls. We prefer to see successful IDM stories instead.

Identiteettivarkaudet - suojaa vai sanktioita?

2010-12-28T12:27:11Z

Mediassa identiteettivarkaudet mielletään usein yksityishenkilöiden ongelmaksi ja neuvoja niiden välttämiseksi tarjotaan paljon. Kuitenkin juuri yrityksiin kohdistuvat henkilötietovarkaudet ovat viime vuosina lisääntyneet huomattavasti. Niistä koituvat menetykset voivat suoraan taloudellisesti sekä yrityskuvan kannalta olla merkittäviä. Vaikka kohu identiteettivarkauksista oli enemmän pinnalla pari vuotta sitten, niin tilastojen mukaan hyökkäykset yrityksiä vastaan ovat vain lisääntyneet ja rikollisuus on entistä järjestäytyneempää. Kohun laimenemisesta voisi päätellä että ongelma onkin jokapäiväistynyt. Tämän ja henkilötietovarkauksiin sovellettavien uusien menetelmien luulisi kuitenkin huolestuttavan erityisesti organisaatioiden tietohallintojohtoa.

Pitkään on elänyt käsitys, että henkilötietojen salaaminen antaa parhaan suojan identiteettivarkauksia vastaan. Usein tämä ei ole kenenkään edun mukaista vaan yrityksissä on oltava toimivat menetelmät henkilötietojen käytön hallintaan, seurantaan ja oikeellisuuden varmistamiseen. Identiteettien jyrkän salaamisen sijaan siis keskitytään käyttövaltuuksien tehokkaaseen hallintaan. Jos identiteetinhallinnan prosessissa tai tietoturvassa ilmenee aukkoja, on yrityksen luotettavuus kuluttajien ja yhteistyökumppaneiden näkökulmasta kyseenalainen. Mikäli organisaatioita ei saada vastaamaan henkilötietojen riittävästä tietoturvasta ja hallinnoinnista niin mitä vaihtoehtoja jää? Voisiko tieto lähtökohtaisesti olla avointa? Identiteettien avoimuutta perustellaan joskus esimerkiksi yhteiskunnan turvallisuuden näkökulmasta; avoimia identiteettejä kun on helpompi valvoa. Niin tai näin mutta nuorempi sukupolvi suhtautuu mm. nettikäyttäytymisessään yksityisyyteen ja identiteettiin aivan eri tavalla kun nyt vallassa olevat sukupolvet, joille henkilötietojen salaaminen on aina ollut lähtökohta.

Avoimet identiteetit, syystä tai toisesta, ovat edelleen lähinnä spekulointien kohde ja henkilötietojen käsittelyssä on organisaatioiden pyrittävä tinkimättömään tietoturvaan. Edellisen todistaa oivasti myös Wikileaks. On yksityishenkilöiden vastuulla hallita omia henkilökohtaisia tietojaan ja huolehtia mihin ne päätyvät, mutta on ensisijaisesti henkilötietoja keräävien organisaatioiden tehtävänä rakentaa niin teknologian kuin prosessienkin suhteen pitävät keinot tietojen säilymiseksi niiden oikeissa käyttötarkoituksissa. Euroopan komissio on tehnyt ehdotuksen identiteettivarkauksien muuttamisesta rikokseksi vuonna 2012, mikä voi osaltaan vauhdittaa samanlaisen lakimuutoksen toteutumista Suomessa, tuoden suomalaisille yksityishenkilöille ja yrityksille vahvempaa lain tukea taistelussa identiteettivarkauksia vastaan.

Standing out with DISE

2010-11-30T11:20:24Z

Venturing into something new is both motivating and rewarding. A special kind of reward spring up when creating tangible value to all stakeholders; customers, partners and your own organization. Technology and innovation are enablers for great success stories but people and knowledge really make the difference. This is the backbone of Digital Identity Solutions Europe Ltd - DISE. Our aim is to combine common sense objectivity and customer centric approach when developing IdM. We feel that it is essential to recognize specific business needs and requirements and then build practical IdM roadmap that supports operations. That is ultimately what we at DISE strive for; the biggest possible value from IdM investments, leaving unnecessary costs out of the equation. This, and only this is DISE.

Identity management is a solution area that is lacking profound expertise in most of the organizations. That was one of the conclusions in our IdM study from past summer. Close to a hundred representatives from different organizations participated in a survey regarding IdM maturity development in Finland. According to many of the respondents, IdM investments are still made at a basic level and only small minority is yet to be ready in order to start building the way up. However, the importance of IdM is surprisingly high and IdM was on a shortlist of major IT investments in majority of the organizations. In addition, it is commonly believed that help from external consultants is necessary to successfully carry out projects. What was also interesting is that companies are generally not satisfied with their current partners. This will actually make the professional services market quite challenging for the customers and one of the main success factors in IdM projects will be to find the right partners with proper competence.

Our goal is to bring leading knowledge to the reach of all organizations and provide continuous support during IdM development. Investing in IdM is always a big decision but we are determined to guide our client organizations through the projects. Please find detailed information on our products and services on the website and feel free to send us feedback, as we are working on adding more content and features. And of course, we are excited to hear about your current or future IdM projects. Challenge us – that’s what we are here for.

DISE - uuden edessä

2010-11-30T11:18:36Z

Uuden asian aloittaminen työelämässä on aina motivoivaa ja usein myös palkitsevaa. Erityisen palkitsevaa se on silloin kun pystyy luomaan jotain jolla on samanaikaisesti aitoa arvoa itselle, asiakkaille sekä kumppaneille. Teknologia ja innovaatiot ovat mahdollistajia, ihmiset ja osaaminen se alkuvoima jolla kaikki saadaan toimimaan arvon luomiseksi. Tälle perustalle olemme rakentaneet DISEn. DISE yhdistää uudella tavalla asiakaslähtöisyyden ja kehittämisen. Kokemuksemme ja osaamisemme kiteytyvät lähestymistavassa jossa kaikki turha on riisuttu pois ja vain olennainen saa huomion. Asiakkaan kehitysresursseihin ja - potentiaaliin oikein mitoitetut osaprojektit takaavat onnistuneet hankkeet ilman turhia kustannuksia. Näin asiakkaamme saavat parhaan hyödyn tekemistään identiteetin hallinnan kehitysinvestoinneista.

Identiteetin hallinta on alue jota ei organisaatioissa vielä erityisen syvällisesti tunneta. Tätä johtopäätöstä tukee viime kesänä tekemämme selvitys jossa kysyimme lähes sadalta organisaatiolta IdM-alueen kehittämisestä. Tehdyt investoinnit ovat edelleen valtaosin perustason ratkaisuja ja tulevissakin fokus on perustan rakentamisessa. Vain alla kymmenes organisaatioista on siirtymässä kyspsyytasolla ylöspäin. Mielenkiintoista vastauksissa oli se että identiteetinhallinnan ratkaisut ovat kuitenkin erittäin korkealla kehityslistoilla ja ne koetaan tärkeiksi. Samalla oma osaaminen koettiin riittämättömäksi eli osaavia yhteistyökumppaneita tarvitaan jatkossa yhä enemmän. Hieman ongelmalliseksi asian tekee se että tyytymättömyys olemassa oleviin yhteistyökumppaneihin ja ratkaisuihin oli suhteellisen korkealla tasolla. Uutta verta ja osaamista siis kaivataan. Ikävä totuus kapealla sektorilla on se että relevanttia osaamista ei kaikkiin hankkeisiin tule riittämään. Hyvien yhteistyökumppaneiden löytäminen tuleekin jatkossa olemaan yksi kehityshankkeiden keskeinen menestystekijä.

Näistä lähtökohdista tuomme jatkossa oman panoksemme identiteetin hallinnan kehittämiseen yhä vahvemmin. Identiteetin hallinta on jokaisen arkkitehtuurin perusinvestointeja, jonka merkitys tulevaisuudessa vain kasvaa. Fokus kehittämisessä tulee kääntymään entistä enemmän liiketoiminnan tukemiseen ja IdM ratkaisualueen rooli mahdollistajana tulee korostumaan. Samaan aikaan kun peräänkuulutetaan tiedon läpinäkyvyyttä organisaatioiden sisällä on tietoturva merkitys edelleen kasvamassa. Turvallinen läpinäkyvyys liiketoimintaprosessien optimaalisen toimivuuden edellyttämällä tasolla on tässä ympäristössä iso haaste mutta ei mahdottomuus.

Toivon että tutustutte sivuillamme löytyvään informaatioon. Tulemme lisäämään sitä jatkossa aktiivisesti ja kaikki palaute sivustoomme liittyen on tervetullutta. Tänne pystymme kuitenkin tallentamaan vain pienen osan kokonaisuudesta eli kun haluat tietää enemmän niin ole yhteydessä. Tulemme mielellämme kuulemaan hankkeistanne ja tarjoamaan apuamme niiden ratkaisussa.