25.04.2017 / Ville Niemijärvi

Istahdin taas alas Lassen, Louhian johtavan Data Scientistin kanssa ja rupateltiin vähän mitä työvälineitä edistyneen analytiikan toteutustöissä tarvitaan.

Edellisessä kirjoituksessa käytiin Lassen kanssa läpi mitkä ovat Data Scientistin 3 tärkeintä taitoa. Noista taidoista voi jo vähän päätellä minkälaista työkaluosaamista pitää myös hallita.

Voit katsoa videon tästä tai tämän blogin alta.

Data Scientistin tärkeimmät työvälineet

Louhialla jo reilun 5 vuoden ajan kymmeniä data science -toteutuksia tehnyt Lasse luettelee ison listan tuotteita, joita käyttää päivittäin työssään.

  • ETL-työ, data integraatio ja muokkaus: SQL Server Integration Services
  • Tietokannat: SQL Server Management Studio
  • Mallintaminen, data science: R, Python, RapidMiner, Azure ML
  • Tiedon visualisointi, raportointi: QlikView, Power BI

Jokaisella tuotteella on oma roolinsa ja jotta saadaan parempi ymmärrys missä niitä käytetään, sijoittelimme ne alla olevassa kuvassa tyypilliseen business intelligence/analytiikka -arkkitehtuuriin.

Tyypillinen analytiikka-arkkitehtuuri ja data scientistin työvälineet

Tyypillinen tietovarasto/business intelligence/analytiikka -arkkitehtuuri
Tyypillinen tietovarasto/business intelligence/analytiikka -arkkitehtuuri

Kuvassa yllä näkyy tyypillinen arkkitehtuuri, joka on joko valmiina rakennettuna yrityksessä tai me rakennamme sellaisen osana analytiikka- tai laajempaa tiedolla johtamisen hanketta.

Alimpana on tietolähteet eli organisaation lukuisat operatiiviset järjestelmät, CRM:t, taloushallinto  jne. Sekä yhä useammin myös ulkoiset tietolähteet, joka avoimien rajapintojen kautta tai ostettuna 3. osapuolelta.

Tieto täytyy tämän jälkeen ladata analytiikkaa varten jollekin tallennusalustalle. Latauksen yhteydessä tietoa usein yhdistetään, muokataan, siivotaan. Tätä kutsutaan tietovarastopiireissä ETL-prosessiksi (extract-transform-load) mutta usein puhutaan vain tiedon integraatiosta.

Tässä Lasse hyödyntää lähinnä SQL Server Integration Serviceä (SSIS). Itse olen käyttänyt SSIS:n lisäksi Pentahoa ja IBM Cognos Data Manageria, joka on nykyään korvattu IBM Infosphere DataStagella.

Muita markkinoilta löytyviä tuotteita on mm. Informatica, Oracle Warehouse builder, SAS Data Integration Studio.

Tieto siis tallennetaan jollekin tallennusalustalle ja useimmiten se edelleen on relaatiotietokanta. Lassen tapauksessa useimmiten SQL Server jota hallitaan SQL Server Management Studiolla.

Big data (esim. Hadoop) ja NoSQL -tietokannat ovat yleistyneet ja niitä on asiakkaillamme mutta lopulta tieto on helpointa viedä relaatiokantaan, jotta sitä voidaan hyödyntää tilastollisessa mallintamisessa eli varsinaisessa data science -työssä.

Tällöin käyttöön otetaan mallinnustyövälineet kuten R, Python, RapidMiner tai Azure Machine Learning.

Muita markkinoilta löytyviä tuotteita ovat mm. SAS, Knime, SPSS, Amazon Machine Learning, IBM Watson.

Kun ennustemallit tai muu edistyneen analytiikan mallinnus on tehty, tulokset viedään usein visualisoituna liiketoiminnalle (jolleivät mene osaksi jotain operatiivista prosessia tai applikaatiota).

Tällöin käyttöön otetaan raportointi-, visualisointi- ja business intelligence -tuotteet. Lasse suosii näissä QlikView:tä ja Power BI:tä.

Muita asiakkaillamme yleisiä BI-tuotteita ovat mm. Tableau, Cognos, SAP ja Oracle.

Data Scientistin pitää hallita iso joukko tuotteita

Kuten yltä näkyy, ainakin konsulttifirmoissa Data Scientistin pitää hallita iso joukko eri tuotteita.

Totta kai isoissa projekteissa usein on omat erikoismiehet tietovaraston tai data laken rakentamiseen ja omansa tiedon visualisointiin.

Mutta prosessi menee todella hitaaksi jos data scientisti joutuisi joka kerta kun tarvitsee uutta data settiä tai muokkauksia olemassa olevaan, kutsumaan ETL-osaajaa avuksi.

Työ on niin iteratiivista, että on tehokkainta, että DS-roolissa pystytään ottamaan myös ETL-työ, tietokannat ja datan visualisointi haltuun.

Katso video kokonaisuudessaan alta. Muista laittaa Louhian Youtube-video seurantaan ja kommentoi rohkeasti jos haluat kuulla ja nähdä lisää analytiikka-asiaa meiltä.

 


3.11.2016 / Jani Liimatta

Oikeaoppinen menetelmä budjettien laadintaanhan on aina alhaalta ylös. Eli laaditaan budjetit alimmalla mahdollisella tasolla, ja summataan sieltä ylöspäin yhteen. Näin yleensä saadaan aikaiseksi luotettavammat budjetit.

No, joskus voi tietysti miettiä, onko sinne alimmalle tasolle aina mielekästä tai edes mahdollistakaan pähkäillä oikeita lukuja? Joskus se vaan on mahdotonta. Ja olisi ehkä kuitenkin hyödyllistä nähdä ne budjettiluvut siellä atomitasolla. Esimerkiksi, jos tuote jakautuu satoihin eri variaatioihin. Askartelepa siitä sitten budjetti kaikille myyntialueille. Tai jos tarkin myyntialue on kuntataso? Budjetoinnin rivimäärä räjähtää käsiin. Perinteisesti tässä on käytetty staattisia kertoimia, tai viime vuoden myyntejä. Voisikohan tämän tehdä jotenkin tarkemmin ja automaattisemmin?

