Laadukas data on yrityksen tärkeimpiä asioita

Yritykset saavat järjestelmistä paljon tietoa, mutta onko se hyödynnetty kaikilta osin ja kuinka laadukasta data on? Yrityksissä ei välttämättä edes olla tietoisia kaikista dataongelmista. Tärkeää olisi huomioida myös onko kaikki asiat osattu ottaa huomioon. Tämän takia yrityksessä olisikin hyvä olla tiedon laatuvastaava, jonka tehtävänä on seurata datan oikeellisuutta, kehittää tarvittavat prosessit ja ohjeistaa käyttäjät tekemään asioita oikein.

Tietovarastoinnin automatisoiduissa prosesseissa valvotaan datan virheitä ja puutteita sekä voidaan ohjata raja-arvoihin sopimattomat arvot virheiksi. Datan oikeellisuuden varmistamiseksi tehdään myös tarkistusprosesseja, joissa verrataan datoja keskenään ja etsitään poikkeamia. Virheelliset tiedot ohjataan automaattisesti virheiksi, joita seurataan päivittäin. Virheellinen data voidaan korjata operatiivisessa järjestelmässä heti ja tiedot saadaan oikeellisiksi pikaisesti. Yrityksissä on paljon myös tietoja, joilla on erityiset vaatimukset tiedon oikeellisuudesta, kuten taloushallintoon liittyvällä datalla.

Virheet voidaan ottaa siis kiinni jo datan latauksissa eikä vasta sitten, kun raportit näyttävät vääriä lukuja. Väärät luvut voivat olla raportilla pitkäänkin, ennenkuin joku huomaa ne ja näin on saatettu tehdä vääriä tulkintoja jo kauankin. Huonolla datalla voidaan tehdä vääriä päätöksiä tai pienillä asioilla voi olla suuriakin vaikutuksia.

Kilpailu on kovaa ja toiminnan pitäisi olla mahdollisimman kustannustehokasta. Tuotekustannuksen komponentteja on toimijasta riippuen useita. Esim: raaka-ainekustannukset, pakkaustarvikkeet, työkustannukset, logistikan kustannukset sekä markkinoinnin kiinteät. Jos näistä joku on analysointimielessä annettu puutteellisesti, aiheuttaa se vääristymän katteessa. Jos yksi näistä kustannuksista jää antamatta tai annetaan vaikka sen voimassaoloaika väärin, jää tuotteen kustannuksista esim 0,05 euroa pois. Vielä jos tämä osuu jonkin volyymituotteen, kuten kaupan merkkituotteen, kohdalle niin virhe kertautuu jo huomattavasti. Esimerkiksi asiakasryhmän omalla merkkituotteella 100 000 kiloa kuukaudessa muuttaa tuolla puuttuneella kustannuksella katteen 5000e paremmaksi, kuin mitä pitäisi. Toinen asiakasryhmä ei osta tuota tuotetta, joten sen kate on oikein, mutta jää virheen takia vertailussa kaikenaikaa heikommaksi. Tätä ei välttämättä heti huomata raportilla, mutta datan käsittelyssä tämä olisi helppo saada kiinni ja heti korjattavaksi.

Tiedon laatu on siis yksi tiedolla johtamisen tärkeimpiä asiota. Oletko miettinyt missä kunnossa datanne on? Viimeistään nyt kannattaisi ottaa tämä kallisarvoinen asia työpöydälle eikä enää jättää sitä vain puheiksi.

SQL Tips: Case sensitive SQL:n WHERE-lauseessa

Tässä esimerkissä on yksinkertainen taulu, jossa dataa näin:

Normaalisti esimerkiksi alla oleva kysely palauttaa rivit riippumatta tekstin kirjainkoosta:

Jos halutaan hakea vain tietyllä kirjainkoolla olevat rivit, pitää WHERE-ehdon perään lisätä oikea COLLATE-osuus. Tässä esimerkissä voidaan käyttää COLLATE SQL_Latin1_General_CP1_CS_AS. Tärkeintä on, että COLLATE-osuudesta löytyy _CS, joka tarkoittaa Case Sensitiveä. _AS (Accent Sensitive) tarkoittaa sitä, että a ei ole sama asia, kuin ä.

