14.11.2019 / Antti Lyytikäinen

Noniin! Olet lukenut edelliset blogikirjoitukseni ja tullut siihen tulokseen, että tietovarastosi haisee kellarilta ja on ehkä aika tehdä jotain.

Mikäli olet SAP-asiakas, sinua varmastikin askarruttaa mihin SAP:n tietovarastotarjooma on menossa ja mitkä olisivat aikaa kestäviä valintoja esimerkiksi kolmen vuoden aikajänteellä. Suunta vaikuttaa hyvin selvältä – SAP keskittyy isoin satsauksin pilvitarjoomansa kehittämiseen.

Pilviratkaisut tuovatkin niitä tuttuja hyötyjä: nopeutta, joustavampaa hinnoittelua, yksinkertaisuutta ja skaalautuvuutta. Uusimpaan tietovarastotuotteeseen SAP Data Warehouse Cloudiin on luvattu juuri tätä ja ajatuksena tämä tietenkin kutkuttaa, varsinkin kun perinteisesti on-premise-pokerin hinta on ollut jotain aivan muuta kuin nyt luvattu käytettyyn tallennustilaan ja prosessoriaikaan perustuva kuukausihinnoittelu.

Tarkempia hintatietoja varmaan saadaan lähiaikoina, niitä odotellessa voi tutustua SAP Data Warehouse Cloudin ilmaiseen kokeilujaksoon.

Onko tuote sitten valmis itsenäisesti korvaamaan esimerkiksi ikääntyvän SAP Business Warehouse 7.x :n vai tulisiko harkita esimerkiksi SAP BW/4HANA-projektia?

Otin osaa SAP Data Warehouse Cloudin beta-ohjelmaan ja vaikka osa toiminnallisuuksista ei ollut beta-vaiheessa kokeiltavissa, uskoisin että yksinkertaisempiin tarpeisiin pilviratkaisu soveltunee varsin nopeasti. Lisää kokemuksia uudesta tuotteesta sain SAP TechEdissä ja varsinkin mallinnuksen helppous sekä suoraan tietovarastovälineeseen integroitu  SAP Analytics Cloud yhdessä teki vaikutuksen jopa kaltaiseeni vanhaan kyynikkoon.

Spaces-konseptin myötä tietomallinnus on toteutettu siten, että mennään aika paljon lähemmäs visiota itsepalvelu-BI:stä, jossa myös loppukäyttäjät pystyvät yhdistelemään tietoja joustavasti. SAP HANA Cloud -alustalla toimiva SAP Data Warehouse Cloud tuo uutta myös persistenssiin: tietoa voidaan säilöä usean tehoisella ja hintaisella medialla aina muistista data laken kautta hadoopiin asti ja lisäksi ratkaisuissa voidaan käyttää myös virtualisointia, jossa tiedot luetaan lähteestä säilömättä niitä erikseen tietovarastoon. Kaiken kaikkiaan olen pitänyt näkemästäni tähän mennessä.

Tuote on kuitenkin uusi ja ominaisuuksiltaan vielä rajattu ja varmasti juuri tästä syystä SAP tarjoaa lähitulevaisuuteen hybridimallia on-premise-sovellusten ja pilvimaailman välillä. Siirtymävaihe on varmaan arkitodellisuudessakin juuri tätä, eli nykyratkaisua kehitetään ja ylläpidetään ja pilviratkaisua kokeillaan uusiin tarpeisiin ja laajennetaan tarvittaessa. Toisaalta kilpailijoiden ratkaisutkaan eivät ole 100% verrattavissa esimerkiksi ominaisuuksilla kyllästettyyn BW:hen. Yhdellä hyppäyksellä pilvitietovarastoon ei siis ehkä vielä mennä, mutta ajateltavaa riittää, mikäli vanhan uusiminen on kovinkin ajankohtaista.

SAP Data Warehouse Cloudin kehitystahti on uskottavan ripeä – uusia iteraatioita uusine ominaisuuksineen julkaistaan muutaman viikon välein. Samalla vauhdikkaalla metodilla kehitetty SAP Analytics Cloud on melko lyhyessä ajassa kasvanut hyvinkin uskottavaksi tuotteeksi raportoinnin, analyyttisten sovellusten,  visualisoinnin ja suunnittelutoimintojen saralla.  Tämän vahvistaa esim. BARC BI Survey, joka on hyvin mielenkiintoista luettavaa.

Analytics Cloudin ottaminen integroiduksi osaksi lähes jokaisen SAP-pilvituotteen (S/4HANA Cloud, Successfactors, Cloud for Customer jne.) operatiivista analytiikkaa osoittaa myös SAP:n omaa uskoa tuotteeseen. Tästä kertoo myös se, että SAC on jatkossa SAP:n analytiikkatuotestrategian kärjessä, ks. tämä tuore  SAP Analytics & Business Intelligence statement of direction.

SAP Analytics Cloud onkin melko luonteva paikka aloittaa analytiikan pilvisiirtymä huokean hintansa ja tuotteen maturiteetin ansiosta. Seuraava askel voi olla sitten sen tietovaraston seuraaminen perässä.

Blogisarjan muissa osissa:

 


13.11.2019 / Antti Lyytikäinen

Miksi valita BW/4HANA?

Ei ainakaan nimen takia. Kirjainlyhenteet, numerot ja kenoviivat samassa pötkössä, herra mun vereni. SAP tunnetaan talona, joka vaihtaa tuotteidensa nimiä, eikä se aina ole hyvästä. Tuoreessa muistissa on esimerkiksi työpöytien ja visuaalisen analytiikan luomisen välineiden SAP Design Studion ja Lumiran niputtaminen Lumira-nimen alle – entuudestaan hyväksi havaittu Design Studio sai tässä iholleen tatuoinnin, jota varmasti katuisi, jos omaisi tietoisuuden. Silti toivon, että nämä kenoviivatuotteet vaihtaisivat nimeään.

Ei nimi kuitenkaan itse tuotetta pahenna, sillä kyseessähän on robustiksi jalostunut tietovarasto-ohjelmisto, luonnollinen lisä SAP-merkkisen toiminnanohjausjärjestelmän kaveriksi. Tällä SAP ERP + Business Warehouse (BW) parivaljakolla useat yritykset ovat pärjäilleet oikein mukavasti pitkään. Moni BW-installaatio alkaa kuitenkin olla elinkaarensa päässä ja hyppy tutusta 7.x -ympäristöstä ”uuteen” BW/4HANAan arveluttaa jo senkin takia, että uusin iteraatio on erikseen lisensoitava tuote.

