Sådan vurderer du, om et ERP er for tidligt

Denne guide hjælper en SMV med at besvare et dyrt spørgsmål, før kontrakten underskrives: vil dette ERP, CRM, MES eller lagersystem løse problemerne, eller vil det fastfryse dem i værktøjet? Grundprincippet er enkelt: software skaber ikke orden. Det kræver orden.

Formål

Et ERP-system kodificerer processer, dataejerskab, ansvar og beslutninger. Hvis de elementer er klare og stabile, kan systemet accelerere dem. Hvis de er uklare, tvinger implementeringen virksomheden til at beslutte under tidspres.

“For tidligt” betyder ikke, at virksomheden ikke fortjener systemet. Det betyder, at køb nu kan koste mere end at vente, fordi en del af prisen betales som kodificeret uklarhed.

Hvornår guiden skal bruges

Brug den, når ERP, CRM, MES eller WMS vurderes, helst før leverandørdemoer.

Brug den, når argumentet lyder: “Vi har brug for orden, og systemet vil give os den.” Det vender rækkefølgen på hovedet.

Brug den også, når et eksisterende system ikke leverer. Nogle gange var problemet ikke kun leverandøren, men en for tidlig implementering.

Før du starter

Testen virker kun, hvis “ikke endnu” er et acceptabelt svar.

Læg den fulde pris frem: licenser, implementering, tilpasninger og intern tid. Den interne tid står sjældent tydeligt i tilbuddet, men kan være lige så dyr.

Operationel sekvens

Trin 1 — Skriv problemerne uden at nævne systemet.

Én sætning pr. problem: “vi kender ikke margin pr. sag”, “ordrer tabes mellem salg og produktion”, “lageret passer ikke”.

Hvis listen ikke kan skrives, og svaret kun er “vi skal være mere strukturerede”, er man måske ved at købe et symbol på orden.

Trin 2 — Test processen.

For hvert problem: findes processen i én version? Er ansvar ved overdragelser klart? Er processen stabil eller under forandring?

Hvis salg og produktion beskriver forskellige flows, skal systemet vælge eller tilpasses. Hvis RACI er uklar, bliver data født uklare.

Trin 3 — Test data.

ERP lever af stamdata: varer, styklister, priser, kunder, leverandører, ruter og kostcentre.

Spørg direkte: findes data, er de rene, og har de en ejer? “Vi rydder op under implementeringen” betyder ofte skjult arbejde eller en beskidt start.

Trin 4 — Test om problemet egentlig er teknologisk.

“Vi kender ikke margin” kan skyldes systemet, men også at ingen registrerer faktiske timer.

“Ordrer tabes” kan skyldes værktøjet, men også en overdragelse uden ejer.

Hvis problemet kunne løses med et delt regneark og én regel, er det ikke først og fremmest teknologisk.

Trin 5 — Saml i tre lister.

Grøn: proces, ansvar og data er klar.

Gul: forudsætninger kan gøres klar på 60–90 dage.

Rød: processen er ustabil, governance uafklaret eller dataejerskab uklart. Her er systemet for tidligt.

Trin 6 — Hvis I går videre, så start småt.

Start med det grønne område. Beslut procesregler, før implementeringskonsulenten kommer. Behandl tilpasninger med skepsis. Kør ét modul stabilt, før næste åbnes.

Forventet output

Tre lister, især den røde: hvad der ikke skal implementeres endnu, og hvorfor.

Typisk opstår også en 60–90 dages forudsætningsplan: proceskort, RACI, datarensning og små piloter på eksisterende værktøjer.

Fejl der skal undgås

Køb ikke systemet for at købe orden.

Lad ikke leverandøren træffe de procesbeslutninger, virksomheden undgår.

Start ikke med big bang.

Lad ikke datarensning ligge til implementeringen.

Brug ikke tilpasning som standardsvar.

Brug heller ikke guiden som undskyldning for at udsætte for evigt.

Eksempel

En metalvirksomhed vil underskrive et ERP-projekt til 140.000 euro plus implementering. Problemerne er ukendt dækningsbidrag pr. sag, ordrer der forsvinder mellem salg og produktion, og et usikkert lager.

En to ugers test ændrer beslutningen. Margin er gul-rød, fordi ingen ejer tidsregistreringen. Ordrer er røde, fordi der findes tre versioner af ordreflowet. Lager er grønt: data er rimelige, processen stabil og ejeren tydelig.

Virksomheden starter kun med lager og indkøbscyklus. Resten venter på verificerede forudsætninger.

MARTRO-forbindelse

I MARTROs læsning er rækkefølge et princip: først tydelighed i proces, ansvar og data. Derefter kodificering.

Software forstærker det, den finder. Finder den klarhed, skalerer den klarhed. Finder den uklarhed, gør den uklarheden dyrere.

Næste skridt

Hvis testen bliver gul på flow og ansvar, fortsæt med proceskortlægning og RACI.

Hvis værktøjet automatiserer beslutninger, gennemgå beslutningsrettigheder og beslutningsarkitektur.

Ofte stillede spørgsmål

Hvad betyder for tidligt ERP? At systemet kan være nødvendigt senere, men processer, ansvar eller data endnu ikke er klar til at blive kodificeret.

Kan et ERP tvinge disciplin? Det kan kræve felter og flows, men det kan ikke alene beslutte ansvar og governance.

Skal alt være perfekt først? Nej. Start med det område, der er klart, og gør resten klar.

Hvad er det største faresignal? “Vi rydder data op under implementeringen.”

Kan et delt regneark være en seriøs pilot? Ja. Det tester, om organisationen kan holde adfærden, før der betales for et fuldt system.