”Datalle on lottovoitto syntyä Suomeen”

Törmäsin oheiseen mainoslauseeseen ja – vaikkakin patrioottina – on pakko valitettavasti olla eri mieltä.

Olemme toteuttaneet puolisen sataa Datalyysiä eri teollisuusyrityksille Suomessa ja muualla Euroopassa. Yhteensä on analysoitu yli 5 miljoonaa nimikettä ja niiden attribuutteja. Kouluarvosanalla (4-10) keskiarvo on 6,2. Ei siis mitenkään hyvä, juuri ja juuri välttävä. No ikävin uutinen on se, että suomalaiset yritykset jäävät selvästi jälkeen eurooppalaisista verrokeistaan.

Insinööri vs. taiteilija

Mistä tämä mahtaa johtua? Itse voisin vastata tähän, että Suomesta puuttuu järjestelmällisyys ja kurinalaisuus suunnitteluosastoilla, jotka kuitenkin pääasiassa vastaavat nimikedatan syntyvaiheista. Suomalaiset yritykset ruokkivat vielä sankarikulttuuria ja näkevät päiväunia alikersantti Rokan uroteoista. Toisaalta olen useammalta taholta kuullut, että konepajoissakin suunnittelu on taidetta, johon koskeminen on tabu. Saksalaisten insinöörien DIN-standardien lähes uskonnollinen seuraaminen on yleensä herättänyt naureskelua suomalaisten taiteilijoiden keskuudessa. Mutta kun Italiassakin, Hollannista puhumattakaan, tuotetaan keskimäärin hyvälaatuista dataa, kannattaisi täälläkin herätä.

Asia paljastuu viimeistään siinä vaiheessa, kun yritykset yhdistyvät ja dataa pitäisi alkaa migratoimaan yhteiseen muotoon – siinä on suomalainen ostaja housut kintuissa, kun paljastuu, että ostettu italialainen konepaja on hoitanut datansa huomattavasti paremmin. Pahimmassa tapauksessa integraattorin kaasukahva siirtyy väärään käteen.

Hyvä data on kasvun mahdollistaja

Mielenkiintoinen havainto Datalyysin tuloksista on myös se, että suuremmilla yrityksillä data on selkeästi parempilaatuista kuin pienemmillä yrityksillä. Tätä voisi nopeasti analysoida siten, että isommilla yrityksillä on paremmat resurssit datan hallintaan. Ehkä todellisempi analyysi on kuitenkin se, että firmat ovat kasvaneet isoiksi juuri siitä syystä, että heillä on alusta asti panostettu dataan ja prosesseihin.

Nyt kun eletään digitalisaation aikakautta ja kaikenlaista hypeä on ilmassa – VR, AR, AI, Blockchain, … niin muistetaan kuitenkin, että digitaalisessa maailmassa kaikki perustuu dataan.

-PDM Preacher

Tuotetieto on nyt Roimasti tärkeämpää!

Kesälomien alla pääsin mukaan mielenkiintoiseen järjestelyyn, jossa tuotetiedonhallintaa vietiin mukaan isompaan kokonaisuuteen. Jo kesän aikana on lamppuja syttynyt monessa paikassa, kun on ymmärretty, mitä hyvä tuotetieto merkitsee varastonhallinnassa,valmistuksenohjauksessa ja IoT:ssä – myyntitoiminnoista puhumattakaan.

Sisälogistiikkaongelmia kymmeniä vuosia ratkaisseet kaverit heräsivät siihen tosiasiaan, että he paikkailevat tuotetietoja logistiikkaprosesseissa (milloin milläkin työkalulla SQL:stä jeesusteippiin), ja olisi mieletön etu, jos niihin ongelmiin puututtaisiin jo yläjuoksulla, kun tieto lähtee liikkeelle.

ERP ratkaisee kaiken?

