Rikkaat tuotetiedot – kuka maksaa?

Kollegani oli ostamassa mökilleen kaivon imuputken pohjaventtiiliä ja selaili tietysti netistä (joka on nykyisin kesämökin välttämättömin perusvaruste) eri toimittajien ja valmistajien tarjoomaa. Hommahan menee kuluttajamaailmassa pääosin näin: surffataan hyväksi todetulle kauppapaikalle, jossa on laaja määrä tuoteinformaatiota eri tuotteiden vertailupohjaksi. Kun oikea tuote löytyy, mennään siihen nettikauppaan, jonka tiedetään olevan halvin ja tilataan tuote sieltä. Tässä vaiheessa ei enää ole väliä sillä, onko tuotteesta saatavilla kaikki mahdolliset sertifikaatit, tekniset ominaisuudet, eri värivaihtoehdoilla näytettävät valokuvat tai virtuaalinen 3D-malli tuotteesta. Riittää, että pystyy identifioimaan oikean tuotteen ja tilaamaan sen mahdollisimman edullisesti.

Mitä tästä pitäisi oppia?

Toivottavasti ei mitään, ainakaan sitä ilmeisintä viisautta, että tyhmä työtä tekee…

Halpa vs. fanituote

Käytiin keskustelua erään yrityksen tuotepäälliköiden kanssa, että pitäisikö niitä tuotetietoja rikastaa, koska rikastaminen tietysti maksaa ja ne kulut näkyvät sitten viimekädessä kuluttajalle korkeampina hintoina. Toisaalta business-guru Porterin mukaan yrityksellä on kolme vaihtoehtoista strategiaa: olla teknologiajohtaja, asiakkuusjohtaja tai kustannusjohtaja – siis markkinoiden halvin. Jos yritys on päättänyt profiloitua alansa kustannusjohtajaksi, voidaan tämä keskustelu tuotetiedon laadusta lopettaa saman tien. Mutta jos strategiana on olla asiakkuusjohtaja, siis yritys jonka asiakkaat eivät ole oikeastaan asiakkaita vaan faneja, mielestäni keskustelua kannattaa jatkaa – ja pitkään.

Säästöpossu

Tuotteen erottautuminen tuoteinformaation avulla

Pelkästään tuotevastuulain perusteella tuotteen valmistajalla on velvollisuus toimittaa tuotteestaan KAIKKI tarvittava informaatio tuotteen turvalliseen ja asianmukaiseen käyttöön. Velvollisuus on tietysti tuotteen valmistajalla tai tarkemmin IPR-oikeudet omistavalla taholla, mutta vastuullinen ja asiakkaistaan välittävä toimittaja välittää tiedot valmistajalta loppukäyttäjälle ilman eri pyyntöä.

Kuka siis tuotetiedon rikastamisen maksaa? Edellisessä kappaleessa oikeastaan annettiin jo vastaus. Viimekädessä tämä on tuotteen valmistajan intressissä kahdestakin syystä. Ensinnäkin riskinhallinnan näkökulmasta; kukaan ei halua julkista oikeudenkäyntiä siitä syystä, että kissa on kuollut mikroaaltouuniin, koska valmistaja ei ollut kertonut, ettei mikroaaltouunissa voi kuivata eläimiä. Ja toiseksi siitä syystä, että varsinkin sähköisen kaupankäynnin aikana kuluttajat tekevät ostopäätöksen saatavissa olevan datan perusteella, koska tuotetta ei päästä hypistelemään tai kysymään myyjältä tarkempia tietoja. Tuotteen erottautuminen tehdään tuoteinformaation avulla.

Tuotedatan laatu toimitusehdoksi

Varsinainen pointti tässä on se, että ostajien pitää vaatia riittävän rikas informaatio tuotteen valmistajilta. Tukkukauppamaailmassa valmistaja tai toimitusketjussa edeltävä toimittaja pyrkii myymään suuria eriä kaupan hyllylle, ja heidän kannaltaan kiinnostus loppuu kun rahat toimituksesta on saatu ja riski tuotteiden myynnistä loppuasiakkaalle siirtyy kauppiaalle. Kauppiaan – tässä tapauksessa ostajan – mahdollisuus vähentää riskiä siitä, että tuotteet jäävät hyllyyn, kun kilpailija myy samat tuotteet halvemmalla, pienentää se, että tuoteinformaatio on riittävän rikasta ja kuluttajaa houkuttelevaa. Ostajan pitää siis osata vaatia kaikki haluamansa informaatio toimittajalta. Tuotedatan laadun pitää olla yksi toimitusehto, jonka perustella toimitukset hyväksytään. Käytännössä osto-organisaatioon ja tavaran vastaanottoon tarvitaan täysin uusi toiminto – tuotedatan laadun määrittely ja valvonta. Ostavalla yrityksellä pitää olla tietysti kyky ottaa data haltuun ja välittää se edelleen omissa prosesseissa mahdollisimman automaattisesti.

