Janoisena hukkuvat

Arkikielen tietoon viittaavat metaforat ovat jännän vetisiä: puhumme sekä tietotulvasta että tiedonjanosta. Tulva ei tässä auta janoon, koska epärelevantti häly koetaan tulvana ja janoa puolestaan helpottaa ainoastaan laadukas, relevantti tieto.

John Naisbitt oli käsittääkseni ensimmäinen, joka muotoili tämän ristiriidan sanoiksi. Muutenkin lukemisen arvoisessa tulevia megatrendejä yllättävän tarkkaan luotaavassa Megatrends-kirjassaan (1982) Naisbitt kirjoittaa ”We are drowning in information and starving for knowledge”.

infoflow

Naisbittin lausahduksessa on osuvasti käytetty sanoja informaatio ja tieto. Datan, informaation ja tiedon suhteesta konsultti leipoisi fläppitaululle kolmion alta aikayksikön: siinä pohjaa pitää data, seuraavalla tasolla lepää informaatio ja huipulla komeilee tieto. Hyvänä päivänä kärkeen lisätään vielä ylevästi viisaus. Tämä nelikko antaa tiedon hierarkialle yleisesti käytetyn DIKW-akronyymin (data-information-knowledge-wisdom).

Kolmio on nopeammin piirretty kuin ymmärretty. Maailma on täynnä keskenään vähän erilaisia ja ristiriitaisia määritelmiä hierarkian eri tasojen sisällöistä ja merkityksistä. Esimerkiksi Zinsin (2007) artikkelissa käydään läpi 130 erilaista määritelmää 45 kansainvälisen tutkijan koostamana. Siltä varalta että asia kiinnostaa tarkemmin, laitan blogikirjoituksen loppuun muutaman mielenkiintoisen DIKW-hierarkiaa käsittelevän artikkeliviitteen.

Itse olen oppinut ajattelemaan niin, että data on yksittäisiä totuuksia. Data voi olla esimerkiksi ”Pekka” tai ”8.8”. Informaatio taas on dataa, joka on asetettu kontekstiin – jolle on annettu merkitys. Tässä yhteydessä voidaan puhua myös metatiedosta; tiedosta, jolla kuvataan dataa.

8.8 voi viitata piste-erotettuun desimaalilukuun, pultin lujuusluokkaan tai vähän väärin kirjoitettuun päivämäärään elokuun alkupuolelta. Informaatioksi 8.8 muuttuu kun siihen liitetään metatietoa, joka kertoo datan kuvaavan nimenomaan ruuvin lujuusluokkaa.

Tietohierarkian kaksi alinta tasoa voivat elää elämäänsä koneen sisällä, mutta tiedon kohdalla ihminen astuu kuvaan. Eri määritelmiä tällekin on useita, mutta itse miellän tiedon olevan ihmisen ymmärtämää, yhdistelemää ja soveltamaa informaatiota. Informaatio jalostuu tiedoksi ihmisen kognitiivisten prosessien kautta.

Juuri tieto on se, mikä liiketoimintamielessä eniten kiinnostaa. Tiedon varassa tehdään päätöksiä – tieto on bisneksen bensaa jonka synnyttämiseen, jalostamiseen ja hyödyntämiseen me kaikki käytämme leijonanosan työajasta. Arkinen työjuhtamme on kyllä ylevästi nimetty tietokoneeksi (vs. computer tai dator), mutta ei kone itsessään paljoakaan tiedä. Data dollarisoituu vasta siinä vaiheessa, kun asiantuntija tarttuu toimeen ja soveltaa järjestelmään hillottua informaatiota mielekkäästi.

Naisbitt ei ole ainoa, joka lausui jotain nasevaa vuonna 1982. Samana vuonna julkaistiin Harlan Clevelandin artikkeli Information as a resource. Siinä on montakin järkevää asiaa, mutta yksi lause pistää rohkeudellaan erityisesti silmään: ”Workers who have previously helped grow or extract or make things, or have been in the non-information services, will have to learn to become information workers – or get used to being unemployed.

Aika kovaa tekstiä yli kolmen vuosikymmenen takaa.

Clevelandin sitaatti on ihan yhtä totta kuin Naisbittin samana vuonna lausuma tietotulvan ja tiedonjanon ristiriita.