BW:n käyttöönottoa ja tunnettuutta onkin taatusti jouduttanut se, että sen on saanut aiemmin ikään kuin kylkiäisenä. Kolikon toisella puolella on kuitenkin se fakta, että monissa asioissa kilpailijoitaan parempi tuote ei ole tuottanut itsenäisesti pennin pyörylää toimittajalleen, kehityspanostuksista huolimatta.

Tätä rahareikää on sitten tilkitty erilaisilla lisenssikummajaisilla (OpenHUB-lisenssin tuntenevat kaikki BW-kiemuroissa pitkään painineet) ja rajoituksilla, jotka pääosin liittyvät datan vientiin ulos järjestelmästä. Ilmainen mutta suljettu järjestelmä.

BW/4HANA on datan loppukohteista vähemmän mustasukkainen: dataa saa viedä toisiin järjestelmiin, nimettyjä SAP-käyttäjiä ei tarvita ja analyytiikkavälineet tietovaraston saa valita vapaammin itse. Myös kolmannen osapuolen lähteistä tiedon tuominen sisään on aiempaa joustavampaa. Tämän päivän monitoimittajaympäristöissä nämä ovat käytännössä pakollisia vaatimuksia. Maksullinen mutta avoin järjestelmä.

Teknisesti BW/4HANAssa on paljon samaa kuin viimeisimmissä 7.x -sarjan versioissa. Mallinnus on kuitenkin siirtynyt käytännössä kokonaan SAP GUI:sta Eclipseen, joten kulmakerrointa on jonkin verran myös vanhoille BW-ketuille. Mallinnus itsessään on aiempaa yksinkertaisempaa, koska ”osattavaa” on vähemmän, sillä mallinnusobjektien määrä on tippunut radikaalisti. Napanuora 3.x: n antiikkisiin objekteihin on myös viimein lopullisesti katkaistu.

Ehkä suurin lisäarvo tulee kuitenkin uudistetusta Business Contentista. Business Content tarkoittaa SAP:n toimittamia valmiita malleja, joilla mahdollistetaan nopea tietomallien kehitystyö lähteestä raportille asti. Eli esimerkiksi talouden tai logistiikan osa-aluille on mahdollista aktivoida valmis sisältö, jolla perustarpeet tyydyttävä raportointiratkaisu on helppo toteuttaa. Tämä toki on ollut BW:n etu kilpailijoihin nähden jo vuosikaudet, mutta nyt sisältö on tehty uusiksi uudempia mallinnuskäytäntöjä hyväksikäyttäen. Esimerkkinä tästä on näkymien käyttö fyysisten objektien sijaan, kannan vaatima tila pienenee huomattavasti.

Viimeinen motivaattori voi olla käytännön pakko: 7.x -tuki loppuu joidenkin vuosien kuluttua, vanhan järjestelmän elinkaari voi olla jo turhankin pitkä, tietotarpeet pakottavat viemään tietoa muihin kohteisiin, ylläpito hankalaa, infran uusiminen liian suuri investointi suuren kannan vuoksi, heikko tai turhan monimutkainen toteutus, jossa häärännyt liian monta kokkia ja niin edelleen.

Miksi siis BW/4HANA?

  • Avoimuus
  • Aiempaa joustavampi ja helpompi mallinnus
  • Uusi Business Content
  • Tukea tiedossa 7.x -versioita pidempään
  • On jo korkea aika

Bilot tuntee SAP:n, BW:n, HANA:n ja näiden yhdistelmät sekä vaihtoehtoiset ratkaisut. Vyöllä komeilevat tosielämän toteutukset, joista kerromme mielellämme lisää.

Blogisarjan muissa osissa:


12.11.2019 / Antti Lyytikäinen

Seuraa täysin hypoteettinen skenaario, yhtymäkohdat todelliseen elämään ovat täysin sattumanvaraisia.

Otetaan yksi kappale keskisuuria tai suuria yrityksiä. Laitetaan sinut vastuuseen raportoinnista.

Yrityksen raportointi on rakennettu SAP Business Warehouse -tietovarastoalustalle, se kattaa ehkä ydintarpeet talousraportoinnista, ehkä logistiikkaraportoinnin ja muita osa-alueita. Tärkeä päivittäinen, viikoittainen tai kuukausittainen työväline.

Tietovarasto on rakennettu ERP-projektin jälkitöinä 11 vuotta sitten. Peruspäivitykset on tehty, mutta muuten tietovarastossa alkaa haista jo kellarilta. Tukitoimittaja on vaihtunut kolme kertaa ja se yksi taitava kaveri, joka aikoinaan teki paljon itse, on jo lähtenyt talosta.

Raporttien ajamiseen käytät raportointiportaalia, josta vartin tiimalasin jälkeen saat luvut ruudukkomuodossa selaimeesi. Äh, unohdit kuitenkin täyttää yhteen triviaaliin muuttujavalintaan oikean arvon.

Ajat uutta raporttia toisen vartin.

Tiputat luvut Exceliin ja teet taulukkoon käsin korjauksia, koska tiedät että osa luvuista ei näy uusimman organisaatiorakenteen mukaisesti. Olet korjannut sen käsin jo kahden edellisenkin organisatorisen mullistuksen jälkeen, menee jo rutiinilla.

Mutta hetkinen, kuluvan kuukauden tiedot puuttuvat. Avaat tiketin.

Palvelusopimustason mukaisesti saat iltapäivällä vastauksen, että asiaa tutkitaan.

Seuraavana päivänä tikettiin on ilmestynyt tekninen selvitys aiheesta: tiedot lähdejärjestelmältä lataava prosessiketju on jumittunut koska taulualue on täyttynyt, tulee virhettä ja monitorit ovat ihan punaisella. Tukiorganisaatiolla propellit pyörivät hatuissa niin että savu nousee, pitää soittaa Basis-asiantuntijalle joka työskentelee eri aikavyöhykkeellä, avata palvelupyyntö SAP:lle, tai jotain muuta mukavaa. Kuukausiraportoinnin takaraja alkaa uhkaavasti lähestyä ja tiedot pitäisi vielä visualisoida Powerpointilla johdoportaalle ymmärrettävään muotoon.

Tukipalvelun tarjoaja koittaa ratkaista ongelmaa. Muutaman, erittäin pitkään kestävän, uusintalatauksen jälkeen järjestelmäjumalat ovat suosiolliset ja uusimmat tiedot on ladattu. Huraa, pääsit käyttäjänä pälkähästä! Jupiset kuitenkin, kun kesti taas kauan.