Jos palataan tarinan alkuun, niin kollegani haki pohjaventtiilin loppujen lopuksi läheisestä rautakaupasta, joka kaiken lisäksi sattui olemaan se halvin….

Näillä saarnoilla kohti kesää.

PDM Preacher

Vaaleanpunaisia omenia

Peter Benson heitti ECCMA:n kesäkuun uutiskirjeessä mielenkiintoisen esimerkin hierarkisten luokittelujen ongelmista. Vaikka yritykset orjallisesti noudattaisivat UNSPSC – luokittelua tai jotain muuta standardia, joka pohjautuu hierarkisuuteen, törmätään vääjäämättä jossain vaiheessa hankaluuksiin. Sama nimike näyttäisi yksiselitteisesti kuuluvan useampaan luokkaan.

Peterin esimerkki oli omenat – ei se puhelimiakin valmistava IT-yritys, vaan tämä ihmiskunnan historiassa merkittävää roolia näytellyt hedelmä, jota Aatami ja Eeva maistelivat ja joka Newtonin päähän pudotessaan mullisti käsityksen maailmankaikkeudesta.  Siis ruokakaupan hyllyiltä löytyvä tuote ”Pink Lady® apple”, joka on UNSPSC luokittelussa määritelty kahdeksaan (8) eri luokkaan:

Pink lady apple UNSPSC luokat

Pink lady apple UNSPSC luokat

Tuon omena-esimerkin voi käydä lukemassa originaalina täältä, hyvä tarina: ECCMA June Newsletter

Esimerkki on loistava siinä mielessä, että siinä esiintyy lähes kaikki tyypilliset nimikeluokittelussa tehtävät virheet. Ensinnäkin Pink Lady® on rekisteröity tavaramerkki – siis brandi. Sitä ei kannata sotkea esimerkiksi termiin, joista muodostuu yrityksen sanasto.

Viime aikoina olemme tehneet useampia sanastoprojekteja, joissa brandi-nimien ohella on tullut vastaan erilaisia apusanoja, kuten ylä, ala, taka, sivu, oikea, vasen. Pahimmillaan sanastossa on termejä tyyliin: ”1. vasen tukivarsi”, ”2. vasen tukivarsi”, ”3. oikea tukivarsi” … Tämä generoi tietysti kielenkääntäjälle töitä, kun kaikki variaatiot käännetään jopa kymmenille kielille.

Loputon suo

Omena-esimerkissä luokittelutekijöihin on lisäksi sotkettu viljelysmenetelmä sekä jälkiprosessointi, joka johtaa siis jäädytettyihin orgaanisesti viljeltyihin omeniin sekä jäädytettyihin muuten vaan viljeltyihin omenoihin. Koska ryhmä ei vielä kerro, onko omenat jäädytetty kokonaisina, viipaloituina vai murskattuina tarvitsemme todennäköisesti vielä lisää ryhmiä. Tällä mallilla suo on loputon. Konepajamaailmassa tyypillisin luokittelusynti on sekoittaa nimikkeen käyttökohde ja funktio – siis esim. KIINNITYSLAIPPA vs. MOOTTORIN KIINNITYSLAIPPA, KYTKIMEN KIINNTYSLAIPPA, NOSTURIN NH15 KIINNITYSLAIPPA jne

Hierarkisuus sinänsä on erittäin ymmärrettävää, koska ihmiset ja varsinkin me insinöörit olemme tottuneet jäsentämään asioita hierarkisesti. Tietojärjestelmät eivät hierarkisuutta tarvitse, joten näin tietointensiivisenä aikana olisi hyvä yhdistää nämä molemmat asiat. Tietomallin luonnissa siis pyritään välttämään kiinteitä hierarkioita, jottei synny duplikaatteja, mutta käyttäjälle pitäisi pystyä asiat tuomaan tarpeen mukaan erilaisten näkymien ja polkujen kautta.

ISO 8000 mukainen kuvaus

ISO 8000 mukainen kuvaus

Tässä hypätään nyt hieman idealistiselle puolelle. Koko nimikkeistön attributisointi kyseiseen tasoon on monelle yritykselle tekemätön paikka. Tietotekniset työkalut ja algoritmit kyllä työssä auttavat mutta puhutaan joka tapauksessa megalomaanisesta työmäärästä, jos nimikemäärä on satoja tuhansia.

