·Audun Martinussen

ERP-migrasjon: hvorfor as-is-mapping er det viktigste steget

De fleste ERP-implementeringer som sprekker på tid eller budsjett, sprekker fordi as-is-mappingen ble hoppet over eller gjort halvveis. Her er hvorfor — og hva en grundig as-is faktisk skal inneholde.

Det er en gjenkjennelig mønster i ERP-prosjekter som sprekker. De starter med stor optimisme, går gjennom designfase med konsulenter, og kommer til UAT der teamet plutselig oppdager at en kritisk prosess fungerer helt annerledes enn det system-integratoren har konfigurert. Da må man enten endre konfigurasjonen (dyrt, sent), endre prosessen (vanskelig, motstand), eller leve med en suboptimal løsning (alle blir frustrert).

Det som mangler i de fleste av disse prosjektene er en grundig as-is-mapping før designfase. As-is betyr "som det er": en faktisk dokumentasjon av hvordan prosessene fungerer i dag, ikke hvordan de burde fungere eller hvordan SOPen sier.

Hva as-is-mapping faktisk er

As-is-mapping er en systematisk gjennomgang av:

  1. Hvordan hver kjerneprosess fungerer i dag, fra start til slutt
  2. Hvilke systemer som er involvert og hva de gjør
  3. Hvilke manuelle steg som finnes, og hvorfor de er der
  4. Hvilke unntak som finnes, og hvor ofte de skjer
  5. Hvilke avhengigheter og integrasjoner som finnes mellom prosesser

Det skal ikke være "slik vi ønsker det", men "slik det faktisk er". To-be — fremtidsbildet — kommer senere, etter du har et ærlig bilde av nåtilstanden.

Hvorfor as-is hoppes over

De fire vanligste grunnene jeg har sett:

  1. "Vi vet jo hvordan det fungerer." Ledelsen tror de vet, men de praktiske detaljene — hvilke validating-regler som ligger i Excel-mellommodeller, hvilke unntak Lise i regnskap håndterer manuelt, hvilke felter som faktisk brukes — er ofte ukjent på ledernivå.
  1. "System-integratoren tar seg av det." Mange integratorer er flinke til å gjøre to-be, men forutsetter at klienten leverer as-is. Når klienten ikke leverer det, hopper de over eller gjør en overflatisk variant.
  1. "Vi vil ikke bruke tid på den gamle prosessen." Tenker man at gammel prosess skal vekk uansett, ser det ut som sløsing å dokumentere den. Men du må kjenne den for å unngå å gjenta feilene i ny prosess.
  1. "Det blir for komplisert." Som-er-prosesser har ofte vokst frem over år og har mange spesialhåndteringer. Det er ubehagelig å konfrontere kompleksiteten.

Hva grundig as-is-mapping skal inneholde

En komplett as-is-leveranse består typisk av:

Per kjerneprosess

  • BPMN-diagram som viser prosessen end-to-end, inkludert alle gateways og unntak. Ikke pent — komplett. Det skal være vondt å se på, fordi reelle prosesser er rotete.
  • Narrativ tekst som forklarer prosessen i ord, inkludert beslutningspunkter, godkjenningsterskler og unntakshåndtering.
  • Systemliste — hvilke systemer er involvert, hvilke felter brukes faktisk, og hva slags integrasjoner finnes.
  • Manuelle aktiviteter — alle Excel-arbeidsark, kopiering mellom systemer, e-poster med vedlegg som inneholder data.
  • Kontroll- og risikoregister — hvilke kontroller er på plass og hvilke risikoer håndteres.
  • Kjente svakheter — punkter der teamet selv vet at noe ikke fungerer bra.

På tvers av prosesser

  • Systemarkitektur — diagram over hvilke systemer som integrerer hvilke veier.
  • Master-data-eierskap — hvem eier kunde-data, leverandør-data, vare-data.
  • Sluttbruker-grupper og roller — hvem gjør hva i dagens systemer.

Vanlige funn under as-is

Når man gjør en ordentlig as-is, finner man typisk:

  • 5–20 % av prosessen kjøres faktisk i Excel-mellommodeller, ikke i ERP-en. Disse er ofte vedlikeholdt av én person.
  • Det finnes 3–5 spesialtilfeller per syklus som ikke er beskrevet noen steder, men som likevel er kritiske for forretningen.
  • Ulike avdelinger gjør samme prosess på ulike måter, ofte uten å vite det selv.
  • Integrasjoner som "fungerer" gjør det faktisk delvis — det finnes manuelle korreksjons-prosesser ingen tenker på som del av integrasjonen.

Disse funnene er gull verdt for design av ny ERP. Hvis system-integratoren ikke kjenner dem, ender du opp med en løsning som glemmer 20 % av forretningen.

ROI av as-is-mapping

For å være konkret med tall jeg har sett: et typisk mellomstort ERP-prosjekt (50–200 ansatte) koster mellom 8 og 30 millioner kroner i konsulentkostnader. En grundig as-is-mapping av 5–8 kjerneprosesser tar typisk 4–8 uker og koster i størrelsesorden 200 000–500 000 kr.

Hvis as-is fanger opp én signifikant prosess-misforståelse — og det gjør den nesten alltid — sparer du selve as-is-kostnaden flere ganger over. For en mer detaljert ROI-betraktning, se denne artikkelen.

Hvem som bør gjøre as-is

Det er tre alternativer:

  1. Internt team. Billigst på papiret, men ofte vanskelig fordi de samme personene har vanlig drift å passe på. Tar typisk 2–3 ganger så lang tid som planlagt.
  1. System-integratoren. Praktisk, men har en åpenbar interessekonflikt: integratoren vil at as-is skal lede til en konfigurering som er enkel å lever. De er ikke ute etter å finne kompleksitet.
  1. Uavhengig tredjepart. Best for de fleste mid-size selskaper. Kostnaden er moderat, kvaliteten er typisk høyere, og du får dokumentasjon som er ditt eget — ikke integratorens.

NorthControl gjør as-is-mapping som en uavhengig tredjepart, ofte før system-integrator velges. Hvis dette er aktuelt, se hvordan vi jobber og eksempel-leveransen.

Hva du bør gjøre i dag

Hvis du planlegger ERP-migrasjon de neste 12 månedene:

  1. Identifiser kjerneprosessene. Typisk 5–10 prosesser dekker over 80 % av transaksjonsvolumet.
  2. Sjekk om du har dokumentasjon. SOPer er ikke nok — du må sjekke at de stemmer med praksis.
  3. Avklar hvem som skal gjøre as-is. Bestem dette før du signerer med system-integratoren, så du har et utgangspunkt for diskusjonen om scope.
  4. Sett av tid før design-fasen. As-is må være ferdig før konsulentene begynner å designe to-be. Hvis du ikke har det, blir design basert på antakelser.

Oppsummering

As-is-mapping er ikke en luksus eller en formalia. Det er ditt eneste forsvar mot et ERP-prosjekt som basert på antakelser om hvordan ting fungerer i stedet for fakta. Det føles som ekstra arbeid, men det er ekstra arbeid som sparer deg for mye mer ekstra arbeid senere.

Vanligste tilbakemeldingen jeg får etter en as-is er ikke "wow, vi lærte mye nytt" — det er "wow, vi er glade for at vi fant ut dette nå og ikke i UAT".

Vil du se hvordan vi dokumenterer prosesser i praksis?

Et komplett eksempel — innkjøp-til-betaling for en 80-personers grossist — er publisert med BPMN, kontroller og risikoer.