Juurisyy jää kuitenkin epäselväksi, koska tukipalveluoperaattorin pitäisi sitä varten perata satoja rivejä dokumentoimatonta ja kommentoimatonta koodia siirtosääntöjen abap-rutiineista, ratkoa miksi osa ratkaisuista löytyy vain tuotantojärjestelmästä, keksiä miksi käytetään räätälöityä ratkaisua standardin sijaan, ymmärtää miksi tauluista toisiin ladataan tietoja loputtoman tuntuisissa loopeissa, ymmärtää miksi asiakkaan ympäristössä käytetään jatkuvassa tuotantokäytössä objekteja jotka on nimetty ”Do not use!!” ”OLD”, ”ZDELETE, ”, ”obsolete”, miksi käytetään vanhentuneita mallinnustapoja, miksi latausjärjestystä ei datan keskinäisen riippuvuuden takia voi muuttaa ja mitäköhän ihmettä se yksi taitava kaveri, joka on jo lähtenyt talosta, oikein on ajatellut tehdessään kymmenen päällekkäistä DSO-taulua tietomalliin…

No, jos se toimii, niin ei kosketa siihen, eikä tätä nyt voida ainakaan tukipyyntöihin varatulla ratkaisuajalla tehdä, aika ei riitä. Käyttäjäkin sai jo datansa ja tikettijonossa on jo viisi uutta tapausta ratkottavaksi.

Tuen näennäisen kalleuden ja historiallisten uponneiden kustannusten takia kukaan ei uskalla ajatellakaan, että tehtäisiin asiat uudestaan fiksummin. Ehkä uusitaan vain se-ja-se raportointialue nyt ja katsotaan puolen vuoden päästä, kun käyttäjät itsepintaisesti käyttävät sitä vanhaa versiota, kun ovat siihen tottuneet.

Pitkästä elinkaaresta, moneen kertaan vaihtuneista toimittajista, nopeista ratkaisuista, purkkavirityksistä, pitkistä latausajoista, mysteerikoodista, jo lähteneistä taitureista ja päällekkäisistä nimeämiskäytännöistä se iäkkäämpi tietovarasto aika usein koostuu.

Mikäli edellä mainittu soittaa kelloja, olisiko aika auditoida nykyiset ratkaisut ja käytännöt?…

Blogisarjan seuraavissa osissa syynissä:

• BW/4HANA – Tietovarastoinnin työjuhta
• SAP Data Warehouse Cloud – Tietovarasto pilvessä


27.05.2019 / Mika Laukkanen

Heti aluksi on mainittava, että tämä blogi on kohdistettu pääasiassa henkilöille, joilla on liittymäpintaa Business Intelligence ratkaisuihin ja nyt niiden parantaminen tekoälyn avulla on alkanut kiinnostaa.


Tekoälyyn liittyvissä esityksissä käytetään usein seuravaanlaista esitystapaa, kun halutaan kuvata mihin tekoäly asemoituu datan hyödyntämisessä.

 

Kuvan alkupää lähtee perusraportoinnista (mitä tapahtui) ja etenee kohti edistyneempää analytiikkaa (ennustamista) – samalla kun vaikeusaste ja ratkaisun arvo kasvaa. Loppupäässä on luonnollisesti kyse nykytermein tekoälystä tai AI:sta.

Pitäisikö kuvaa tulkita niin, että tekoäly on kehittyneempää Business Intelligenceä? 

Yllättävän usein olen törmännyt eri yrityksissä ajatteluun, jossa tekoälyn kehittäminen on sidottu Business Intelligence järjestelmien kehittämiseen. Ajatuksena se, että kun kerätään dataa ja tehdään raportteja, niin sen jälkeen ollaan kypsiä hyödyntämään koneoppimista (tekoälyä) samassa aihepiirissä.

Eli tekoälyprojektien aloittamista saatetaan (turhaan) viivytellä, jos “perusraportointi ei ole kunnossa”.

Kynttilöistä ei kehittynyt hehkulamppuja

Jos katsotaan reaalimaailman tekoälysovelluksia, niin vain melko harvassa niistä on havaittavissa em. kehityskulku raportoinnista tekoälyyn. Seuraavissa tapauksissa ko. esitystapa ei oikein edes toimi. Eikä varmaan ole tarkoituskaan.

  • Kuvantunnistus ja konenäkö
  • Tekstianalytiikka ja luonnollisen kielen tunnistus
  • Ennakoiva huolto reaaliaikaisella IoT datalla
  • Anomalioiden löytäminen Big Datasta
  • Musiikin tai kuvien tuottaminen tekoälyn avulla

Eli tekoälyratkaisuja syntyy paljon alueille, joissa perinteisellä Business Intelligencellä ei ole roolia.

Toisaalta, tekoälyratkaisuja voidaan usein kehittää ilman taustalla olevaa BI ratkaisua vaikka se toisikin lisäarvoa tai asioiden välillä näyttäisi olevan luonnollinen jatkumo.

Otetaan esimerkki asiakasanalytiikasta, vaikka asiakaspoistuma. Jos BI:n ja AI:n sitoo toisiinsa, niin on luonnollista rakentaa ensiksi BI-järjestelmä, jossa asiakastiedot ovat tietovarastossa, josta tehdään nippu raportointia, esim. “kuinka monta % asiakkaista poistuu vuosittain”.  Ja kun tämä on valmiina, niin hyödynnetään tekoälyä ennustamaan, että ketkä ovat seuraavat kytkimen nostajat.

Näin voi toimia, mutta käytännön elämässä on toimittu myös käänteisesti.

Kuvassa on esitetty erään oikean tekoälyprojektin vaiheet. Siinä aloitettiin keräämällä asiakastietoja monista eri lähteistä, vain ennustamista varten. Kun myöhemmin ennustemallit huomattiin toimiviksi (olivat jo tuotannossa), niin ko. tietoja alettiin tuoda BI-järjestelmään.

Kuulin joskus hauskan vertauksen, jossa todettiin ettei kynttilöistä kehittynyt hehkulamppuja. Siinä oli kyse disruptiivista keksinnöistä, hehkulamppu ei ollut vain parempi kynttilä. Mielestäni sama analogia toimii myös aika hyvin BI:n ja AI:n välillä.

Eri tarkoitus, eri kehityspolut

Business Intelligence -ratkaisut ovat nyt ja jatkossa kivijalka yritysten raportoinnille ja analytiikalle, jota ilman ei tule toimeen. Omenakauppiaan tulee tietää monta omenaa meni kaupaksi eilen, viime viikolla ja joulumyynnissä.