Eräällä asiakkaalla haasteena oli että budjetit luodaan tuotteittain ja kuukausittain. Nämä pitäisi sitten jakaa myyntialueille – eli esim. 10 tuotetta * 12 kk * 30 aluetta = 3600 riviä. Käsipelillä tekemätön paikka jo muutamallekin tuotteelle.

Esimerkki: kenkätehtaan budjetointihaasteet.

Kenkätehtaalla on laaja skaala kenkiä, joita myydään maantieteellisesti eri alueille. Kuukausimyyntien jakaumat poikkeavat toisistaan. Saappaita myydään pohjoisessa eri tahtiin kuin etelässä. Tarve on räjäyttää budjetoitu myynti alueille, joita Suomessa on kymmeniä. Lisäksi on erityyppisiä kauppoja; kenkäkauppoja, tavarataloja, nettimyyntiä jne.

Lisäksi eri tuotteet ovat eri vaiheissa elinkaartaan. Siksi mitään perinteisiä kertoimia budjetin jakamiseksi ei pystytä asettamaan. Täytyy keksiä jotain viisaampaa.

Budjetithan voisi ylätasolla syöttää vaikka SharePoint-listalle, josta ne luetaan jatkojalostusta varten eteenpäin. Eli syötetään budjetit tuotetasolle, myyntikanavittain. Lisäksi uusille tuotteille annetaan oma laskentamallinsa, jos historiamyynti puuttuu.

 

 

 

 

 

 

 

Data kirjoitetaan ja luetaan SSIS:n SharePoint-komponenteilla SQL Server-tietovarastoon.

Seuraavaksi valjastetaan maailmalla hypetetty R budjetointiprosessin tajunnanräjäyttäjäksi.

rlogo

  1. Tietovarastosta luetaan R:lle annettujen parametrien perusteella myyntihistoria alueittain taaksepäin useamman vuoden ajalta. Eli per yksi budjettirivi, meillä on käsissä useamman vuoden myyntihistoria kaikilla maantieteellisillä alueilla. Myyntihistorian muodostuksessa huomioidaan myös annetut parametrit: ‘Uusi kärkituote’-myyntihistoria muodostetaan uusien kärkituotteiden tuoteryhmästä. Kävelykengät-historia kaikista kävelykengistä alueittain.
  2. Integroidaan ennustavan analytiikan R osaksi ETL-prosessia. Hyödynnetään sinne itse rakennettuja älykkäitä aikasarjaennustemalleja. R-koodi valitsee parhaan algoritmin automaattisesti kullekin tuotteelle, sekä generoi myyntiennusteen hamaan tulevaisuuteen.

Eli: syöttämällä 1 budjettirivi per tuote, ennustemoottori jyvittää yhden budjettirivin 30:lle myyntialueelle automaattisesti. Näin saadusta myyntiennusteesta lasketaan vielä ennustettu suhteellinen myynnin jakauma. Jakaumalla kerrotaan käyttäjän antama budjetti.

Lopputuloksena on aluekohtainen raportti, jossa samalla saadaan näkyviin sekä toteutunut myynti, että myyntibudjetti. Budjetti jatkuu toteutuneen myynnin jatkeena hämmästyttävällä tarkkuudella.

Graafi

Saapas lyhyt on uusi tuote, jolla ei ole aikaisempaa myyntiä. Lenkkarilla sen sijaan on. Olisi voinut tehdä hieman monimutkaisemmat graafit tähän. Junamatka loppui kerrankin kesken.

Lopputuloksena saatiin generoitua automaattisesti hirmuinen nivaska budjettirivejä. Ja voidaan mainostaa turuilla ja toreilla nykyiseen liioittelevaan tyyliin, että käytettiin budjetoinnissa AI:tä, koneoppimista, machine learningia, ennustavaa analytiikkaa ja R:ää. Big Dataa ei nyt sentään. Mutta hetkonen… tähänhän olisi voinut lyödä sekaan vaikka pitkän aikavälin luotettavat sääennusteet. Tiedettäisiin etukäteen, kuinka moneen kumisaappaaseen täytyy tilata raaka-aineita. Ja somedatasta saataisiin selvitettyä onko kumisaappaista tulossa uusi muoti-ilmiö..

 

 

 

 


2.09.2016 / Jani Liimatta

On synkkä ja myrskyinen perjantai-iltapäivä. Käyn läpi toisen konsultin tekemää tietovarastoa ja ETL-latauksia. Otsasuoni pullistuu. Yritän oikean käden tiiviillä hiirityöskentelyllä epätoivon vimmalla löytää edes yhden parhaiden käytäntöjen mukaisen toteutuksen spagetin joukosta. Vasen käsi hapuilee farkkujen taskun pohjalta verenpainelääkitystä, siinä kuitenkaan onnistumatta. Päässä pyörii epätoivoisia ajatuksia:

  • Jos tehdään jotain uutta (= ei ole ennen tehty tietovarastoja), olisiko syytä edes hieman opiskella asiaa? Olisikohan joku jo maailmalla miettinyt, miten homma kannattaisi tehdä?
  • Löytyykö tekijöiltä minkäänlaista kunnianhimoa työn jäljen suhteen?
  • Eikö osaamista jaeta lainkaan edes yhden yrityksen sisällä? Eivätkö konsulttiyritykset edes halua luoda omia parhaita käytäntöjä? Onko busineksen ainut arvo laskutetut eurot, työn laadulla ei ole niin väliä? Kolikon kääntöpuolella on tietysti se, että puolivillaisesti tehty toteutus generoi enemmän laskutustunteja.

Normipäivä siis.

