Sisältöön

Tiedonhallinnan riskien hallinta - SecMeter

Ohita valikko
Ohita valikko

Tiedonhallinnan riskien hallinta

Yritysturvallisuus > Riskienhallinta
Miten tiedonhallinnan riskejä hallitaan



Yrityksen tiedonhallinnan haasteet eivät ratkea lisäämällä teknologiaa, vaan lisäämällä ymmärrystä. Rakenteellisten syiden (juurisyiden) tunnistaminen edellyttää päätöslähtöistä, liiketoimintaan kytkeytyvää ja kokonaisuutta tarkastelevaa lähestymistapaa.

Ilman rakenteellisten syiden tunnistamista tiedonhallinnan kehittäminen jää väistämättä ilmentymien (oireiden) hallinnaksi. Kun ongelma määritellään oikein, ratkaisut ovat usein yksinkertaisempia kuin alun perin ajateltiin ja niiden vaikutus huomattavasti kestävämpi.

Yritykset, jotka ottavat rakenteellisen lähestymistavan osaksi tiedonhallinnan johtamista, siirtyvät reaktiivisesta korjaamisesta ennakoivaan kehittämiseen. Tämä siirtymä ei ole tekninen, vaan strateginen.

Yritykset, jotka kykenevät tekemään tämän näkyväksi, rakentavat tiedonhallinnasta kestävän liiketoimintakyvykkyyden, eivätkä vain kokoelmaa ratkaisuja.
Tarkistuslista tiedonhallintahankkeiden riskeille
Liiketoiminnan tarve ja päätöslähtöisyys

  1. Onko hankkeen käynnistävä liiketoiminnallinen ongelma kuvattu selkeästi ilman teknisiä ratkaisuja?
  2. Onko tunnistettu ne päätökset, joita hanke tukee?
  3. Onko määritelty, miten päätöksenteko paranee hankkeen seurauksena?
  4. Onko tunnistettu, mitä tapahtuu, jos tietoa ei saada tai se on virheellistä?
  5. Onko varmistettu, ettei hanke ole pelkkä reaktio yksittäiseen operatiiviseen oireeseen?

Ongelman määrittely ja rakenteellisten syiden tunnistaminen

  1. Onko nykytila analysoitu koko tiedon elinkaaren näkökulmasta?
  2. Onko erotettu selkeästi ilmentymät (oireet) ja mahdolliset rakenteelliset syyt (juurisyyt)?
  3. Onko tarkasteltu vaihtoehtoisia selityksiä ongelmalle?
  4. Onko analyysi tehty yhdessä liiketoiminnan ja tiedonhallinnan kanssa?
  5. Onko dokumentoitu, mitä ei vielä tiedetä?

Käsitteet ja määritelmät

  1. Onko keskeisille liiketoimintakäsitteille sovitut ja dokumentoidut määritelmät?
  2. Ymmärtävätkö eri yksiköt ja roolit käsitteet samalla tavalla?
  3. Onko tunnistettu kriittiset käsitteelliset ristiriidat?
  4. Onko päätetty, kuka vastaa käsitteiden ylläpidosta ja muutoksista?
  5. Onko varmistettu, että määritelmät ohjaavat myös teknistä toteutusta?

Omistajuus ja vastuut

  1. Onko nimetty liiketoimintalähtöinen omistaja keskeiselle tiedolle?
  2. Onko roolit ja vastuut erotettu selkeästi (omistaja, tuottaja, käyttäjä)?
  3. Onko päätetty, kuka hyväksyy muutokset tiedon rakenteeseen tai merkitykseen?
  4. Onko omistajuus dokumentoitu ja viestitty?
  5. Onko vastuu jatkuvaa, ei vain hankeaikaista?

Tiedon elinkaari ja laatu

  1. Onko tunnistettu, missä tieto syntyy ja millä oletuksilla?
  2. Onko dokumentoitu, miten tieto muuttuu eri vaiheissa?
  3. Onko kriittiset laadun riskikohdat tunnistettu?
  4. Onko päätetty, missä kohdassa laatu varmistetaan, ei vain raporteissa?
  5. Onko laadun mittarit sidottu liiketoiminnan tarpeisiin?

Teknologia ja arkkitehtuuri

  1. Tukeeko valittu teknologia tunnistettuja rakenteellisia syitä?
  2. Onko teknologia valittu vasta ongelman määrittelyn jälkeen?
  3. Onko ratkaisu suhteessa organisaation kyvykkyyksiin ja osaamiseen?
  4. Onko vältetty päällekkäisiä ratkaisuja ja turhaa monimutkaisuutta?
  5. Onko selkeä suunnitelma teknologian pitkäaikaiselle hallinnalle?

