HR Analytiikka – Nuppiluvut ja FTE

Nuppiluvut ja FTEt ovat yksi tärkeimmistä HR raportoinnin ja analytiikan perusluvuista, antaen kuvan työntekijöiden määrästä yrityksessä ja missä päin yritystä he työskentelevät. Nuppilukuja käytetään esimerkiksi kun suunnitellaan tarvittavaa henkilöstömäärää tulevaisuuden projekteihin ja
tehtäviin, näyttäen nykyisen tarjonnan. Lisäksi nuppiluku/fte on usein jakajana kun lasketaan erilaisia kuluja per henkilö (FTE) tai liikevaihto per henkilö (FTE). Toki myös viranomaisraportointia joutuu tekemään.

Määritelmät
Nuppiluku (HeadCount): Työsuhteessa oleva työntekijä lasketaan nuppiluvuksi 1
FTE: Työntekijöiden määrä täysiaikaisina työntekijöinä (jos työskentelee vain puolet viikosta/kuukaudesta, saa luvun 0.5)

Mistä lähteistä nämä luvut saadaan?
Alla näkyvässä kuvassa näkyy miten johdetut taulut HeadCount ja FTE on kytketty muihin
HR-perusjärjestelmän tauluihin.

Nuppiluvut otetaan yleensä HR-perusjärjestelmän työsuhde-taulusta. Laskelmat tehdään yleensä kuukauden tarkkuudella ja määritelmä voi olla esimerkiksi ’jos henkilöllä on työsuhde voimassa kuun viimeisenä päivänä’ saa hän arvon 1 sille kuukaudelle. Tähän voi lisätä muita versioita tai rajauksi ottamalla pois henkilöt jotka ovat pitkillä poissaoloilla, tai jotka eivät ole varsinaisia työntekijöitä vaan contractoreita (konsultteja) yhtiössä. Alla näkyvä HeadCount taulu on lopullisessa raportointi-muodossa tähtimallissa, jossa Työsuhteen tiedot on tuotu suoraan HeadCount tauluun kiinni. Nuppilukulaskelmissa päänsärkyä voi aiheuttaa työntekijät joilla on konserniin useita työsuhteita yhtäaikaa eri yhtiöihin meneillään. Näitä voi ajatella kaikkia yhtenä HeadCounttina tai sitten jättää mahdollisuuden BI työkalussa katsoa niitä yhtenä tai useana HeadCounttina.

FTE laskelmat menevät eri tavalla kuukausittaisille työntekijöille ja tuntipalkkalaisille. Kuukausipalkkalaisille lähteenä käytetään HR-perusjärjestelmän työsuhde-taulua, ja laskelma eroaa seuraavalla tavalla nuppiluvuista: Henkilö saa arvon 1 FTE ollessaan koko kuun töissä, mutta jos hän on vain puolet kuusta niin arvoksi tulee 0.5. Yleensä HR haluaa FTE:stä eri versioita, esimerkiksi vähentäen kuukauden aikana olleet poissaolot tai vain palkattomat poissaolot. Myös osa-aikaiset työntekijät tulee huomioida.

Tuntipalkkalaisten FTEt otetaan yleensä maksetuista palkoista, joissa siis tulisi näkyä maksetut tunnit. Kuukauden aikana maksetut tunnit jaetaan kuun maksimituntimäärällä, ja jälleen täysiaikainen töissäolo antaa arvon 1. Alla näkyy FTE-taulu tähtimallimuodossa.

Usein FTEt halutaan lisäksi jakaa kustannusjakoperusteella eri kustannuspaikoille, kun taas nuppiluvut saatetaan näyttää vain pääkustannuspaikalla. On oleellista myös huomata miten eri tavoin HR raportointi ja perusjärjestelmän logiikka toimivat. Esimerkiksi jos huomataan että perusjärjestelmässä on virheellisesti työsuhde (henkilöä ei ole todellisuudessa ollutkaan työllistettynä) niin HR-perusjärjestelmään virhe korjataan, mutta jos luvut on tuolla perusteella jo aiemmin raportoitu niin usein lukujen halutaan pysyvän samoina, eikä niiden haluta muuttuvan jatkuvasti vielä vuosien päästä.

Nuppiluku ja FTE laskelmat saattavat olla monimutkaisia tarkalla tasolla ja onnistunut projekti vaatii usein syvää HR-alueen ymmärrystä.

HR raportointi ja tietomallit

HR – datan ymmärrys sekä hyödyntäminen on tärkeää kaikille isommille organisaatioille, alkaen pakollisesta viranomaisraportoinnista aina strategiseen HR-suunnitteluun ja linjauksiin suhteessa liiketoiminnan tavoitteisiin.