Ei hitto. Olisipa peruskoulussa opetettu googlauksen alkeet. Olisi edes joku perusasia kunnossa. Jos vaikka olisi väistetty edes yksi pahimmista munauksista ao. vartissa kirjoitetulta syntilistalta…

  1. SQL Server Integration Services-DW:n paras oppikirja tehtiin jo vuonna 2005! Huikeaa. Lue tämä ennen kuin teet ensimmäistäkään työliikettä. Moni alla olevista vinkeistäkin löytyy tästä kirjasta http://www.kimballgroup.com/data-warehouse-business-intelligence-resources/books/microsoft-data-warehouse-dw-toolkit/
  2. Mallinnus. Oli se sitten tähtimalli tai DataVault. Dimensiodata dimensioon, faktat faktoihin jne. Määrittelyvaiheessa on tehtävä tietokannan mallinnus. Mallinnus on koko homman A ja O. Eräässä casessa oli päädytty tälläämään kaikki erityyppiset faktat yhteen ja samaan faktatauluun. No, tässä tapauksessa ei sitten voinut oikein puhuakaan agilesta kehityksestä, joustavuudesta tai kannan suorituskyvystä, ainakaan samassa lauseessa.
  3. Ensimmäiset johtopäätökset tekemisen laadusta voi melkein vetää jo siitä, onko SSIS:ssä käytetty mitään template-pakettia vai ei. 90%:ssa tapauksista ei. Omalla template-paketilla saat esim. lokitukset ja virheenkäsittelyt kuntoon. Ja yhtenevät muuttujat, dataflowt jne eri pakettien välillä – ja tekemisen edes jollain tasolla yhteneväiseksi eri kehittäjien kesken. Peukalosääntö: 1 taulu per 1 paketti. Jossain Microsoftin omassa esimerkeissäkin on tehty koko DW parilla paketilla. Mutta miten hoidat useamman kehittäjän työskentelyn tai suorituskyvyn optimoinnin, jos koko DW on yhdessä paketissa? Näitä virityksiä on nähty monessa projektissa.
  4. Mieti ETL:ää tehdessäsi kahta asiaa: ylläpidettävyys ja suorituskyky. Väärin käytettynä SSIS tappaa suorituskyvyn. SSIS perustuu muistin käyttöön, osa valmiskomponenteista vaatii koko datan lukemisen kerralla palvelimen muistiin. Kaksi karmeaa käytännön esimerkkiä kotimaisista tietovarastototeutuksista:
    1. Tietovarastoon kirjoitettiin kaikki data prosareilla, joita komennettiin Oledb Command-komponentilla. So what? No, jokainen tietovaraston läpi mennyt uusi rivi kutsui yksitellen prosaria. Eli miljooonan rivin kirjoittaminen kantaan generoi miljoona yksittäistä kyselyä. Loppuasiakas ihmetteli, kun ei meinannut latauksissa yö riittää. No ei ihme.
    2. Toisessa casessa tietovaraston rakentamisessa oli käytetty SSIS-paketteja – mutta kaikki oli tehty SQL:llä MERGE-kyselyitä käyttäen. Ylläpito oli “hieman” hidasta ja kankeaa… ja olisihan sitä voinut myös googlettaa, suositteleeko MERGE:n käyttöä maailmalla kukaan muu… Tässä projektissa oli onnistuneesti jätetty käyttämättä kaikki SSIS:n hyvät puolet ja yhdistetty siihen päälle suorituskyvytön ja hankalasti ylläpidettävä SQL-koodi.
  5. Tietokannan perusasiat kuntoon. Ovatko indeksit, Foreign Keyt, Primary Keyt  tuntemattomia käsitteitä? Ei uskoisi, ellei omin silmin näkisi kantoja, joista kaikki mainitut pikkudetaljit ovat päässeet jotenkin unhottumaan. Tai relaatiot eri taulujen välillä hoidetaan SUBSTRING-funktioilla. Tämäkin on nähty, usko tai älä.
  6. Kannattaa perehtyä uusien työkaluversioiden tuomiin mahdollisuuksiin huolella ja ajatuksella. Äkkinäinen voisi kuvitella, että esimerkiksi kymmenessä vuodessa ETL-työkaluun saattaisi tulla joitain sellaisia ominaisuuksia, jotka kannattaisi jopa ehdottomasti ottaa käyttöön. Ehkä version 2005 kaikkia ominaisuuksia ei enää kannata käyttää vuonna 2016?

 


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.


23.04.2015 / Jani Liimatta

Viime vuosina on itselläni on ollut mahdollisuus nähdä melkoinen nivaska muiden yritysten ja kehittäjien toteuttamia tietovarastoja, ETL:stä tietokantoihin. Toteutusten yleinen taso on ollut hyvin kirjavaa, samoin kuin asiakastyytyväisyyskin näihin projekteihin. Yksi suurimmista riskeistä on siinä miten kovan osaajan toimittaja pöydän toiselle puolelle tällää määrittely- ja toteutusvaiheissa.

Tietovaraston tekeminen ei ole mitään rakettitiedettä. Onnistunut projekti vaatii tekijältä siltikin harvinaisen laajaa osaamista. Tarvitaan mm

  • Asiakkaan prosessien ja liiketoiminnan laajaa ymmärrystä
  • Osaamista lähdejärjestelmistä, niiden toiminnoista ja tietokantarakenteista
  • Mallinnusosaamista tietovaraston osalta – jotta se palvelee mahdollisimman hyvin raportointi yms. tarpeita.
  • Tietokantojen mallinnus niiltä osin mitä se vaikuttaa suorituskykyyn ja latausnopeuksiin
  • ETL-välineen teknistä osaamista ja ymmärrystä
  • Vahvaa tietokantaosaamista suorituskyvyn ja teknisen toteutuksen osalta

Kolmeen ensimmäiseen kohtaan eivät auta tekniset työvälineet – tai koulutuskaan välttämättä. Näissä osaaminen tulee aika pitkälti kokemuksen kautta. Auttaa paljon jos tekijä on tehnyt elämässään jotain muutakin kuin kirjoittanut koodia. Kannattaa perehtyä tekijän referensseihin huolella.

tx2014Kokemusteni mukaan tekijöillä on suuria puutteita myös teknisessä osaamisessa. Nämä riskit ovat osittain taklattavissa teknisillä apuvälineillä. TimeXtender automatisoi tekniset asiat ja suorittaa sen aina parhaiden käytäntöjen mukaisesti. Kehittäjän ei välttämättä tarvitsekaan osata esimerkiksi

 

  • tehdä Update/Insert-logiikkaa niin että se on latausajoiltaan mahdollisimman nopea
  • Osata käyttää ETL-välineen oikeita palikoita oikeissa paikoissa. Sekin näyttäisi olevan monelle perustekijälle hämmästyttävän vaikeaa. On helppoa syyttää suorituskykyongelmista liian kevyttä rautaa tai työkalun ongelmia.
  • Osata indeksoida tietokantaa – ja nimetä indeksejä oikeaoppisesti. Luoda suurten tapahtumataulujen partitioinnit
  • Luoda mahdollisimman tehokkaasti toimivaa hitaasti muuttuva-dimensio-rakennetta
  • jne