Välillä mietityttää, mitä tai mikä siellä tuotetiedon ytimessä oikeastaan on. Tuskin arvaus menee kovin pieleen, jos veikkaan siellä olevan parivaljakon informaatio ja ihminen. Kolmas pyörä saadaan koneellisesta käsittelystä: informaatiota on niin paljon, että ahkerampikin asiantuntija tikahtuu lähtöruutuun ilman fiksuja työkaluja.

Tiedonjanoisille lisäluettavaa:

Cleveland, Harlan. Information as a resource. Futurist, 16(6):34–39, 1982.

Frické, Martin. The knowledge pyramid: a critique of the DIKW hierarchy. Journal of Information Science, 35(2):131–142, 2009.

Naisbitt, John. Megatrends. Ten New Directions Transforming Our Lives. Warner Books, 1982.

Rowley, Jennifer. The wisdom hierarchy: representations of the DIKW hierarchy. Journal of Information Science, 33(2):163–180, 2007.

Zins, Chaim. Conceptual approaches for defining data, information, and knowledge. Journal of the American Society for Information Science and Technology, 58(4):479–493, 2007.

Mainokset

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 –

Semantiikasta ja mitä kilpikonna sanoi Akilleelle

Lupasin joskus aikaisemmin jatkaa semantiikan pohdiskelua, joten tässä tulee. Mikäli et tiedä mitä otsikon jälkikaneetti ilmaisee kerrottakoon; Kyseessä on yksi perustason semanttisen ratkaisumallin kompastuskiviä, jonka esitteli Lewis Carrol novellissaan jo aikoja, aikoja sitten. Myöhemmin Saman asian esitti Gödel epätäydellisyysteoreemissaan  ja kvanttiajattelun puolella Schrödinger maailman toisiksi kuuluisimmalla kissallaan.

Semantiikka tarkoittaa tietojärjestelmämielessä korkeamman tason logiikkaa, jossa järjestelmä kasvaa ulos tietovarastosta, ”ymmärtäväksi olioksi”. Järjestelmä tuntee konsepteja, asiayhteyksiä ja huomioi viitteitä tiedossa niin, että käsittelymalli säätyy tiedon ehdoilla. Tämänkaltainen toiminta voidaan mieltää vaikkapa kesätyöntekijäksi, joka lähtee ilman kokemusta toteuttamaan annettuja tehtäviä, ja loppukesästä homma toimii jo annettujen input-tietojen pohjalta ilman ulkoista ohjausta kohtuullisen tehokkaasti.

Semantiikka on hyvä keino löytää ja yhdistää tietyn tapaista tietoa, ja yhdistettynä tehokkaisiin algoritmeihin ja hakutapoihin tulokset saattavat olla erinomaisia tapauksesta riippuen. 80/20 sääntöä voitaisiin ajatella aika optimaalisena tuloksena ainakin alkuvaiheessa, eli 80 % menee nappiin ja 20 % poskelleen. Ilman semantiikkaa n. 50-60 % osuu paikalleen ja varmuus on yleisesti ottaen huonompaa  (tietoa on vähemmän ja ymmärrystä järjestelmässä ei sinänsä ollenkaan) . Semantiikka, ja  korkeamman tason merkitysten tuominen järjestelmään on tottakai hieno asia, eikä varmasti ainakaan pahenna järjestelmän toimintaa.

No mitä se kilpikonna sanoi Akilleelle?

Järjestelmäkehittäjien tulisi kysyä otsikonmukainen kysymys itseltään aina silloin tällöin. Kun tullaan semantiikan piiriin, tulee muistaa tämä: järjestelmä ei ole aukoton. First order logic lienee yleisin tapa lähestyä ongelmaa, mutta mitä silloin tapahtuu negaatiolle? Voimme määritellä vaikkapa kouluesimerkin mukaisesti seuraavaa; yksisarvinen on myyttinen eläin ja myyttinen eläin on kuolematon. Yksisarvisella on sarvi. Jos yksisarvisella on sarvi, se on myyttinen JA taianomainen. Jos yksisarvinen on taianomainen, se on myyttinen eläin. Lisäksi yksisarvinen on ontologisesti nisäkäs. Jos yksisarvinen omaa sarven TAI se on nisäkäs (joka tarkoittaa myyttisen negaatiota, joka tarkoittaa kuolevaista, mikä taas tarkoittaa… ) se on… Mitä?  Olikohan sitä yksisarvista aluksikaan 😉

