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ä


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

 


7.10.2016 / Mika Aho

Jokusen BI- ja tietovarastointiprojektin läpi kahlanneena olen usein miettinyt, kuinka suureen määrään (liiketoiminta)dataa BI-veijareilla on mahdollisuus päästä, tulivatpa sitten talon sisältä tai konsultin roolissa ulkopuolelta.

Muutaman pääkäyttäjän oikeuksin ajetun valmiin raportin kautta löytyy usein koko organisaation taloudelliset tunnusluvut, budjetit ja ennusteet, myynti, ostot, tilauskanta, merkittävimmät asiakkaat ja projektista riippuen joskus palkkatietojakin. Ja paljon muuta.

Jos taitaa muutaman lauseen SQL:ää, simppelillä SELECT-lauseellakin saa kaivettua tietokannan uumenista vaikka mitä, varsinkin jos osaa filtteröidä tilejä WHERE-ehdolla. Yleensä tätäkään ei tarvitse tehdä, sillä tulos ja tase ovat jo valmiiksi rakennettuna summariveineen tietovaraston tilidimensioon.

Oikeastaan jo lähtökohtaisesti ajatus on huvittava: suuri määrä arkaluontoista dataa kerätään yhteen paikkaan, jossa toisilleen tuntemattomat ihmiset pääsevät siihen käsiksi. Ok, useimmiten dataa rajataan raportointipäässä vaikka liiketoimintayksikön tasolla, mutta edelleen BI-veijareilla on samat admin-natsat käytettävissä. Vaikka sensitiivisempää dataa, kuten palkkatietoja, rajattaisiin tietokantapäässä näkymien avulla, kyllä ne taustalla olevat taulut ovat edelleen löydettävissä – ainakin latausalueelta.

Mitäs sitten, kun asiakas ei olekaan tylsä teollisuusyritys, vaan julkishallinnon puolelta vaikkapa sairaanhoitopiiri, Poliisi tai verottaja? Toivottavasti potilastietojen kanssa työskentelevillä BI-veijareilla on tietoturva hanskassa ja salassapitosopimukset kunnossa.

Q3-osavuosikatsaukset

Pian saadaan taas seurata, mitenkäs se kesälomien jälkeinen aika pörssiyhtiöissämme menikään. Entäpä, jos BI-veijarille tulisikin kiusaus katsoa Arvopaperi-lehdestä analyytikoiden ennusteita ja verrata BI-, suunnittelu- ja konsolidointijärjestelmistä löytyviä toteumia sekä ennusteita näihin? Siinä voi sitten tulosjulkistuksen alla arpoa, lähteekö viikonlopun viettoon short-positiolla, lyökö rahaa tiskiin vai myykö vanhat osakkeet salkusta turskaamasta. Tässä tapauksessa kun suomalainen voittaa aina.

Mitäpä jos tulisi houkutus muuttaa tulosjulkistuksen alla numeroita parempaan tai huonompaan suuntaan? Tai muuten vain tehdä pientä kiusaa naapuriyksikön mulkvistille? Ei suotta sanota SQL:n olevan ilmaisuvoimainen kieli.

Vai onko riski kuitenkin talon sisällä?

Yksi ihan mielenkiintoinen elävä esimerkki oli eräästä konsernin hankintoihin liittyvästä raportointiprojektissa, jossa olin jo vuosia sitten mukana. Yrityksessä oli muutoin tietoturva hyvällä mallilla: VPN-putkia ei ollut eli työtä tehtiin asiakkaan tiloissa, henkkarit katsottiin aulan tiskillä, omia läppäreitä ei saanut käyttää, BI-palvelimilta ei päässyt ulkoverkkoon, tiloissa kuljettiin aina saattajan kanssa ja yksin ei saanut jäädä puuhailemaan. Vessassa sai sentään käydä rauhassa.

Rakennettiin hienot tietovarastot, kuutiot ja raportit. Testausvaiheessa aloin kuitenkin saada hankintajohtajalta työsähköpostiini suojaamattomana raportteja konsernin suurimmista toimittajista euromäärineen. Tuli heti turvallinen olo.

Pitäisikö asialle tehdä jotain?

Kyllä ja ei. Varsinkin kehittäjän näkökulmasta on hyvin hankalaa ja jopa raivostuttavaa, mikäli BI-työkalut eivät ole käytettävissä ja dataa saatavilla, kun kehitystyö on kuumimmillaan. Yleensä kun näissä hommissa painaa kiire päälle.

Toisaalta huhtikuussa hyväksytty EU:n tietosuoja-asetus (täällä kauniisti visualisoituna) ohjaa yrityksiä varmistamaan tietoturvansa riittävyyden ja varautumaan ongelmatilanteisiin. Ihan älytön hoppu ei ole, sillä Suomessa asetusta ryhdytään soveltamaan kahden vuoden siirtymäajan jälkeen eli aikaisintaan keväällä 2018. Kannattaa kuitenkin varautua ajoissa, sillä jopa 20 miljoonan euron sakko tietosuojasäännösten rikkomisesta rohkaisee kyllä laittamaan henkilötietojen käsittelyn kuntoon myös BI-projekteissa.

With Great Power Comes Great Responsibility. Louhia on hyvien puolella.


3.08.2016 / Ville Niemijärvi

Microsoft SQL ServerTeen kesän aikana jo toiselle asiakkaalle shortlistaa IT-toimittajista, jotka toteuttavat tietovarastoja, osaavat ETL-työvälineenä Microsoftin SSIS:ää ja mahdollisesti mallintaa data vaultilla.

Tarve on siis hyvin spesifille korkean tason osaamiselle, mielellään serfitikaattien kera.

Tunnen alan toimijat hyvin joten helppo homma?

Ei ihan.

Kukaan ei halua olla duunari

