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.
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."
Det splittrade systemlandskapet är ett informationsproblem. Och lösningen börjar inte med att välja ett nytt system.
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:
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.
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.
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:
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.
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.
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.
“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.
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.
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:
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.