Tekoälyratkaisut eivät auta omenakauppiasta vain ennustamaan omenoiden menekkiä, vaan myös tulkkaamaan kiinalaisten turistien omenatiedustelut ja automatisoimaan kirjanpidon.

BI ja AI ratkaisuilla on yleensä eri tavoitteet, mutta myös itse projektit saattavat erota kuin yö ja päivä toisistaan. Näistä syistä en sitoisi niiden kehittämissuunnitelmia liian tiukasti toisistaan riippuvaiseksi.


21.02.2019 / Mika Laukkanen

Kun aloitin työurani 1990 luvun lopulla, niin tietovarastojen ja raportoinnin toteutus oli nykyistä paljon selkeämpää. Tietolähteet olivat pääasiassa relaatiokantoja tai melko yksinkertaisia tekstitiedostoja.  Eikä raportointikaan ollut kovin monimutkaista, koska silloisilla työvälineillä rajat tulivat nopeasti vastaan. Itsensä tunsi kuninkaaksi, jos sai graafin ja taulukon samalle sivulle.  Datan laatu oli toki samaa puppua kuin se nykyäänkin tuppaa olemaan.  Tuon ajan tyypillinen DW arkkitehtuuri oli seuraava.

Nykyiset arkkitehtuurikuvat ovat yksinkertaisimmillaan vastaavia, mutta yleensä kuitenkin monipuolisempia. Nyt on enemmän erilaisia tietolähteitä, samoin kuin datan tallennus- ja esityspään ratkaisuja.

Miksi sitten tietovarastoja alettiin alunperin rakentaa? Tässä muutamia syitä, jotka löytyivät vuonna 2001 tehdyiltä powerpointeilta.

  • Tietojen yhdistely ja harmonisointi eri tietojärjestelmistä
  • Yksi totuus päätöksentekoon
  • Käyttäjien ad-hoc kyselyt mahdollisia ja tietohallinnolle jää aikaa muuhun työhön
  • Tietovarasto historioi yrityksen datat, saadaan aikasarjoja ja analytiikkaa
  • Ei rasiteta operatiivisia järjestelmiä raportoinnilla

Nämä samat argumentit pätevät varsin hyvin vielä nykyäänkin. Mainittakoon että jossakin vaiheessa oli buumi, jonka mukaan kaikki yrityksen datat pitäisi saada keskitettyyn EDW ratkaisuun. Nyt ajatus tuntuu vähän hassulta, mutta ei tuntunut silloin, koska dataa syntyi suhteellisen pieniä määriä ja lähinnä omissa järjestelmissä.

Tietovarastot tehtiin raportoinnin tarpeisiin

Perinteisesti tietovarastoihin tuotava data on määräytynyt raportointitarpeiden mukaisesti. Esimerkiksi talousraportteja varten on tuotu talousdataa ja HR-raportteja varten HR-dataa. Lisäksi tietysti löytyy kombinaatioita, joissa raporteille on yhdistelty eri alueiden tietoja.

Nyt kun tiedetään, että koneoppimis- ja tekoälyratkaisut tarvitsevat dataa oppiakseen, niin eikös ole loistavaa, että vuosikymmeniä dataa on purkitettu tietovarastoihin?

Vastaus on toisinaan kyllä, mutta usein ei.

Kun dataa on kerätty vain raportointitarpeita ajatellen, niin on sattuman kauppaa, että sopiiko se koneoppimisen hyödyntämiseen. Selvennetään asiaa esimerkillä.

Tietovarastoon XYZ kerätään asiakasdataa, josta on tarkoituksena raportoida asiakaskohtaiset eurot tuotteittain, tuoteryhmittäin, asiakassegmenteittäin ja vaikkapa päivätasolla. Kerätään siis tietovarastoon laskutus-, tuote- ja asiakastiedot.

Tässä vaiheessa paikalle saapuu datatieteilijä, joka haluaisi tehdä asiakaspoistumamallin. Hetken dataa tutkailtuaan hän havaitsee, että tietovarastoon ei ole tuotu asiakkaan sopimukseen liittyviä tietoja. Ne olisivat todennäköisesti keskeinen elementti asiakaspoistumamallissa. Tai ehkä sopimustiedot ovat tietovarastossa, mutta niistä tunnetaan vain viimeisin tilanne – ei koko asiakkaan sopimushistoriaa, joka olisi jälleen olennaista asiakaspoistumamallin kannalta. Dataa siis voi olla, mutta siitä ei silti ole olennaista hyötyä.

Olen ollut mukana kymmenissä koneoppimisharjoituksissa, ja vain harvoissa kaikki tarvittava data on ollut saatavilla ns. perinteisestä tietovarastosta. Tyypillisimmät haasteet ovat olleet:

  • Tarvittavaa dataa ei ole ollenkaan tietovarastossa tai vain osittain
  • Dataa on tietovarastossa, mutta liian lyhyeltä ajalta (historiaa poistettu)
  • Tarvittavan datan historiointi on liian harvaa / epätäydellistä

 

Miten huomioida tekoäly tietovarastojen suunnittelussa?

Koska tietovarastojen suunnitteluun ja tekemiseen joka tapauksessa upotetaan valtavia summia rahaa, niin kannattaisi tehdä muutamia toimenpiteitä, jotka tukisivat ajatusta, että tietovaraston sisältö voisi olla syötteenä tekoälyratkaisuille jatkossa. Esimerkiksi.

  • Samalle datalle on hyvä olla useampi käyttötarkoitus (esim. asiakkaaseen liittyvä perinteinen raportointi, asiakaspoistumamallinnus ja asiakaskohtaiset myyntiennusteet).
  • Raportointitarpeiden lisäksi tarvitaan siis näkemystä, että millaisia tekoälyratkaisuja jatkossa halutaan tehdä. Jos ei ole dataa, niin ei tule ratkaisujakaan.
  • Datan historiointi kattavasti. Tämä vaikuttaa mm. tietovaraston mallinnustapaan. Näyttäisi siltä, että Data Vault ei ole hassumpi vaihtoehto vaikka pelkkään yksinkertaiseen BIDW projektiin se saattaakin olla järeähkö menetelmä.
  • Datan määrällä on merkitystä tekoälylle vaikkei raportoinnissa tarvittaisi kuin 3 viimeistä vuotta. Tietovarastoja ei siis kannata tyhjentää ”turhasta datasta”, vaan mieluummin siirtää vanhaa dataa muuhun ympäristöön. Jos vain vähääkään näkee, että sillä voisi olla käyttöä myöhemmin.
  • Kaikkea tekoälyratkaisuissa käytettävää dataa ei tarvitse tai kannata tuoda välttämättä tietovarastoon. Usein on viisaampaa pitää esim. IoT sensoridatat tai nettisivujen verkkolokit jossakin muussa ratkaisussa.