Nykypäivänä ainakin firmojen web-sivujen mukaan kukaan ei tee tietovarastoja. Se on passe. Suorituskyvyn johtamista, koneälyä, big dataa, integraatioratkaisuja, tiedolla johtamista, IoT:tä ja digitalisaatiota tuntuu tekevän kaikki. Mitä ne sitten ikinä tarkoittavatkaan?

Mutta harva asiakas ostaa yhden digitalisaation. Tai yhden integraation. Tai kaksi tiedolla johtamisen konsultaatiota ja yksi suorituskykyn johtamisen ratkaisu. 

Jopa sellaiset yritykset jotka tunnen erittäin hyvin ja tiedän heidän olevan maan huippuja tietovarastoinnissa ja esimerkiksi SSIS-työvälineen käytössä, vaikenevat verkossa täysin näistä taidoista.

Tällöin asiakkaiden on erittäin vaikea ostaa osaamista. Ja kaupat jäävät syntymättä.

Näissä parissa casessa olenkin joutunut kysymään Microsoftilta suoraan, ketkä suomalaiset IT-talot toteuttavat esimerkiksi tietovarastoja Azureen, keneltä löytyy SSIS-osaajia, ketkä hallitsevat teknologian X.

Ja näillä konkreettisilla hakusanoilla asiakkaat usein kumppaneita etsivät. Vaikka tuomiopäivän pasuunat muuta väittävät, tietovarastoja tehdään edelleen täyttä häkää. Ja isoja sellaisia. Ja paljon parempia, monipuolisempia ja fiksumpia kuin vuosikymmen sitten.

Firmat ajattelevatkin varmaan, että tietovarastojen toteutus on liian bulkkia, leimaa heidät duunareiksi.

IT-firmojen pitäisi ottaa mallia Timo Soinista

Kaikki tuntuu haluavan näyttäytyvän korkeamman tason digitalisaation sanansaattajina, oppaina ja konsultteina. Tunnustan: niin mekin.

Tämä ylätason huttu on kuitenkin juuri sitä ihteään. Huttua. Liian epämääräistä, liian korkealentoista, että sillä olisi oikeasti käyttöä. Viestintää joka menee täysin hukkaan.

Toisaalta kun kaikkien tuntema tietovarastoja sorvaava akselirasvaosaston IT-firma koittaa näyttää korkeamman jalostusasteen johdon konsulttifirmalta, Accenturelta, Mckinseyltä ja mitä lie, niin jossain vaiheessa siitä jää kiinni. Viimeistään silloin kun propellipää “konsultti” menee asiakkaan johtoryhmälle puhumaan biteistä ja pilvestä. Sieltä lentää äkkiä niskaperseotteella ulos.

IT-firmojen kannattaisikin ottaa mallia Timo Soinin selkokielenkäytöstä. Puhua. Yksinkertaisin. Lausein. Ehkä firmojen pitäisi popularisoida web-sivujensa viestintä. Kansanomaistaa se.

Olisikin ilahduttavan pirteää nähdä IT-firma, joka toteaa webissä etusivulla: me teemme tietovarastoja Microsoftin teknologialla.

Olen pommin varma, että tällöin tulisi kauppaa enemmän kuin diipadaapalla. Ei ehkä jytkyä mutta kauppaa silti.


Ps. Näihin pariin caseen shortlistit on luotu ja toimittajat on kontaktoitu tai tullaan pian kontaktoimaan. Mutta näitä toimeksiantoja tulee meille kuitenkin yhtä enemmän ja enemmän eteen.

Jotta helpotamme omaa työtämme ja palvelemme asiakkaitamme paremmin, lähdemme ylläpitämään listaa suomalaisista eri tiedolla johtamisen osa-alueille erikoistuneista yrityksistä. Toimimme puolueettomana konsulttina ja etsimme asiakkaalle parhaimman toteutuskumppanin.

Jos yrityksesi on siis erikoistunut tietovarastoihin, data science:en, business intelligenceen, raportointiin tai muuhun tiedolla johtamisen alueeseen, ja olet jatkossa kiinnostunut saamaan tarjouspyyntöjä isoista DW/BI/DataScience/IoT -projekteista, nakkaa vaikka maililla (ville.niemijarvi@louhia.fi)

Teknologioita on pilvin pimein ja kaikkia softia ja niiden osaajia emme ala listaamaan mutta aloitamme ainakin näillä, joista on tullut eniten kyselyjä:

  • ETL-työvälineet: SSIS, Informatica
  • pilviratkaisut: Azure, AWS
  • tietovarastot pilvessä, Paas-ratkaisut: Azure SQL DW, Amazon Redshift
  • big data -ratkaisut osana tietovarastointia ja raportointia, Hadoop etc.
  • data science ja edistynyt analytiikka (tästä olemme jo keränneet kattavan listan)

(Raportointituotteiden osalta peli on selkeämpi ja Tableau, Cognos, QlikView, Birst etc. konsultit löytyy helposti. Ehkä listaamme niitäkin mutta ei nyt)

Olisi kiva tietää:

  • mitä yllämainittuja osa-alueita yrityksenne toteuttaa?
  • hieman osviittaa montako toteutusprojektia on takana, mahdolliset referenssit?
  • osaajien lukumäärät, sertifikaatit plussaa?

Auta meitä auttamaan suomalaisia asiakkaita. Ja sinua siinä samassa.


7.01.2016 / Jani Liimatta

ERP:in ja CRM:n asiakastiedot ovat monasti rämettyneitä. Yritysasiakkaiden tiedot on onneksi helpompi päivittää ajan tasalle kuin kuluttaja-asiakkaiden. Tässä käydään teknisesti läpi miten PRH:n tarjoamaa avointa dataa voidaan käyttää SSIS-välineillä. Tavoite on siis päivittää yritysasiakkaiden tiedot ajantasaisiksi.

PRH on julkaissut JSON-rajapinnan kautta YTJ-tietopalvelun sisältämän datan. Tätä kautta saadaan näppärästi, halvalla ja vaikka päivittäin yritysten

  • Osoitetiedot
  • Yritysten lakkaamistiedot
  • Sulautumiset, uudet y-tunnukset, yritysmuodon muuttumiset
  • Toimialatiedot