Alla olevassa kuvassa näkyy HR – raportointiin liittyvät peruskäsitteet. Yritys tallentaa työntekijän perustiedot kuten nimen ja osoitteen ja perustaa henkilölle työsuhteen (tai kyseessä voi olla myös alihankkijan henkilö), joka määrittää suurimman osan perustiedoista (dimensioista) raportointinäkökulmasta katsottuna. Huomaa myös että joissain tapauksissa on mahdollista, että työntekijällä on samaan aikaan useampi työsuhde voimassa saman konsernin eri yritysten kanssa. Työsuhteita on myös eri luonteisia, osalla työntekijöistä voi olla useita lyhytikäisiä määräaikaisia työsuhteita saman vuoden aikana.

Onnistunutta HR-raportointikehitystä varten on oleellista ymmärtää tämä prosessi ja siihen liittyvä tietojen tallennus  HR-perusjärjestelmässä. Työsuhteen tarjoamat perustiedot liittyvät työajan tallennukseen, poissaoloihin ja palkanmaksuun työntekijälle.

HR raportoinnin tarpeet vaihtelevat liiketoiminnan luonteen mukaan. Alla olevat metriikat täyttävät yleisen perusraportoinnin tarpeen HRlle.

1. Työsuhde

  • Henkilömäärä      (aktiivisten työntekijöiden määrä)
  • FTE-luvut               (työntekijöiden määrä täysiaikaisina työntekijöinä -full time equivalents)
  • Vaihtuvuus             (yrityksestä lähtevät työntekijät ja uusien palkkaaminen)

2. Maksut työntekijälle

  • Työntekijän/työtunnin keskimääräinen hinta
  • Ylitöiden määrä ja hinta

3. Poissaolot, lomat ja työaika

  • Poissaolojen määrä ja keskiarvo eri työntekijäryhmissä
  • Kertyneet lomapäivät
  • Työajan seurannasta projektikohtainen työtuntimäärä, eri tehtäviin käytetty työaika

Tämän lisäksi HR raportointiin voi kuulua esimerkiksi rekrytointiprosessiin liittyviä asioita (kuinka pitkään menee uuden henkilön löytämiseen), henkilöstökyselyt (työtyytyväisyys) ja koulutuspäivien määrä ja kustannukset.

Yleiset ryhmittelevät tekijät (dimensiot) HR datalle ovat sukupuoli, ikäryhmät, työsuhteen vakinaisuus/määräaikaisuus, erilaiset maksu/kompensaatiotyypit kuten peruspalkka, bonukset, luontoisedut ja työntekijä-esimies hierarkia sekä kustannuspaikka-hierarkia.

Alla on esimerkki loogisesta tietomallista, josta saa johdettua yllä luetellut metriikat. Yleensä kaikki tiedot linkittyvät työsuhteeseen ja henkilöön. Raportoinnin kannalta on ensiarvoisen tärkeää että myös muutokset työsuhteen tai henkilön perustietoihin tallentuvat ainakin raportointia varten. Yleensä jo HR-perusjärjestelmä tallentaa nuo muutokset, mutta aina näin ei ole ja silloin tallennus on tehtävä HR-raportointijärjestelmässä (HR DWssä). HR-raportointitietokannan fyysisessä toteutuksessa on yleensä tarpeen tehdä omat taulut FTE-luvuille, henkilömäärille, sekä käyttää teknisiä voimassaolopäivämääriä työsuhteen ja henkilön perustietojen muutoksien tallennukseen.

Yllä on kuvattu lyhyt johdanto HR – datan maailmaan.

Ota yhteyttä, jos HR – data sekä prosessien kehittäminen datan avulla kiinnostavat!

myynti@readysolutions.fi

Esittelyssä 3 tietomallinnusmenetelmää

Tietomalli määrittää ja dokumentoi ohjelmiston perussuunnittelun data-näkökulmasta. Mallinnus voidaan aloittaa korkean tason konseptuaalisesta mallinnuksesta, josta seuraava askel on looginen malli ja lopuksi päädytään fyysiseen tietomalliin. Tässä artikkelissa esittelen 3 tietomallinnusmenetelmää fyysisen tietomallin tekemiseen. Tarkoituksena on näyttää miten erilaisia taulurakenteet ovat riippuen siitä mikä menetelmä on valittu. Tämä on tarkoitettu enemmän introduction-tyyppiseksi kirjoitukseksi, eikä se sisällä kaikkia mahdollisia nyansseja joita eri ratkaisuihin liittyy.  Esimerkkinä mallinnusratkaisuissa käytetään myyntilasku, tuote ja asiakas -tietoja.