Näillä muutamalla opilla tietovarastoista tulee jo tekoälykelpoisempia. On kuitenkin hyvä huomata, että datan purkittaminen yhteen paikkaan ei itsessään synnytä tekoälyratkaisuja – siihen tarvitaan selkeät business caset. Data toimii sitten mahdollistajana.


9.01.2018 / Mika Laukkanen

Otsikon mukainen kysymys tuli mieleeni, kun eräänä päivänä katselin lävitse Louhian tekemiä koneoppimis- ja AI-projekteja. Kävi nimittäin ilmi, että kymmenistä eri harjoituksista vain murto-osassa datat olivat tulleet yrityksen tietovarastosta tai tietovarastoista (DW, EDW). Noihin tietovarastoihin on kuitenkin upotettu miljoonia, mutta ensimmäisten AI-kokeilujen osalta ne olivat pääosin hyödyttömiä.

Aloin selvitellä asiaa tarkemmin ja syyksi “hyödyttömyyteen” paljastuivat seuraavat kaksi asiaa. 

  1. Tarvittavaa dataa ei ollut lainkaan tietovarastossa
  2. Tarvittava data oli tavallaan tietovarastossa, mutta puutteellisena

Kohta 1 on varsin selvä. Tietovarastot on suunniteltu ihmisen toteuttaman raportoinnin tarpeita ajatellen. Ja nämä raportointitarpeet ovat yleensä historiaan katsovia mittareita, kuten montako omppua myytiin viime vuonna ja paljon niistä jäi katetta. Tai ketkä olivat suurimpia omppujen ostajia. Tai paljonko meiltä jäi omppuja myymättä.

Koneoppimisen ja tekoälyn avulla taas yleensä ratkotaan ongelmia, joilla ennustetaan tulevaisuuden skenaarioita. Esimerkiksi, halutaan ennustaa omppujen hintakehitystä tulevien viikkojen aikana, jotta voidaan ostaa niitä optimaalisella hinnalla.

Miksi sitten esim. tällaisessa keississä perinteinen tietovarasto ei yleensä sisällä relevanttia dataa ennustamisen kannalta?

  • Omppujen hintakehitykseen vaikuttavat kasvattajamaan säätilat –> tuskin löytyy tietovarastosta valmiina, koska niistä ei tehdä BI-raportteja
  • Omppujen hintakehityksen osalta olisi olennaista tietää kulloisetkin markkinahinnat, joilla omput ovat olleet tarjolla –> tietovarastosta kuitenkin löytyy vain ostohinnat

Vastaavia tilanteita tulee jatkuvasti esiin AI-projekteissa.  Lisäksi ne saattavat mennä osa-alueille, joissa ei ns. perinteistä raportointia ole tehty aiemmin ollenkaan. Esimerkiksi lokeista tehtävään vikaantumisen ennustamiseen. Tällöin dataa ei varmastikaan ole firman EDW:ssä. Puhumattakaan kuvien tunnistukseen tai tekstianalytiikkaan liittyvistä projekteista.

Kohdan 2 tilanteessa tietovarastossa on jo melkein relevanttia dataa. Esimerkiksi tietovarastoon on kerätty asiakastietoja ja tehty siitä raportointia. Tässä tilanteessa voidaan törmätä siihen, että dataa ei ole historioitu oikein tai riittävästi. Esimerkiksi asiakaspoistuman ennustamiseksi voidaan tarvita tietoja asiakkaan aiempien sopimustilanteiden statuksista eri ajanhetkinä. Näitä ei kuitenkaan välttämättä ole tallennettu, vaan tietovarastossa on vain viimeisin status asiakkaan sopimustilanteesta.

Dataa on myös voitu summata liian karkealle tasolle, jotta siitä olisi mielekästä tehdä koneoppimista.

Kun tietovarastoja on kehitetty, niin ei vain ole osattu ajatella näitä uudenlaisia tarpeita. Todellinen haaste kuitenkin voi olla, että osataanko vieläkään? Rakennetaan innolla versiota 3.0 EDW:stä ilman, että huomioidaan tulevia tarpeita riittävästi. Tehdään vain parempi ja kattavampi versio vanhasta.

Ketterästi vai hooposti?

Oletaan lähtötilanne, jossa on kaksi yritystä, X ja Y, jotka molemmat haluavat ennustaa omppujen myyntiä ja hintaa. Näillä on kuitenkin erilaiset lähtökohdat tehdä projekti.

  • Yritys X päättää, että tarvittavat datat on tuotava ensiksi tietovarastoon. Pitää käynnistää siis projekti tietovarastotoimittajan kanssa. …(hypätään ajassa eteenpäin..) Kaksi vuotta myöhemmin  datat todellakin löytyvät EDW:stä käyttökelpoisena.
  • Yritys Y taas päättää kerätä datat ensiksi vaikkapa csv-tiedostoihin eri lähteistä ja yhdistellä ne data-analyytikon läppärillä. Tähän kuluu pari viikkoa.

Molemmissa yrityksissä tehdään Deep-Omppu malleja ennustetaan omppujen myyntiä ja hintaa tuleville viikoille. Molemmissa paikoissa päästään samoihin päätelmiin mallin kannalta olennaisesta datasta ja muuttujista. Huomataan että kaikesta kerätystä alkudatasta vain alle puolet on merkityksellistä mallin kannalta.

Nyt yritys X on investoinut jo valmiiksi paljon aikaa ja rahaa viedäkseen tietovarstoon myös merkityksettömät datat. Yritys Y sen sijaan aloittaa vasta tässä vaiheessa datan tietovarastoon viennin – nyt kun tiedätään mistä siellä oikeasti tarvitaan. Kumpihan on fiksumpaa?

Esimerkki saattaa olla vähän karrikoitu, mutta perustuu kokemuksiin useista eri projekteista tällä alalla.

Yhteenvetona

  • Varaudu siihen, että aiemmin tehty tietovarasto ei taivu koneoppimisen ja tekoälyn tarpeisiin
  • Suunnittele tulevat tietovarastot siten, että ne taipuvat
  • Etene ketterästi ja kokeile ensiksi toimiiko tekoälyideat ennen kuin aloitat EDW-projektia sen vuoksi

 


21.08.2017 / Mika Laukkanen