Eli ne olellisimmat. Liikevaihtotiedot, tulostiedot, luottokelpoisuudet jne. täytyy toki ostaa erikseen esim. Asiakastiedolta tai Fonectalta – mutta tärkeintä on toki ensin päästä tilanteeseen, jossa asiakkaiden joukossa ei ole esim. päättyneitä y-tunnuksia.

PRH:lla on tarjolla näppärä käyttöliittymä datan tarkastelemiseen http://avoindata.prh.fi/ytj.html, jossa avointa rajapintaa pääsee testaamaan.

Tässä demossa käytetään Pragmatic Worksin Task Factoryyn kuuluvaa Rest Source:a datan lukemiseksi SSIS:ään. Ilmainen avoimen lähdekoodin komponenttikin on tähän olemassa, esim. https://jsonsource.codeplex.com/, toki tuollaisen koodailee itsekin aikan nopeasti. Valmista, natiivia Json-tietolähdettä ei SSIS:stä löydy.

Homma lähtee asentamalla Pragmatic Works Task Factory (TF). Kehityskäytössä TF ilmainen. Tuotantokäytössä Rest Source:n sisältävä versio TF:stä kustantaa luokkaa 1500 USD. Task Factoryyn sisältyy monta muutakin hyvin hyödyllistä komponenttia.

Yritystietojen haku massana PRH:lta

Itse Json-datan lukeminen ei vaadi juurikaan asetuksia Connection Manageriin, koska tässä tapauksessa data on avointa, eikä käyttäjätunnistusta tarvita. Endpoint URL:nä voi käyttää suoraan esimerkkiä PRH:n sivuilta. Se rajoittaa testattaessa yritysmäärää sopivasti.

Root Json Path on PRH-datan tapauksessa ‘results’.

Lisäksi on määriteltävä Column Name:t sekä Token Path:it. Eli Column Name on sarakkeen nimi, joka tulee komponentista ulos – ja Token Path viittaa Json-määrittelyyn.

Rest Source

 

Preview-välilehdellä pääsee kätevästi tarkastelemaan, onnistuivatko asetukset. Tässä onnistuivat – Json-data on nätisti mappautunut tehtyihin sarakkeisiin.

Rest Source Preview

Yritystiedot sisältävät varsin rajoitetusti tietoa. Tarkempien yritystietojen hakuun on käytettävä toista rajapintaa – jossa täytyy parametroida kyseltävä yritys.

Tästä eteenpäin data luonnollisesti kirjoitetaan tietokantaan – ja jatkokäytetään tarvittavilla tavoilla. Perus-SSIS:ään tai SQL:ään ei tässä kohtaa mennä.

 

Olemassaolevien asiakastietojen rikastaminen

Olemassaolevien yritystietojen rikastaminen on tehtävä siis yksi yritys kerrallaan. Eli SSIS-komponentteja käytettäessä on kätevintä sijoittaa TF Rest Source For Each-loopin sisälle. On siis tehtävä yksi kutsu per yksi yritys – ja parametroitava y-tunnus. Esimerkissä on luotu muuttuja BusinessID, jonka avulla Rest-rajapinta hakee yhden yrityksen tiedot kerrallaan.

Esimerkiksi businessIdChanges-kohta Json:ista saadaan otettua talteen määrittelemällä Root Json Path ‘..businessIdChanges’. Alla on määritelty käyttöön sarakkeet NewBusinessId – eli uusi Y-tunnus, syykoodi, muutospäivä sekä vanha Y-tunnus.

Rest Company

Valmiskomponentin huono puoli on se, että jokaista path-kohtaa kohti täytyy tehdä oma source – ja yhdistää ne SSIS:n Data Flow:ssa. Ja toki noita kutsuja PRH:n sivuille tulee minimissään 1/asiakasyritys – eli tuhansien yritysten tietojen haku voi viedä hetken. Jos tarvittavaa dataa on useammasa path:issa Json:in sisällä, on tällä komponentilla käytännössä tehtävä useampi rest-kysely PRH:n palvelimelle per asiakasyritys.


3.11.2015 / Ville Niemijärvi


-100 päivää, sen verran se kestää, piste.

Mutta Matti kiltti, voisitko kuitenkin avata vähän tätä rakentamiseen menevää aikaa. 100 päivää on aika ylimalkainen…
-Ei näitä aleta pilkkomaan. Se vie minkä se vie.

Kuuntelin sivukorvalla kun projektipäällikkö yritti saada tietovarastoarkkitehtiä purkamaan noin 100 päivän eli karkeasti 100 000 euron investointia tarkemmalle tasolle. Pätevä ja mukava kaveri mutta todella old school, oli tottunut tekemään töitä, paperinpyörittely ja työmääräarviot kuului muille.

Itse annoin raporttiarkkitehdin ominaisuudessa omat työmäärät puolenpäivän tarkkuudella ja erittelin joukosta vielä vessa- ja kaffetauot. Kunnon etupenkin ahterin lipoja siis.

Haluaako toimittaja laittaa vähän ilmaa työmääriin vai onko hän vain epäpätevä?

Vaikka Matti (osoite muutettu) on mukava ja pätevä niin kokeneen ammattilaisen pitää pystyä pilkkomaan työmäärät tarkalle tasolle. Tämä on osa kokemuksen tuomaa ammattitaitoa. Jotain mitä myös asiakkaiden pitää vaatia toimittajilta.

Jos toimittaja ei pilko työmääriään könttäsummaa tarkemmalle tasolle, hän ei joko:

a.) osaa tehdä sitä eli ei tiedä miten tietovarastoja rakennetaan tai
b.) hän on ylimielinen asiakasta kohtaan ja haluaa laittaa työmääriin ilmaa eli rahastaa asiakasta

Pahimmassa tapauksessa molempia.