Ohjaus, priorisointi ja päätöksenteko

  1. Onko hankkeella selkeä omistaja ja ohjausmalli?
  2. Onko päätöksentekovastuut määritelty ja toimivia?
  3. Onko priorisointi sidottu liiketoimintavaikutuksiin, ei äänekkäimpiin tarpeisiin?
  4. Onko ristiriitatilanteisiin sovittu ratkaisutapa?
  5. Onko hanke linjassa tiedonhallinnan kokonaiskuvan kanssa?

Muutos, käyttöönotto ja jatkuvuus

  1. Onko huomioitu toimintamallien muutos, ei vain tekninen käyttöönotto?
  2. Onko käyttäjät osallistettu riittävän aikaisin?
  3. Onko osaamisen kehittämiselle suunnitelma?
  4. Onko määritelty, miten ratkaisu elää hankkeen jälkeen?
  5. Onko vastuu siirtymästä projektilta jatkuvaan toimintaan selkeä?

Arvon mittaaminen ja seuranta

  1. Onko määritelty, mitä arvoa hanke tuottaa ja kenelle?
  2. Onko mittarit sidottu päätöksentekoon tai toiminnan tehostumiseen?
  3. Onko sovittu, milloin ja miten vaikutuksia arvioidaan?
  4. Onko valmius muuttaa suuntaa, jos odotettu hyöty ei toteudu?
  5. Onko opit dokumentoitu seuraavia hankkeita varten?

Lopullinen itsearviointi

  1. Voidaanko perustella, että hanke ratkaisee tunnistetun rakenteellisen syyn, ei vain ilmentymän?
  2. Onko hanke ymmärrettävissä liiketoiminnan näkökulmasta ilman teknisiä termejä?
  3. Onko kokonaisuus yksinkertaisempi hankkeen jälkeen kuin ennen?
Rakenteelliset syyt ratkaisevat toimenpiteet
Yrityksen tiedonhallinta on harvoin liiketoiminnan strateginen painopiste silloin, kun se toimii. Asia nousee agendalle vasta, kun päätöksenteko hidastuu, raportteihin ei luoteta tai liiketoimintayksiköt tuottavat keskenään ristiriitaisia lukuja.

Näissä tilanteissa huomio kiinnittyy nopeasti näkyviin ilmentymiin ja niiden välittömään korjaamiseen. Samalla vaarana on, että todelliset rakenteelliset syyt jäävät tunnistamatta.

Tiedonhallinnan haasteet eivät yleensä ole yksittäisiä vikoja, vaan seurausta valinnoista ja toimintamalleista, joita on muodostunut ajan kuluessa. Kun yritys reagoi vain ilmentymiin, se rakentaa kerros kerrokselta monimutkaisempaa kokonaisuutta, jonka hallinta käy yhä vaikeammaksi. Kestävä tiedonhallinta edellyttää rakenteellisten syiden tunnistamista ennen ratkaisujen valintaa.

Ilmentymäpohjainen lähestymistapa johtaa paikalliseen optimointiin
Yrityksissä tiedonhallinnan ilmentymät näkyvät usein operatiivisina kipupisteinä. Raportit eivät valmistu ajoissa, analytiikka kuormittaa asiantuntijoita tai liiketoiminta käyttää merkittävän osan ajastaan lukujen täsmäyttämiseen. Näihin vastataan tyypillisesti paikallisilla ratkaisuilla, jotka kohdistuvat yksittäiseen prosessiin tai järjestelmään.

Paikallinen optimointi voi parantaa tilannetta hetkellisesti, mutta se harvoin korjaa kokonaisuutta. Usein ongelma siirtyy vain toiseen kohtaan tiedon elinkaaressa.

Ilman kokonaiskuvaa yritys investoi ratkaisuun, joka näyttää toimivan omassa kontekstissaan, mutta heikentää läpinäkyvyyttä ja hallittavuutta muualla.

Tiedonhallinnan rakenteelliset syyt ovat liiketoimintalähtöisiä
Yrityksen näkökulmasta tiedonhallinnan perimmäiset haasteet eivät useinkaan liity siihen, miten dataa tallennetaan, vaan siihen, miten sitä käytetään ja johdetaan. Tyypillisiä rakenteellisia syitä ovat epäselvät liiketoimintamääritelmät, puuttuva omistajuus sekä ristiriitaiset tavoitteet eri yksiköiden välillä.

Jos käsitteet, kuten asiakas, liikevaihto tai kannattavuus, ymmärretään eri tavoin, tekninen yhdenmukaistaminen ei tuo luotettavuutta. Samoin, jos dataa tuotetaan järjestelmiin ilman selkeää käyttötarkoitusta, sen laatu ja liiketoiminnallinen merkitys heikkenevät väistämättä.