Seuraava kirjoitus on julkaistu Tieke lehden numerossa 1-2017. Jaetaan se nyt täälläkin.


Tärkeintä on laadukas data

Voimme päivittäin lukea uutisvirrasta uusien tekoälyratkaisujen tulevaisuuden potentiaaleista. Datamäärien ja laskentatehon kasvu yhdessä algoritmien kehityksen kanssa ovat potkaisseet tekoälyn kehitysvauhdin uudelle kiertoradalle.

Nykyään lähes kaikki tekoälyratkaisut perustuvat neuroverkkoihin, joiden prosessoitavaksi on ohjattu dataa. Neuroverkko ohjelmoidaan oppimaan datasta, jossa on syötteitä (esimerkiksi asiakkaan taustatietoja ja ostohistoriaa) ja vasteita (esimerkiksi ostiko asiakas tuotteen vai ei).
Näin neuroverkko muodostaa mallin, jonka avulla se ennustaa syötteiden avulla vasteita.

Varmista vahva perusta

Kun tekoälyä ryhdytään valjastamaan liiketoiminnan resurssiksi, ensin onkin ymmärrettävä, että kaikki lähtee laadukkaasta datasta. Fiksuinkaan tekoälysovellus ei palvele tarkoitustaan, jos sille syötetään epärelevanttia dataa. Toisin sanoen: mitä kattavammat ja paremmat datavarannot yrityksellä on, sen järeämmät edellytykset sillä on rakentaa toimivia tekoälyratkaisuja liiketoiminnan eri osa-alueille.

Vältä järjettömät ratkaisut

Datan huonosta laadusta esimerkkinä käy botti, jonka piti opetella twiittailemaan. Valitettavasti Twitter-käyttäjät syöttivät sille rasistisia ja sovinistisia twiittejä, ja bottihan oppi ne nopeasti, ja alkoi heittää vastaavia twiittejä. Kunnes joutui itse jäähypenkille konekatumaan.
Yksi tekoälyratkaisujen heikkous onkin, että niillä ei ole kontekstia ympäröivään maailmaan, ja siksi ne voivat päätyä joissakin tilanteissa järjettömiin ratkaisuihin.

Korvaamaton resurssi

Jatkossa yritysten datavarannot ovat yksi tärkeimmistä kilpailutekijöistä, kun taistellaan paikasta auringossa. Ne ovat tärkeämpiä kuin vaikkapa ohjelmistot tai tekoälyalgoritmit, koska jälkimmäiset ovat melko helposti kopioitavissa tai ostettavissa. Datavarannot ovat taas rahanarvoista omaisuutta, jota kilpailijat eivät voi kopioida. Esimerkiksi Google julkaisee tekoälykoodejaan avoimesti, mutta datasta saa maksaa. Eikä kaikkea dataa tietenkään saa edes rahalla!

Laadi tekoälystrategia

Monissa yrityksissä datavarantojen muodostamisesta vastaa it-osasto, joka hankkii ohjelmistoja ja teknologioita asian toteuttamiseksi. Liiketoiminnat osallistuvat tiedonkeruuseen käyttämällä ohjelmistoja (esimerkiksi ERP tai CRM). Tämän mallin riskinä on, että datavarantojen sisällön kehitystä ei vie eteenpäin ennalta mietitty strategia. Seurauksena voi olla siilomaisia ja pistemäisiä ratkaisuja, jotka eivät kustannuksiin nähden tuo riittävästi arvoa. Yrityksissä olisikin korkea aika pohtia datan strategista arvoa liiketoiminnan kannalta ja kehittää datan keräämistä sekä hyödyntämistä sen mukaisesti.

 


9.08.2017 / Mika Aho

Kävin toukokuussa Prosessipäivillä höpisemässä tietovarastoinnin ja tekoälyn/koneoppimisen yhteydestä. Nyt kun aihe on monella suunnalla aktiivinen, kirjoittelin siitä myös oman bloginsa.

Ajatuksena oli herätellä yleisöä pohtimaan ensinnäkin tekoälyn ja tietovarastoinnin nykytilaa, mutta ennen kaikkea mihin näitä kahta voisi yhdessä soveltaa. Alla varsinainen esitys sekä muutamia käyttötapauksia ja sovelluskohteita.

[slideshare id=75973994&doc=prosessipivt2017-korvaakotekolyperinteisentietovarastonnetti-170515055044&w=750]

Ei syvennytä tässä kirjoituksessa tekoälyyn tai moderniin tietovarastointiarkkitehtuuriin, vaan keskitytään enemmänkin neljään eri sovelluskohteeseen.

Tietomallinnus

Tietomallinnusta tehdään useammalla eri tasolla. Tyypillisesti luodaan jonkinlainen (ylätason) käsitemalli, ehkä pilotoidaan mallinnusta tietyssä liiketoiminnassa ja luodaan siitä osa-aluekohtainen käsitemalli, näistä edelleen looginen malli ja vielä fyysinen malli valittuun tietokantateknologiaan. Jokaisessa eri vaiheessa syntyy myös metatietoa, esimerkiksi tietovirtakuvauksia, rakennekuvauksia, käsitemääritelmiä ja niistä muodostettuja sanastoja.

Hyvän tavan mukaisesti mallinnusta tehdään tietomallinnusvälineessä (esim. ER/Studio, Enterprise Architect), jotta homma pysyy paremmin hanskassa, eivätkä hanskat huku toimittajan vaihtuessa.

Tämän lisäksi on olemassa erilaisia tapoja mallintaa tietoa. Perinteisesti tietovarastoja on mallinnettu Kimballin tähtimallin mukaisesti ja nykyisin entistä enemmän Lindstedin Data Vault -menetelmällä. Jälkimmäinen on hieman työläämpi, mutta siinä on omat etunsa ja tiettyjä vaiheita pyritään usein automatisoimaan.

tietomallinnus

Missä välissä koneoppiminen ja tekoäly sitten tulevat mukaan? Itse näen, että meillä on paljonkin mahdollisuuksia automatisoida mallinnusprosessia. Kone on mahdollista opettaa oppimaan rakenteita, muokkaamaan niitä lennossa, “ajattelemaan” kontekstia ja korjaamaan prosesseja. Oppiminen tapahtuu esimerkiksi loppukäyttäjän tekemien kyselyiden ja analyysien kautta.