Entä virhealttius? Jokainen tietovarastoprojekti on erilainen, jopa silloinkin kun kahdella asiakkaalla on sama lähdejärjestelmä ja asiakkaat toimivat samalla toimialalla. Raportointitarpeet ovat siltikin uniikkeja. Tämä johtaa siihen että myös tietovarastot ja niihin liittyvä logiikka ovat uniikkeja. Jos automaatio hoitaa logiikan rakennuksen, eikö silloin tule väkisinkin vähemmän virheitä ja testaustarvekin on pienempi?

Kolmas riski liittyy projektin sisältöön. Jos määrittely on massiivinen, logiikka kompleksinen ja työmäärät valtavia – voi käydä niin että projektin valmistuessa liiketoiminnan vaatimukset ovat jotain ihan muuta kuin mitä määrittelyissä todettiin. Tätä voi osin taklata agileilla menetelmillä. Vielä paremmin taklaus onnistuu jos avuksi otetaan jotain kättä pidempää jolla projektin läpimenoajat saadaan järkevälle tasolle.

Lue lisää TimeXtender-tuotteesta: www.timextender.com tai varaa oma demoaika 040-777 1142,

tai tule paikalle katsomaan demo TDWI-tapahtumaan 28.5.


9.04.2015 / Jani Liimatta

Tietovarastojen tekeminen on kokemassa suurta murrosta. Meidän lisäksi pari muutakin kilpailijaa kotimaassa on puuhastelemassa automatisointituotteiden parissa. Louhia on valinnut tuotteekseen yhden maailman markkinajohtajista, tanskalaisen TimeXtenderin. TimeXtender toimii täysin Microsoftin BI-stack:in päällä.

Miten tuo otsikossa mainittu 80% ajansäästö on mahdollista? Olen itse asiassa hyvin vakuuttunut tästä. Ajan säästö koostuu mm.

  • Automaattisesta tietokantaskeemojen ylläpidosta (kehittäjä ei enää lisää sarakkeita, indeksejä, näkymiä jne tietokantaan)
  • SQL:n määrän radikaalista vähenemisestä
  • Pienemmästä virhemäärästä (mm. partitioinnit, hitaasti muuttuvat dimensiot, inkrementaaliset lataukset kun hoituvat tavallaan itsestään, aina samalla tavalla)
  • Pienemmästä aivotyöstä (aikaa kuluu vähemmän ratkaisujen pohdiskelemiseen)
  • Tietovaraston ylläpito voidaan hoitaa asiakkaan pääkäyttäjän toimesta (vaikka nyt uuden sarakkeen tuonti lähdejärjestelmästä kuutioon/Qlik:iin/raporteille asti)

Toki – jos lähdejärjestelmä on kovin monimutkainen, tarvittavat laskennat ja datan muokkaukset hyvin vaativia, datan laatu huttua, ei tuo 80% toteudu. Kaikkea ei kuitenkaan voi automatisoida.

Tietovarastohankkeessa kuitenkaan ei pidä ajatella pelkän yksittäisen projektin kustannusta. On ajateltava myös koko hankkeen elinkaarta. Esimerkiksi – jos haluat valmiista tietovarastosta raportille uuden puuttuvan sarakkeen, tapahtuu perinteisessä ympäristössä seuraavia steppejä:

  1. Ota yhteyttä toimittajaan. Määrittele lähdejärjestelmän sarake ja kuvaa mihin se pitäisi raportilla/tietovarastossa saada
  2. Odota toimittajan resurssin toimenpiteitä. Tässä voi mennä aikaa 1-15 päivää
  3. Toimittaja tekee seuraavaa stagen osalta: muokkaa lähde-SQL:ää, lisää stage-kantaan sarakkeen, muuttaa ETL-latausta, suorittaa latauksen
  4. Toimittaja tekee seuraavat toimenpiteet tietovaraston osalta: muokkaa lähde-SQL:ää, lisää kantaan tai metamalliin sarakkeen, päivittää tietokannan, ajaa ETL:n
  5. Toimittaja päivittää dokumentaatiota, jos päivittää. Tässä vaiheessa ollaan vasta kehitysympäristössä.

Tässä menee yleensä kalenteriaikaa 3…15 päivää. Suuren toimittajan laskutus tästä ilosta voi olla 2 htp sisältäen muutokset testiympäristössä, testaukset, viennit tuotantoon. ISTU JA PALA! YHDEN SARAKKEEN LISÄÄMINEN RAPORTILLE!

TimeXtenderillä homma hoituu seuraavasti:

  1. Avaa työkalu
  2. Klikkaa lähdejärjestelmän saraketta, prosessoi (tietokantaan lisätään sarake automaattisesti, ETL päivitetään automaattisesti)
  3. Klikkaa stagella oleva data mukaan tietovarastotauluun. Prosessoi (tässäkin kaikki tapahtuu automaattisesti taustalla)
  4. Dokumentaatio on automaattisesti ajan tasalla

Asiakas pystyy pienellä opastuksella tekemään tämän itse. Aikaa tähän kuluu latausten lisäksi ehkä 15 minuuttia. Toimittaja ei lähetä laskua. Näin tämän homman pitääkin mennä. Pysy kuulolla, tästä aiheesta kirjoittelemme lähiaikoina lisää.

Tule katsomaan miten homma tehdään 28.4. PASS-tapahtumaan

Jos et ehtinyt PASS-tapahtumaan, varaa oma demoaika 040-777 1142 tai tule paikalle TDWI-tapahtumaan 28.5.

Lue lisää TimeXtenderistä: www.timextender.com


9.02.2015 / Jani Liimatta

QlikView, Tableau, PowerBI, Hadoop. Siinä muutama kuuma tuote jotka ovat viime vuosina tuoneet uusia tuulia BI-markkinoille. Raporttien luonti on muuttunut ketterämmäksi. Samoihin aikoihin kankeimmatkin BI-talot ovat alkaneet siirtymään vähä vähältä agile-menetelmiin, pois vesiputousmallista. Onhan tämä tuonut pientä notkeutta ja nopeutta tietovarastojen kehitykseen. Tämä osin näennäinenkin kehitys ei vaan riitä vielä millään.