Kaikki eri COLLATE vaihtoehdot voit tarkistaa kyselyllä:

SELECT name, description 
FROM sys.fn_helpcollations()

Nyt kysely palauttaa vain halutulla kirjainkoolla olevat rivit:

Jos halutaan, että Tekstiarvo-kentässä mahdollisesti olevat indeksoinnit vaikuttaisivat, pitää rivi lisätä vielä ilman COLLATE-osuutta SQL-lauseeseen.

SQL Tips: Harmeja NULL-arvosta

SQL-kyselyissä NULL-arvot aiheuttavat usein harmeja. On tärkeää ymmärtää, että NULL tarkoittaa puuttuvaa arvoa. Se ei tarkoita välilyöntiä eikä nollaa vaan tuntematonta arvoa. Jos mahdollista, pyri muuttamaan NULL-arvot aina joko nollaksi (0) tai tyhjäksi (’’) niin säästyt monelta harmilta.

Totuus on, että tauluista löytyy kuitenkin aina myös NULL-arvoja. Siksi onkin syytä huomioida, ettei NULL käyttäydy samoin kuin muut arvot.

Tässä ensin esimerkkitaulujen tiedot ja esimerkit NULL-arvojen toiminnasta.

Jos laskukaavassa on mukana NULL-arvo palauttaa laskenta aina NULL. AlennettuHinta jää siis laskennassa NULL-arvoksi, koska Alennus on NULL.

NOT IN kyselyssä Fakta-taulun TuoteID on NULL-arvo, joten seuraava lause ei palauta mitään vaikka periaatteessa TuoteID 223 puuttuukin Fakta-taulusta.

NULL ei toimi taulujen liitoksissa (JOIN tai MERGE). Vaikka molempien taulujen avainkentässä olisi NULL, niin se ei yhdistä rivejä ja rivi jää puuttumaan. Esim. jos Fakta2 taulu olisi samanlainen taulu kuin Fakta ja yhdistetään ne TuoteID sekä Yhtio kenttien avulla. Kysely ei palauta yhtään riviä vaikka TuoteID 222 löytyykin molemmista tauluista ja Yhtio molemmissa on NULL.

Merge lauseessa syntyy joka kerta uudet rivit, koska NULL-arvo ei yhdistä avaimia.

Ongelman voi kiertää NULL tarkistuksilla, kuten esim. lisäämällä IS NULL -ehdot tai käyttämällä COALESCE()-funktiota.

Tai

Saatat myös ymmärtää NULL-arvon ja tyhjän arvon eron seuraavan havainnollistavan kuvan avulla:


Kuva: DevRant

SQL Tips: INT-muotoisen kentän jakolaskut

Jakaessa kahta INT-tyyppistä kenttää keskenään tulos on aina myös INT ja vieläpä niin, että tulosta ei pyöristetä, vaan se katkaistaan.

Esim. alla oleva SQL-lause palauttaa vastaukseksi 1.

SELECT 9 / 5

Jos taas lauseen jompikumpi arvo konvertoidaan desimaaliksi esimerkiksi näin

SELECT 9 * 1.0 / 5

tai näin

SELECT CAST(9 as float) / 5

palauttaa SQL vastaukseksi 1,8.

Samoin toimii sisäänrakennetut aggregointifunktiot, esim. AVG.

Esim. Tässä yksinkertainen taulu, jossa int-tyyppisessä kentässä arvoja

Normaali AVG-funktio palauttaa keskiarvoksi 2.

Kun taas konvertoituna palauttaa näin

Desimaalin muuttamiseksi kannattaa valita kyselyyn sopiva suorituskykyisin keino

Rikun harjoittelu oli monipuolinen oppimismatka

