Så samlar du ett splittrat HR-systemlandskap: steg för steg

Du vet redan hur det ser ut: ett system för lön, ett för tid, ett för rekrytering, ett för sjukfrånvaro, samt massa kalkylark som håller ihop det som systemen inte gör.

Det som är svårare att sätta ord på är hur man tar sig ur det. Processen kräver ett antal strategiska beslut, och att skippa något av dem är det vanligaste skälet till att projekt landar i "vi bytte system men ingenting förändrades egentligen." Här är de besluten, i rätt ordning.

Vad fragmenteringen faktiskt kostar

Det som gör splittrade system till ett segdraget problem är att kostnaden sällan syns som en enskild budgetpost. Den är utspridd, osynlig och blandad med saker som "bara är så här."

Dubbelregistrering. Medarbetaren registreras separat i lönesystemet, tidssystemet och HR-systemet—var och en med risk för att avvika från de andra.
Saldon som inte stämmer. Medarbetaren ser 22 semesterdagar i en app, lönesystemet visar 19. Någon måste avgöra vilket som stämmer, och det är alltid manuellt.
Lönekörningar som kräver manuell avstämning. Tidssystemet och lönesystemet pratar förbi varandra, och varje månad sitter någon och jämför kolumner för att säkra att utfallet blir rätt.
Rapportering som tar dagar. Inte för att informationen inte finns, utan för att den definieras på olika sätt i olika system och måste sättas ihop manuellt varje gång.
Uppföljning som är i praktiken omöjlig. Meningsfull personalanalys kräver att samma data mäts lika. När headcount, sjukfrånvaro och arbetstid lever i separata system med separata definitioner går det inte.
Beroende av nyckelpersoner. Den erfarna löneadministratören som är den enda som vet hur man plockar ihop data från system A, B och C på ett sätt som aldrig dokumenterats. Slutar den personen försvinner kunskapen med dem.

Det splittrade systemlandskapet är ett informationsproblem. Och lösningen börjar inte med att välja ett nytt system.

1. Börja med den fråga som avgör allt annat

Innan du utvärderar ett enda system behöver du besvara en fråga: var börjar en anställning i er organisation?

Det låter enkelt. Men svaret avgör hela er konsolideringsstrategi; vilka system som är relevanta att titta på, hur integrationer ska byggas och vad som behöver migreras vart.

Det finns två grundmodeller att välja mellan:

Globalt HR-system: anställningsprocessen startar där, chefen initierar ett ärende, det går via attestflöde till lön och HR-systemet äger persondata och föder lönesystemet.
Lönesystemet som master: tar emot information från ett externt mastersystem via öppna API:er, medan lön kompletterar med lönespecifik information.

För att bestämma vilken modell som passar er så kan du titta på var den tyngsta kompetensen och det faktiska ägarskapet för persondata sitter idag. Är det löneavdelningen som är navet (dvs. den som vet mest, hanterar mest och har störst beroende av att datan är korrekt) pekar det mot en mastermodell för lön. Är HR-funktionen mer central i onboarding och anställningsprocessen pekar det mot HR som master.

2. Förstå vad som faktiskt finns i ert landskap

Kartläggningen handlar om att dokumentera beroendeförhållanden. Gå igenom varje system och ställ tre frågor: vilken data äger det, vad tar det emot från andra system och vad skickar det vidare? Rita sedan flödena.

Det ni letar efter är tre saker: var sker dubbelregistrering, var saknas ägarskap för data och var finns manuella överföringar som ingen dokumenterat men alla vet om. De manuella lapparna är ofta de viktigaste att hitta då de är systemlandskapets dolda infrastruktur, och de försvinner inte automatiskt när ni byter system.

Det brukar se mer komplicerat ut på papper än det kändes i vardagen. Det är poängen. Du kan inte konsolidera ett landskap du inte förstår fullt ut.

3. Bestäm vad som tillhör mastern

Nästa beslut är att dra en tydlig gräns: vad måste vara sammanhållet? Ett praktiskt test: påverkar den här processen löneutfallet direkt? Om ja, hör den hemma i kärnan.

Det handlar konkret om:

Anställningsinformation och masterdata
Tidrapportering
Lönerevision
LAS-hantering
Sjukrehabilitering och karenshantering

Dessa processer är ömsesidigt beroende. Om semesterdagar laggar, om LAS-tid inte stämmer, om tidssystemet och lönesystemet inte synkar, genererar varje lönekörning rättelser som kostar tid och urholkar förtroendet.

Rätt ställe att börja är där de flesta medarbetare finns, där de största vinsterna av effektivisering ligger och där felen kostar mest. I detta sammanhang är det dessutom ett faktum snarare än ett val. Villkorsavtalet kräver att lönerevision, LAS och ferieuppehåll hanteras sammanhållet. De kan varken lösas i separata system eller kopplas ihop efteråt utan att avtalskomplexiteten skapar fel.

