En procesejer er den leder i forretningen, der ejer en hel arbejdsgang fra start til slut, fx fra ordre til betaling, på tværs af afdelinger og selskaber. Rollen bliver afgørende, når flere enheder deler ét system. Så er der pludselig en række spørgsmål, som ingen enkelt afdelingsleder kan afgøre, og som IT ikke bør afgøre. Hvordan skal en kreditnota håndteres i alle selskaber? Hvem må oprette en ny varetype? Uden en procesejer lander disse spørgsmål hos IT-afdelingen eller programmet, og det er her, mange ERP-programmer kører fast. Herunder står forskellen på rollerne, og hvordan I udpeger dem.
Forskellen på procesejer og systemejer
Hvad en systemejer laver, står på ekstern-it-ledelse.dk. Kort sagt ejer systemejeren systemet: hvad det koster, hvordan det forvaltes, og hvem der må bruge det. Procesejeren ejer arbejdsgangen, og den går ofte gennem flere systemer og flere afdelinger.
Forskellen betyder lidt, når et selskab har én afdeling og ét system. Den betyder meget, når et ERP-system bruges af fire selskaber og af både salg, lager og økonomi. Her kan systemejeren ikke afgøre, hvordan salg og lager skal arbejde sammen, for det er et forretningsspørgsmål. Og salgschefen kan ikke afgøre det alene, for beslutningen rammer lageret og økonomien.
En sund fordeling lyder sådan: procesejeren beslutter, hvordan arbejdet skal foregå. Systemejeren beslutter, hvordan systemet understøtter det. IT rådgiver om konsekvenserne og udfører ændringen. Tre roller med tre spørgsmål, og det er en stor hjælp at kunne sige det i én sætning.
Hvorfor ERP-programmer kører fast uden dem
Et ERP-program består af rigtig mange små valg om, hvordan virksomheden skal arbejde. Mange af dem kan ikke tages af en konsulent eller af projektlederen. Når der ikke er en procesejer, sker der som regel en af tre ting.
Valget bliver udskudt, og programmet venter. Tiden løber, mens en arbejdsgruppe mødes igen. Eller konsulenten træffer valget, fordi planen kræver det, og forretningen opdager resultatet ved test eller go-live. Eller hver afdeling får sin version, så systemet bliver dyrere og sværere at vedligeholde, og den fælles arbejdsgang forsvinder.
Et tænkt eksempel: et ERP-program dækker tre selskaber, der godkender indkøb på hver sin måde. I arbejdsgruppen er ingen villig til at give afkald på sin metode. Spørgsmålet går frem og tilbage, indtil styregruppen spørger, hvem der ejer indkøbsprocessen. Ingen gør det. Først da koncernens indkøbschef får rollen og mandatet, bliver der truffet en beslutning.
Det er også derfor, rollen skal besættes, inden programmet starter. Hvem der skal sidde i programmet, og hvordan deres daglige arbejde bliver dækket, står under forretningens bedste folk i programmet.
Hvem der skal være procesejer
Procesejeren skal have tre ting: autoritet over de fleste af dem, der arbejder i processen, forståelse af arbejdet og tid til opgaven. Rollen er en ledelsesrolle, og den egner sig dårligt til en superbruger, som ingen lytter til, når det bliver svært.
Hovedprocesserne har ofte et naturligt hjem. Ordre til betaling kan ligge hos salgsdirektøren eller økonomidirektøren. Indkøb til betaling kan ligge hos indkøbschefen. Regnskabsaflæggelse ligger hos økonomidirektøren. Personale kan ligge hos HR-chefen. Listen skal være kort. Otte til tolv hovedprocesser er nok til de fleste, og starter I med dem, programmet rammer, kommer resten senere.
I en koncern skal I afgøre, om procesejeren er én for hele koncernen, eller om der er en fælles ejer med lokale kontaktpersoner. Hænger svaret sammen med, hvad der er fælles, så læs om det fælles og det lokale og om fælles ERP-skabelon.
Mandatet skal skrives ned
Procesejeren bliver først virkelig, når rollen har et mandat. Beskriv kort:
- hvilken proces rollen dækker, og hvor den begynder og slutter,
- hvad procesejeren kan afgøre alene, og hvad der skal op i styregruppen,
- hvem der må afvige fra den fælles proces, og hvem der godkender det,
- hvordan processen måles, og hvem der får tallene,
- hvor meget tid rollen forventes at tage, og hvad der bliver lagt fra.
Det sidste punkt er det, der oftest bliver sprunget over. En leder, der får rollen oven i et fuldt job, kan sjældent løfte den, og så falder beslutningerne tilbage til IT. Giv lederen tid, og giv lederens chef besked om det.
Efter programmet
Det er fristende at lade rollen dø, når programmet lukker. Det er en fejl. Efter go-live kommer ændringsønsker, nye selskaber og fejl i arbejdsgangene, og hvis ingen ejer processen, bliver systemet langsomt skilt ad igen.
Læg derfor rollerne ind i den faste governance, så procesejerne har en plads, når ønsker prioriteres. Så bliver spørgsmålet “hvem bestemmer?” besvaret samme sted hver gang, også når der ikke kører et program.
Hvad gør I nu?
Tag jeres vigtigste forretningsproces, og spørg, hvem der ejer den fra start til slut. Kommer der tre navne eller slet intet, har I fundet hullet. Lav en liste med få hovedprocesser, sæt navn på hver, og lad direktionen godkende listen. Den er en af de bedste forberedelser til et større systemskifte.
Det skal I lade være med
- At lægge rollen hos IT · iT kan ikke afgøre, hvordan forretningen skal arbejde.
- At udpege en procesejer uden autoritet · rollen kræver en leder, som de andre lytter til.
- At opløse rollen, når programmet slutter · processen lever videre, og det gør behovet også.
Det skal I kræve af dem, der leder IT
- ☐ En liste over systemer med systemejer og de processer, de støtter.
- ☐ Indstilling til procesejeren, hver gang et valg rammer en arbejdsgang.
- ☐ Tydelig besked om, hvilke beslutninger programmet venter på, og hos hvem.
- ☐ En kort beskrivelse af konsekvenserne, når en afdeling ønsker en afvigelse.
- ☐ En plads til procesejerne, når ændringsønsker prioriteres.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Forretningens accepttest · IT-governance-model
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CIO hos Nielco IT