Samalla näemme viikoittain asiakkaita jotka ovat ongelmissa erityisesti QlikView-ympäristöjensä kanssa. Nämäkään projektit eivät ole olleet lähimainkaan niin helppoja ja yksinkertaisia kuin on alkuun luultu. Mallit pirstaloituvat, arkkitehtuuriset korttitalot huojuvat. Monessa paikassa on alettu pohtimaan uudestaan koko arkkitehtuuria. Tarvittaisiinko se tietovarasto sittenkin?  Huonot kokemukset tietovarastoprojekteista kuitenkin hirvittävät.

Toisaalla suuret kilpailijat rummuttavat valtavan kalliiden appliance-ratkaisuiden sekä Data Vault-mallinnuksen ylivertaisuutta. Jättämällä kertomatta että sen Data Vaultin päälle on kaiken kukkuraksi rakennettava se perinteinen tähtimallinen ja kankea tietovarasto.

Louhialaisetkaan eivät ole lepäilleet laakereillaan. Erityisesti muualla maailmassa on alettu enenevissä määrin puhumaan tietovarastojen tekemisen automatisoinnista. Voisiko tietovarastoja oikeasti luoda ketterillä menetelmillä?

Miten saada uusi sarake mahdollisimman nopeasti tietovarastoon, kuutioon, QlikView:iin? Onko pakko odottaa kaksi viikkoa?

Voisiko pääkäyttäjä lisätä uutta dataa tietovarastoon ihan omatoimisesti?

Tiedämme ette kotimaassa ole ainoita. Olemme törmänneet pariinkin projektiin jossa kehitellään automatisointivälineitä, tosin niissä ei ilmeisesti olla ilmeisesti kovin pitkällä kun tuotteita ei uskalleta vielä sen suuremmin mainostaa.

Maailmalla on käynnissä useampia työkaluprojekteja jotka käyttävät avointa BIML (Business Intelligence Markup Language)-rajapintaa.

  • BIML:issä itsessään on aika korkea oppimiskäyrä, vaatii skriptikielen opettelua
  • Tässä on kyse lopulta vain uudesta käyttöliittymästä tietovarastojen rakentamiseen.
  • Itse skriptikieli vaatisi ympärilleen vielä metadatan hallinnan, DDL:t, kuutiot jne.

Tämän lisäksi maailmalla on jo markkinoilla useampiakin valmistuotteita jotka pyrkivät ratkaisemaan automatisoinnin . Yhteistä lähes kaikille näille tuotteille on se että pyörivät Microsoftin SSIS:n (SQL Server Integration Services) päällä. Microsoftin välineet ovat meidän kokemustemme mukaan olleet tietovarastojen ylivoimaisesti yleisimmät työkalut jo useita vuosia.

Muutamia tuotteita maailmalla:

http://www.varigence.com/Products/Mist/Capabilities (perustuu BIML:iin)

http://www.cloveretl.com/

http://www.biready.com/

Tietovarastojen automatisoinnin kehitystä hidastavat suuret konsulttiyritykset. Moni kilpailijamme saa suuren osan liikevaihdostaan ETL-työstä. Mitä jos siitä työstä katoaakin yht´äkkiä 80%?

Stay tuned, tietovarastojen teon automatisointi tulee lyömään itsensä läpi. Jäykkää ja massiivista perinteistä tietovarastoprojektia ei ehkä kannata aloittaa vielä. Perinteiset jäykät tietovarastoprojektit ovat katoavaa kansanperinnettä. Maailmalla yksi suurimpia automatisointiin siirtyviä asiakasryhmiä ovat ne, jotka ovat jo kertaalleen kokeneet perinteisen tietovarastokehityksen hitausmomentin.

 


13.11.2014 / Ville Niemijärvi

Pari vuotta sitten saimme tarjouspyynnön energia-alan tietovarastohankkeen toteutuksesta.

Projektista oli tehty oikeaoppisesti esimäärittely, mutta sen oli tehnyt yritys, joka ei ollut koskaan tietovarastoa nähnytkään. Asiakkaalle oli iskostettu päähän ajatus, että tietovarasto on kaupan hyllyltä ostettava tuote, joka otetaan käyttöön plug ‘n’ play –tyylisesti päivässä. Tietovaraston määrittely, suunnittelu, toteutus ja testaus oli tarkoitus toteuttaa alle kuukaudessa.

Olin sattumoisin ollut vastaavan toimialan lähes identtisessä hankkeessa mukana vastikään. Tuon tietovarastoprojektin budjetti oli 400 000 euroa ja suunniteltu aikataulu n. ½ vuotta. Projekti saatiin valmiiksi lähes kahden vuoden jälkeen kun rahaa oli palanut konsultointityöhön yli miljoona ja lisensseihin jotain 500 000€ ja miljoonan väliltä. Jossain välissä ostettiin Netezza.

On sanomattakin selvää, että tarjouspyynnön lähettäneellä yrityksellä oli virheellinen käsitys siitä mitä tietovarastohanke kustantaa ja kauanko se kestää. Tässä tapauksessa jouduimme kieltäytymään projektista, mutta lähetimme yritykselle oppaan ”Mitä tietovarasto maksaa, kauanko se kestää ja mistä vaiheista se koostuu”. Käyn tässä ja seuraavassa osassa läpi olennaisimmat pointit.

Mistä tietovaraston kokonaiskustannukset koostuvat?

Tietovarasto ei ole yksittäinen ohjelmisto tai tietokanta. Se on joukko prosesseja (esim. tiedon lataus ja muokkaus, historiointi), valtava määrä tietoa ja laskentasääntöjä, sovelluksia, rautaa, palvelimia ja ihmisiä joilla on erilaisia rooleja. Itse puhunkin usein tietovarastoympäristöstä.

Mutta mistä tietovarastoympäristön kustannukset muodostuvat? Tässä olennaisimmat kuluja aiheuttavat tekijät. Osa näistä on valinnaisia kuten analytiikkasofta.

  • Lisenssit:
    • palvelin (esim. Windows server) ja sille riittävästi rautaa (muistia ja levytilaa)
    • tietokanta (esim. SQL Server, DB2, Oracle)
    • ETL-softa (esim. SQL Server, Informatica, IBM Data Stage, Pentaho)
    • raportointisofta (esim. SQL Server, IBM Cognos, Qlikview, SAP BO, Webfocus, Tableau)
    • analytiikkasofta (esim. RapidMiner, SPSS, SAS, R, Azure ML, SQL Server, Knime)
  • Rakennustyö
    • konsultointityö
    • yrityksen oma työ
  • Ylläpito ja käyttökustannukset
    • softaylläpito
    • konsultointityö
    • yrityksen oma työ
    • koulutuskustannukset
  • Bonus: Käyttökustannukset menetetystä työajasta