Mikä on tarkka taso työmäärille? Itse pyrin siihen, että tehtävät laitetaan päivän tai parin palikoihin. Jos nyt 3-5 päivän könttiin päästään niin sekin on hyvä. Mutta 10 päivää on jo turhan ylimalkainen, sadasta puhumattakaan.

Okei, kun tehdään +1000 päivän hanketta ja alussa hahmotellaan projektisuunnitelmaa niin sallitaan vähän isommatkin köntsät, kunhan ne ei ole konsultin housuissa.

Miten arvioida DW/BI –hankkeen kustannuksia?

Kerron seuraavaksi yhden karkean tavan arvioida työkustannuksia ennen kuin projekti on alkanut ja kun ei vielä tiedetä kaikkia detaileja. Malli ei pidä sisällään asiakasyrityksen omia työmääriä.

Tämä on karkea, suuntaa-antava ja ei tarkoituksella pidä sisällään kaikkia DW-projektin tehtäviä ja yksityiskohtia. Nämä pilkotaan sitten esille projektisuunnitelmaa tehdessä. Malli ei ota kantaa käytetäänkö jotain kehitystyön nopeuttajaa ja se sopii parhaiten perinteiseen dimensionaaliseen tietovarastomalliin, sovellettavissa toki vaikka data vault -maailmaan.

Tämän on tarkoitus olla tyhjää parempi, tämä ohjaa oikeaan kokoluokkaan. Kun halutaan tietää onko kyseessä 20ke vai 200k€ hanke. Mallin avulla myös asiakas voi itse päätellä nopeasti, mitä kustannus voisi olla. Tämän avulla asiakas voi arvioida, onko toimittajan arviot tai toteuma laisinkaan realistisella tasolla.

Muistakaa kuitenkin, että aina, siis ihan aina, tulee eteen jotain yllättävää. Jokin vaatimus muuttuu, lähdetiedoista paljastuu outouksia, testaus venyy kun asiakkaalla on muita kiireitä… Mitään pomminvarmaa millimetripaperin tarkkaa mallia ei ole olemassakaan. Emmekä pyri selittämään koko maailmaa, emme edes tietovarastointia.

Mutta yksinkertainenkin malli on parempi kuin ei mitään. Ja kun edes hieman yrittää miettiä ja tuotteistaa tekemistä, johtaa se yleensä aina parempaan tulokseen kuin ei tekisi mitään. Tai yrittäisi selittää kaiken.

Kaikki palaute ja parannusehdotukset laskentamalliin otetaan vastaan, joten kommentoikaa rohkeasti tai laittakaa mailia. Ja kärsimätön twitter-sukupolvi, joka ei jaksa lukea pitkiä sepustuksia voi hypätä kirjoituksen loppuun jossa homma on vedetty yhteen esimerkin kera.

Laskentamalli DW/BI-hankkeen työkustannuksille

Tietovarastoinnin työkustannusten arviointiin kuuluu tietyt enemmän tai vähemmän kiinteät osiot, kuten projektin aloitus ja suunnittelu, teknisen ympäristön pystytys, vaatimusmäärittely… ja sitten on liikkuvat osat kuten toteutus (tietovarasto + raportit).

Kiinteitä osioita ovat:

  • Projektin suunnittelu (ns. 0-vaihe: scope, tavoitteet, toimintamallit)
  • vaatimusmäärittely, suunnittelu (tietomallit, arkkitehtuuri jne.)
  • Toteutus x iteraatiota: sis. tietovarasto + raportointi
  • Testaus, käyttöönotto: n. 10% toteutuksen työmääristä
  • projektinhallinta: n. 10-15% koko projektin työmääristä

En avaa tässä tarkemmin mitä nämä vaiheet pitää sisällään. Poraudutaan sen sijaan olennaiseen eli miten arvioida sitä isointa epämääräistä kokonaisuutta eli toteutuskustannuksia.

DW:n toteutuskustannuksiin vaikuttaa seuraavat tekijät:

  1. Tietolähteiden ja asiakokonaisuuksien (käsite/kohde/entiteetti) määrä
  2. Datan määrä ja ennen kaikkea laatu
  3. Raporttien, mittarien, työpöytien määrät
  4. Tekninen monimutkaisuus ja erityisvaatimukset (DW, raportit, jakelu)
  5. Yrityksen/organisaation sitoutuminen projektin läpivientiin ja tukemiseen
    (esim. osallistuminen suunnitteluun ja määrittelyyn, testaaminen)
  6. Tekniset valmiudet ja maturiteetti (0 –taso vs. valmis BI-ympäristö, joka upgradetaan)

Seuraavassa malli miten arvioida kunkin tekijän vaikutusta.

1.) Tietolähteiden ja asiakokonaisuuksien määrä
(asiakokonaisuus: esim. myynti, varastosaldot, tuote, asiakas)

Suuntaa antava yleisohje: 1 kokonaisuus vie 2 htpv toteutustyötä per tietolähde.

Laskukaava on siis: 2 pv * lähteiden määrä * asiakokonaisuuksien määrä.