Olen ollut Oiwalla harjoittelussa noin puoli vuotta ja työharjoitteluni on nyt päättymässä. Tämän vajaan puolen vuoden aikana olen oppinut paljon uusia asioita. Olen päässyt syventämään koulussa opittuja tietoja ja taitoja konkreettisesti työelämässä, sekä kokemaan millaista on työskennellä IT-alalla.

Harjoittelun aloittaessani tiesin, että tulen oppimaan paljon asioita, joista en ole ennen kuullutkaan, sillä koulussa BI:stä ei oltu puhuttu. Kahvitauoilla kuullut termit kuulostivat omaan korvaan aluksi aivan tuntemattomilta ja sitä vain naureskeli mukana, vaikkei mistään ymmärtänytkään, mutta nykyään sitä naureskelee mukana termejä ymmärtäen. Koulusta opitun tiedon soveltamiseen tuli yllätyksen aiheita jo heti harjoittelun alussa, kun esimerkiksi tietokannaksi ei enää riittänytkään koulussa opittu relaatiotietokanta.

Harjoittelussa pääsin tekemään kaikenlaista. Harjoittelu alkoi tutustumalla aiheisiin SSIS, SSAS ja SSRS, jotka silloin särähtivät korvaan täysin tuntemattomina aiheina. Moneen näistä tuli tutustuttu projektissa, jossa minulla annettiin Excelit ja pyydettiin tekemään Power BI -raportti. Projektin aikana tutuiksi muodostuivat DW-kanta, ETL, tabulaarinen kuutio, Azuren pilvipalvelu sekä Power BI. Pääsin tekemään myös monenlaisia scriptejä tiedon lukuun ja tiedon siirtoon liittyen, sekä myös tietokannan ylläpitosovelluksia niin natiivisovelluksena kuin web-sovelluksena, käyttäen uusinta Angular-tekniikkaa.

Työharjoittelu Oiwalla on ollut monipuolista ja mielenkiintoista. Työssä on pitänyt olla tarkkana ja haasteita esiintyi jatkuvasti, haasteet koin kuitenkin opettavaisina.

Täällä Oiwa Solutionsilla sain kokea, miten hyvä on työskennellä sellaisessa työympäristössä, jossa on mukava porukka ja sitä myöden hyvä työyhteisö. Täällä jokainen otetaan huomioon ja jokainen on samalla viivalla, harjoittelijanakin tuntui siltä, että olisi yksi työntekijä. Apua ja ohjeita sai aina tarvittaessa, joku oli aina valmiina auttamaan. Jokaisena aamuna töihin oli kiva tulla, vaikka pyöräillessä olisi ollut kuinka väsy ja ulkona sataisi vettä. Harjoittelussa pääsin kokemaan, millaista on työskennellä IT-alalla, joka oli aihe mikä harjoitteluun tultaessa jännitti. Koulussa siitä ei juurikaan puhuttu. Oli hieno oppia ja nähdä kuinka projektit etenevät ja kuinka vastuu jaetaan kaikille tasaisesti.


Harjoittelun viimeisenä päivänä Riku kävi lounaalla Hannan ja Juhan kanssa.

Riku aloittelee kolmannen vuoden tietojenkäsittelyn tradenomiopintojaan Vaasan ammattikorkeakoulussa. Hän viettää vapaa-aikaansa tyttöystävänsä ja kavereidensa kanssa. Kavereiden kanssa Riku pelailee tietokonepelejä ja myös liikunta on ollut aina osa hänen elämäänsä.

Datan rakennus- ja pelastushommat

Jos datan hyödyntämisen kanssa ollaan ongelmissa, puhutaan oikeastaan kahdenlaisista tilanteista. Tyypillinen tilanne on, että dataa ei joko hyödynnetä ollenkaan tai sitä pyöritellään vaikeasti ja raportteja koostetaan paljon käsin. Toinen tapaus on se, että datan hyödyntämistä on automatisoitu, mutta toteutustavat ontuvat. Tällöin data pitää pelastaa toimimattomista ratkaisuista.

Siispä haalarit jalkaan ja auttamaan asiakasta! Tarkastellaanpas näitä kahta tilannetta erikseen.

