Hallinnoiko tietohallinto tietoa?

En ole nähnyt virallista tutkimusta siitä, kuinka moni ihminen mieltää datan välittömästi osaksi tietotekniikkaa, mutta väittäisin hyvin monen tekevän niin. Tämä on heijastunut yritysmaailmassa siten, että data, sen hallinnoiminen ja kehittäminen, on pitkään nähty yhtenä tietohallinnon osa-alueena.

Jo PDM-Saarnasmies Salovaaran viimekertaisessa data-aiheisessa artikkelissa todettiin, ettei käsite nimeltä data voi kokonaisuudessaan olla yhden osaston vastuulla.

Sanasta miestä

Termi ”data” tarkoittaa itse asiassa hyvin montaa asiaa ja termin määrittely on lievästi sanottuna moniulotteinen. Omakohtaisen kokemukseni mukaan on kuitenkin olemassa kirjoittamaton sääntö, että datalla tarkoitetaan jotain sähköisessä muodossa olevaa tallennetta/ syötettä ja hyvin usein puhutaan datasta, vaikka kyse on informaatiosta tai tiedosta. Näistä on tullut puhekielessä toistensa synonyymeja. Tässä mielessä tietohallinnon roolina on tarjota riittävät työkalut ja prosessit datan/informaation taltiointiin, varmistamiseen ja tietomassojen hallintaan teknisellä tasolla, niinkuin englanninkielinen termi Information TECHNOLOGY antaa ymmärtää.

Itse datan sisältö, sen oikeellisuus ja riittävyys kuuluu koko organisaation vastuulle. Siis aina sillä, joka dataa järjestelmään luo. HR-järjestelmään uuden työntekijän tiedot syöttävä HR-koordinaattori/-päällikkö/-assistentti/-asiantuntija/-guru on vastuussa tietojen oikeellisuudesta. IT:llä on luonnollisesti (tai siis optimimaailmassa) työkalut, joiden avulla HR-järjestelmään syötettyjen tietojen perusteella provisioidaan uudelle työntekijälle kaikki tarvittava automaattisesti sähköpostiosoitteesta SAP-käyttäjätiliin. Tietohallinto ei päätä sisällöstä.

Tieto rakentuu informaatiosta, joka taasen rakentuu datasta.

Datasta rakentuva informaatio on ensisijaisesti johtamisen ja päätöksenteon työkalu, siksi sen laadukkuuden olettaisi kiinnostavan yritysten johtoa. Seuraava tiedon laatuvirheiden vaikutuksia havainnollistava esimerkki on poimittu suoraan Tietokone-lehden 5/2012 artikkelista ”Yritystä johdetaan tiedolla”:

Konepajayritys saa tilauksen harvoin toimitettavasta vakiotuotteesta. Sen kallein osa, Diesel-moottori, tilattiin kokoonpanoa varten alihankintakumppanilta. Moottorin saapuessa huomattiin varastossa pölyyntynyt laatikko, jossa oli vastaava moottori, joka oli jäänyt yli vastaavanlaisesta isosta toimituksesta. Virhe johtui nimikkeen löytymisestä järjestelmästä kahdella eri koodilla, jonka vuoksi todellista varastotilannetta ei nähty. Kun valmis tuote lähetettiin tilaajalle naapurimaahan, se juuttui viikoiksi kuljetusliikkeen välivarastoihin. Konepaja joutui maksamaan viivästyssakkoja myöhästyneestä toimituksesta. Virheen syy: Asiakkaan tiedoissa oli väärä postinumero.

Tarina ei kerro, onko esimerkki tosi vai ei, mutta opetus on relevantti: kate pieneni, toimitusvarmuus heikkeni ja tuskin asiakastyytyväisyyskään kamalasti parani. Siis vain siksi, koska datassa oli virheitä tai sitä ei ollut olemassa. Osto teki päätöksen ostaa uusi moottori, koska ei löytänyt merkintää sellaisen olemassa olosta omassa varastossa. Asiakastietojen ylläpitoon ei luultavasti oltu määritelty prosessia, eikä postinumeron tarkistaminen siten ollut kenenkään vastuulla.