Mihin tuo 2 päivää sitten menee? Sen aikana tiedot ladataan lähdejärjestelmästä (muodostetaan SQL-kysely, joka lukee esimerkiksi myyntitilausotsikot ja –rivit ERP:stä ja lataa ne tietovaraston staging-alueelle. Tämän jälkeen tiedot viedään DW:n faktatauluun, harmonisoidaan data jos se tulee useasta taulusta, muodostetaan surrogaattiavaimet, hoidetaan tiedon historiointi (hitaasti muuttuvat dimensiot) ja muut perusrutiinit.

Tässä muutama esimerkki:

Myynti-faktataulun muodostaminen yhdestä lähteestä: 2*1*1 = 2 htp
Myynti-fakta ja tuotedimensio kahdesta lähteestä: 2*2*2 = 8 htp
Myynti, tuote ja saldotaulu kolmesta lähteestä: 2*3*3 = 18 htp
Myynti, tuote, saldot, asiakkaat, myymälät, toimittajat ja varastotapahtumat 3 lähteestä: 2*7*3= 42 päivää

Tämä laskumalli on tehty DW:n tähti-/lumihiutalemallia varten käyttäen 2-tasoista hierarkiaa (stage+DW). Jos mallinnat DW:n data vault –mallilla, joudut vähän soveltamaan tätä.

Data vault vaatii usein 3 kerrosta (stage+raw vault + business vault) ja tähän päälle pitää rakentaa vielä tähtimalli, jotta raportointi on mahdollista. Eli 4-kerrosarkkitehtuurin myötä työmäärät kasvavat jonkin verran. Oma kokemus data vaultista on sen verran vähäistä, että joku kokeneempi data vault konkari voi arvioida ja kommentoida tätä. Yhden lähteen mukaan data vaultin työmäärät ovat kolminkertaiset dimensionaaliseen mallintamiseen verrattuna. Toisaalta useilla suomalaisilla data vaultilla toteuttavilla konsulttitaloilla on jotain kehitystyötä kiihdyttäviä apuvälineitä. Mutta ei mennä siihen tällä erää tarkemmin.

Tuo edellä mainittu 2 päivää asiakokonaisuutta kohden tarkoittaa sitten nappisuoritusta. Että kaikki menee hyvin. Se edellyttää kokenutta ETL-tekijää ja ei ole haittaa, että tuntee vähän miten datat on mallinnettu ERP:ssä. Se tarkoittaa, että liiketoiminnan säännöt tunnetaan hyvin ja tiedetään esim. miten rajataan sisäinen laskutus pois myyntilaskuista tai miten valuuttamuunnokset tehdään. Toisin sanoen se tarkoittaa, että tekninen määrittely on tehty hyvin.

Jos teknistä määrittelyä ei ole tehty ja jos lähdedataa ei tunneta, tuo 2 päivää voi kasvaa 20 päiväksi. Jos tiedetään, että esim. tuotekoodit eroavat tietolähteiden välillä, lisätään mäppäystyöhön extrapäiviä.

2.) Datan määrä (rivejä tietokannan tauluissa)

Suuntaa antava yleisohje:

  • Vähän dataa: 10 000 – 1 000 000 riviä per faktataulu (esim. myynti, sis. koko historian)
  • Keskiverto: 1 000 000 – 100 000 000 riviä per faktataulu
  • Paljon dataa: 100 000 000 ->

    Vaikutus työmääriin (DW-toteutustyöhön lisäkerroin):
  • Vähän dataa: kerroin 1
  • Keskiverto: kerroin 1,5
  • Paljon dataa: kerroin 2

Esim. DW-toteutus (etl-työ) pienellä datalla  = 30 htpv, keskiverto datamäärillä 45 htpv ja suurilla data määrillä 60 htpv.

Miksi lisääntynyt data aiheuttaa ongelmia? Kyse on kahdesta tekijästä:

  • isojen tietomassojen lataus vie aikaa. Jos päivität tauluun satoja miljoonia rivejä dataa update/insert:llä ja teet sille paljon laskentaa, haet surrogaatit jne., saattaa tämä kestää tuntikausia. Kun taas 100 000 riviä menee yleensä muutamassa minuutissa. Eroja alkaa tulemaan kun latauksia pitää tehdä kehitystyön aikana jatkuvasti uudestaan ja uudestaan kun huomataan virheitä latauksissa.
  • pitkä historia sisältää usein huonolaatuista dataa. Mitä pidemmältä ajalta dataa on, sitä suurempi todennäköisyys on, että historiassa on ollut jotain eri käsittelysääntöjä tai muuten vain erilaista dataa. Tämä aiheuttaa aina lisätyötä etl-prosessissa.

3.) Raporttien, mittarien yms. määrä

Luokittelen raportit 3 luokkaan vaatimustason mukaan:

Taso 1: Helpot raportit: 1 htpv/raportti

  • yksinkertainen lista/graafi
  • ei toiminnallisuuksia, ei vaatimuksia vasteajoille (raportin ajo saa kestää hieman)

Taso 2: Keskivaikeat raportit : 1-3 htpv/raportti

  • useampi lista/graafi
  • pientä toiminnallisuutta, esim. valintalistoja, porautuminen, monimutkaisempia filttereitä ja aikavertailuja

Taso 3: Vaikeat raportit: +4 htpv/raportti (15 htpv monimutkaiseen raporttiin ei ole harvinaisuus)

  • useampi lista/graafi, dashboard, karttapohja
  • monimutkainen toiminnallisuus: esim. filtteröinti käyttäjätunnuksen mukaan
  • tarkat vaatimukset layoutille ja vasteajoille

Raportteja ennen pitää tehdä usein metamalli, esimerkiksi SAP:n Universe, Cognoksen Framework Manager –malli tai Microsoftissa esim. data source view Reporting Servicen osalta. Metamallin päälle, tai rinnalle, saatetaan tehdä raportointikuutio.

Jos tietovarasto on hyvin mallinnettu, metamallin tekeminen on yleensä hyvin suoraviivainen. Varaan itse Cognoksen Framework Manager –mallinnukseen 2 päivää. Jos suunnitellaan suurta enterprise-tason mallia, jossa on tiedon suojauksia ja paljon liiketoimintalogiikkaa, on hyvä varata 5-10 htpv.

Kuutioiden toteutukseen varaan 5 htpv. Kuutioista saadaan yleensä ensimmäinen malli ulos päivässä mutta sitten se varsinainen hierominen vasta alkaa.

QlikViewn tapauksessa ei ylläoleva laskenta ihan päde koska siellä tehdään enemmänkin raporttiapplikaatioita, jotka sisältävät useita erillisiä raporttiobjekteja. Laskentaa voi kuitenkin soveltaa QV maailmaankin.