4. Avgör best of breed-strategin

Konsolidering betyder inte ett system för allting. Rekrytering, reseräkning och medarbetarundersökningar kan leva utanför kärnan utan att skapa systemiska problem (förutsatt att de inte dubbelregistrerar persondata). Här kan ni vara snabbrörliga, byta system oftare och välja det som är bäst för just det behovet.

Flexibilitet i avtal är inte detsamma som flexibilitet i systemlandskap, och det är en skillnad som ofta missförstås.

Det finns en viktig distinktion här. Rätten att byta ut en del av din lösning längre fram, om ett bättre alternativ dyker upp, är något du kan förhandla in i avtalet. Det är klokt. Men den flexibiliteten finns i kontraktet, inte i hur systemen är uppbyggda idag.

Att splittra kärnprocesserna i separata system för att "vara flexibel" skapar precis det problem du försöker lösa. Bygg en sammanhållen kärna, och sätt rätt villkor i kontraktet för framtiden.

5. Sätt namn på vem som äger vad

Det här är det steg som skippas oftast, och det orsakar mer problem post-go-live än nästan något annat.

Systembytet ersätter det gamla sättet att arbeta. Om inget nytt sätt definierats uppstår ett vakuum. Vem ansvarar för att ändringar i kollektivavtal uppdateras i systemet? Vem hanterar avvikelserapportering på det nya sättet? Vem äger vilken data och ansvarar för att den stämmer?

Gör det konkret genom att gå igenom varje kritisk process och tilldela en namngiven individ. Inte en funktion, inte en avdelning, utan en person. Dokumentera det innan driftstarten, och se till att de personerna är aktiva deltagare i projektet från dag ett. Inte inkallade på slutet för att godkänna något de aldrig förstått.

6. Räkna med att migreringen av data tar tid, och kräver dig

“Datafasen” är den del av projektet som underskattas mest, och som i särklass avgör om ni lyckas.

Systemet ni bygger är precis så bra som den data ni fyller det med. I ett fragmenterat systemlandskap är data sällan konsistent. Processen ser ut så här: ni kartlägger vilka fält i det gamla systemet som ska mappas mot rätt fält i det nya, kör en datakopia, ser avvikelserna, rättar dem och gör om. Det händer flera gånger, med riktig data, i en testmiljö som ni och leverantören jobbar i parallellt.

Det kräver er aktiva medverkan. Leverantören kan köra migreringsverktygen, men bara ni vet om det är rimligt att en medarbetare har 47 övertidstimmar registrerade under en period då verksamheten var stängd. Den typen av avvikelse syns inte i ett automatiserat test—den kräver att någon som känner verksamheten tittar på datan och bedömer vad som stämmer.

7. Välj rätt tidsfönster för driftstarten

Ett konsolideringsprojekt tar vanligtvis tolv till fjorton månader från start till driftstart. Det är inte för att processen är komplicerad i sig, utan för att datamigrering, testcykler och go-live-planering kräver sin tid, och för att fönstren för en go-live är färre än de flesta räknar med.

December och januari är olämpliga, med hög belastning på grund av rapportering till externa parter. Sommaren drabbas av semesterperiod. Kring semesterårsskiftet i april krävs egna förberedelser. Och tidssystemet måste gå live en månad innan lönesystemet, så att det finns riktig tidsdata att köra den första lönekörningen mot.

Räknar du ihop de månader som faktiskt är lämpliga är det inte många. Februari–april och september–november är de vanligaste fönstren. Planera därför baklänges därifrån med tillräcklig marginal för att datafaserna inte ska behöva stressas. Det är lätt att trycka ihop de sista stegen, och det är nästan alltid ett misstag.

Det som faktiskt avgör om projektet lyckas

Stegen ovan är nödvändiga. Men de räcker inte. De flesta konsolideringsprojekt som misslyckas gör det för att organisationen underskattar vad projektet kräver av dem internt.

Tre mönster är vanligast:

Projektet bemannas med de som råkar vara tillgängliga istället för de som faktiskt känner processerna, och gamla dataflöden förbises.
Organisationen avsätter för lite intern tid och underskattar hur mycket av det dagliga arbetet som konkurrerar med projekttiden.
Ingen definierar ägarskapet för processer i det nya läget. Det gamla sättet försvinner, det nya etableras aldrig riktigt.

Det som fungerar: rätt personer från dag ett, en tidsram som tar hänsyn till hur din organisation faktiskt fungerar, och ägarskap som är namngivet och förankrat innan ni trycker på startknappen.