HR-systemet og lønnssystemet bør dele de opplysningene som er nødvendige for å gjennomføre lønnsprosessen korrekt, uten at de samme dataene må vedlikeholdes manuelt i begge systemer.
En vanlig modell er at HR-systemet vedlikeholder godkjent informasjon om medarbeideren og arbeidsforholdet, mens lønnssystemet håndterer lønnsberegning, trekk, utbetaling og rapportering. Den riktige arbeidsdelingen varierer, men hvert dataelement bør ha ett definert system, en ansvarlig eier og en tydelig dataflyt.
HR-systemet og lønnssystemet bruker mange av de samme opplysningene, men til ulike formål.
| HR-systemet | Lønnssystemet |
|---|---|
| Vedlikeholder medarbeider- og organisasjonsdata | Beregner og behandler lønn |
| Støtter hendelser som ansettelse, rolleendring og avslutning | Håndterer faste og variable lønnsdata |
| Beskriver stilling, leder og organisatorisk tilhørighet | Håndterer skatt, trekk, ytelser og utbetalingsinformasjon |
| Støtter HR-prosesser og organisasjonsrapportering | Produserer lønnsresultater og grunnlag for regnskap og offentlig rapportering |
| Kan sende godkjente endringer til lønnssystemet | Kan sende status, avvik og utvalgte resultater tilbake |
Systemene erstatter ikke hverandre. De bør utføre de oppgavene de er best egnet til, og utveksle nødvendige opplysninger gjennom en kontrollert integrasjon.
Lønn er avhengig av riktige opplysninger om blant annet arbeidsforhold, stillingsprosent, start- og sluttdato, arbeidssted og lønnsbetingelser.
Dersom opplysningene registreres manuelt flere steder, øker risikoen for at:
A-meldingen er en månedlig rapportering til Nav, SSB og Skatteetaten om blant annet inntekt, arbeidsforhold, forskuddstrekk og arbeidsgiveravgift. Feil eller mangler kan få konsekvenser for medarbeiderens skattemelding eller ytelser fra Nav. Arbeidsforholdet skal rapporteres hver måned til og med den måneden medarbeideren slutter.
God dataflyt handler derfor ikke bare om å spare administrativ tid. Den skal også bidra til riktigere lønn, bedre kontroll og mer pålitelig rapportering.
Det første steget er å definere systemet der den godkjente informasjonen vedlikeholdes.
Når den samme opplysningen kan endres i både HR-systemet og lønnssystemet, blir det vanskelig å vite hvilken versjon som er riktig. En integrasjon løser ikke dette problemet. Den kan i stedet spre motstridende eller uriktige data raskere.
En mulig ansvarsfordeling er:
| Informasjon | Mulig system der godkjent informasjon vedlikeholdes |
|---|---|
| Medarbeider-ID | HR-system |
| Navn og kontaktinformasjon | HR-system |
| Ansettelsesstatus | HR-system |
| Start- og sluttdato | HR-system |
| Stilling og stillingsprosent | HR-system |
| Leder og organisatorisk tilhørighet | HR-system |
| Juridisk enhet og arbeidssted | HR-system |
| Fraværsdata | HR-system |
| Bankkonto | HR-system |
| Fastlønn | HR-system, kompensasjonsløsning eller lønnssystem |
| Variable tillegg og timer | Tids-, fraværs- eller lønnssystem |
| Skattetrekk og andre trekk | Lønnssystem |
| Beregnet brutto- og nettolønn | Lønnssystem |
| Utbetalingsresultat | Lønnssystem |
| Regnskapsgrunnlag | Lønnssystem eller økonomisystem |
Dette er et eksempel, ikke en fasit. Fastlønn kan for eksempel bli godkjent gjennom en lønnsreguleringsprosess i HR-systemet, men vedlikeholdes videre i lønnssystemet. I andre virksomheter blir den godkjente lønnen vedlikeholdt i HR-systemet og overført til lønn.
Det viktigste er at virksomheten dokumenterer:
En integrasjon bør ikke kopiere alle medarbeiderdata fra HR-systemet til lønnssystemet.
Virksomheten bør vurdere hvert dataelement ut fra:
Prinsippet om dataminimering innebærer at virksomheten bare skal samle inn og behandle personopplysninger som er nødvendige for det definerte formålet. Det gjelder også overføring og tilgjengeliggjøring mellom interne systemer.
Eksempelvis trenger lønnssystemet normalt informasjon om medarbeiderens juridiske arbeidsgiver og stillingsprosent. Det trenger ikke nødvendigvis informasjon om kompetansevurderinger, utviklingsmål eller etterfølgerstatus.
En smal og tydelig dataflyt er enklere å forstå, teste, sikre og forvalte.
Navn og e-postadresse kan endre seg. De er derfor lite egnet som eneste identifikator mellom systemene.
Bruk i stedet en stabil og unik medarbeider- eller arbeidsforholds-ID som følger personen eller det aktuelle arbeidsforholdet gjennom systemene.
Dette er særlig viktig når:
Virksomheten må definere om identifikatoren skal representere personen, ansettelsen eller det enkelte arbeidsforholdet. I noen systemlandskap kan det være nødvendig med flere identifikatorer.
En god integrasjon bør også ha tydelige regler for hva som skjer dersom identifikatoren mangler, er ugyldig eller allerede finnes i mottakersystemet.
HR, lønn og IT bør ha en felles oversikt over dataene som utveksles.
For hvert felt bør oversikten beskrive:
| Egenskap | Eksempel |
|---|---|
| Navn | Stillingsprosent |
| Definisjon | Avtalt stillingsprosent i det aktuelle arbeidsforholdet |
| System der informasjonen vedlikeholdes | HR-system |
| Mottakende system | Lønnssystem |
| Format | Tall fra 0 til 100 |
| Obligatorisk | Ja |
| Gyldig fra-dato | Påkrevd ved endring |
| Overføringsfrekvens | Daglig |
| Dataeier | HR |
| Teknisk ansvarlig | IT |
| Avvikshåndtering | Avvises og sendes til definert feilkø |
En slik databeskrivelse reduserer risikoen for at systemene tolker den samme opplysningen forskjellig.
Det bør for eksempel være avklart om «sluttdato» betyr:
Uklare definisjoner kan skape feil selv om den tekniske overføringen fungerer som planlagt.
Lønnssystemet bør normalt motta informasjon som er tilstrekkelig kontrollert og godkjent for bruk i lønnsprosessen.
Tenk for eksempel på en endring av stillingsprosent. Prosessen kan være:
Dersom uferdige eller ikke-godkjente endringer overføres automatisk, kan lønnsavdelingen begynne å behandle informasjon som senere blir endret eller trukket tilbake.
Virksomheten bør derfor definere hvilke statuser eller godkjenninger som må være på plass før data sendes.
Datoer er avgjørende for riktig lønn.
Integrasjonen bør kunne skille mellom:
En lønnsendring kan for eksempel bli godkjent 20. mars, gjelde fra 1. april og først påvirke lønnskjøringen for april.
Systemene bør også håndtere:
Fremtidige endringer
Tilbakevirkende endringer
Korrigeringer
Kansellerte endringer
Flere endringer som gjelder samme arbeidsforhold
Endringer som blir registrert etter lønnssystemets frist
For tilbakevirkende endringer må virksomheten definere om lønnssystemet skal beregne korreksjonen automatisk, om den skal vurderes manuelt, eller om integrasjonen bare skal varsle om behovet.
Unngå integrasjoner som overskriver en verdi uten å beholde informasjon om når og hvorfor den ble endret.
Alle data trenger ikke å overføres i sanntid.
Riktig frekvens avhenger av:
Hvor raskt opplysningen må være tilgjengelig
Hvor ofte den endrer seg
Hvilken risiko en forsinkelse medfører
Lønnssystemets frister
Kapasiteten og mulighetene i systemene
Behovet for kontroll før data brukes
En mulig modell kan være:
| Hendelse eller data | Eksempel på frekvens |
|---|---|
| Ny medarbeider | Ved godkjenning eller flere ganger daglig |
| Sluttdato | Ved godkjenning eller daglig |
| Rolle- og organisasjonsendring | Daglig |
| Fastlønn | Ved godkjenning og før lønnsfrist |
| Variable tillegg | Etter avtalt periode eller før lønnskjøring |
| Fravær med lønnseffekt | Daglig eller etter avsluttet periode |
| Avstemmingsdata | Før hver lønnskjøring |
Dette er eksempler. En virksomhet med ukentlig lønn kan ha andre behov enn en virksomhet med månedlig lønn.
Det sentrale er at frekvensen er dokumentert, kjent og tilpasset fristene i lønnsprosessen.
Integrasjonen bør kontrollere dataene både før de sendes og når de mottas.
Aktuelle kontroller er:
At obligatoriske felt er fylt ut
At datoer har riktig format
At sluttdato ikke kommer før startdato
At stillingsprosent ligger innenfor tillatte verdier
At juridisk enhet finnes i begge systemer
At kostnadsstedet er gyldig
At medarbeider-ID-en er unik
At kodeverdier er riktig oversatt mellom systemene
At fremtidige endringer har en virkningsdato
At bare godkjente endringer blir overført
En teknisk vellykket overføring betyr ikke nødvendigvis at dataene er riktige. Integrasjonen kan for eksempel sende en gyldig kode som er knyttet til feil juridisk enhet.
Kontrollene må derfor omfatte både teknisk format og forretningsregler.
Feil vil oppstå, også i en godt utformet integrasjon. Det avgjørende er om virksomheten oppdager dem og vet hvem som skal følge dem opp.
Integrasjonen bør vise:
Hvilke opplysninger som ikke ble overført
Hvilken medarbeider eller hvilket arbeidsforhold feilen gjelder
Hvorfor dataene ble avvist
Når feilen oppstod
Hvilket system som avviste opplysningen
Hvem som har ansvar for oppfølgingen
Om dataene blir sendt på nytt automatisk
Unngå feilmeldinger som bare sier «overføring mislyktes». Meldingen bør gjøre det mulig å forstå og rette problemet.
Det bør også være mulig å skille mellom:
Kritiske feil som kan påvirke lønn
Advarsler som bør kontrolleres
Tekniske forsinkelser som blir forsøkt på nytt
Kritiske avvik bør varsles til en definert rolle, ikke bare bli liggende i en teknisk logg.
En integrasjon reduserer behovet for manuell registrering, men fjerner ikke behovet for kontroll.
Før lønnskjøringen kan virksomheten blant annet kontrollere:
Avstemmingen bør være risikobasert. Det er ikke nødvendig å sammenligne alle felt manuelt dersom virksomheten har gode automatiske kontroller.
Målet er å oppdage vesentlige avvik før de påvirker lønn, rapportering eller medarbeidere.
HR- og lønnsdata er personopplysninger. Tilgang og overføring må derfor begrenses til det som er nødvendig for arbeidsoppgaven og formålet.
Virksomheten bør avklare:
Datatilsynet anbefaler at tilgang til personopplysninger baseres på tjenstlig behov, og at tilgangsstyringen ivaretas i alle deler av dataflyten. Opplysninger som behandles, skal også være korrekte og oppdaterte for formålet.
NSMs grunnprinsipper fremhever behovet for å kartlegge systemer, avhengigheter, brukere og tilgangsbehov, og for å velge sikkerhetstiltak ut fra virksomhetens risiko.
Dersom en ekstern leverandør behandler personopplysninger på vegne av virksomheten, skal forholdet reguleres gjennom en databehandleravtale. Avtalen bør blant annet tydeliggjøre behandlingen, ansvaret og kravene til sikkerhet.
En integrasjon mellom HR og lønn er ikke bare et IT-prosjekt.
En praktisk ansvarsfordeling kan se slik ut:
| Rolle | Typisk ansvar |
|---|---|
| HR | Definisjoner, medarbeiderdata og godkjenning av HR-endringer |
| Lønn | Lønnsregler, lønnskjøring, kontroll og offentlig rapportering |
| IT | Teknisk arkitektur, integrasjon, sikkerhet og overvåking |
| Dataeier | Formål, definisjon og kvalitetskrav for bestemte data |
| Systemeier | Forvaltning, prioriteringer og endringer i det aktuelle systemet |
| Informasjonssikkerhet og personvern | Risikovurdering, tilgang og forsvarlig behandling |
| Økonomi | Regnskapsdimensjoner, avstemming og økonomisk rapportering |
| Leverandører | Avtalt utvikling, drift, dokumentasjon og feilretting |
Virksomheten bør i tillegg avklare:
Uten tydelig ansvar kan et avvik bli sendt frem og tilbake mellom HR, lønn, IT og leverandørene.
HR oppretter medarbeideren og registrerer godkjent informasjon om arbeidsforholdet.
Lønnssystemet kan motta:
Lønnssystemet bør gi en status tilbake dersom medarbeideren ikke kan opprettes, for eksempel fordi en obligatorisk verdi mangler.
En rolleendring kan påvirke:
Endringen bør inneholde riktig virkningsdato. Dersom flere forhold endres samtidig, bør integrasjonen behandle dem som en sammenhengende og sporbar endring.
HR registrerer og godkjenner sluttdatoen.
Lønnssystemet trenger informasjonen for å:
Sluttdato bør bare brukes når arbeidsforholdet faktisk avsluttes. Skatteetaten har påpekt at feilaktig avslutning av et arbeidsforhold i a-meldingen kan påvirke medarbeiderens rettigheter og utbetalinger fra Nav.
Ja, men bare når HR har et tydelig behov for informasjonen.
Aktuelle data kan være:
Virksomheten bør være forsiktig med å kopiere detaljerte lønnstransaksjoner tilbake til HR-systemet dersom opplysningene ikke skal brukes der.
Still disse spørsmålene før en returflyt etableres:
To integrasjonsretninger kan være riktig, men det bør ikke bety at begge systemene kan endre de samme dataene.
Dette skaper usikkerhet om hvilken verdi som gjelder.
Definer ett system der den godkjente informasjonen vedlikeholdes.
Dette øker kompleksiteten og kan gi flere personer eller systemer tilgang til opplysninger de ikke trenger.
Overfør bare data som er nødvendige for lønnsprosessen.
Da kan endringer få effekt i feil lønnsperiode.
Skill mellom registreringsdato, godkjenningsdato og datoen endringen skal gjelde fra.
En teknisk logg hjelper lite dersom HR eller lønn ikke vet at en viktig medarbeiderendring er avvist.
Send forståelige varsler til rollen som kan rette feilen.
HR-systemet kan bruke én kode for juridisk enhet, mens lønnssystemet bruker en annen.
Dokumenter oversettelsen og test nye verdier før de tas i bruk.
En liten endring i et felt eller grensesnitt kan påvirke mange medarbeidere.
Bruk avtalte testmiljøer, testdata og godkjenningsrutiner.
En vellykket integrasjon kan fortsatt inneholde feil data.
Kontroller kritiske endringer og avviste meldinger før lønnen behandles.
Bruk disse spørsmålene når dere vurderer eller forbedrer integrasjonen:
Et HR-system kan fungere som systemet der godkjent medarbeider- og organisasjonsinformasjon vedlikeholdes. Godkjente endringer kan deretter overføres til lønnssystemet og andre relevante løsninger.
Verdien avhenger likevel av mer enn den tekniske integrasjonen. Virksomheten må også ha:
CatalystOne tilbyr integrasjoner mot blant annet lønnssystemer. Lønnsintegrasjonene kan brukes til å overføre godkjente endringer i HR-masterdata til lønnssystemet. Hvilken dataflyt og konfigurasjon som er riktig, avhenger av virksomhetens systemlandskap, regler og arbeidsprosesser.
Ikke nødvendigvis. Det avhenger av hvordan virksomheten gjennomfører og godkjenner lønnsendringer. Noen vedlikeholder godkjent fastlønn i HR- eller kompensasjonsløsningen, mens andre bruker lønnssystemet. Det viktigste er at bare ett definert system vedlikeholder den godkjente verdien.
Nei. For mange data er en planlagt overføring flere ganger daglig eller én gang per dag tilstrekkelig. Frekvensen bør bygge på lønnsfrister, prosesser og konsekvensen av forsinkelser.
Ansvaret bør defineres på forhånd. IT kan ha ansvar for den tekniske feilen, mens HR eller lønn kan ha ansvar for å korrigere ugyldige data. En navngitt prosess- eller systemeier bør sikre at avviket blir fulgt opp.
Nei. Bare data som støtter et definert HR-formål, bør overføres og gjøres tilgjengelige. Det bør også avklares hvem som har tjenstlig behov for å se dem.
Følg med på både tekniske og forretningsmessige målepunkter. Det kan være antall avviste meldinger, tid til feilretting, manuelle korreksjoner, avvik før lønnskjøring og antall lønnsfeil som skyldes manglende eller utdaterte HR-data.
Den kan redusere behovet betydelig, men ikke nødvendigvis fjerne det. Virksomheten bør fortsatt kontrollere kritiske endringer og avvik, særlig før lønnskjøringen.
En god integrasjon mellom HR-systemet og lønnssystemet handler ikke først og fremst om å sende flest mulig data raskest mulig.
Den handler om å sikre at:
Når arbeidsdelingen er tydelig, blir det enklere å redusere dobbeltregistrering, forbedre datakvaliteten og gi lønnsavdelingen et mer pålitelig grunnlag for lønnskjøring og rapportering.
(Artikkelen gir generell veiledning. Virksomheten bør kvalitetssikre dataflyten opp mot egne lønnsprosesser, avtaler, systemer og regulatoriske forpliktelser.)