Toisaalta surullista todeta, kuinka paljon edelleen eri järjestelmät toimivat omissa siiloissaan, omalla datallaan. Isot ERP-toimittajat eivät tätä asiaa ratkaise yhtään paremmin –  ehkä jopa huonommin. Transaktiohin ja konsernin konsolidointiraportointiin kehitetyt järjestelmät käsittelevät liiketoimintaobjekteja ainoastaan em. draivereiden pohjalta. Ne jättävät aukon syvällisempään asiakastiedon käsittelyyn, lattiatason työnohjaukseen tai tällä foorumilla erityisen kiinnostuksen kohteena olevaan tuoteinformaatioon. Jos isot nimeltä mainitsemattomat ERP-toimittajat samalla tekevät täydentävien järjestelmien integroinnin hankalaksi teknisesti tai lisenssipoliittisesti, ei tästä hyödy kukaan – ei ainakaan asiakas.

siilot

Omakin ymmärrys on jo lyhyellä matkalla laajentunut Roimasti ja uusia kolmikirjaimisia lyhenteitä, joita aiemmin en ollut kuullutkaan, on noussut kahvipöytäkeskusteluihin. Yllättäen ERP-scopen ulkopuolelta löytyy paljon erillistoimintoja, joihin tarvitaan omia järjestelmiä – on mommia (MOM), messiä (MES), vemssiä (WMS), ym. mutta yllättäen ja pyytämättä kaikissa järjestelmissä käsitellään tuotetietoa ja se tulee ”jostain” milloin missäkin muodossa, tai jos ei tule, niin naputellaan itse.

Varastopaikka vs. varastointiperuste

Todella mielenkiintoinen havainto on se, että nimikkeen varastopaikka on tyypillinen ERP- attribuutti – tämän kaikki ymmärtävät. Mutta mikään olemassaoleva järjestelmä ei tallenna esimerkiksi varastointiperustetta – eli onko tuote räjähdysherkkä tai helposti syttyvä, mitkä ovat varastointidimensiot, ABC-luokka tai esim myyntiaika. Näitä tietoja tarvitaan, jotta varastologistiikkaa päästään optimoimaan! Varastopaikkaa joudutaan, tai sitä kannattaa, vaihtaa monistakin syistä. Jos esimerkiksi jonkun tuotteen myyntiaika on päättymässä, kannattaa tuote sijoittaa toimituskeskuksessa lähelle lähtöporttia. Joten jos nimikkeestä tiedetään vain varastopaikka, joku joutuu tekemään paljon turhaa työtä uuden varastopaikan määrittelemiseksi.

tuotetietomaster

Olen saarnannut tuotetiedon roolista liimana eri prosessien ja järjestelmien välillä pitkään. On mahtavaa huomata, mikä potentiaali sillä todellisuudessa on! ICT Standard Forumin julkaisema informaatioarkkitehtuurimalli alkaa purra myös käytännössä. Viime aikoina olen jo kuullut julistuksia, että yritysintegraatioon tai järjestelmähankkeeseen mennään data edellä, mikä kuulostaa aika vallankumoukselliselta tietohallintojohtajien suusta kuultuna.

Ja lopuksi Mattia ja Teppoa siteeraten: Kaiken takana on nai… eikun siis…  nimike!

-PDM Preacher

Minun Datani!

Saimme vieraaksemme erään maailman arvostetuimmista dataguruista, tohtori Peter Aikenin, joka esitteli teesejään Betonia vai vaahtokarkkia – seminaarissa. Sehän ei ole tällä foorumilla uutinen, että betoninen perusta liiketoiminnalle ja varsinkin sähköiselle liiketoiminnalle on hyvälaatuinen data. Ehkä enemmän ajatuksia herätti datan omistajuus, se että omistajuutta on harvoin määritelty. Ja jos onkin, omistaja ylisuojelee dataa niin, että sen hyödyntäminen käy omistajan oman siilon ulkopuolisessa liiketoiminnassa mahdottomaksi.

