ERP-projektteam korrekt oprette i 7 roller

Et ERP-projekt fejler sjældent, fordi softwaren kan for lidt. Det fejler, når ingen træffer bindende beslutninger, fagområder inddrages for sent, eller projektlederen skal håndtere projektet ved siden af sine andre opgaver. Hvis man vil oprette ERP-projektteamet korrekt, skal man først skabe klarhed over ansvar, tid og beslutningsveje. Dette er især vigtigt for små og mellemstore virksomheder: I har ingen afdeling, der kan arbejde udelukkende på projektet i flere måneder. I har brug for et team, der hurtigt kan handle - uden overengineering.

Hvorfor projektteamet bestemmer tempo og accept

SAP Business One forbinder indkøb, salg, lager, finans og analyser i ét system. Dermed ændrer implementeringen ikke kun en teknisk overflade. Den fastlægger, hvem der vedligeholder data, hvordan godkendelser fungerer, hvornår en ordre betragtes som leveringsklar, og hvilke tal der er pålidelige i månedsafslutningen.

Hvis disse spørgsmål kun besvares i forbifarten, opstår der senere dyre korrektioner. Salget fortsætter med at arbejde med Excel, lageret omgår nye bogføringer, og regnskabsafdelingen skal rydde op i manglende oplysninger. Et godt team forhindrer netop disse problemer, fordi de mennesker, der kender processerne og kan træffe beslutninger, sidder ved bordet.

Det gælder: Ikke alle personer skal forstå alle detaljer. En direktør behøver ikke at opsætte kontoplaner. En lageransvarlig behøver ikke at designe en autorisationsstruktur. Men alle involverede skal vide, hvilken opgave de har, hvornår de skal levere, og hvem der træffer beslutninger i tilfælde af konflikter.

Disse 7 roller har jeres ERP-projektteam brug for

Rollerne kan i en virksomhed med ti medarbejdere til dels falde sammen i én person. I en større mellemstor virksomhed vil de normalt blive besat separat. Det afgørende er ikke antallet af navne i organisationsdiagrammet, men at ingen kerneansvar bliver efterladt åbne.

1. Opgavegiver med beslutningsmandat

Denne rolle ligger normalt hos ledelsen, den kommercielle ledelse eller COO. Opgavegiveren fastsætter mål, budgetramme og prioriteter. Frem for alt løser han målkonflikter: Skal startdatoen overholdes, eller har en specialproces brug for en ekstra runde? Er en individuel tilpasning virkelig nødvendig, eller er en ren standardproces tilstrækkelig?

Uden denne instans venter teamet på beslutninger. Det koster mere tid end nogen teknisk opgave. Opgavegiveren bør ikke deltage i hvert projektmøde, men være tilgængelig i en fast styregruppe og træffe bindende beslutninger.

2. Den interne projektleder

Den interne projektleder holder trådene sammen. Han planlægger møder, dokumenterer åbne punkter, kræver beslutninger og sørger for, at fagområderne ikke udsætter deres opgaver. Vigtigt: Denne person har brug for et reelt tidsbudget. Hvis man skal lede ERP-projektet ud over en allerede fyldt operativ stilling, havner man hurtigt i en permanent krise.

Projektlederen behøver ikke at være den dybeste SAP-ekspert. Han skal arbejde struktureret, adressere konflikter og forstå jeres daglige drift godt nok. En erfaren ekstern partner kan lede projektet metodisk. Ansvaret for prioriteter og intern medvirken forbliver dog hos jer.

3. Procesansvarlige fra fagområderne

For hvert område har I brug for mindst én person, der kender den nuværende proces og medbestemmer den fremtidige proces. Typisk er ansvarlige for salg, indkøb, lager og finans. Hos produktionsvirksomheder tilføjes produktionen, hos tjenesteydere ofte projektfakturering.

Disse personer bør ikke konfigurere efter personlig præference. Deres opgave er at designe processen, så den fungerer for hele virksomheden. Et eksempel: Salget ønsker at registrere ordrer så hurtigt som muligt. Lageret har dog brug for komplette leverings- og lagerdata. Begge krav skal drøftes, før en indstilling i systemet fastlægges.

4. Det finansielle ansvar

Finanserne må ikke først inddrages kort før starten. Kontoplan, skatte-logik, betalingsbetingelser, åbne poster, omkostningssteder og månedsafslutning bestemmer mange grundlæggende elementer i ERP. Hvis man inddrager regnskabsafdelingen for sent, skal stamdata, bilag og analyser senere rettes op.

Har I ingen egen regnskabskapacitet, har I stadig brug for en fast kontaktperson på jeres side eller hos revisionskontoret. Hun kontrollerer, om processerne passer til jeres krav. Ved en outsourcet finansbogføring direkte i systemet skal ansvarsområderne være særligt klare: Hvem kontrollerer bilag, hvem godkender betalinger, og hvem afklarer afvigelser?

5. Stamdataansvarlig

Stamdata virker uspektakulære, men afgør datakvaliteten efter starten. Artikler, kunder, leverandører, priser, styklister, lagersteder og betalingsbetingelser skal renses, tildeles og frigives. Dette arbejde kan ikke blot overlades til ERP-partneren. Han kan levere skabeloner, regler og kontrolrutiner - fagligt korrekte bliver dataene kun med jeres viden.