Esimerkkilaskelma Cognos-maailmasta:

  • tehdään nopea metamalli: 2 htpv
  • tehdään 1 kuutio: 5 htpv
  • tehdään 1 vaativa raportti ja 4 helppoa raporttia: 8 htpv
    Yhteensä: 15 htp

4.) Tekninen monimutkaisuus, erityisvaatimukset raportoinnille

Yksinkertainen toteutus: yrityksen sisäiseen käyttöön, pienelle käyttäjämäärälle, ei erityisiä toiminnallisia vaatimuksia.

Monimutkaisuutta lisää mm.

  • käyttäjät ovat ”tuntemattomia” eli tehdään extranet-ratkaisu (heidän selaimet, näyttöjen resoluutiot , käyttötavat jne. ovat tuntemattomia)
  • raportointi on julkisessa internetissä, käyttäjämääriä ei tiedetä
  • toiminnallisia vaatimuksia (esim. datan suodatus rivitasolla käyttäjäoikeuksiin perustuen monimutkaisen matriisiorganisaation tarpeisiin)
  • erillisen käyttäjähallinnan toteutus (ei voida hyödyntää valmista Active Directory:ä)
  • dataa pitää kirjoittaa raporteilta takaisin tietokantaan
  • monimutkaiset simuloinnit joissa x vaikuttaa y:hyn 20 eri muuttujan kautta
  • monimutkaiset dashboardit ja balance scorecard -toiminnallisuudet

Arviota näiden vaikutuksista ei voida antaa ennen raporttien määrittelyä. Usein lisäkerroin työmääriin koskee jotakin tiettyä kohdetta, esim. monimutkainen tuote-käsittely tai kustannusten allokointi ja jyvitys katelaskentaa varten. Harvoin koko ympäristö on erityisen monimutkainen.

Esimerkkinä: eräässä kuluttajille suunnatussa raportointiprojektissa käyttöoikeuksien hallinta /kirjautuminen oli oma n. 100 00€ aliprojekti.

5.) Yrityksen/organisaation sitoutuminen projektin läpivientiin ja tukemiseen

Kun lähdetään toteuttamaan tietovarasto- tai raportointiprojektia, kaikki yritykset vakuuttavat että he ovat ylintä johtoa myöten sitoutuneita homman läpivientiin ja kaikki tuki on hankkeen takana.

Mutta sitten kun pitää alkaa iskemään päiviä kalenteriin tästä juhannukseen saakka eli investoimaan omaa aikaa työhön, ääni muuttuu usein kellossa.

Sama pätee hankkeiden ja datan omistajuuteen. Sitoutuminen tarkoittaa myös sitä, että hankkeesta ottaa vastuun yksi henkilö. Joku jolla on riittävän suuri mandaatti ja natsat puhua hankkeen puolesta yrityksen johtoryhmässä, saada sille riittävästi huomiota ja rahoitusta muiden kymmenien hankkeiden joukosta.

Sitoutumisen määrää on vaikea mitata ja sen vaikutusta työmääriin hankala arvioida. Jos kuitenkin yritys epäilee jo alussa oman ajankäytön riittävyyttä, jos projektille ei löydy omistajaa ja jos datalle (esim. tuote-dimensio) ei löydy omistajaa, kannattaa valmistautua työmäärien lisääntymiseen.

6.) Tekniset valmiudet ja maturiteetti (0 –taso vs. valmis BI-ympäristö, joka upgradataan)

Kirjoitin taannoin siitä, miten tietovarastot eivät ole enää mammuttihankkeita. Tarkoitin tällä sitä, että kun yritys on tehnyt jo yhden tai pari tietovarastoa tai raportointiympäristöä, on sen maturiteetti jo aika hyvä.

Miten maturiteetti näkyy työmäärissä?

  • käyttäjät tietävät mitä haluavat > määrittely on nopeampaa, iteraatioita tarvitaan vähemmän
  • data tunnetaan, tietolähteet ovat tuttuja > etl-työssä kuluu aikaa huomattavasti vähemmän
  • tiedon laatu on kunnossa > testaus on huomattavasti nopeampaa

Jos tehdään ihka ensimmäistä tietovarastoa, käyttäisin kerrointa 1,5 arvioidessa työmääriä. Eli kun korkean maturiteetin yritys joka tekee uuden sukupolven tietovarastoa arvioi toteutustyöksi 100 htp niin matalan maturiteetin yrityksen kannattaa varata samaan työhön 150 htp.

Yhteenveto: tietovarastojen toteutustyön ja kustannusten arviointi

Tietovarastoympäristöjä rakentaessa työmäärät voivat heilahdella todella paljon ja olen nähnyt samasta työstä annettavan 20 päivän ja 120 päivän työmääräarvioita. Molemmat olivat pihalla kuin lumiukko ja osoittivat vähäistä ammattitaitoa ja toisen osalta halua kupata asiakas kuiviin.

Purkamalla toteutustyön osuuden atomeiksi eli mahdollisimman pieniin osiin, voidaan työmääriä arvioida usein hyvinkin tarkalla tasolla. Lisääntynyt läpinäkyvyys ei ole haitaksi luottamuksen rakentamisessa asiakkaan ja toimittajan välillä.