Suunta kyllä kannattaa pitää mielessä ja aloittaa esimerkiksi myytävistä omista tuotteista, toimittajat nimittäin vastaavat ostokomponenttien jalostamisesta, mikäli haluavat niitä myydä 😉

PS: En siis mitenkään halua kyseenalaistaa UNSPCS-luokittelun käyttämistä – päinvastoin, mutta sitä kannattaa käyttää omiin tarpeisiin järkevästi soveltaen.

Tässä kesäkuun saarna. Eiköhän lähdetä nauttimaan kotimaisista, UNSPSC-vapaista, kirkkaan punaisista mansikoista.

-PDM Preacher

Missä se kura syntyy ja kuka siitä on vastuussa?

Kallekin jo aiemmassa kirjoituksessa viittasi otsikossa mainittuun aiheeseen, joka oli tänä vuonna Talentum Eventsin järjestämän Master Data Management 2012 -seminaarin esitekstinä. Seminaarissa moni puhuja korosti ihmisen merkitystä hyvälaatuisen tiedon hallinnassa, eikä varmasti turhaan. Yksittäisen tiedon laatuhan syntyy sitä syötettäessä.

Seminaarissa nähtiin esimerkkejä hyvistä käytännöistä. Niissä kaikissa oli jotain yhteistä. Master datan vastuu oli nimetyllä tiimillä, joka myös hallitsi dataa. Globaalin tason tiimi ylläpitää nimikedataa, ja tiimiltä pyydetään uutta nimikettä sitä tarvittaessa. Koska tiedon laatu on tiimin vastuulla, perustettava nimike tulee syötettyä tarkasti: oikeassa muodossa ja oikeat tiedot oikeissa kentissä, mahdollisen datastandardin mukaisesti. Luonnollisesti tiimi huolehtii myös siitä, ettei duplikaatteja pääse syntymään. Eräs toimija kertoi heidän sisäisen SLA:nsa uuden nimikkeen luonnille olevan 48 tuntia. Äkkiseltään ajateltuna tuon kuvittelisi aiheuttavan käyttäjäkunnassa nurinaa, mutta kokemukset ovatkin päinvastaisia. Ehkä suuri osa aiemmin nimikkeitä luoneista käyttäjistä on omakohtaisesti kokenut tuskaa miettiessään, mitä mihinkin kenttään pitää syöttää, missä muodossa syöte on, mitä yksiköitä käytetään missäkin, onkohan nimike jo olemassa –  tarvittavista kieliversioista puhumattakaan. Nimiketiimin palvelu ei siis ainoastaan paranna nimikedatan laatua, vaan poistaa myös peruskäyttäjiltä työtä, josta he eivät välttämättä pidä.

Vaikka nimiketiimin sisäinen prosessi on yksinkertainen, huolehtii se systemaattisesti ja jatkuvasti tiedon laadusta.

Ihmistyön tärkeyden ohella pitää työkalujen olla kunnossa siten, että ne tukevat mahdollisimman hyvin laadukkaan nimiketiedon tuottamista, ja että laadukas tieto saadaan luotettavasti yrityksen muihin järjestelmiin.

Sponsori

Toinen seminaarin esityksissä esiin tullut yhteinen piirre hyvissä ja huonoissa käytännöissä oli sponsori. Hyvissä käytännöissä master datan käytännöillä oli korkean tason, usein ylimmän johdon, ”tukija” yrityksessä. Huonoissa käytännöissä tuo niin sanottu sponsori puuttui. Ilman korkeimman johdon ymmärrystä ja sitä kautta tukea ei hommaan satsata tarpeeksi resursseja. Tai se joutuu jopa säästötoimien alle, vaikka jotain hyvää olisi saatu aluilleen. Viimeksi eilen kuulin asiakkaamme kertovan, että resursseista on joutunut alkuvaiheessa hieman tappelemaan. Onkohan kyse ollut juurikin riittävän korkean tason sponsorin puutteesta?

Mistä alkuun?