Udpeg derfor tidligt en ansvarlig person. Hun beslutter også, hvilke gamle data der faktisk skal overtages. Ikke alle Excel-lister fortjener en plads i det nye system. Ofte er det mere fornuftigt kun at migrere aktive artikler, åbne bilag og relevante historikker i stedet for at tage årtiers datakaos med.

6. Den tekniske kontaktperson

Selv i et cloud-miljø forbliver tekniske opgaver: Brugere, enheder, printere, grænseflader, e-mail-forsendelse, autorisationer og eventuelt tilslutning af shop, logistik eller dokumenthåndtering. Den tekniske kontaktperson koordinerer disse emner internt og sikrer, at jeres ERP-partner får de nødvendige adgangsoplysninger og informationer.

Det behøver ikke at være en klassisk IT-stilling. I mindre virksomheder kan det være en teknisk kyndig medarbejder. Det afgørende er, at denne rolle ikke først dukker op i ugen før produktionsstart. Især grænseflader har brug for en tidlig klar faglig beskrivelse: Hvilke data flyder hvornår, hvem reagerer ved fejl, og hvilket system er førende?

7. De senere brugere som fast stemme

De mennesker, der dagligt skriver tilbud, bogfører varemodtagelser eller kontrollerer fakturaer, opdager ofte upraktiske processer tidligere end ledelsen. Involver derfor udvalgte brugere i tests og træning. De behøver ikke at deltage i hver session, men de bør gennemspille reelle processer og åbent kunne påpege problemer.

Det øger accepten betydeligt. Samtidig skal I sætte en grænse: Et projektteam er ikke en afstemningsrunde, hvor hver vane bevares. Hvis fem personer ønsker fem forskellige måder for den samme ordre, kræver det en beslutning til fordel for en klar, forståelig proces.

Sådan opretter I ERP-projektteamet korrekt

Start ikke med en lang liste af softwareønsker. Fastlæg først målbilledet. Vil I erstatte Excel-lister, styre lagre pålideligt, afslutte hurtigere, afbilde flere selskaber eller automatisk behandle indgående fakturaer? Et konkret mål gør prioriteter synlige og beskytter projektet mod funktionsønsker, der ikke bringer nogen målbar nytte.

Derefter opretter I en enkel rolleoversigt: Navn, rolle, beslutningsret, forventet tidsforbrug og stedfortræder. Især stedfortræderen bliver ofte glemt. Hvis den eneste person for lager eller finans er væk i to uger, må projektet ikke gå i stå.

Planlæg også faste beslutningsveje. Operative spørgsmål afklarer projektteamet hurtigt. Emner med indflydelse på omkostninger, tidsplan eller processtandard går til opgavegiveren. Hvad der ikke besluttes inden for få dage, skal synligt på en eskalationsliste. Så forsvinder åbne punkter ikke i e-mail-indbakker.

En praktisk rytme består af et kort ugentligt arbejdstermin og en styregruppe med faste intervaller. Arbejdsterminen behandler opgaver, tests og forhindringer. Styregruppen beslutter afvigelser. Flere møder er ikke automatisk bedre. I et projekt med klar forberedelse kan en SAP-Business-One-implementering lykkes på fire til otte uger. Det forudsætter dog, at jeres team leverer data, tager tests alvorligt og ikke udsætter beslutninger.

De mest almindelige fejl - og hvordan I undgår dem

Den første fejl er en projektleder uden frihed. Hvis operativ travlhed fortrænger hver projektopgave, skrider tidsplanen straks. Reducer målrettet andre opgaver i projektperioden eller fordel dem i teamet.

Den anden fejl er dominansen af et enkelt område. Et ERP er ikke kun et salgs-, lager- eller finanssystem. Procesbeslutninger skal tage hensyn til konsekvenserne for tilstødende områder. En ren godkendelsesproces kan betyde et ekstra trin, men forhindrer senere manglende data og diskussioner i afslutningen.

Den tredje fejl er: Tilpasning før procesafklaring. Individuelle felter, rapporter eller grænseflader kan være nyttige, hvis de repræsenterer en reel konkurrencefordel eller et nødvendigt krav. De er dog ikke en erstatning for klare ansvarsområder. Undersøg først standardprocessen, derefter konfigurationen og først derefter en udvidelse.

Den fjerde fejl er en test med eksempeldatasæt. Test med reelle tilfælde: Delmængder, reklamationer, prisafvigelser, restordrer, fremmed valuta eller fakturaer med flere omkostningssteder. Først da viser det sig, om processen holder i hverdagen. Hvis I vil bruge KI til dokumentbehandling eller forespørgsler via chat, skal også databeskyttelse, autorisationer og godkendelsesregler fra starten indgå i testen.

En god ERP-partner bringer erfaring og struktur, men tager ikke de interne beslutninger for jer. RConsult arbejder derfor med klare ansvarsområder, pragmatiske projektplaner og et fokus på SAP Business One i stedet for overdimensionerede programmer. Målet er ikke et endeløst projekt, men et system, som jeres team bruger pålideligt efter starten.

Udpeg denne uge opgavegiveren, projektlederen og procesansvarlige. Et kort møde med klare navne er mere værdifuldt end flere måneder med Excel-nødløsninger - og giver jeres ERP-projekt den start, det fortjener.