Hei,
Mietin kuluvalla viikolla orgnisaatioiden perusolemusta. Kuulostaa syvälliseltä ja joku ehkä miettii, että mitä tekemistä tällä on datan kanssa, mutta bear with me.
Tämä ajatusten ketju sai syntynsä alunperin siitä, että Ellie Technologies Oy:tä on lähestynyt hiljattain useampi sijoittaja, tarkemmin sanottuna VC-sijoittaja (Venture Capital).
Niille, joille asia ei ole kovin tuttu, nämä ova yrityksiä jotka sijoittavat startuppeihin siinä toivossa, että saavat sijoituksensa moninkertaisesti takaisin.
Olen heille joutunut kertomaan, että mikä Ellie on ja mihin tuotekategoriaan se kuuluu.
Organisaation järjestäytyminen perustuu työnjakoon
Jos lähdetään aivan kautta rantain pohtimaan asiaa, että mihin asiakkaamme Ellietä käyttävät ja miksi se on niin suosittu, niin pitää mennä ihan sinne organisaatioteorian ytimeen.
Nythän on niin, että organisaatiot ovat kaikki järjestetty tiettyjen funktioiden mukaan. Niitä voidaan kutsua osastoiksi, divisiooniksi, yksiköiksi, ydin- ja tukifunktioiksi ja vaikka miksi.
On tyypillistä, että jako tapahtuu erikoistumisen mukaan. Talousosasto on erikoistunut talouteen ja HR henkilöstöön ja niin edespäin.
Usein asia mielletään prosessien ympärille, eli jaetaan organisaatio end-to-end prosesseihin ja järjestäydytään niiden ympärille.
Kaikki tämä on tietyllä tavalla luonnollista ja ymmärrettävää. Kyse on tietysti työnjaosta ja erikoistumisesta.
Jos vaikkapa kuvitteellisen kauppalaivan henkilöstö haaksirikkoutuu autiolle saarelle, niin ensimmäiseksi ruvetaan miettimään että ketkä lähtee hankkimaan ruokaa, ketkä keskittyy asumusten rakentamiseen ja ehkä tulen tekoon.
Yrityksissä ja muissa organisaatioissa tämä on tietysti viety pidemmälle ja kokonaiset koulutuslaitokset kouluttavat porukoita tietyn osaston muottiin sopiviksi.
Se luo myös tietyt kulttuurierot yksiköiden välille. Ryhmille muodostuu oma yhteinen “kieli”, ryhmähenki sekä uskomukset. Ne alkavat usein muodostua jo siellä opinahjossa.
Jokainen osasto hankkii omat IT-järjestelmät ja sovellukset
Kaikki edellä mainittu aiheuttaa toisaalta isoja haasteita organisaatioiden toimintakyvylle. Erityisesti data-alle (tietysti IT-alalle myös laajemminkin).
Jokainen yksikkö hankkii nimittäin omat IT-järjestelmät, softat ja sovellukset. Niiden käyttöönotto saattaa olla suhteellisen sujuvaa, kun sovellus hankitaan vain pienen porukan käyttöön.
Jos menet vaikkapa ison firman markkinointiosastolle kysymään, että mitä appeja siellä on käytössä, niin et ole kuullut niistä puolistakaan. Ne ovat tietyille käyttäjäryhmille, eikä niitä ole tarkoituskaan muiden käyttää.
Tämä toimii joiltain osin tietysti hyvin, koska kukaan ei varmasti kiistä työnjaon tärkeyttä. Haasteet nostavat yleensä päätään tilanteissa, joissa jonkin IT-järjestelmät tulisi palvella useita eri osastoja. Näinhän pitäisi olla asian laita esimerkiksi modernien data-alustojen kehittämisessä.
Myös Data Governance ja MDM praktiikoiden lähtökohta on datan hyödyntäminen yli osastorajojen.
Kuten alussa todettiin, osastot ovat usein järjestäytyneet prosessien ympärille – prosessi on ikään kuin se viitekehys, joka erottaa eri osastot toisistaan.
Mistä prosessi alkaa?
Mietitään esimerkiksi yrityksen asiakasta. Kaikilla yrityksillä on sellainen ja äkkiseltään voisi ajatella, että myynti vastaa asiakkuuksista.
Mutta miten sitten laskutus? Myyntiyksikkö ei laskuta asiakasta, vaan talousosasto. Asiakaspalautteen hoitaa kolmas yksikkö ja tuotteen tai palvelun toimituksen asiakkaalle neljäs.
Monet data-alan ongelmat johtuvat mielestäni juuri tästä, eli ihmiset ja järjestelmät ovat siiloissa ja toteuttavat jotain nimettyä prosessia, joka ei vastaa täysin todellisuutta.
Hyvin harva osaa vastata missä kohtaa myyntiprosessi alkaa ja mihin se päättyy. Alkaako se asiakkaan tilauksesta, myyntitapaamisesta tai itse asiassa markkinoinnista?
Päättyykö se kaupan solmimiseen tai laskun lähettämiseen? Vai onko prosessin lopullinen päätepysäkki sittenkin tuotteen toimitus?
Onko myyntihenkilöstön bonusten määritys talousosaston tai myynnin alueella?
Talousosasto periaatteessa vastaa palkoista, mutta ei voi määrittää bonuksia ilman myyntijohtoa. Vai onko palkitseminen lopulta HR:n tontilla, koska HR:n vastuulla on sitouttaminen, jonka keskeinen osa-alue on juuri kompensaatiomallit.
Esimerkkejä yksiköiden päällekkäisyyksistä on loputon määrä.
Minusta tuntuu, että tämä ongelma on koko ajan taustalla, mutta sitä ei tunnisteta. Mietitään että jokin tässä mättää, mutta ei tiedetä tai osata sanallistaa että mistä on kyse.
Ihmisillä on kai taipumus hahmottaa maailma lineaarisesti jatkuvien prosessien sarjana.
Sitähän se on osittain, mutta luonnollisesti maailma toimii monimutkaisempien vuorovaikutusketjujen kautta.
Muuttujia on paljon, joskus mennään ylös, sivulle, takaisin ja taas eteenpäin. Muuttujat vaikuttavat toisiinsa ristiin rastiin.
Ennen kuin tämä alkaa mennä liian filosofiseksi, jos se ei siksi jo mennyt, palataan takaisin maanpinnalle ja data-alaan.
Hajauttaminen vs. keskitys
ERP, ja muut enterprise -tason järjestelmät sekä vaikkapa tietovarastot ovat tietyllä tavalla yhdenlaisia yrityksiä ratkoa tätä ongelmaa.
Organisaatiot ratkovat siilo-ongelmaa myös matriisi mallilla, eli että esimerkiksi IT-osasto palvelee kaikkia muita yksikköä, ikään kuin ”sisäinen” konsulttiyritys.
Usein keskitetyn mallin haasteena on taas se, että keskitetty dataosaajien tiimi ei voi tuntea kovin hyvin jokaista yksikköä, sen bisneskiemuroita tai heidän sovellusten tuottamaa dataa.
Tämä ei vain millään ole mahdollista, koska kukaan ei voi olla joka alan asiantuntija, vaikka olisi kuinka fiksu tahansa.
Siksi kaikki “enterprise” -tason IT-tekeminen on niin älyttömän vaikeaa välillä, koska siinä taustalla on siilomainen organisaatiorakenne ja toisaalta systeeminen todellisuus.
Näissä hankkeissa kaikki liittyy kaikkeen ja dataa on valtava määrä. Kun ollaan tekemässä ns keskitettyä ratkaisua, niin jostain lähdetään liikkeelle.
Mutta yhteen suuntaan lähdetään, niin saatetaan eksyä pitkälle ja kauas siitä “keskitetystä”. Ja kun kaikki liittyy kaikkeen, on todella vaikea hahmottaa missä järjestyksessä on hyvä edetä, miten data-alustan rakentaminen tulisi jaksottaa?
Mikä on oikeasti olennaista ja miten edetä “palastellen”?
Osastojen ja prosessin rajapintojen hallinta
Kun kysymme Ellien asiakkailta, että mihin he sitä käyttävät, niin alamme päästä lähelle vastausta alussa esitettyyn kysymykseen.
Asiakkaat sanovat, että he käyttävät Ellietä ns. scopen määrittämiseen tietyssä data projektissa, oli se sitten vaikkapa MDM, data-alusta tai muu kehityshanke.
Scopen voisi tässä kohtaa kääntää tarkoittamaan aluetta tai kokonaisuuden pienempää osa-aluetta.
Usein scope voidaan määrittää tietyn tietotarpeen perusteella, eli liiketoiminta tarvitsee dataa vaikkapa tietystä tuotantoprosessista sen kehittämiseksi.
Se voi olla data-analyyttinen tutkimus tai vakiomuotoinen BI-raportointitarve. Toisaalta kyseessä voi olla esimerkiksi sovelluskehitys tai asiakasdatan harmonisointiin liittyvä projekti (MDM).
Kaikkiin näihin tarvitaan scope, eli mitä liiketoiminnan prosesseja asia koskee ja mitä dataa tarvitaan asian ratkaisemiseksi.
Usein ne ovat luonteelta sellaisia, että menevät yli järjestelmä- ja yksikkörajojen. Siellä ovat usein myös mielenkiintoiset oivallukset.
Tämä juuri tekee esimerkiksi data governance-tekemisestä pirullista, koska vastuualueet määritellään usein IT-järjestelmäkohtaisesti mutta se ei täysin toimi juuri näiden päällekkäisyyksien vuoksi.
Tähän on havahduttu myös maailmalla ja esimerkiksi paljon puhuttu Data Mesh-paradigma liittyy juuri tämän problematiikan hallintaan.
Elliellä tehostat toimintaa
Koska organisaatiot ovat ikään kuin täynnä dataa, ei edes kannata ruveta sen “täydelliseen” mallintamiseen ja kuvaamiseen kerralla, vaan tehdään sitä pala palalta, yksi käyttötapaus tai alue kerrallaan.
Myös trendikkäässä Data Mesh-paradigmassa olennaista on juuri se, että eri osastojen (domain) erikoisasiantuntijat ovat keskeisessä roolissa määrittelyvaiheessa – nimenomaan sen vuoksi, ettei data engineerit ja muut tekniset asiantuntijat voi heidän puolestaan päättää scopesta.
Asiakkaamme ova huomanneet, että käyttämällä Ellietä keskitetty datatiimi pystyy toimimaan entistä tehokkaammin, koska Ellie mahdollistaa paremman yhteistyön – bisneslähtöinen informaatioarkkitehtuuri toimii kuten pohjapiirustus rakennusprojekteissa: se tuo kaikki osapuolet samalle sivulle.
Olen huomannut, että efekti on hieman sama kun ensimmäinen Iphone tuli kosketusnäyttöinen markkinoille. Muistan miten moni oli vahvasti sitä mieltä, ettei sellaista härpäkettä tarvita, vanha näppäimistöllinen luuri riittää aivan hyvin.
Nykyisin kuitenkaan on vaikea enää olla toista mieltä “applemaisen” kännykän ylivertaisuudesta.
Myös Steve Hoberman vaikuttui Ellien uudenlaisesta lähestymistavasta! On todella hienoa, että saimme ehkä maailman kuuluisimman datanmallintajan mukaan kehittämään Ellieen uusia ominaisuuksia.
Seuraavassa Ellien versiossa tulee olemaan esimerkiksi ominaisuuksia API-rajapintoihin sekä ns loogiseen mallinnukseen, tarkoittaen että voit jatkossa tehdä paremmin tarkempia teknisiä tietomalleja, kuten Data Vaultia tai tähtimalleja.
T. Johannes Hovi
PS. Tervetuloa uusitulle SQL-kurssille:
SQL perusteet, 2.9 – 3.9.2021
SQL on data-ammattilaisen perustyökalu tiedonlouhintaan. Se on myös ensimmäinen askel Data Sciencen maailmaan: SQL on tässä työtehtävässä kaikista olennaisin taito. Vuoden 2021 Data Science työpaikkailmoituksissa SQL on toiseksi kysytyin taito.
Ari Hovin ainutlaatuiset harjoitukset ja kurssiin sisältyvä SQL-kirja takaavat, että opit varmasti.
Kyseessä on Suomen Top30 yritysten vakiokurssi, jonka saat yrityskohtaisena myös isommalle porukalle. Etätoteutus sekä mahdollisuus valita kurssikieleksi englanti, mahdollistavat kansainvälisten tiimien kouluttamisen.
Lue tästä lisää kurssin sisällöstä.
Lue kurssista lisää tästä
