Slutt å skrive kravspesifikasjon for HR-systemet

Det starter som regel med et regneark. Noen har begynt på en liste over funksjoner det nye HR-systemet skal ha, og etter noen uker har lista hundre og tjue linjer. Så sendes den ut til fire leverandører, som alle svarer ja på nesten alt.

Da har dere brukt to måneder på å gjøre valget vanskeligere.

Jeg har vært med på flere slike anskaffelser, og feilen skjer nesten alltid i det første dokumentet.

Forskjellen på et krav og et behov

En kravspesifikasjon beskriver hvordan systemet skal løse noe. «Systemet skal ha en modul for medarbeidersamtaler med mulighet for å laste opp vedlegg.»

En behovsspesifikasjon beskriver hva dere trenger at resultatet skal bli. «Alle ledere skal kunne se når de sist hadde en samtale med hver av sine, og hva som ble avtalt, uten å spørre HR.»

Den første låser deg til én løsning før du vet om det finnes en bedre. Den andre lar leverandørene vise deg hvordan de ville løst det — og gjør at du kan sammenligne dem på noe som betyr noe.

Behovsspesifikasjonen tar også en jobb kravspesifikasjonen aldri gjør: den tvinger dere til å bli enige internt om hvilke forretningsprosesser dere faktisk trenger støtte til. Det er den samtalen som er verdifull. Systemet er bare det som kommer etterpå.

Fire ting behovsspesifikasjonen må svare på

Bedriften deres, ikke bedriften generelt. Hvilken fase er dere i — vokser dere, konsoliderer dere, eller står dere i en omstilling? Hvilket språk skal systemet fungere på, og hvilken kultur skal det inn i? Hvilke andre systemer må det snakke med, og hvem eier dataen i dag? Et system som passer for en organisasjon på tretti, passer sjelden for den samme organisasjonen på to hundre.

IT fra dag én. Sikkerhetskrav er ikke noe dere legger på i etterkant. HR-systemer inneholder de mest sensitive personopplysningene dere har: sykefravær, lønn, personalsaker, i noen tilfeller varslingssaker. Databehandleravtale, tilgangsstyring, lagringssted og sletterutiner må inn i vurderingen før dere velger, ikke etter at kontrakten er signert. Ta med IT på det første møtet, selv om det føles for tidlig.

Norske krav. Bedriften deres driver i Norge. Trenger dere integrasjon mot Altinn? Skal systemet levere data til a-meldingen, eller skal lønnssystemet gjøre det? Hva med feriepenger, permisjonsregler, sykepengeoppfølging og tillitsvalgtes rolle? Internasjonale plattformer er ofte gode, men bygget for et annet regelverk, og gapet dukker opp i implementeringen der det koster mest.

Ambisjon med edruelighet. Glem innkjøp med ti års horisont. Det er unødvendig å kjøpe et system med ti moduler når organisasjonen er moden for tre. De sju resterende blir stående ubrukt, og de gjør systemet tregere å innføre, dyrere å drifte og vanskeligere å få folk til å like. Kjøp for det dere er, med en tydelig vei videre.

Bruk den i leverandørmøtet

Behovsspesifikasjonen gjør noe med samtalen. I stedet for å hake av på funksjoner, stiller dere ett spørsmål per behov: hvordan ville dere løst dette hos oss?

Gode leverandører viser deg det i systemet, med deres egne eksempeldata. Svake leverandører snakker om veikartet sitt. Forskjellen er lett å høre, og den er vanskelig å høre gjennom et regneark med hundre og tjue avkryssingsbokser.

Be også om å få snakke med to kunder på deres størrelse, i Norge, som har innført systemet det siste året. Spør dem hva som tok lengst tid.

Hva du gjør først

Sett av et møte med dem som faktisk skal bruke systemet — ansatte og lederne, ikke bare HR — og still ett spørsmål: hva bruker dere tid på i dag som dere mener systemet skulle ha løst?

Svarene der er behovsspesifikasjonen deres. Resten er formulering.

En kravspesifikasjon gir dere et system. En behovsspesifikasjon gir dere et system som løser noe.

Sitter dere fast i lista og trenger noen til å sortere behovene før dere snakker med leverandører, er det en fin bruk av en rådgivningstime.