Yrityksissä on huomattava määrä tietoa, johon olisi hyödyllistä soveltaa MDM-käytäntöjä. Nimiketieto on asiakastietojen ohella tyypillisesti eniten ongelmia aiheuttava osa-alue, kun mietitään millaisiin raportteihin asiakastiedoilla tai nimiketiedoilla on vaikutusta. Puhumattakaan raporteista, joissa molemmat ovat vaikuttavia tekijöitä. Ja vielä kun mietitään, mitä esimerkiksi ryvettynyt nimikedata tarkoittaa raporttien luotettavuudelle, voi vain arvailla miten hyviä päätöksiä raporttien perusteella tehdään. Nimiketieto ei ole siis lainkaan hullumpi kohde aloittaa Master Data -käytäntöjen hyödyntäminen. Toki tuon ”aloittamisen” usein kuvitellaan olevan helppo ja kokonaisuutenakin kohtuullisen pieni juttu. Järjestelmän suhteen kyseessä ei ole järisyttävän valtava hanke, mutta toimintamallien muuttaminen keskitettyyn datan hallintaan on usein se, mikä vaikuttaa läpi organisaation enemmän tai vähemmän. Toki jos MDM-käytännöt otetaan käyttöön esimerkiksi ERP-hankkeen yhteydessä, on se tietysti osa massiivista kokonaisuutta. Tärkeää on luonnollisesti miettiä hyvin tarkkaan kunkin organisaation tavoiteltu prosessimalli, mahdollinen tiedon standardointi, välineet ja integraatiot, sekä tietysti tarvittava harmonisointityö olemassa olevan datan laadun saattamiseksi oikealle tasolle. Ja menestykseen tarvitaan vielä se sponsori.

Kura syntyy loppukäyttäjän ja päätten välilläAlkuperäiseen kysymykseen: Missä se paljon puhuttu kura syntyy ja kuka viime kädessä on vastuussa? Suurin osa kurasta syntyy suuren porukan näppäimistön ja selkänojan välissä. Vastuuseen siitä ei oikein tahdo saada ketään.

Kannattaisiko keskittää nimikedatan luomisen ja ylläpitämisen vastuu rajatulle porukalle, jolla on käytössä hyvät työkalut, yksinkertainen mutta kuvattu prosessi, ja se sponsori. Kuraa ei enää synnykään ja tarpeet massiivisille datan harmonisoinneille poistuvat tulevaisuudessa.

– Jani –

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 –

2011 Top 3 artikkelit

Blogimme elinkaaren ensimmäinen neljännes alkaa olla pikkuhiljaa lopuillaan. Tänä aikana blogiin on kirjoitettu hyvinkin erilaisia artikkeleita, joita yhdistää yhteinen teema: Tuotetieto. Kuluneen neljänneksen aikana on myös vietetty kesälomat, joka näkyi selvästi heinäkuun ja elokuun alun lukijamäärissä.

Ajattelin jakaa teillekin kolme suosituinta artikkelia kuluneen kolmen  kuukauden ajalta, joten tässä tulee:

1. Tuotteistamisesta tehoa vai tuhoa? (17.6.2011)

Palvelukuvaus armeijan tyyliinTuotteistamisen nimeen on vannottu pitkään. Sen avulla saadaan tekeminen jämäkäksi ja sähläystä vähennettyä, ja onhan se tuotetiedon parissa työskenteleville elinehto. Tämän päivän käsityksen mukaan melkein mitä tahansa voidaan tuotteistaa, terveydenhuoltopalveluista paperikoneiden huoltoon […]

2. MDM – Back to Basics – 1/2 (23.8.2011)

Kun tietomalli ei ole oikein...MDM eli Master Data Management on kuin kuuma peruna, joka polttelee monien suussa ja nousee esille useissa eri yhteyksissä. Mitä MDM sitten oikeasti on? Sitä heräsin itsekin tässä miettimään, kun minua pyydettiin erään julkaisun yhteydessä lyhyesti kertomaan, miten itse määrittelen MDM-järjestelmän […]

3. Onko nimikkeestä hyötyä juuri minulle? Pragmaattinen nimikelaadun näkökulma (21.6.2011)

Nimikkeen laatuvaatimukset

Perinteisten tiedon laatunäkökulmien syntaktisen ja semanttisen rinnalle on noussut, mielestäni varsin oikeutetusti, pragmaattinen tiedon laatunäkökulma. Pähkinänkuoressa pragmaattinen näkökulma  vastaa kysymykseen ”Onko siitä tiedosta mitään hyötyä juuri minulle?”[…]

Kiitoksia kaikille lukijoille! Urhea kirjoitustiimimme jatkaa edelleen tuotetiedon maailman monipuolista penkomista ja tutkimista. Jos sinulla on ideoita tai toiveita artikkelien aiheiksi, niin voit nyt laittaa toimitustiimillemme palautetta (risuja & ruusuja) blogista täältä.

Yksiselitteiset tiedot, kiitos!

Auton huoltoon liittynyt aiempi blogijuttu kirvoitti työkaveriltakin autoon ja tiedonlaatuun liittyvän kokemuksen.