Voidaanko tästä syyttää tietohallintoa?

Kalle –

Corrupted Information = vääriä päätöksiä?

Pohdiskelen tässä blogiartikkelissani yrityksissä käytettävien tietojärjestelmien (toiminnanohjaus, tuotetiedonhallinta, tms.) kyvykkyyttä palvella liiketoiminnan informaatio-/ohjaustarpeita. Miten kyvykkyyden käy, kun yritys pyrkii mukautumaan liiketoimintaympäristössään tapahtuviin muutoksiin? Etenkin järjestelmien globaali käyttö altistaa yrityksiä tässä käsiteltävälle ilmiölle, muttei ilmiö ole vieras paikallisissakaan implementaatioissa.

Voidaan kai yleisesti todeta, että tietojärjestelmän kuin tietojärjestelmän käyttöönotto liittyy johonkin yrityksen toiminnankehityshankkeeseen. Yritys muuttaa tai kehittää toimintaansa, jolloin uutta toimintatapaa tukemaan tarvitaan jokin työväline (=tietojärjestelmä tai vastaava) tai kehittyneempi versio jo käytössä olevasta työvälineestä. Käyttöönottoa edeltää usein pitkähkö määrittelyvaihe, jonka aikana käyttöönotettavan järjestelmän toiminnallisuus sekä toiminnallisuutta ohjaavat parametrit määritellään. Tehdään siis jonkinlainen vaatimusmäärittely. Näin varmistetaan, että tarvittavat liiketoimintatapahtumat saadaan kirjattua järjestelmään, ja että syötetyn datan perusteella saadaan liiketoiminnan ohjaamiseen tarvittava informaatio yrityksen käyttöön. Järjestelmän toiminnallisuus ja parametrit edustavat yrityksen liiketoimintaympäristön sen hetkistä tilannekuvaa.

Kriittisten liiketoimintajärjestelmien elinkaari on kohtuullisen pitkä, useita vuosia ellei vuosikymmeniä. Tällaisen ajanjakson aikana yritysten liiketoimintaympäristössä yleensä tapahtuu sellaisiakin muutoksia, joihin yrityksen on tavalla tai toisella vastattava omaa toimintaansa muuttamalla.  Samalla myös liiketoiminnan ohjaamisessa tarvittava informaatio muuttuu.

Miten tietojärjestelmät sitten elävät mukana tällaisessa muutoksessa? On sanottu, että esimerkiksi toiminnanohjausjärjestelmät ”betonoivat” yrityksen tavan toimia. Mitä tämä ”betonointi” käytännössä saattaa tarkoittaa?

  1. Onko kyse siitä, että järjestelmät usein itsessään ovat niin kankeita ja vaikeasti säädettävissä, että pientenkin muutosten tekeminen on kallista ja aikaa vievää, eikä siihen siksi haluta panostaa? Vai onko niin, että järjestelmistä puuttuu ”säätövara” ihan kokonaan?
  2. Vai onko kyse siitä, että yritys ei ole ollut halukas tekemään investointia, jolla järjestelmän säätämiseen tarvittava osaaminen olisi tavalla tai toisella hankittu yrityksen käyttöön, vaikka järjestelmä itsessään mahdollistaisi tällaisen säätämisen?
  3. Vai onko niin, että yrityksen johtamiseen käytettävän informaation johtamiseen ei syystä tai toisesta ole kyvykkyyttä?