Ensimmäinen malli alla on Dimensionaalisen menetelmän mukainen. Dimensioonalisen mallinnuksen
tekniikan esitteli ensimmäisen kerran Ralph Kimball 90-luvulla ja se on yksi käytetyimpiä menetelmiä tietovarastoinnissa. Dimensionaaliset mallit ovat helposti ymmärrettäviä, joustavia ja niistä saa helposti kyseltyä erilaisia aggregaatteja (summia) ulos. Kääntöpuolena dimensionaalisessa mallissa on että ne tallentavat ylimääräistä dataa. Esimerkiksi alla olevassa mallissa maa-tieto toistuu, kuin myös SalesInvoice-taulun Asiakas ja Due_Date. Dimensionaalista mallia ei ole optimoitu operatiivisten järjestelmien pohjaksi. Alla oleva malli ei myöskään tallenna kaikkia muutoksia lähdejärjestelmissä, vaikkakin dimensionaalisen mallinnustekniikan SCD2 dimensiolla se olisi mahdollista.

Dimensioonaalinen malli

Seuraava malli on 3. normaalimuodon mukainen (yleisesti puhutaan myös normalisaatiosta), jonka esitteli E.F.Codd jo 70-luvulla. Normaalimuotoja on tunnistettu yhteensä 6 kappaletta (1-6), mutta kolmatta normaalimuotoa pidetään yleensä riittävänä tarjoamaan riittävän yksinkertaisen tietomallin kuitenkin poistaen Update, Insert ja Delete -operaatioihin liittyviä anomalioita. Normalisointi poistaa datan turhaa/päällekkäistä tallentamista ja sitä käytetään operaatiivisissa järjestelmissä joissa on runsaasti Insert ja Update -operaatioita (Transaction processing).

3 normaalimuodon malli. ”[Every] non-key [attribute] must provide a fact about the key, the whole key, and nothing but the key so help me Codd.”

Viimeisenä esittelyssä Dan Lindstedin vuonna 2000 julkaiseman Data Vault (DV) -mallinnustekniikka. Data Vaulttia käytetään dimensionaalisen mallinnustekniikan tavoin pääasiassa tietovarastointi projekteissa. Alla olevasta kuvasta voi todeta että Data Vault menetelmä on selvästi monimutkaisempi kuin edellä mainitut menetelmät, ainakin taulujen määrällä mitattuna. DV ei ole kaikkein käytetyin menetelmä, joskin sillä on intohimoinen kannattajajoukko. Menetelmä tallentaa kaikki lähes kaikki muutokset lähdejärjestelmästä, joka on voi olla tietyissä tilanteissa toimiva ratkaisu. Esimerkkimallista voi nähdä kyselyjen tekeminen tähän malliin on selvästi monimutkaisempaa kuin esimerkiksi dimensionaalisesta mallista.

Data Vault malli

Dataintegraation yleisimmät ongelmat

Dataintegraatio projektit voivat olla varsin suuria investointeja ja työ ei yleensä pääty alkuperäisen projektin jälkeen. Uusia järjestelmiä rakennetaan ja liiketoiminta esittää uusia vaatimuksia, jotka tarkoittavat uusien dataintegraatioiden rakentamista. Tässä rakennustyössä täytyy olla tarkkana, muuten yritys voi huomata että rakennettu systeemi vaatii alati kasvavan ylläpitotiimin jotta dataintegraatioprosessit pysyvät pystyssä. ITssä on kyse automaatiosta, ja jatkuva manuaalinen työ voi viedä elinvoiman järjestelmien loppukäyttäjiltä.

Mitkä ovat suurimmat ongelmat ja kuinka ne voi välttää?

Flat-tiedostot (Flat Files)

Flat-tiedostoja käytetään usein dataintegraatiossa, ja usein ne ovat ongelmien pääsyyllinen. Jaan tässä nämä tiedostot kahteen ryhmään:

  • automaattisesti generoidut tiedostot
  • excel-tyyppiset tiedostot, joita käyttäjät päivittävät suoraan.

Automaattisesti generoidut Flat-tiedostot

Yleinen ongelma on että tiedosto ei saapunut oikeaan aikaan. Paras ratkaisu tähän ongelmaan on tiedoston generoivan prosessin linkkaaminen sitä vastaanottavaan (lukevaan) päähän. Jos tämä ei ole mahdollista, jää vaihtoehdoksi lisätä lukevan prosessin joustavuutta niin että se pystyy odottamaan tiedoston saapumista ja vasta luettuaan tiedoston käynnistämään sen jälkeen tulevat integraatioprosessit. Vaikka tämä kuulostaa ilmiselvältä, liian usein dataintegraatioita rakennetaan
oletuksella että tiedosto saapuu tasan tietyllä kellonlyömällä, ja epäonnistumisen jälkeen kukaan ei ota vastuuta huonosti toimivasta prosessista.