Datan hyödyntäminen

Talousjohtaja (tai pienemmissä firmoissa toimitusjohtaja itse) käyttää joka viikko kaksi päivää työajastaan keräämällä dataa. Hän koostaa sitä eri järjestelmistä omin käsin, osa tiedoista tulee muiden ylläpitämistä, sähköpostilla lähetetyistä exceleistä. Edistyksellisemmässä tilanteessa Excel-tiedostot ovat jaettuja tiedostoja pilvessä, mutta silti talousjohtaja lähettää osastopäällikölle sähköpostin: ”Onko tieto ajan tasalla?”

Hikeä otsalta pyyhkien talousjohtaja saa johtoryhmän kokoukseen raportit kasaan, mutta koska niiden koostamiseen on mennyt niin paljon työaikaa, hän ei ole ehtinyt analysoida keräämäänsä dataa ja ennustaa tulevaa sen pohjalta. Johtoryhmä keskittyy katsomaan menneisyyteen.

Datan pelastaminen

Yrityksessä on alusta datan jalostamiselle ja analysoinnille. Kaikki ei kuitenkaan suju, niin kuin pitäisi. Virheellinen data kaataa kaikki ajot yöllä ja aamulla IT-osaston ihmisten työhyvinvointi on koetuksella. Kyseessä on sekasotku, jonka ylläpito maksaa paljon ja josta saatuun tietoon ei voi täysin luottaa. Alkaa selittely liiketoimintajohdolle, joka ei voi ymmärtää, miten tämmöiseen tilanteeseen on päädytty. Käytävillä käydään tiukkoja keskusteluja. Johtoryhmässä arvaillaan, onko data ajan tasalla, vai onko syytä epäillä. Pahimmassa tapauksessa koko tuotanto seisoo, kun tuotantoa ohjaavat raportit uupuvat.

Toisessa yrityksessä järjestelmä on otettu käyttöön nopeasti ja siihen ollaan oltu tyytyväisiä. Ongelmat ilmenevät vasta siinä vaiheessa, kun yritys ostaa uuden yrityksen, jonka ERP:stä data haluttaisiin myös raportointiin mukaan tai päätetään ottaa yhteinen uusi ERP käyttöön. Ilmenee, että ERP:n vaihto vaatii muutoksen lähes jokaiseen raporttiin ja että vanhasta ERP:stä haettu data ei olekaan tallessa missään. Koko vanha raportointiratkaisu on siis melko hyödytön ja muutokset tulevat maksamaan todella paljon.

Mikä avuksi?

Oiwan haalareissa kun tullaan paikalle, pystytään syvällä kokemuksella havaitsemaan, että rakennushommat ovat alun perinkin lähteneet väärään suuntaan. Ei se haittaa, ei kaikkea voi hallita, siksi tehdään yhdessä korjausliike. Se tarkoittaa koeponnistusta rajatulla osa-alueella. Siirretään vaikkapa myynnin tai HR:n data täysin uuteen tietovarastoon, pyöritellään sitä kuutioissa ja tuotetaan johtoryhmälle pitkälle analysoitua dataa. Sen jälkeen voidaan laittaa koko homma, osa kerrallaan, kuntoon.

Molemmissa tapauksissa on pohjimmiltaan kyse siitä, että datan hyöty liiketoiminnan ennustamisessa on ymmärretty, mutta sitä tehdään kustannustehottomasti. Joko se vie liikaa ihmisten aikaa tai datan jalostamiseen ja analysointiin kehitetty ratkaisu ei toimi.

Aihe on lähellä sydäntäni ja toivoisinkin, että yritykset käyttäisivät arvokasta dataa paremmin hyödyksi liiketoiminnassaan. Fakta on, että vain murto-osa yrityksistä on oivaltanut datan hyödyntämisen mahdollisuuden bisneksensä kasvattamisessa!

Hanna on Oiwan toimitusjohtaja ja tiedon hyödyntämisen ammattilainen. Tutustu Hannaan täällä.