Sudenkuopat arvioitaessa DW/BI-hankkeen kustannuksia

Ylläpito:
Usein kokonaiskustannuksia laskettaessa jätetään ylläpitotyö kokonaan pois. Tämä voi olla iso menoerä, varsinkin alkuvaiheessa projektia. Parhaimmassa projektissa tekemämme tietovarasto ja raportit toimivat mallikkaasti vuoden ennen kuin asiakas ensimmäisen kerran ilmoitti ajojen kaatuneen. Toisessa casessa ylläpitoon meni tasaisesti 10 htpv/kk ensimmäisen puolen vuoden ajan. Tämä tarkoittaa n. 10 000€/kk budjetoimatonta kulua.

Ja toki ei saa unohtaa softalisenssien ylläpitoa. Tuotteesta riippuen tämä on 20% hankintahinnasta, joissain tuotteissa enemmänkin. Jos lasket 3 vuoden kokonaiskustannuksia niin 100 000€ lisenssihankinnasta tulee siis yhteensä 160 000€ kustannukset (kyllä, ensimmäisestäkin vuodesta menee joillakin toimittajilla ylläpitomaksu).

Koulutus:
Koulutuskustannukset unohtuvat helposti kustannuslaskelmista. Tämä koskee etenkin raportointivälineitä, koska toimittajat hoitavat usein ETL-toteutuksen ja ylläpidon.

Osa softista on helpommin omaksuttavissa, ja osassa oppimiskäyrä on jyrkempi. Oma kokemus koulutustarpeesta helpoimmasta vaikeampaan itselle tutuista tuotteista on jotakuinkin:

Tableau
QlikView
Microsoft
Cognos
Oracle

Yleensä softafirmat tarjoavat pääkäyttäjille sellaisia 3-5 päivän paketteja. Peruskäyttäjille riittää alkuun pääsemiseen usein 2x muutaman tunnin luokkahuonekoulutus pääkäyttäjien tai ulkopuolisen toimittajan toimesta.

Koulutuskustannuksia arvioitaessa kannattaa huomioida, että esimerkiksi Microsoft Reporting Servicen tai Cognoksen Report Studion todellinen hallinta vie kuukausia päivittäistä työtä. Sillä 3-5 päivän IBM:n tarjoamalla koulutuksella ei pääse edes alkuun. Olemme nähneet tämän usealla asiakkaalla. Todellinen tuotteen hallinta vaatii kuukausien ajan viikoittaista, jollei päivittäistä tekemistä. Microsoftin osalta voidaan valita raportointityövälineeksi pelkkä Excel, tällöin oppimiskäyrä on huomattavan paljon loivempi.

QlikView:n osalta olen taas nähnyt kun pätevät käyttäjät ottavat sen haltuun itsenäisesti parissa päivässä, ilman mitään koulutuksia. Isoissa käyttäjämäärissä tässä tulee iso ero kustannuksissa.

Asiakasyrityksen oma työ
Valitettavan usein asiakkaan oma panos jätetään pois kustannusarvioista, tämä aiheuttaa kuitenkin usein erittäin mittavan kustannuserän.

Asiakkaan omaa panosta tarvitaan etenkin määrittely- ja testausvaiheissa. Myös käyttöönotto ja koulutukset luonnollisesti vievät asiakkaan aikaa ja usein asiakkaalta tarvitaan oma projektipäällikkö hankkeeseen. Jos toimittajalta menee projektiin 100 htpv niin voit varata sisäistä työtä vähintäänkin saman verran.

Tietovarastohankkeiden ääripäät

Olemme olleet tekemässä miljoonaluokan tietovarastoja, mutta toisinaan DW on toteutettu parissakymmenessä päivässä. Keskiarvo on tällöin huono mittari, koska hajontaa työmäärissä on paljon.

Mutta jos otamme ääripäät pois ja tarkastelemme 90% kaikista toteutetuista DW-projekteista, liikkuvat työmäärät jossain 50 ja 150 henkilötyöpäivän välillä.

Ja tässä otoksena on lähes 100 tietovarastohanketta yli 10 vuoden ajalta ja lähes 10:ltä eri toimialalta, aina terveydenhuollosta vähittäiskauppaan ja tukkukaupasta valmistavaan teollisuuteen.

Päivähintana kustannuksia arvioitaessa kannattaa käyttää tuhatta euroa, se on tasoltaan laadukkaan konsultin hintataso.

Mitä esimerkkiprojekti voisi siis kustantaa?

Oletetaan, että yrityksen pitää hankkia raportointisofta 50 käyttäjälle. He lähtevät liikkeelle SQL Server -tietokannalla ja ETL-työvälineellä (SSIS). Standardiversio riittää hyvin. Raportointiin he valitsevat QlikView:n. Analytiikkasoftaa he eivät hanki, koska maturiteetti ei ole vielä ihan sillä tasolla ja analytiikka saa palvelunakin. Fiksu yritys ei mene työväline edellä.

Kyseessä on perinteinen valmistavan teollisuuden yritys ja datamäärät on maltillisia, joitakin miljoonia rivejä maksimissaan, tyypiltään myyntejä, tilauksia, ostoja/tuotantoa, varastoa jne. ERP:jä on pari ja dataa pitää tuoda myös CRM:stä sekä taloushallinnon järjestelmästä. Dimensioita pitää siis harmonisoida ja laskentasääntöjä yhdenmukaistaa. Perussettiä siis. Lasketaan esimerkkikustannukset:

  • Lisenssit
    • 2 * palvelin Windows server, esim. 4000€
    • 1 * tietokanta SQL Server 2014, esim.  4000€
    • 1 * ETL-softa SQL Server 2014: 0€ (sisältyy tietokantalisenssiin)
    • 50 * Qlikview raportointisofta nimetyille käyttäjille + Qlikin palvelinlisenssit: n. 90 000€
  •  Rauta
    • QlikView vaatii paljon RAM-muistia. Esim. 256Gb, palvelimen hintaluokka levyineen voi olla esim. 30 000€.
    • Kantapalvelin voi olla paljon kevyempi, esim. 8 000€
  •  Rakennustyö
    • konsultointityö: 100 000€ (100 htpv)
    • yrityksen oma työ (400e/pv): 40 000€ (100 htpv)
  • Ylläpito ja käyttökustannukset
    • softaylläpito 20%: 20 000€/vuosi
    • konsultointityö: 3000€/kk = 36 000€/vuosi
    • yrityksen oma työ: 1000€/kk = 12 000€/vuosi
    • koulutuskustannukset: 5 pääkäyttäjää * 3pv kurssi: 15 000€