Niin tai näin, tällaisen kehityksen tuloksena järjestelmien tuottaman informaation laatu heikkenee ja rapautuu aikaa myöden. Yritysten toiminnan tehokkuus kärsii, kun luotettavaa liiketoimintaa ohjaavaa informaatiota ei ole suoraan saatavilla. Informaatiota pitää täydentää ja sen laatua varmistella muista täydentävistä informaatiolähteistä (Excel ;-)).  Tämä yhdistettynä ajan myötä kasvaneeseen informaatiomäärään asettaa yrityksen vaikeaan tilanteeseen – yrityksellä on tietovarastoissaan valtava määrä dataa, jonka perusteella johdettuun ohjausinformaatioon ei voida luottaa.

Teknologia vs. Sisältö

Miten tällaista informaatiojohtamisen kulttuuria voitaisiin lähteä muuttamaan?

Leikitäänpä ajatuksella: Mitä tapahtuisi, jos yrityksen ohjaamiseen käytettävään informaatioon, sen hallintaan ja käyttöarvon ylläpitämiseen suhtauduttaisiin kuten yrityksen tuotantokoneistoon ja -laitteisiin? Tuotannollisissa yrityksissä on kunnossapito-organisaatio, joka vastaa siitä, että yrityksen tuotantokoneisto rakennetaan toimimaan, ja että se toimii yrityksen strategian mukaisesti. Kunnossapito-organisaatio voi olla joko yrityksen oma tai ulkoistettu (hankitaan palveluna, palveluiden ostaminen, palvelukuvaukset, palvelusopimukset, SLA), kunnossapidon johto on kuitenkin yleensä aina yrityksen oma.

Voitaisiin varmaan ajatella, että tietohallinto-organisaatio, tai ainakin osa sitä, hoitaa yrityksissä tällaista roolia. Näkemykseni on kuitenkin se, että nykyisellään yritysten tietohallinto-organisaatiot paneutuvat pikemminkin kaikkeen muuhun kuin yrityksen ohjaamiseen käytettävään informaatioon, sen hallintaan ja käyttöarvon ylläpitämiseen liittyviin tehtäviin. Tekniikka on kehittynyt paljon nopeammin kuin ohjelmistot – teknisten vimpainten kanssa on mukava touhuilla. Mobiilimaailman syövereihin on muodikasta ja mukavaa uppoutua. Virustorjunnan ja haittaohjelmien torjuntaankin pitää paneutua. On somet ja pilvet ja vaikka mitä. Ei siinä ole aikaa miettiä yrityksen ohjaamiseen käytettävään informaatioon liittyviä asioita. Ainakaan jos kukaan ei oikein sitä osaa vaatia.

Mitä jos nostettaisiin yritysinformaatio organisaatiossa sille kuuluvaan keskeiseen rooliin, ja perustettaisiin yrityksiin erillinen yritysinformaation kunnossapito-organisaatio? Se sitten vastaisi yrityksen ohjaamiseen käytettävästä informaatiosta, sen laadusta, hallinnasta ja käyttöarvon ylläpitämiseen liittyvistä tehtävistä.

Lyhyeksi lopuksi oheinen kuva, johon on kiteytetty ainakin osa tämän kirjoituksen sanomasta.

Tarina jatkuu (kuka tietää?) ja kuvakulma tarkentuu artikkelin saaman palautteen perusteella. Jatketaan siis pohdiskelua ja jaetaan ajatuksia. Kiitos ajastanne!

Seitsemän kuolemansyntiä

Hyllystä tarttui käteen vanha kirja ”Anti-patterns: Refactoring Software, Architectures, and Projects in Crisis”. Varsinkin ohjelmistokehityksen parissa työskentelevän kannattaa tähän perusteokseen tutustua, sieltä saattaa löytyä syitä kävellä tuijottamaan itseään vessan peilistä.

Kirjassa esitellään ongelmien perimäisiksi aiheuttajiksi seitsemän kuolemansyntiä. Voisiko näistä perisynneistä johtaa myös järjestelmähankkeiden ongelmien syitä?

7 sins

1. Kiire