Oma suuntaa-antava arviointimalli perustuu seuraavaan kaavaan:

  1. Tietolähteiden ja asiakokonaisuuksien (käsite/kohde/entiteetti) määrä:
    • 2 pv * lähteiden määrä * asiakokonaisuuksien määrä.
    • Esim. myynti ja tuote -taulut yhdestä tietolähteestä: 2 htp * 1 tietolähde * 2 kohdetta = 4 htp
  2. Datan määrä ja ennen kaikkea laatu:
    • Vähän dataa: kerroin 1
    • Keskiverto: kerroin 1,5
    • Paljon dataa: kerroin 2
  3. Raporttien, mittarien, työpöytien määrät
    • Helppo raportti: 1 htp/raportti
    • Keskivaikea raportti: 1-3 htp/raportti
    • Vaikea raportti: +4 htp/raportti
  4. Tekninen monimutkaisuus ja erityisvaatimukset (DW, raportit, jakelu)
    • tapauskohtaista, vaatimusmäärittelyn jälkeen tiedetään paremmin
  5. Yrityksen/organisaation sitoutuminen projektin läpivientiin ja tukemiseen
    • Arvioitava näppituntumalla. Vaikea asia perustella asiakkaalle jos käyttää isoa kulmakerrointa.
  6. Tekniset valmiudet ja maturiteetti (0 –taso vs. valmis BI-ympäristö, joka upgradetaan)
    • Aivan uusi tietovarasto, alhainen maturiteetti: kerroin 1,5
    • Yritys on jo tehnyt aiemmin tietovarastoja, korkea maturiteetti: kerroin 1

Esimerkkilaskelma tietovaraston ja raporttien rakennuskustannuksista, sisältäen kiinteät osuudet:

Esimerkkiympäristön kuvaus: 2 ERP-järjestelmää. Tunnistettuja faktakäsitteitä on myynti, ostot, varastosaldot ja varastotapahtumat. Tunnistettuja dimensioita on tuote, asiakas, organisaatio, aika. Yhteensä siis 8 asiakokonaisuutta/kohdetta ja 2 lähdejärjestelmää.

Yritys tekee ensimmäistä tietovarastoa ja tiedon laatu on kysymysmerkki. Valmiita sql-lauseita ei ole saatavilla kuin osittain vanhoilta Excel-raporteilta. Teknisesti ei ole asetettu mitään erityisehtoja toiminnallisuuteen. Raportteja tehdään 1 isompi työpöytä ja 4 perinteistä listaraporttia.

Rivimäärät on keskivertoja, kaikki taulut yhteensä n. 2 miljoonaa riviä.

Arvioidut työmäärät:

  • Projektin suunnittelu ja aloitus: 5 htp
  • Vaatimusmäärittely: 10 htp
  • Tekninen ympäristö (palvelimet, ohjelmistot): 2 htp
  • Toteutus:
    • DW (ETL-työ): 2 htp * 2 lähdettä * 8 kohdetta = 32 htp. Lisäkerroin datamääristä 1,5*32= 48 htp
    • Raportit: 4 htp * 1 iso työpöytä + 1 htp * 4 helppoa raporttia = 8 htp
    • Yhteensä totetutus: 56 htp. Lisäkerroin alhaisesta maturiteetista: 1,5 * 56 htp = 84 htp
  • Testaus: 10% toteutuksen työmääristä eli pyöritettynä: 8 htp
  • Projektinhallinta: 10% kokonaistyömääristä: 109 htp * 0,1 = 11 htp

KAIKKI YHTEENSÄ: 120 htp

Käytän itse tätä mallia tehdessä karkeata arviota tietovarastoprojektin tai vaikka projektiin liittyvien lisätöiden kustannuksista. Se luo läpinäkyvyyttä ja nostaa luottamusta myös asiakkaassa kun hän tietää mitä tulemme tekemään ja mistä näemme työn muodostuvan.

Projektisuunnitelmassa ja tuntiseurannassa työt jaetaan sitten vielä paljon pienempiin osiin, esimerkiksi yksi faktataulu voidaan laittaa kolmeksi seurantakohteeksi: 1. stagelataus, 2. dw-lataus ja 3. testaus. Käyttäjähallinta, ympäristön automatisointi, virheiden valvonta, käyttöönotto, koulutukset ja dokumentoinnit tulevat tietenkin päälle. Mutta tietovarastojen projektin hallinnan vaihejako ja parhaat käytännöt on sitten toisen kirjoituksen aihe.

Toivottavasti tästä mallista on hyötyä muillekin ja jos teillä on parempia laskentamalleja tai korjausehdotuksia niin laittakaa tulemaan mailia tai kommentoikaa tätä kirjoitusta alla.


Ps. Jos aihe kiinnostaa, lue myös vanha kirjoitus: Paljonko tietovarasto maksaa?


18.03.2015 / Ville Niemijärvi

Edellisessä kirjoituksessa muistutin miksi vähänkään isomman yrityksen ja vakavasti itsensä ottavan CIO:n ei kannata rakentaa yrityksensä tietoarkkitehtuuria ja johtamisjärjestelmää pelkästän Qlikin varaan. Tai minkään raportointityövälineen.

Turvallisempi, suorituskykyisempi, skaalautuvampi ja pitkällä tähtäimellä edullisempi ratkaisu on rakentaa se tietovaraston päälle.

Tästä huolimatta tiedän, että Suomessa valtaosa Qlik-ratkaisuista on tehty suoraan operatiivisten järjestelmien päälle.

Tällaisissa tapauksissa voidaan mennä parin vuoden sisällä todella syvälle suohon tai koittaa selviytyä tilanteesta kunnialla. Eli nyt tarkkana: kumpaan kastiin haluat kuulua?

Käyn seuraavaksi läpi jälkimmäisen vaihtoehdon; miten tehdä hyvä Qlik-ratkaisu ilman tietovarastoa.

Simuloi Qlikillä tietovarastointia

Qlikissä on alkeellinen sql:n kaltaiseen komentokieleen perustuva ns. etl-työväline. Voit ladata ja muokata sillä dataa aika monipuolisesti. Qlikissä on myös omat datatiedostot (tiedosto.qvd), joihin voi tallentaa suuria määriä tietoa, ennen kuin sen vie varsinaiseen qlik-sovellukseen (tiedosto.qvw).

Qlikillä on siis kaikki komponentit, joilla voidaan toteuttaa samankaltainen arkkitehtuuri ja toiminnallisuus kuin tietovarastossa. Lisäksi kun otat käyttöön muutamia parhaita käytäntöjä, jotka ovat tietovarastomaailmassa arkipäivää, pääset varmasti säädyllisen lopputulokseen (edelleen olet menossa perse edellä puuhun mutta nyt sentään tyylillä).