YHTEENSÄ: 359 000€

Tämä on siis ensimmäisen vuoden kustannus. Jos lasketaan 3 vuoden kokonaiskustannus niin tähän lisätään kahdelta vuodelta raportointisoftan ylläpitomaksu (2 * 20 000€) sekä koko ympäristön ylläpito (2* 36 000€ + 12 000€). Tällöin 3 vuoden kokonaiskustannus on: 359 000€ + 88 000€ = 447 000€.

Tässä laskelmassa ei ole mukana jatkokehitystä, raporttien toteutusta matkan varrella, uusintakoulutuksia jne.

Jos hinta alkaa huimaamaan, voidaan raportointityöväline vaihtaa vaikka Microsoftiin. Silloin investointikustannus putoaa lisenssien osalta 90 000 €. Lisäksi toinen palvelin voi olla paljon kevyempi, kantapalvelin hieman raskaampi, kokonaishinta voisi olla tällöin luokkaa 447 000€ – 90 000€ – 10 000€   = 347 000€.

Investoinnin pitää maksaa itsensä takaisin

Nyt kun katsot hintaa niin mietit ehkä, kylläpä se maksaa. Tulee mieleen: voiko tästä säästää? Voinko oikoa polkuja? Rakentaisinko omakotitalon mutta jättäisin perustukset rakentamatta? Suosittelen kokeilemaan. Se pitää meidät konsultit leivässä ja kustantaa lopulta kolminkertaisesti. Suomi kiittää yritystäsi.

Kaikkein oleellisin kysymys on: Mitä teen tällä kaikella? Miten investointi maksaa itsensä takaisin? Saadaanko tämän avulla vähintään 447 000€ lisää katetta tai kustannuksia alas seuraavan 3 vuoden aikana?

 

Toinen kysymys itselle: onko vaihtoehtona jäädä paikalleen? Ei tehdä mitään?

Syvennytään myöhemmin siihen, miten “esimerkki”-teollisuusyrityksemme sai tietovaraston maksamaan itsensä takaisin niin, että sukan varteen jäi jotain kivaa omistajillekin.

Se mitä yrityksesi hanke tulee maksamaan, riippuu monista asioista ja etenkin siihen käytettävästä rakennustyöstä. Vasta tarkemman määrittelyvaiheen jälkeen voidaan antaa tarkka arvio mitä rakentaminen tulee maksamaan.

Tietovarasto- ja raportointihankkeen kustannuksia voidaan kuitenkin haarukoida etukäteen eri menetelmin. Seuraavassa osassa käynkin näitä keinoja läpi.

Pysy siis kuulolla niin tiedät miten laittaa luun kurkkuun toimittajalle, joka tarjoaa övereitä työmääräarvioita.


29.09.2014 / Ville Niemijärvi

IBM Cognos Data Manager logoIBM Cognos Data Manager on sovellus, jolla hieman yksinkertaistaen sanottuna tehdään tietovarastoja. Se on niin sanottu ETL-ohjelmisto (extract-transform-load). Sillä ladataan tietoa eri tietolähteistä (tietokannat, tekstitiedostot jne.), muokataan ja käsitellään dataa ja lopulta tuupataan kohdetietokantaan joka on useimmiten tietovarasto.

Ja nyt tuote on tiensä päässä, IBM on antanut kaikkien odottaman käskyn sammuttaa tuotteesta valot. Tästä voi lukea lisää IBM:n sivuilta.

Ne suomalaiset yritykset, joilla on Data Manager vielä käytössä, kannattaa lukea eteenpäin…

Data Managerin tuki loppuu

IBM:n ilmoituksen mukaan tuotteen tuki loppuu vuoden päästä 09/2015. Me, jotka olemme tuotetta käyttäneet viimeisen 10 vuoden ajan, tiedämme että varsinainen tuotekehitys on loppunut jo silloin 10 vuotta sitten. Alunperin mainio tuote on jäänyt auttamatta vanhaksi. Versionumero on kyllä vaihtunut, mutta todellisia parannuksia ei ole tullut. Viimeistään siitä lähtien kun IBM osti Cognoksen, oli selvää että käyttäjät halutaan siirtää IBM:n omaan etl-ohjelmistoon, InfoSphere DataStageen.

Osa Data Managerin asiakkaista onkin alkanut aiheellisesti siirtymään eteenpäin. Harva tosin DataStageen, ainakin meidän kokemusten mukaan SQL Server Integration Services on vienyt suurimman osan asiakkaista ja joku harva on vaihtanut Pentahoonkin.

IBM Data Manager
IBM Cognos Data Manager: esimerkki latausprosessista.

Sisältääkö tuotteen poismeno liiketoiminnallisen riskin?

Data Manager siirtää dataa todennäköisesti vielä 10/2015:kin samanlaisella varmuudella kuin tässäkin kuussa.  Samanlaisella suorituskyvyllä kuin tähänkin asti. Jos luotat siihen että vanha palvelimesi käy ja kukkuu maailman tappiin asti – eikä liiketoiminnalta tule paineita tietovaraston kehittämiseen, olet turvassa. Mutta:

  • Uusia Data Manager-projekteja ei ole aloitettu aikoihin. Eli kokeneet Data Manager-kehittäjät alkavat pikku hiljaa olemaan kiven alla.
  • Data Manager on 32-bittinen softa. Miten kauan uudet käyttöjärjestelmät ja ajurit toimivat 32-bittisenä?
  • Entä jos nykyinen palvelin hajoaa käsiin, mistä löytyy asennusmediat? Asentuuko Data Manager seuraavaan Windows-versioon?
  • Entä jos joku kuitenkin alkaa haluamaan raportointiin dataa nopeammassa syklissä, levytila loppuu kesken, lataukset kestävät liian pitkään, jotain pitäisi tehdä?
  • Entä jos Data Manager ei tunnistakaan enää vuotta 2020?