Aikenin tunnetuimpia teesejä on Monetizing Data Management – eli miten kuvaat dataan liittyvät haasteet ja mahdollisuudet niin, että kulmahuonekin ne ymmärtää.

Tietosiilojen purkaminen – elämän ja kuoleman kysymys

Pysäyttävimmän esimerkin Aiken kertoi kuitenkin kategoriassa ”not yet quantified”. Hän oli saanut joitakin vuosia sitten toimieksiannon USA:n puolustusministeriöltä (DoD = Department of Defence). He halusivat selvittää, miten voidaan tunnistaa itsemurhiin taipuvat sotilaat mahdollisimman ajoissa.

Amerikassa oli noteerattu, että Vietnamin sodassa kuoli 50.000 sotilasta, mutta sotaretken jälkeen 120.000 ex-sotilasta kuoli oman käden kautta.

Nyt Irakin sodan jälkeen haluttiin oppia ja vaikuttaa riskitekijöihin etukäteen. Sotilaita lähdettiin ”nimikkeellistämään” erilaisten tietojen perusteella: fyysinen kunto, psyykkinen kunto, koulutus, rikosrekisteri, ym. ennen armeijaan tuloa, miten nuo parametrit muuttuivat armeijan aikana ja sen jälkeen. Ongelmana oli, että tietoja oli talletettu useaan eri tietovarastoon, jotka olivat eri osastojen vastuulla.Never let you Buddy fight alone

Kaikki suojelivat omaa tietoaan eikä kukaan uskaltanut julkistaa niitä yhteisen analyysin aikaansaamiseksi. Koko projekti oli jäädä paikoilleen, kunnes Aiken marssi puolustusministerin puheille ja selitti asian. Puolustusministeri kutsui kenraalikunnan palaveriin ja jyrähti: ”Tämä on minun dataani – kuka on sitä mieltä, että tätä dataa ei saa käyttää itsemurhien estämiseen?” Yhtään kättä ei noussut.

Kuka dataa huoltaa?

Hieman kevyempi esimerkki datan huonosta käytettävyydestä oli mielenkiintoinen havainto siitä, mitä IT-alan opiskelijoille opetetaan. Missään koulussa tai kursseilla ei opeteta olemassa olevan datan huoltoa. Yleensä ensimmäiseksi opetetaan, miten perustan uuden tietokannan. No tästä seuraa tietysti se, että kaikki perustavat omia tietokantojaan kun pääsevät yrityselämään ja siitähän se tiedon siiloutuminen alkaa.

create new data baseData ja yrityksen strategia

Risto Silvola Konecranesilta on väitöskirjaansa varten tutkinut suomalaisten yritysten Master Data Management -käytäntöjä ja strategiaa. Hän havaitsi, että joka kymmenes suuri suomalainen yritys on ottanut datan osaksi yritysstrategiaa samalle tasolle kuin asiakkuuden hallinta, tuotehallinta, tilaus-toimitusprosessi tms. perinteinen avainprosessi. Peter Aiken säesti, että jenkeissä tilanne on sama. Valistustyötä vielä riittää, koska tosiasia on se, että jos yritysjohto julistaa yrityksensä strategiaksi IoT:n tms. digitalisaatio-aiheisen viestin, on se todella pahasti ristiriidassa käytännön kanssa, ellei dataa nähdä strategisena asiana ja siihen kuuluvana resurssointina. Ilmeisesti nykyisen johtajasukupolven pitää vaihtua ennenkuin data ymmärretään samanlaisena tase-eränä kuin kiinteä omaisuus. Vai pitäisikö itseasiassa kirjanpitolaki muuttaa?

– koska datalle ei ole määritelty taseessa omaa tiliä – sitä ei siis ole oikeasti olemassa!