Kiirehän on aina, deadline jyskyttää päälle koko ajan. Tietysti hyvin suunniteltu aikataulutus tuo projektille tarvittavaa ryhtiä. Synniksi kiire muuttuu siinä vaiheessa, kun tehtäville ei anneta niiden vaatimaa aikaa ja puristetaan hatusta vedettyyn aikatauluun taskit kohdalleen luottaen tekijöiden sankarillisiin yksilösuorituksiin. Tälläinen toimii kerran ja kaksi, ehkä kolmekin jos tekijää oikein kehutaan, mutta sitten se on siinä.

2. Välinpitämättömyys

Välinpitämättömyys voi ilmetä monellakin tavalla. Esiintuleva ongelma siirretään syrjään analysoimatta sen kriittisyyttä, koska se ei oikein tunnu osuvan kenenkään osapuolen vastuualueelle. Toimintatavoissa on ongelmakohtia, mutta muutosta ei saada aikaan , koska ’aina on tehty näin’.

3. Ahdaskatseisuus

Ahdaskatseisuus ja näköalattomuus johtuu pitkälti muutoksen pelosta. Järjestelmähankkeet, yllättäen, aiheuttavat usein muutoksia. Muutoksen pelko aiheuttaa usein tunnepohjaista vastustusta, pelkoon reagoidaan vihamielisesti. Jos jättää muutosvastarinnan huomioimatta, se potkaisee vähintään nilkkaan myöhemmin.

4. Laiskuus 

Laiskuudesta löytyy varmasti esimerkkejä. Jos projektipalaverissa joku sanoo, että ”en usko että sitä XXX tarvitsee tehdä”, ja tuo XXX asia on sinun vastuualueellasi, niin herätys! Jollain tavalla joudut tämän asian hoitamaan myöhemmin ja yleensä alkuperäistä suuremmin kustannuksin. Tässä kohdassa tuntuisi avainsanoja olevan QA, muutoksen hallinta ja lisensointikysymykset.

Usein törmää myös siihen, että jätetään ratkaisu puolitiehen. Ajatellaan, että tehdään ensi vaiheessa vain välttämätön ja loput joskus myöhemmin. Sitä myöhemmin ei koskaan tule. Samalla on kuitenkin tiedostettava, että tie helvettiin on päällystetty hyvillä aikomuksilla, kuten täydellisyyden tavoittelulla (ks 5. Ahneus).

5. Ahneus

Ahneudessa mikään ei tunnu riittävän. Ahne haluaa vain lisää, vaikka sitä ei muillakaan olisi, eikä missään nimessä luovu omastaan toisen tai yhteiseksi hyväksi.  Järjestelmähankkeiden kohdalla ahneus esiintyy keskittyminä. Toimintoja ja prosesseja keskittyy kokonaisarkkitehtuurissa järjestelmäkartassa yhteen paikkaan. Ydinprosessien ja -toimintojen kohdalla tämä saattaa olla mielekästä ja tietoinen valinta, mutta seuraukset on syytä tiedostaa.

6. Tietämättömyys

Tietämättömyys tuntuu tulevan vastaan päivittäin. Nykymaailman informaatiotulvassa ja muutosten määrässä on oma haasteensa pitää osaaminen ajan tasalla. Kerran hyväksi koettu ratkaisu saattaa olla vanhentunut ja parempaa olla jo tarjolla. Toisaalta uusin teknologia ja innovaatio ei välttämättä ole aina alkumetreillään ihan paras ratkaisu. Oman ajantasaisen ratkaisupakin hallinta on tänä päivänä onnistumisen edellytys.

7  Ylpeys

Tästä löytyy varmasti esimerkkijä ja sudenkuoppia. Kuvitellaan perusteettomasti, että kyllä osaamista löytyy, uskotaan sokeasti omiin kykyihin, kuvitellaan datan laadun ja tietomallien olevan täydellisiä ja aukottomia. On eri asia luulla tietävänsä kuin tietää tietävänsä.