Kuinka paljon haittaa liiketoiminnallesi on, että käyttäjät eivät saa raporttejaan enää huomenna? Tai ylihuomenna?

Mitä migraatio maksaa?

Jos yritykselläsi on käytössä Data Manager ja et ole tehnyt migraatiosuunnitelmaa työkalun vaihdon suhteen, kannattaa toimia.

Riippuen tietovaraston ja siinä esiintyvien ajoketjujen (Buildit ja Jobit) määrästä, migraatio voi olla kallis. Kustannuksia voit arvioida laskemalla DM buildien määrän ja kertomalla tämän keskimääräisellä ajalla, mitä kestää toteuttaa sama toiminnallisuus uuteen tuotteeseen.

Esimerkiksi:

  • Buildien määrä: 200
  • Migraatio per buildi: 6h
  • Työaika yhteensä: 1200h eli 160 henkilötyöpäivää.

Jos lasketaan konsulttityölle keskimäärin 1000e/päivä hinnan niin migraatiosi tulisi maksamaan 160 000 euroa. 

Tähän tulee päälle tietenkin paljon muuta tehtävää kuten suunnittelutyö, mahdollinen koulutus, ajoketjujen ja virhevalvonnan automatisointi jne.

Ja tietenkin oleellinen, kirjaimellisesti miljoonan taalan kysymys: mikä tuote valitaan uudeksi ETL-softaksi ja paljonko se maksaa?

Miten edetä – mistä korvaaja Data Managerille?

Nyt tulee hieman lohtua tilanteeseen. Uuden ETL-työvälineen ei tarvitse olla kallis paukku. Se voi olla sitä, lähtien 100 000 eurosta ja ylöspäin. Tai sitten se voi olla ilmainen. Kyllä, ilmainen.

ETL-työvälineen valinnassa on kolme tärkeää valintakriteeriä:

  1. Hinta
  2. Ominaisuudet
  3. Osaajien määrä Suomessa

Kun pohdit mitä tahansa tuotetta, tarkasta edellä mainittu lista, kysy se toimittajalta.

Suomen markkinoilla käytetyimmät ETL-softat ovat Informatica ja SQL Server (Integration Services). Nämä ovat toiminnallisuuksiltaan molemmat huippuja ja täyttävät kaikki tarpeet, mitä tietovarastossasi tarvitset. Molemmille löytyy myös mukavasti osaajia. SQL Serverille toki paljon enemmän.

Niissä on vain yksi suuri ero: hinta. Toinen lähtee sieltä 100ke ja ylöspäin. Toinen on ilmainen. Niin. Ilmainen. Jos ja kun yritykselläsi on SQL Server tietokantoja, teillä on myös SQL Server Integration Services eli etl-työväline.

IBM DataStage on vaihtoehto varmasti ominaisuuksiltaan. Osaajien määrä ei tule Suomessa olemaan lähellekään sitä mitä Informaticalla tai SQL Serverillä. Ja sitten se tärkeä: kysy IBM:ltä tuotteen hintaa*. Niin.  Ja sitten tarkasta vielä paljonko SQL Server maksoi?

SQL Server on varteenotettavin vaihtoehto kun mietit Data Managerin korvaajaa. Sille löytyy ylenmäärin osaajia, toiminnallisuus on erinomainen ja hinta on mitätön, jollei jopa ilmainen.

Lisäksi maailmalla on tarjolla läjäpäin kolmannen osapuolen valmiskomponentteja toiminnallisuuden laajentamiseen. Kuten nyt vaikka valmiit Dynamics CRM, SharePoint, SAS, SalesForce, Nav, AX, SugarCRM, Tableau-konnektorit, jotka nopeuttavat kehitystyötä. Tarvittaessa voit koodata itse lisää C#:lla. Laajentaa tietovarasto hyödyntämään vaikka Big Dataa. Tai hyödyntää vaikka helposti analytiikan (esim. R, RapidMiner) tuomaa lisäarvoa loppukäyttäjien raporteilla.

Työvälineen vaihto sisältää myös mahdollisuuden uudelle alulle

Puhdasta copy-paste-vaihtoa työvälineestä toiseen ei kannata tehdä, varsinkin jos se maksaa kymmeniä, ellei satoja tuhansia. Tämä onkin oiva paikka aloittaa kehittää arkkitehtuuria eteenpäin: poistaa historian painolastia, mallintaa tietovarastoa tehokkaammaksi ja palvelemaan uusia tarpeita ja hyödyntämään uusia teknologisia innovaatioita ja mahdollisuuksia. Tai säästää vaikka 90% käytetystä levytilasta mallintamalla asiat uudestaan.

Ja tällä kertaa sitä tietovarastoa ei sitten kannata tehdä vesiputousmallina.


Ps. Älä maksa turhista lisensseistä

En tiedä tarkkaan missä vaiheessa IBM lakkaa veloittamasta tuotteesta, mutta voit itse pohtia omalta osalta, kuinka kauan kannattaa maksaa vuosittaista support-maksua, jos tuotteeseen ei ole tiedossa tukea saati versiopäivityksiä? Ehkä olisi paikallaan katkaista support-maksut jo nyt eikä pulittaa enää ensi vuotta?

Parilla asiakkaallamme laskimme, että säästämällä vuoden Data Managerin support maksut (20% hankintahinnasta), rahoitamme koko migraatioprojektin.


Lisäys 30.9.2014

* IBM tarkensi (=suomensi) lisenssipolitiikkaa. Jos asiakkaalla on aktiivinen Data Manager ylläpitosopimus, voi hän vaihtaa DM lisenssit 1:1 DataStageen. Tällöin asiakkaalle ei tule ylimääräisiä lisenssikustannuksia. Migraatiokustannus tietenkin säilyy.

Tämä tarkoittaa myös sitä, että asiakkaat jatkavat ylläpitomaksun maksamista, vaikka he eivät DataStageen vaihtaisi. Tällöin maksu on jokseenkin turha, jollei sitten halua pitää optiota hankkia DS ja maksaa tästä mahdollisuudesta. Useilla asiakkailla pelkkä support-maksu on kuitenkin kymmeniä tuhansia per vuosi, joten kukin voi puntaroida tämän järkevyyttä.