Harvasta yrityksestä löytyy johtajia, jotka nousisivat framille ja julistaisivat: Tämä on minun dataani. Vastaan siitä, että se on niin hyvässä kunnossa, että koko yrityksen ja verkoston toiminta on laadukasta ja kannattavaa.

Tässä hieman pohdittavaa kesälaitumille.

  • PDM Preacher

 

Data kunnossa?

Tuotetiedon laatu on ollut erillisenä aiheena Modultekin agendalla jo jonkin aikaa. Myös yrityksissä on havahduttu siihen tosiasiaan, että tietojärjestelmät eivät toimi ja ”tuota” odotusten mukaisesti, jos data on huonoa. Monessa yrityksessä on investoitu suuriakin summia hienoihin tietojärjestelmiin, mutta projektiaikataulujen ja kustannusten paineessa datan haltuunotto ja parannus usein vaihtuvat tilanteeseen, jossa data vain survotaan vanhasta järjestelmästä uuteen mahdollisimman nopeasti.

Datan parannus – tuottava investointi

Täydellistä dataa ei ehkä ole olemassa, eikä siihen edes kannata pyrkiä. Yritykset ja maailma ympärillä muuttuu, samalla muuttuvat myös vaatimukset. Datan hallinta (governance) pitää asettaa järkevälle tasolle. Monella yrityksellä se tarkoittaa ensivaiheessa sitä, että prosessi aloitetaan… Datan parannus voidaan ajatella investointina, joka pitää pystyä perustelemaan ja jonka pitää tuottaa. Toisin sanoen toimet pitää osata mitoittaa oikein.

Modultekissa on pohdittu jo pitkään, millaista hyvä nimike- ja tuotedata on. Aluksi teimme sisäisiä dokumentteja ja ohjeistuksia. Nyt olemme jo useamman vuoden ajan ihan julkisesti puhuneet ”Hyvä Nimike” konseptistamme. Yhtenä osana sitä olemme kehittäneet nimike- ja tuotedatan analysointipalvelun Datalyysin™. Sinällään varsin arkipäiväinen toimenpide, jossa yrityksen datan laatua tarkastellaan vakioiduilla menetelmillä ja jonka pohjalta asiakkaalle annetaan suosituksia parannuskohteista ja -keinoista.

Hyvät käytännöt ja tietojärjestelmän tuki

Missä kunnossa yritysten data sitten oikeasti on? Nyt kun Datalyysejä on tehty n. 40 yrityksen ja n. 3,8 miljoonan läpikäydyn nimikkeen osalta, voin ehkä antaa jonkinmoisen välitilinpäätöksen. Lyhyesti voisi sanoa, että yritysten tuotedata ei kovin kummoisessa kunnossa ole. Jos kaikkien yritysten keskiarvoa kuvaisi perinteisellä kouluarvosanalla, tulisi arvosanaksi 6,5. Mukaan mahtuu kuitenkin muutamia varsin hyviä tuloksia.

Parhaiden tulosten takana on yhdistelmä hyviä käytäntöjä, tietojärjestelmän antamaa tukea ja automaatiota.

Varsin hyviin tuloksiin on päästy myös tiukalla ja systemaattisella toimintatavalla, vaikka tietojärjestelmän antama tuki olisikin ollut puutteellista. Toisaalta paraskaan tietojärjestelmä ei pelasta tilannetta, jos vastuutusta ja käytäntöjä ei ole hoidettu kuntoon.

Yksi huomion arvoinen seikka on se, että suomalaisissa yrityksissä data näyttäisi olevan keskimäärin heikommassa kunnossa kuin muissa eurooppalaisissa yrityksissä. Otanta ei ole kovin suuri, mutta kuitenkin. Liekö tähän syynä suomalasten yritysten vähemmän muodollinen ja hierarkkinen toimintatapa? Entä mikä vaikutus heikommalla datan laadulla on Suomen muuta Eurooppaa kehnompaan taloudelliseen tilanteeseen?

Dataukko – Janne J

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.

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 –

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 –