Teologiassa yhtenä synnin tunnusmerkkinä pidetään tietoisuutta väärin tekemisestä. Tässä yhteydessä tiedon puute on kuitenkin nähtävä yhtenä syntinä. Toisaalta tiedon haalimisen riivaamana ajautuu helposti ahneuden syntiin, johtaa kiireen kautta välinpitämättömyyteen ja ahdaskatseisuuteen. Samoin käy jos osaamisen kehittäminen laiminlyödään kiireen välttämiseksi ja laiskuuden vuoksi – päädytään helposti ahdaskatseisuuden ja ylpeyden synteihin, joissa oma osaaminen ja toiminta nähdään ainoana olemassa olevana  ratkaisuna ja palvotaan sitä kultaisena vasarana ja kaikki ongelmat ovat nauloja.

Näiden seitsemän kuolemansynnin välttäminen näyttäisi tarkoittavan yleisesti kohtuullisuutta ja kokonaisuuden huomioimista. Osa-optimointi ja yhteen asiaan keskittyminen johtaa syntiin ja kadotukseen, näin mahtipontisesti sanottuna. Jos esimerkiksi Six-Sigma yleensä pyrkii estämään osa-optimointia, niin missähän on tapahtunut virhe, jos kuudella koitetaan korjata seitsemää. Puuttuuko Six-Sigmasta jotain vai onko seitsemässä kuolemansynnissä jotain liikaa. Palataan tähän numerologiaan tuonnempana

– Software Samurai –

Löytyykö se järjestelmästä?

Hehkutin taannoin, millaisen vaikutuksen tuotetiedonhallinta-järjestelmä minuun aikoinaan teki. Edelleen olen vakuutettu siitä, että ko. tietojärjestelmä on hyvälle bisnekselle must, mutta toisaalta järjestelmäuskovaisuuteni on myös kokenut kolauksen.

Oma kantapää ja kaverit ovat kertoneet, ettei mikään tietojärjestelmä itsessään tee autuaaksi. Jokaista järjestelmää voisi hioa ja parannella loputtomasti: lisätään uusia toiminnallisuuksia, parannetaan käyttöliittymää ja käytettävyyttä, verkotutaan muihin tarpeellisiin järjestelmiin, yms yms. Mikään toimenpide sinällään ei tuo sijoitettuja euroja takaisin suurempien hyötyjen muodossa, ellei järjestelmää käytetä järkevästi ja yhtenäisesti.

Ihminen on avain

Olen siis törmännyt vanhaan totuuteen: Järjestelmä on juuri niin hyvä kuin sen käyttäjät ovat. Auts.

”Löytyykö se järjestelmästä?” on kysymys jonka usein kuulen ja itsekin kysyn. Ellen vie dokumenttia/tuotetta/asiakasta/ projektia/sähköpostia/etc. järjestelmään, sitä ei ole olemassa!  Tekemäni työ on jäänyt vain omaksi ilokseni, ja jos huonosti käy, en itsekään löydä sitä enää myöhemmin.

Järjestelmää hankittaessa ja ainakin viimeistään ennen käyttöönottoa yhteisesti sovittavat käytännöt ja toimintatavat on nostettava prioriteetille yksi. On varattava aikaa ja mietittävä omat prosessit kuntoon. Tähän kannattaa hakea sparrausapua asiantuntijalta,  jotta uskalletaan kyseenalaistaa vanhat tavat ja saadaan hankittavan järjestelmän antamat mahdollisuudet hyödynnettyä täysimääräisesti.

Seuraava haaste on sitouttaa kaikki käyttäjät uusiin toimintatapoihin. Negatiiviselta kalskahtava ”käyttäjäkuri” on itseasiassa positiivinen asia ja ainoa toimiva lääke, kunnes tiedonhallintajärjestelmään saadaan ajatustenlukutoiminnallisuus mukaan. Sitä odotellessa…

– Lilli