– Juha –

Onpas sinusta kasvanut jo iso järjestelmä!

*DM-järjestelmien kanssa painiessa otsikon mukainen lausahdus tulee usein mieleen. Erilaista tietoa on runsaasti, tieto on syvästi rakenteellista ja monimutkaista. Kukaan ei liene täysin selvillä siitä mitä kaikkea yksittäinen tuoterivi saattaa sisältää. On siirtotietoa, suuretietoa, lajittelutietoa, kuvauksia jne. Tästä tuskasta kertoo myös järjestelmien tietorakenteet; Esimerkiksi SAP:n tietokanta (RDBMS) sisältää tuhansia tai kymmeniä tuhansia tietokantatauluja. ECC ja R/3 koostuu yli kolmestakymmenestä tuhannesta taulusta kun taas CRM saattaa jäädä alle kymmenen tuhannen. Vertailun vuoksi jotkin PDM-järjestelmät sisältävät tauluja vain noin 100-200. Rakenteellisuus on olennainen osa järjestelmiä, mutta samalla rakenteellisuus ainakin tietoalkiotasolla tuo mukanaan melkoisia ongelmia mitä tulee itse järjestelmien toimintaan. Viitteiden ylläpidon, tiedon reaaliaikaisuuden ja tiedon esittämisen haasteet lisääntyvät eksponentiaalisesti, mitä suuremmaksi objektien rakenne kasvaa. Tiedonhaku vaikeutuu ja järjestelmän koko ”pullistuu”.

Järjestelmädieetti

Ratkaisuna monimutkaisiin rakenteisiin ehdotan  NOSQL-tyyppisiä järjestelmiä, tuettuna relaatiokannalla metadatan tallentamista varten. Poistetaan turhat rakenteelliset attribuutit ja tuodaan rekursion sijaan peliin leveät tietueet, kuten esim. BigTable, HBase, Amazon SimpleDB, Cassandra, Lucene jne. Mitä laveampi data tarkoittaa käyttäjälle? Tietokanta-/kyselymielessä jokaiseen liitokseen voidaan liittää aikakustannus. Kustannus ei ehkä ole suuri (tyypillisesti millisekunteja keskikokoisessa järjestelmässä), mutta kun näitä kustannuksia on paljon, puhutaan helposti sekunneista tai jopa kymmenistä sekunneista.

Kuinka merkittäviä sekunnit ovat? Jos haet tietoa vaikkapa 500 kertaa päivän aikana, löydökset ovat 70% tarkkoja (lue: haet tietoa todella hyvin ja tarkasti) sekunnin kustannus on jo kohtuullisen merkittävä. Kustannus (hakutulokset ja niiden kahlaaminen huomioonottaen) kuluttaa työpäivästäsi n. 20 %. Merkittävä määrä aikaa siis menee tiedon hakemiseen. Laveassa tietomallissa liitokset ovat jo soveltuvin osin kiinni itse alkuperäisessä objektissa ja tästä suora seuraus on hakuaikojen lyheneminen, tiedonsaannin tehostuminen sekä myös hakuominaisuuksien suoraviivaistuminen.

Muistithan bonukset?

Mitä muuta etua saavutetaan? Kun mukana ei enää kuljeteta merkityksetöntä sisäistä tietoa, tilantarve palvelimella pienenee, riippuen tietorakenteesta. Lisäksi tehokkaammat ja nopeammat järjestelmät voidaan ottaa esimerkiksi data mining-käyttöön (duplikaattien poisto, tiedon eheyden tarkistus, samankaltaisuuksien poiminta, puuttuvien tietojen etsintä jne.).  Voidaan hyödyntää ”uudenlaisia” ja tehokkaampia hakutapoja, ja mikä tärkeintä, voidaan esitellä semantiikkaa, mikä taasen tarjoaa aivan uusia ja mullistavia tapoja ”* Data Managementtiin”. Semantiikasta jatkakaamme myöhemmin, tämänkertainen ajatusvirta olkoon tässä.

– Juha –