Seuraavassa on kolme tärkeää oppia tietovaraston maailmasta, jotka kannattaa ottaa käyttöön Qlik-ympäristöä toteuttaessa.

1. Tietomallinnus ja datan harmonisointi on tärkeintä

Tietovarastossa on tärkeää määrittää yhteiset käsitteet ja laskentasäännöt. Tietovaraston perusperiaatteita on datan yhteismitallistaminen – tarjota yhdet yhteiset luvut yhdestä paikasta.

Tähän päästään mallintamalla yrityksen tiedot, päättämällä miten se kate lasketaan tai mikä on yrityksen virallinen tuote- tai tilihierarkia. Miten hyvitykset ja alennukset huomioidaan myynnissä ja puhutaanko ylipäätään myynnistä, liikevaihdosta vai laskutuksesta.

Tämän lopputuloksena on tietomalli. Tai käsitemalli. Se kuvaa yrityksen tärkeimmät käsitteet ja niiden väliset suhteet selkokielellä. Tietomalli on tietovaraston sydän ja sisäelimet, runko ja ranka.

tietomalli
Tietomalli, joka sopii 9/10 suomalaisista tietovarastoista.

 

Tietomalli toimii ennen kaikkea kommunikointivälineenä IT:n ja liiketoiminnan välillä. Se auttaa myös Qlik-kehittäjiä hahmottamaan, miten eri tietokokonaisuudet linkittyy toisiinsa.

Qlik-sovelluksia tehdessä kannattaa käyttää hetki aikaa käsitemallinnukseen. Lupaan, että tämä maksaa itsensä takaisin moninkertaisesti.

2. Kerroksellinen arkkitehtuuri (2- tai 3-kerros)

Tietovarastot toteutetaan kerroksittain. Alunperin tietovarastoissa oli kaksi kerrosta: ns. datan latausalue (staging-tietokanta) ja varsinainen tietovarasto. Nykyään data vaultin myötä näkee 4-tasoarkkitehtuureja. Tätä samaa kerroksellisuutta kannattaa suosia Qlikissä.

Onkin erittäin tärkeää erotella Qlikissä data ja sovellukset toisistaan. Tallenna siis operatiivisten järjestelmien data kuten laskutus, ostotilaukset, varastosaldot, tuotteet… kukin omaan Qlikin datatiedostoon (qvd).

Määrittele lisäksi hallintamalli kullekin datatiedostolle ja dokumentoi latausrutiinit hyvin: millä syklillä, järjestyksellä ja millä logiikalla tärkeitä yhteisiä käsitteitä ja etenkin dimensioita päivitetään.

Tuotteet, asiakkaat, organisaatio, tilihierarkia jne. ovat useimmiten tärkeimpiä yhteisiä dimensioita. Määrittele näille tiedon omistaja, joka vastaa siitä, että dimensiot pysyvät kunnossa ja data on validia.

Näin datatiedostot ajavat tietovaraston virkaa. Tärkeimmät tiedot ovat keskitetyssä paikassa ja Qlikin sovellukset pystyvät myös lukemaan niitä huomattavasti nopeammin kuin operatiivisia tietolähteitä.

Pyri minimoidaan suoraan Qlik-sovelluksiin (esim. johdon työpöytä) tietojen lataaminen, vaikka se kuinka kivalta ja nopealta tuntuisikin. Se, että viet datan ensiksi qvd-tiedostoon, vie ehkä 15 min enemmän aikaa mutta vuoden sisällä tämä voi säästää sinulta 15 päivää. Lue aiheesta lisää: Usain Bolt Jukolan viestissä.

3. Datan yhteiskäyttö: pyritään yhteen totuuteen

Kun datat on keskitetysti ylläpidetyissä datatiedostoissa, voit käyttää samoja tiedostoja useissa eri sovelluksissa. Tuotteita saatetaan tarvita kymmenellä eri sovelluksella ja raportilla – nyt se haetaan kaikille raporteille yhdestä keskitetystä paikasta. Sama pätee myynteihin, ostoihin, saldoihin, kiertonopeuksiin ja muihin tärkeisiin mittareihin.

Tällöin käyttäjät saavat yhteismitallista tietoa mutta helpotat myös IT-osaston työtä kun tiedot ovat helpommin hallittavissa kun liittymiä on vähemmän ja laskentalogiikat hallitaan keskitetysti.

Yhteenveto

Vaikka päädyt innoissasi tekemään Qlik-ratkaisun ilman raportointikantaa tai tietovarastoa, älä hätäänny. Plöröt on housuissa mutta ne voi pestä ja tilanteesta voi selvitä kunnialla. Tässä tiivistetyt ohjeet:

  1. Tee tietomalli
  2. Tee kevyt hallintamalli, määritä latausrutiinit ja tiedon omistajuudet
  3. Erota data ja sovellukset toisistaan (2- tai 3-tasohierarkia)
  4. Yhteismitallista ja yhteiskäytä: pyri yhteen yhteiseen totuuteen

Alla vielä kuvina miten Qlikillä voi tehdä a.) tuhoa b.) kohtuullisen fiksusti ja c.) todella järkeviä ja kestäviä ratkaisuja. Valinta on sinun (kuten vastuukin).

Qlik arkkitehtuuri tehtynä väärin
Qlik sillisalaatti: älä lataa sovelluksiin tietoa suoraan lähdejärjestelmistä.

 

Qlik arkkitehtuuri tehtynä lähes oikein
Erottele data- ja sovelluskerros toisistaan. Näin simuloit tietovarastointia ja teet eheämmän kokonaisuuden.

 

Qlik arkkitehtuuri tietovaraston kanssa on kestävä
Fiksuin ratkaisu on kuitenkin rakentaa Qlik-ratkaisu tietovaraston päälle. Näin varmistat modulaarisuuden, turvallisuuden, skaalautuvuuden ja suorituskyvyn.