Förbered ditt lärosätes HR-systembyte: En checklista för IT-ansvariga

De flesta HR-systembyten misslyckas inte av tekniska skäl. De misslyckas för att roller är otydliga, krav ställs för sent och IT kallas in när förutsättningarna redan är satta. Den här artikeln ger dig ett strukturerat ramverk för vad du behöver ha på plats, från upphandling till driftstart.

1. Din roll är tydligare än den ofta är

IT:s roll i ett HR-systembyte varierar. Ibland är du påverkare, ibland är du en granskningsfunktion som bockar av en lista. Det är sällan rollen definieras tydligt i förväg. Och det är ett problem.

Otydlighet kring ansvar är en av de vanligaste orsakerna till friktion i systembyten. HR antar att IT hanterar det tekniska. IT antar att HR hanterar konfigurationen. I överlappszonen (såsom processuppsättning, systemkonfiguration, och HR-systemförvaltarens behov av tekniskt stöd), uppstår missar.

Sätt din roll på pränt tidigt: vad du äger, vad du granskar och vad som tillhör HR. Det förhindrar de klassiska spänningarna och gör att du kan säga nej med tydlig grund när projektet vill ta genvägar på din tid.

2. Ställ säkerhets- och tekniska grundkrav i upphandlingen

Säkerhet är ditt primära fokus, och det är rätt. Men krav som inte är formulerade i upphandlingen är löften, inte åtaganden.

Det du bör specificera och kräva bevis på:

• Säker plattform med ISO-certifiering på lösningsnivå. Certifieringen ska gälla de faktiska produkterna du köper.
• Data lagrat inom EU, med dokumentation på var och hur.
• Single sign-on (SSO). Ett inlogg för organisationens användare, inte ett nytt system att hantera separat.
• Öppna API:er är avgörande för hur väl systemet integrerar med resten av ert systemlandskap.
• Tillgänglighet och SLA (mer om det specifikt längre ner).

Skillnaden mellan ett modernt och ett föråldrat system syns ofta här. En leverantör som inte kan svara på dessa krav med konkret dokumentation är en leverantör du inte vill ha i ett affärskritiskt system.

3. Förberedelser innan projektet drar igång

Det tekniska enablement-arbetet hamnar lätt utanför projektplanen. Det är ditt jobb att se till att det inte gör det. Innan projektet startar behöver du ha på plats:

• Brandväggar och nätverksåtkomst: Konfigurerade för att det nya systemet ska kunna kommunicera med era befintliga lösningar.

• Teknisk åtkomst till testmiljö från dag ett: Projektet behöver en stage-miljö där integrationer och data kan testas utan att påverka produktionsmiljön.

• Kartlagda integrationsberoenden: Vilka system ska prata med det nya HR-systemet, och vad krävs av dem? Motpartens tekniska förutsättningar behöver du förstå tidigt, inte mitt i projektet.

Du gör inte allt det här ensam. Men du skapar förutsättningarna. Projekt som missar dessa steg upptäcker det när det kostar mest att rätta till dem.

4. Datamigrering: det jobb ingen annan kan göra åt dig

Datamigrering är en av de mest kritiska faserna i ett systembyte, och en av de mest underskattade. Typiskt migrerar man tre till fem år av historisk data.

Det som är mest kritiskt att få rätt:

• Saldon och ackumulerade värden: semesterdagar, övertidssaldon, sjukrehab-historik. Görs detta fel så kommer det att märkas direkt av medarbetarna.
• Rätt person kopplad till rätt saldo: en mappning som låter enkel men kräver noggrann genomgång när data kommer från fragmenterade källsystem.

Leverantören hjälper till med specifikationer och att mappa fält. Men filerna måste levereras av dig, din gamla leverantör eller er gemensamt. Det glöms bort i planeringen tills det är bråttom.

Boka det tidigt. Det är en förutsättning för att allt annat ska stämma vid driftstart.