Rakenteellisten syiden tunnistaminen edellyttää, että tiedonhallintaa tarkastellaan osana liiketoiminnan ohjausta, ei erillisenä IT-toimintona.

Rakenteellinen näkökulma tuo läpinäkyvyyttä
Yrityksen tiedonhallintaa on hyödyllistä tarkastella kokonaisuutena, jossa data kulkee lähteistä päätöksentekoon. Tällöin huomio kiinnittyy siihen, missä kohtaa tiedon merkitys hämärtyy tai vastuu katoaa.

Usein ongelmat syntyvät siirtymäkohdissa. Liiketoiminnan ja IT:n rajapinnassa, järjestelmävaihdoksissa tai organisaatiorajojen ylityksissä.

Rakenteellinen tarkastelu paljastaa, että monet ongelmat ovat toistuvia ja ennustettavia. Ne eivät ratkea yksittäisillä investoinneilla, vaan selkeyttämällä kokonaisuutta ja tekemällä näkyväksi ne periaatteet, joiden varaan tiedonhallinta rakentuu.

Viitekehys rakenteellisten syiden tunnistamiseen
Seuraava viitekehys tarjoaa käytännöllisen tavan tunnistaa tiedonhallinnan rakenteellisia syitä ennen ratkaisujen valintaa. Se on tarkoitettu johdon, liiketoiminnan ja tiedonhallinnan asiantuntijoiden yhteiseksi työkaluksi.

Päätöslähtöinen tarkastelu
Ensimmäinen askel on tunnistaa ne päätökset, joita data tukee. Raportit ja mittarit eivät ole itseisarvo, vaan väline päätöksentekoon. Ilman selkeää ymmärrystä päätöksistä tiedonhallinta ajautuu helposti tuottamaan dataa, jolla ei ole todellista käyttöä.

Keskeisiä kysymyksiä:

  1. Mihin dataa oikeasti tarvitaan?
  2. Mitkä ovat liiketoiminnan kriittisimmät päätökset?
  3. Mitä tietoa nämä päätökset edellyttävät?
  4. Mitä tapahtuu, jos tieto on virheellistä tai myöhässä?

Käsitteellinen selkeys
Seuraavaksi on varmistettava, että keskeiset liiketoimintakäsitteet ovat yksiselitteisiä ja yhteisesti ymmärrettyjä. Ilman tätä tekninen yhtenäistäminen ei tuo luotettavuutta.

Keskeisiä kysymyksiä:

  1. Onko keskeisille tiedoille yhteiset määritelmät?
  2. Ymmärtävätkö eri yksiköt käsitteet samalla tavalla?
  3. Missä kohtaa merkitykset alkavat eriytyä?

Omistajuus ja vastuu
Data on liiketoiminnan resurssi, jonka arvo edellyttää omistajuutta ja hallintaa. Jokaisella kriittisellä tiedolla tulee olla nimetty omistaja, joka vastaa sen merkityksestä, laadusta ja muutoksista.

Keskeisiä kysymyksiä:

  1. Kuka omistaa liiketoimintakäsitteen, ei vain järjestelmän?
  2. Kuka päättää muutoksista ja priorisoinnista?
  3. Missä kohtaa vastuu katoaa tai hajautuu?

Tiedon elinkaari
Rakenteellisten ongelmien tunnistaminen edellyttää ymmärrystä tiedon koko elinkaaresta. Ilmentymät syntyvät usein varhaisessa vaiheessa, mutta näkyvät vasta raportoinnissa.

Keskeisiä kysymyksiä:

  1. Missä tieto syntyy ja millä oletuksilla?
  2. Miten se muuttuu matkan varrella?
  3. Missä kohtaa laatu tai merkitys heikkenee?
  4. Mihin tieto päätyy?

Ohjaus ja priorisointi
Lopuksi on tarkasteltava, miten tiedonhallintaa johdetaan. Ilman selkeää ohjausmallia ratkaisut syntyvät hajautetusti ja reaktiivisesti.

Keskeisiä kysymyksiä:

  1. Kuka päättää tiedonhallinnan investoinneista?
  2. Millä perusteella priorisointi tehdään?
  3. Miten varmistetaan, että ratkaisut palvelevat kokonaisuutta?
Ohita valikko
Sääntö nro 1
Yritysturvallisuuden on palveltava toimintojen tavoitteita.
Sääntö nro 2
Valvontaa ei voi korvata luottamuksella.

Sääntö nro 3
Riittävän isolla vasaralla voi rikkoa mitä tahansa.

Sääntö nro 4
Jonkun pitää aina johtaa.


Sääntö nro 5
Delegoimalla ei voi välttää vastuuta.

Takaisin sisältöön