Publisert
Problemet er gjenkjennelig
Ordren er registrert i ERP. Produksjon trenger en oppdatert stykliste. Engineering har endret produktstrukturen i PLM. Mellom disse systemene ligger en arbeidsbok.
Noen eksporterer data fredag ettermiddag. Rydder kolonner, retter artikkelnummer og legger til felt som mangler. Mandag morgen importeres filen i neste system — eller sendes som vedlegg til den som skal registrere manuelt.
Det er ikke et tegn på at folk er late eller at systemene er dårlige. Excel er ofte det eneste stedet der noen faktisk kan se hele bildet — og gjøre nødvendige justeringer underveis.
Hvorfor Excel blir valgt
Excel blir sjelden planlagt som integrasjonsplattform. Det vokser fram fordi det fungerer — inntil det ikke gjør det. Det er et mønster jeg ser ofte i industribedrifter og engineering-miljøer:
1. Excel er fleksibelt
Systemene snakker ikke samme språk. Artikkelnummer matcher ikke. Revisjoner mangler. Leverandørdata må berikes. I Excel kan noen fikse dette i praksis — uten å vente på et integrasjonsprosjekt.
Arbeidsboken blir et mellomledd der data transformeres, valideres og berikes. Det er integrasjonslogikk — bare utført manuelt av noen som kjenner både systemene og prosessen.
2. Excel føles trygt
Automatisk overføring uten kontroll skaper utrygghet. Hva om feil data sendes til produksjon? Hva om revisjonen er feil? Med Excel er det et menneske i loopen — noen som ser over før data går videre.
Det gir en opplevelse av kontroll som et uklart API-grensesnitt sjelden matcher. Derfor fortsetter manuelle prosesser lenge etter at systemene teknisk sett kunne kobles sammen.
3. Terskelen er lav
Nesten alle kan Excel. Integrasjonsprosjekter krever tid, budsjett og avklaringer på tvers av avdelinger. En eksport-import-rutine kan settes opp på en dag.
Excel blir derfor den raskeste veien når to systemer skal dele data — og den raskeste veien blir ofte permanent fordi ingen prioriterer å erstatte noe som «fungerer».
Les også: Prosessautomatisering
Når Excel-lim blir risiko
Så lenge én person kjenner flyten og filen er liten, holder det. Risikoen øker når Excel blir kritisk infrastruktur uten at noen behandler den som det.
Ingen sporbarhet
Hvem endret hva, og når? I et system finnes ofte logg og revisjonshistorikk. I en arbeidsbok på en nettverksdisk eller i en e-postkjede er det vanskelig å spore tilbake til kilden.
Når noe går galt i produksjon eller innkjøp, starter avklaringen ofte med «hvilken versjon av Excel-filen brukte dere?» — ikke med en systemlogg.
Skjult kompleksitet
Det overrasker ofte hvor mye arbeid som ligger i en «enkel» Excel-flyt: formler, makroer, manuelle steg og unntak som bare én person kjenner. Virksomheten er avhengig av kompetanse som ikke er dokumentert i noe system.
Når den personen er syk, slutter eller bytter stilling, stopper eller forvrenges dataflyten. Excel-limet er personavhengig — selv om problemet først viser seg som en teknisk feil.
Feil forsterkes
En feil i eksporten kopieres til alle systemer nedstrøms. Manuell rydding reduserer risiko, men introduserer nye: tastefeil, utelatte rader, feil revisjon valgt fra en lang liste.
Jo flere systemer som er koblet sammen via samme arbeidsbok, jo større konsekvens får ett feiltrinn.
Les også: Industri, Produksjon
Hva skjer når Excel er den eneste integrasjonen?
Konsekvensene er konkrete: forsinket produksjonsstart fordi noen må vente på ferdig fil, dobbeltregistrering fordi data importeres og sjekkes på nytt i neste system, og beslutninger basert på utdatert informasjon fordi eksporten ikke kjører ofte nok.
Ledelsen ser symptomene — ineffektivitet, feil, frustrasjon — men årsaken er sjelden «folk bruker for mye Excel». Årsaken er at systemene ikke deler informasjon pålitelig, og Excel fyller gapet.
I miljøer der produktdata skal fra engineering til ERP og produksjon, er Excel ofte symptomet på et større brudd i dataflyten — ikke selve problemet.
Les også: Hvorfor produktdata stopper mellom PLM og ERP, ERP-integrasjon
Hva må på plass før du erstatter Excel?
Å fjerne Excel uten å forstå hva den faktisk gjør, er en vanlig feil. Arbeidsboken er ofte den eneste dokumentasjonen av hvordan data skal mappes, valideres og berikes mellom systemer.
Det første jeg pleier å se etter er hvilken systemgrense Excel dekker, hvilke felt som transformeres, og hvilke unntak som håndteres manuelt. Det er integrasjonskravene — de ligger bare i noens hode og i en fil.
Deretter må én konkret flyt velges. Ikke «integrer alt», men for eksempel stykliste fra PLM til produksjon, eller ordrestatus fra ERP til planlegging. Den flyten må kartlegges steg for steg før automatisering.
Til slutt: bygg erstatningen med logging og sporbarhet. Integrasjonen må være minst like pålitelig som Excel-prosessen oppleves i dag — ellers finner brukerne tilbake til arbeidsboken.
I praksis handler det om prosessautomatisering og systemintegrasjon i kombinasjon — avhengig av om problemet sitter i arbeidsflyten, i datastrukturen eller i grensesnittet mellom systemene.
Les også: Systemintegrasjon, Prosessautomatisering
Hvor starter du?
Velg én Excel-flyt som gjentas regelmessig — ukentlig eller oftere. Dokumenter: hva eksporteres, hva endres, hva importeres, og hvem som eier prosessen.
Kartlegg deretter hvilke systemer som er involvert og hvilke felt som må overføres. Ofte viser det seg at «Excel-problemet» egentlig er uavklart masterdata, mapping eller revisjonskontroll — ikke mangel på et verktøy.
Kjenner du igjen ukentlig eksport og import mellom systemer? Da er det sannsynligvis et integrasjonsproblem — ikke et Excel-problem. Spørsmålet er hva arbeidsboken gjør som systemene ikke gjør, og hva som må på plass før den kan fases ut.