Mitä nimike maksaa?

Ensin tulee tietenkin tarkentava kysymys: ”Mitä nimikettä tarkoitat?”.  Sen jälkeen kysymykseen vastataan 100% varmuudella joko kertomalla myyntihinta tai ostokustannukset. Jos puhutaan omavalmisteisesta nimikkeestä, ollaan jo askeleen tarkempia ja lasketaan materiaali- ja työkustannukset – voipa joku jyvittää työkalukustannuksiakin nimikkeelle.

Nimikekustannus nähdään perinteisesti vain suorina kustannuksina. Tietojärjestelmien aikakaudella pitäisi ymmärtää myös se, että jos nimikettä yleensä voidaan hyödyntää suunnittelussa, valmistuksessa, logistiikassa tai "Nimikenääri"palveluliiketoiminnassa, merkittävä painoarvo prosessin tukemiseen tulee nimikkeen tiedoista – informaatiosta eli siis viimekädessä datasta, jolla se on eri järjestelmiin kuvattu.

Vanha kunnon Metalliteollisuuden keskusliitto MET (rest-in-peace) sivusi varovasti aihetta jo aivan 80- ja 90-lukujen taitteessa. Erilaisten tutkimusten pohjalta päätyivät siihen, että nimike maksaa 1500 mk vuodessa. Siis siksi, että se on järjestelmissä; sillä on varastopaikka, jonka vuoksi se pitää inventoida jne.

Ja hinta nousee…

Hieman pidemmälle menivät jenkeissä Zenger ja Cafone tutkimuksessaan ”Economic Justification for Part Number Reduction During Product Design”. Siinä lähtökohtana oli DFMA –suunnittelu (Design for Manufacturability and Assembly) ja se, kannattaako mieluummin käyttää kalliimpia  monikäyttöisiä komponentteja, jotka toiminnallisuudellaan korvaavat esimerkiksi viisi halvempaa komponenttia.

He lähtivät suunnittelemaan kustannusrakennetta, joissa perinteisten materiaali-, työvoima- ja työkalukustannusten oheen määriteltiin kuusi kustannuskategoriaa:

  1. Tuote- ja prosessisuunnittelu
  2. Tuotanto
  3. Kuljetus ja varastointi
  4. Laatu
  5. Tiedonkäsittely
  6. Yleiskustannukset

Jokainen osasto siis arvioi omista lähtökohdistaan kustannukset uudelle nimikkeelle . Lopputuloksena päästiin eräässä keskisuuressa konepajassa nimikkeen yleiskustannukseen $9437.

No, totuus on varmaan jossain tuossa välissä ja riippuu erittäin paljon yrityksen toimintamallista ja käytettävistä järjestelmistä – jotkut ERP-järjestelmät vaativat nimikkeelle 500 attribuuttia, jotkut selviävät vähemmällä.

Puhutaan kuitenkin sen verran merkittävästä kustannuksesta, että on ihme, ettei sen hallintaan ole löytynyt kiinnostusta. Vai olisiko kyse työkalujen tai menetelmien puutteesta.

Tieto on tuote

Paras tapa lähestyä asiaa on mielestäni hyväksyä se, että jokaiseen yrityksen nimikkeeseen liittyy toinen nimike – informaationimike. Sitä voidaan käsitellä aivan samoin menetelmin kuin fyysistä nimikettä eli perinteisin tuotehallinnan keinoin.  Myös tiedolla on elinkaari, hankinta- ja ylläpitokustannukset sekä erilaisia laatuvaatimuksia. Kustannukset elävät elinkaaren mukana, ja kun tieto käsitellään tuotteena, voidaan myös helpommin asettaa tavoitteita tiedon kustannusten pienentämiseksi tai vastaavasti lisäämällä investointia tiedon laatuun saadaan fyysisen nimikkeen kustannuksia pienennettyä.

Miltä kuulostaa, onko Teidän yrityksessänne mietitty tietoa tuotteena? Vai onko nimikeinformaation kustannuksia yleensä noteerattu?

Jukka

PS. Jos edellinen blogi Keisarin uusista raporteista tuntui pelkältä tsoukilta, voi saman asian  lukea tieteellisemmässä kontekstissa esim. Peter Aikenin esityksistä .