Työkaveri oli ollut ohittamassa edellä ajavaa, kun autosta yhtäkkiä hävisi tehot. Onneksi paluu omalle kaistalle onnistui, ja sitten suorinta tietä autohuoltoon. Huoltomies pääsi jyvälle varoitusvalon indikoimasta ongelmasta; hiukkassuodattimen paine-eroanturi oli rikkoutunut. Oikea anturi löytyi varastosta ja vaihto sujui käden käänteessä, joten ei muuta kuin takaisin tien päälle.

Auto piiputtaa kesken ohituksen

Matka ei kuitenkaan sujunut odotusten mukaan, vaan hetken ajon jälkeen ongelma palasi. Tehot lähtivät ja nyt myös kojelaudan kaikki varoitusvalot alkoivat vilkutella. Oli palattava huoltoliikkeeseen, jossa todettiin että vikakoodi viittasi edelleen anturiin. Auto jäi huoltoon tutkittavaksi.

Parin päivän päästä tuli soitto: Vika löytyi ja auton saa hakea. Vaihdettu paine-eroanturi oli osoittautunut väärän painealueen anturiksi. Huoltomies oli hyvässä uskossa vaihtanut osan; koodi oli oikean anturin koodi. Kävi vain ilmi, että kahden eri painealueen anturilla oli vahingossa sama koodi, eikä muita tarkentavia tietoja ollut.

No, auton omistaja selvisi episodista ohitustilanteen sydämentykytyksillä ja parilla ylimääräisellä reissulla huoltoliikkeeseen – korjauskulut ja anturi kun menivät takuun piikkiin. Autoliikettäkään ei yhden ylimääräisen paine-eroanturin kustannus heilauta, vaikkakin siihen tällä kertaa tuli päälle parin-kolmen päivän työt. Ja laina-auto.

Tuotetiedon näkökulmasta tapaus oli kouluesimerkki siitä, miten hyvälaatuinen, yksiselitteinen data on edellytys toimivalle tilaus-toimitusketjulle ja siten asiakastyytyväisyydelle. Sama käänteisesti; ilman luotettavaa tuotetietoa ei ole luotettavia toimituksia eikä tyytyväisiä asiakkaita.

– Lilli –

Sitä saa mitä tilaa

Jatketaan Maijasen Jannen viime viikolla aloittamaa tiedon laadun tarkastelua:Mikä on ISO8000-sertifioitu laatumääritelmä

Tiedon laadun merkitys on kovaa vauhtia kasvamassa, mutta jatkuvasti nousee esiin kysymys: mitä se tiedon laatu oikein on? Hyviä ja oikeita määrityksiä on varmasti useita, mutta ECCMA:n puuhamies Peter Bensonin määritelmä on mielestäni varsin naseva:  ”Quality Data is Portable  Data”.

Lyhyt lause ja sen sisältö aukeaa kun perehtyy ISO 8000 -standardiin. Standardihan on luotu, jotta tietoa voitaisiin välittää laadukkaasti organisaatioiden välillä. Teknisen syntaksi-  ja semantiikkamäärittelyn alla on periaate, että tiedon tarvitsija pyytää tarvitsemaansa tietoa. Vastuu on siis tiedon tarvitsijalla, kuulijalla. Kuulijan pitää ensin määritellä tietomalli, eli päättää mitä tietoa tarvitsee. Kun ymmärtää mitä tietoa tarvitsee ja missä muodossa, tiedon toimittajan on huomattavasti helpompi vastata pyyntöön laadukkaasti.

Tiedon siirrettävyyden merkitys laatutekijänä korostuu verkostoituvien ja tuotantoaan siirtelevien yritysten välillä. Erilaiset kielet ja kulttuurit eivät helpota tiedon laadukasta välittämistä, mutta tehtävä ei ole ollenkaan mahdoton. Tehtävää helpottamaan on laadittu useitakin standardeja, valmiita luokitteluja ja sanastoja. Toisaalta mitkään ulkopuoliset luokittelut ja standardit eivät poista sitä tosiasiaa, että kotiläksyt pitää tehdä. Prosessiajattelun rinnalla pitäisin tasa-arvoisesti rinnalla tietomalliajattelua, kutsuttakoot sitä vaikka informaatioarkkitehtuuriksi. Laadukas tieto on siis sellaista, jota voidaan välittää ihmiseltä, järjestelmältä ja organisaatiolta toiselle siten, että se on ymmärrettävää. Jotta tähän päästäisiin pitää ymmärtää mitä tarvitsee, sillä sitä saa mitä tilaa…

Janne J.

Datasta informaatiota