Ei ehkä kovin kaukaista tulevaisuutta, että koneelta kysellään luonnollisella kielellä dataa ja se muodostaa tarvittavat tietorakenteet lennossa lähdejärjestelmiin perustuen. Tämän jälkeen tietovarastosta tuleekin enemmänkin musta laatikko, joka imaisee lähdejärjestelmien rakenteita sekä datoja ja muodostaa tuloksen loppukäyttäjän tarpeen mukaan. Ei meidän tarvitse sille tulevaisuudessa enää opettaa, että järjestelmän X taulun J8KA13KF sarake I0NYX5H1 pitäisi mapata tietovaraston F_SALES.SalesAmountEUR-kenttään.

Tällainen “tekoälykäs” tietoalusta pystyy toimimaan minimaalisella inhimillisellä ohjauksella, oppii kokemuksistaan ja tunnistaa piilossa olevia malleja tietovirroissa ja tietopyynnöissä. Se pystyy myös hakemaan itsenäisesti lisätietoa esimerkiksi datan laatua koskevan ongelman vahvistamiseksi tai vaikkapa tietojen hankkimiseksi vaihtoehtoiselta lähteeltä.

Datan laadunvalvonta

Datan laatu on ollut perinteisesti IT:n tehtäviä: on seurattu dataa, yritetty ymmärtää sen sisältöä (profilointi) ja luotu tietojen puhdistus- ja yhteensovitussääntöjä (standardointi). Koneoppimisella on paljonkin mahdollisuuksia datan laadun arvioinnissa.

Virheitä on ainakin kahdenlaisia:

  1. Järjestelmälliset virheet, jotka esiintyvät säännöllisesti tietyissä olosuhteissa
  2. Satunnaiset virheet, jotka tapahtuvat epäsäännöllisesti tietyissä olosuhteissa

Järjestelmälliset virheet ovat huonompi kandidaatti koneoppimiselle, sillä ongelman tunnistaminen vaatii tietämystä datan käytöstä. Käyttäjien onkin helpompi tunnistaa tällaisia virheitä, varsinkin jos ne esiintyvät usein.

Satunnaisia virheitä on puolestaan helpompi havaita tilastollisten menetelmien avulla. Tällainen voi olla vaikkapa äkillinen muutos datan arvoissa. Ihmisille tämän tyyppiset virheet helposti piiloutuvat suurien tietomäärien taakse varsinkin jos ne esiintyvät harvakseltaan.

Otetaan esimerkki. Meillä on runsaasti erilaisia dataa kerääviä järjestelmiä, kuten ERP, CRM, tuotanto, talous ja HR. Dataa integroidaan näiden järjestelmien välillä ja osa tiedoista siirretään myös tietovarastoon. Isossa organisaatiossa erilaisia automatisoituja datasiirtoja voi olla sadoista useisiin tuhansiin.

Miten varmistutaan, että dataa siirtyy oikea määrä?

dataaDW

Analytiikka seuraa siirrettävän datan volyymeja ja antaa varoituksen, jos dataa tulee liian vähän tai liikaa. Alla (ei niin kuvitteellinen) esimerkki myyntirivien seurannasta tuoteryhmittäin, jossa tässä tapauksessa tuoteryhmän myynti on tasaista ympäri vuoden. Dataa tulee yli sadasta eri kauppaliikkeestä ja joskus niiden latauksissa on ongelmia.

Tilastollinen malli luo automaattisesti luottamusvälit datavolyymin vaihtelulle. Mikäli toteutunut datavolyymi rikkoo luottamusvälin, niin siitä lähtee tiedote ylläpitoon. Alla esimerkkikuva oikeasta datasta laskettuna:

data_luottamusvälit

Punaisen raksin kohdalla osa tiedosta ei tullut lainkaan, joten volyymit putosivat. Usein tällainen virhe ei jää kiinni ETL-prosessissa, vaan se menee nätisti läpi, joskin pienemmillä datamäärillä. 

Pidemmälle vietynä tällainen malli ei pelkästään auta määrittämään ja parantamaan tiedon laatua, vaan tarjoaa myös älykkäämpiä suositeltuja toimenpiteitä tietojen laadulle sekä toiminnallisille parannuksille. Se pystyy myös luokittelemaan datan laatuongelman tyypin tai vakavuuden mukaan.

Datan standardointi

Kolmas hyvä sovelluskohde koneoppimiselle on datan standardointi.

Aika usein datan siivoamista tehdään käsityönä eli poistetaan duplikaatteja ja yhdistellään tietueita keskenään. Käsin tehtynä sääntöjen määrittäminen kestää, vaatii syvällistä ymmärrystä datasta ja on lisäksi kallista. Ymmärrettävästi tietolähteiden kasvaessa ja datan formaattien sekä tietotyyppien lisääntyessä sääntöjen rakentamisesta tuleekin äkkiä iso harjoitus. Lisäksi datan manuaalinen yhteensovittamisen tarkkuus on aina kyseenalaista.

Koneoppimisen avulla modernilla data-alustalla voidaan luoda matchaussääntöjä automaattisesti datasta. Järjestelmä myös oppii ja mukautuu käyttäjien käyttäytymiseen. Tämän tyyppistä toiminnallisuutta löytyy esimerkiksi Talendin Data Fabric -tuotteesta.

Datan paikkaaminen

Koneoppimista voidaan hyödyntää myös datan rikastamiseen tai paikkaamiseen ilman käyttäjän syötettä. On mahdollista laskea erilaisia segmentointiattribuutteja, arvioida asiakaspoistumaa, luottotappiota tai vaikkapa laskennallisesti täydentää asiakkaiden tietoja. Mika ja Ville ovat kirjoittaneet tästä aikaisemmin Louhian blogiin, kannattaa lukaista läpi.

Asiakkaiden tietojen täydentämiseen liittyen kannattaa muuten olla tarkkana. Kun seuraavan kerran törmäät Facebookissa tai vastaavassa kyselyyn, jossa sinua pyydetään vastaamaan “10 viattomaan kysymykseen”, kannattaa miettiä pari kertaa, vastaisiko. Silloin tällöin niissä taustalla olevat algoritmit muodostavat mallin, jotka pystyvät 10 vastatun kysymyksen perusteella ennustamaan ”100 syvällisen kysymykseen” liittyviä asioita. Tällöin sinusta tiedetäänkin aika paljon enemmän ja se iPhone jää kuitenkin saamatta.

voitaIphone


4.05.2017 / Ville Niemijärvi

Olimme aikanaan tekemässä QlikView-toteutusta ja ihmettelimme miten karmean näköistä jälkeä edellinen konsulttitalo oli tehnyt.

Koodi oli hirveää spagettia ja ulkonäkö oli karmea. Miten niin hyvällä tuotteella, joka on tunnettu hyvästä visualisoinnista, voi tehdä tällaista jälkeä?