5. Format, krav och förutsättningar för integrationer

Integrationer kan byggas på flera sätt: API-baserade, via filöverföring eller via message bus. API är den moderna standarden och ger mest flexibilitet. Prioritera det där det är möjligt.

Det du behöver klargöra tidigt:

• Vilka system ska integreras med det nya HR-systemet?
• Vilka format och protokoll använder motparterna?
• Vad ansvarar leverantören för, och vad ansvarar du för att öppna upp?

Ansvaret är en vanlig källa till frustration. Kunden förväntar sig att leverantören hanterar allt, men i praktiken behöver du öppna miljöer, skapa åtkomster och ibland bygga integrationen på er sida. Om det inte är tydligt i upphandlingen är det tydligt i projektet (på ett obekvämt sätt).

6. Parallellkörning som den sista kontrollen innan driftstart

En månad innan go-live kör ni systemet parallellt. Anledningen är enkel: lön körs månadsvis, och den naturliga strategin för tester är att följa den rytmen.

Parallellkörningen ska inte täcka allt. Välj ut de kluriga fallen, såsom anställningar med ovanliga villkor eller historik som migrerats från ett komplext källsystem. Det är där fel visar sig om de finns.

Vad du konkret kontrollerar:

• Att integrationerna skickar och tar emot data korrekt i de verkliga intervallerna
• Att migrerad historik och saldon stämmer mot det gamla systemet
• Att behörigheter och åtkomster fungerar som de ska för alla användargrupper

7. Vad du bör kräva av ett affärskritiskt system (SLA)

Lön och HR är affärskritiska system. SLA-nivåerna ska reflektera det, men de förhandlas ofta utan tydlig bild av vad som faktiskt krävs.

Vad ett välformulerat SLA bör innehålla:

1. Tillgänglighet: I praktiken 24/7 med planerade underhållsavbrott. Planerade avbrott ska kommuniceras i förväg med tillräcklig framförhållning.
2. Support: Ofta 8–17 på vardagar, med tydlig prioritering av kritiska ärenden. Säkerställ att definitionen av "kritiskt" stämmer med din verksamhets behov.
3. Ärendehantering: En tydlig process för hur buggar och incidenter hanteras, eskaleras och kommuniceras tillbaka till dig.
4. Rådgivning: Om det ingår, säkerställ att det är definierat vad som räknas som support och vad som räknas som konsulttid.

8. Train the trainer

Upplägget för utbildning är ofta train the trainer: projektmedlemmar lär sig systemet löpande under arbetspakets gång och utbildar sedan vidare internt. Det är effektivt men det förutsätter att ni faktiskt avsätter tid för det under projektet, inte på slutet.

Kompletterande format som leverantören vanligtvis erbjuder:

• Kundunika utbildningar för specifika roller eller processer
• Webbinarier för återkommande ämnen som villkorsavtal och systemuppdateringar
• Kunddagar och nätverk med andra lärosäten som använder samma system

Det sista är underskattat. Att ha tillgång till ett nätverk av organisationer i liknande situation, med samma avtal, samma komplexitet, och samma frågor, är en del av värdet av att välja rätt leverantör.

9. Det som faktiskt avgör om projektet lyckas

Det mesta är möjligt tekniskt. Det är sällan de tekniska frågorna som fäller ett systembyte.

Det som avgör är inställningen, målbilden och förankringen. En projektgrupp som inte är enig om vad bytet ska uppnå tappar riktning när det blir svårt. En IT-funktion som kallas in för sent hinner inte skapa förutsättningarna som behövs. En upphandling som är otydlig kring ansvarsfördelningen skapar friktion som ingen räknade med i budgeten.

Du kan påverka alla tre, där din roll är att ställa de obehagliga frågorna tidigt. Är ansvarsfördelningen tydlig? Har projektet en realistisk målbild? Är förutsättningarna faktiskt på plats innan ni sätter igång?