Toinen yleinen ongelma on että tiedosto ei ole oikeassa formaatissa. Tyypillisesti formaatin on rikkonut muutama rivi, joista löytyy tiedoston tulkitsemislogiikan käyttämiä erikoismerkkejä väärästä paikasta (esim. rivinvaihto tai sarake-erotin). Nämä on sellaisia asioita jotka tiedoston generoivan prosessin pitäisi aina tarkastaa, erityisesti sellaisten kenttien osalta joissa alkuperäinen inputti on tullut avoin tekstikenttä-tyyppisestä syötöstä. Tiedoston generoivan prosessin tulee tarkastaa onko edellämainittuja erikoismerkkejä väärissä paikoissa ja poistaa ne. Tapauksesta
riippuen myös lukevassa päässä voi olla joustavuutta niin että se selviää muutamasta ’huonosta’ rivistä.

Flat-fileet joita käyttäjät päivittävät suoraan (esim. excelit)

Tämä onkin vaikeampi kategoria, ja en oikeastaan suosittelisi tällaista käyttämään ollenkaan sillä näiden muokkaamisessa tuntuu tulevan virheitä joka toisella kerralla. Ja vaikka tiedostoa muokkaava henkilö olisikin hyvin tarkka työssään, voi olla että hän jossain vaiheessa siirtyy muuhun työpaikkaan tai tehtäviin, ja seuraavaksi exceliin arvoja syöttävä henkilö ei onnistukkaan yhtä hyvin. Tämän tyyppisen tiedon syöttämisen tulisi tapahtua sellaisen systeemin läpi joka jo syöttövaiheessa tarkastaa tietotyyppien oikeellisuuden ja mahdollisesti myös arvojen oikeellisuuden.

Tietokannat

Tietokannoista lukemisessa on huomattavasti vähemmän ongelmia. Mutta toki silloin tällöin yhteys voi pätkäistä tai luettava tietokanta on muuten kiireinen (lukossa). Ongelmaa voi helpottaa asettamalla dataa lukevan prosessin yrittämään uudestaan, jos ensimmäinen kerta epäonnistui. Toki jos luettava tai kohde -tietokanta on jatkuvasti hidas tai lukossa, on tutkittava mikä tilanteen aiheuttaa ja korjattava ongelman juurisyy.

Huonosti toteutetut datatransformaatiot

Datatransformaatiot täytyy tehdä niin että tietotyypitykset otetaan huomioon. Esimerkiksi jos meillä on ’If x=y then a else b’ -lauseke joka ei pysty käsittelemään arvoa null kentässä x. Vaikka null arvoja ei kyseisessä kentässä tällä hetkellä näkyisikään, täytyy prosessin pystyä ne käsittelemään, jos lähdetietoihin on mahdollista sellaisia arvoja syöttää.

Liian paljon turhia riippuvuuksia

Edellä mainitut ongelmat voivat suurentua merkittävästi jos dataintegraatioprosessien välille on rakennettu liikaa riippuvuuksia. Tarpeettomia riippuvuuksia ei tietenkään pitäisi olla ollenkaan. Jos prosessi x on loogisesti riippuvainen vain ja ainoastaan prosessien y ja z onnistumisesta, ei ylimääräistä riippuvuutta muihin prosesseihin tule rakentaa. Suurissa dataintegraatioprojekteissa tämä tulee erittäin tärkeäksi, sillä pahimmassa tapauksessa mikä tahansa virhe pysäyttää koko dataintegraatioprosessin, eikä vain sitä osaa joka on riippuvainen virheen aiheuttaneesta osasta, johtaen toistuviin manuaalilatauksiin. Dataintegraatioprosessien riippuvuudet toisiinsa tulee asettaa minimitasolle.

Virhe johtaa aina manuaaliseen uudelleen lataukseen

Joku voi kuitenkin mennä pieleen. Erityisesti transaktio-tyyppisen datan latauksissa on hyvä idea sisällyttää ladattavaan batchiin enemmän kuin vain tarpeellinen data, esim. 1 päivän sijaan viimeisen kahden päivän data. Näin prosessi korjaa itse itsensä seuraavan päivän automaattisessa latauksessa.

Ready Solutions Oy:n sivut on avattu

Olemme pääsemässä vaiheeseen, jossa voimme julkaista sivustomme yleisölle.

Tarkoitus on kertoa mitä osaamme, mitä olemme tehneet sekä toivottavasti saamme luvan muutaman mielenkiintoisen asiakastapauksen julkaisuun!

Ready Solutions Oy julkaisee myös LinkedInissä sisältöä, seuratkaa meitä siellä.

https://www.linkedin.com/company/ready-solutions-oy