Paljastuikin, että kyse ei ollut konsulttien taidoista vaan siitä, että asiakas oli halunnut säästää ja investoida vain muutaman päivän kerralla.

Välillä yritys teki kehitystä omin voimin ja sitten taas konsultti paikalle pariksi päiväksi.

Toisaalta arkkitehtuurisuunnitteluun ja tietomallinnukseen ei panostettu laisinkaan. Lähdettiin vain tekemään.

Ei paljoa mietitty miten ja missä dataa summataan. Mikä lataus hoitaa keskitetysti tuotetiedot ja tallentuuko johonkin tuote- tai asiakasmaster.

Yhtenäisestä käyttöliittymäsuunnittelusta (UI/UX) puhumattakaan.

Tehtiin siis tilkkutäkkiä ja kokonaisuutta ei ehditty tai pystytty hahmottamaan. Vuosien varralle toteutus paisui ja paisui. Lopulta oli kasassa 20GB mötkylä, jonka suorituskyky oli heikko ja jota ei voitu laajentaa. Ja se näytti aivan karmealta.

Oltiin solmussa.

Vaikka et käytä tietovarastoa, älä laista arkkitehtuurisuunnittelusta ja tietomallinnuksesta.

Vaikka lähtisitkin nopeasti liikkeelle, älä unohda arkkitehtuurisuunnittelua ja tietomallinnusta.

Vaatimusmäärittelyn ohella nämä ovat tärkeimmät vaiheet business intelligence -hankkeissa.

Tämä pätee myös silloin kun et käytä tietokantaratkaisua pohjalla tiedon tallentamiseen.

Myös Qlik, Tableau tai PowerBI toteutus vaatii sen arkkitehtuurisuunnittelun.

Niihin ei tarvitse käyttää aikaa viikkotolkulla. Päivässäkin saat aikaan valtavasti ja saatat säästää ehkä kymmeniä tai satojatuhansia tai ainakin annat BI-ympäristöllesi pari vuotta lisäaikaa kun spagettikoodihirviöitä ei tarvitse rakentaa uudestaan vuoden päästä.

Tässä oma esimerkki yhdestä isohkosta tietovarastohankkeesta.

  • piirsin loogisen tietoarkkitehtuurin tunnissa powerpointiin. Karkea esimerkki löytyy edellisestä blogikirjoituksesta.
  • heitin sen asiakasorganisaation experttien kommentoitavaksi
  • muutamat asiat olivat vaihtoehtoisia, emme osanneet päättää (pilvi vs. on-premise vs. hybridi, datan aggregointi: miten ja missä, MPP vs. normirelaatio)
  • näitä päätöksiä varten tilasimme ulkopuolisen asiantuntijan, pidimme 2 kpl noin 3h työpajoja
  • vedimme konsulttien, meidän ja asiakasorganisaation suositukset yhteen ja teimme päätökset arkkitehtuurista

Kalenteriaikaa saattoi kulua ehkä pari viikkoa mutta työaikaa ehkä vain pari päivää. Ei kovin iso investointi kun lähdetään rakentamaan satojen tuhansien investointia.

Älä hinkkaa arkkitehtuuria liian kauan, tärkeintä on lähteä liikkeelle

On tapauksia missä yritys ei ole osannut lähteä liikkeelle laisinkaan.

On pohdittu kumpi on parempi:

  • MS SQL Server vai Oracle
  • Azure vai AWS
  • SSIS vai Informatica
  • normi-sql vai mpp vai datan virtualisointi

Vaihtoehtojen runsaus ja joskus myös konsulttien kykenemättömyys antaa suosituksia (ja olla jotain mieltä) on aiheuttanut sen, että ei ole tehty mitään tai että hanke on viivästynyt kuukausilla.

Vaikka tekisit “väärän” päätöksen, voi tuon päätöksen muuttaa. Ja hankkeen menestykselle on tärkeämpää saa loppukäyttäjän palautetta ja kokemusta uudesta arkkitehtuurista mahdollisimman nopeasti, kuin yrittää päättää täydellinen arkkitehtuuri kerralla.

Ahteri edellä puuhun, soitellen sotaan ja takki auki ei kannata edetä. Mutta älä yliajattele, älä ylisuunnittele. Sekään ei ole hyväksi.

Kyseessä on oppimisprosessi. Lähde siis liikkeelle pienesti ja opi matkan varrella. Tärkeintä on vain lähteä.

Kyllä nämä jutut vähän maksavatkin

Vedin kerran asiakkaalla toimittajien kilpailutusta. Erään toimittajan konsultin hieman ylimielinen kommentti hieman kummaksutti kun kysyimme häneltä perusteluja suurille työmääräarvioille:

“No kyllä nämä vaan maksavat”

Kaveri oli tietovarastoinnin huippuosaaja ja hänen leipälajina ei ollut myynti tai (potentiaalisten) asiakkaiden ärsyttäviin kysymyksiin vastaaminen.

Mutta hän oli oikeassa tuossa tylyssä vastauksessa.

Kyllä näissä vain menee aikaa ja se maksaa.

Ne ketkä tuntevat työtapaani tai kirjoituksiani, tietävät että halveksin ylisuuria työmääräarvioita ja asiakkaita kuppaavia konsultteja. Tykkään tehdä hommat nopeasti ja joskus oikoa mutkiakin.

Mutta olen itsekin joskus vääntänyt 20-30 päivää yhtä dashboardia. Se oli kallis työpöytä.

Mutta kannattaa huomata, että tuotetoimittaja haluaa myydä asiakkaalle lisenssin.

Hänen etuna on vähätellä työmäärän suuruutta. Jos työmäärä on kovin iso, voi se haitata lisenssimyyntiä. Siksi kannattaa mainostaa, että meidän softalla teet hienot raportit päivässä.

Konsultit näkevät usein pidemmälle. Se on heidän intresseissään. Ajatella pari vuotta eteenpäin. Ajatellaan laajennettavuutta, skaalautuvuuta, suorituskykyä, tulevia käyttötapauksia. Ajatellaan käytettävyyttä, käyttöönottoa, koulutusta.

Konsulttina tietenkin näen jälkimmäisen näkökannan paremmaksi.

Kuuntelit sitten konsulttia, tuotemyyjää tai lompakkoasi, suosittelen seuraavaa:

  • pysähdy edes edes päiväksi miettimään tietoarkkitehtuuriasi
  • älä mieti päätäsi puhki, loppukäyttäjän palaute ja oppi on niin tärkeämpää kuin saada täydellistä kerralla