Hvem bør eie artikkelnummeret i en prosjektorientert virksomhet?
I arbeid med PLM og ERP dukker spørsmålet om artikkelnummer nesten alltid opp før eller siden. Mange tar det som en selvfølge at ERP bør eie varenummeret, siden det er der innkjøp, produksjon, lager og økonomi håndteres. I virksomheter med serieproduksjon og katalogprodukter er dette som regel helt riktig. Produktene lever lenge, bestilles om igjen og må styres stramt fra et logistikk‑ og økonomiperspektiv.
I prosjektorienterte, ingeniørstyrte ETO‑bedrifter ser imidlertid hverdagen ofte annerledes ut. Her eksisterer produkter og komponenter som regel fordi et bestemt prosjekt trenger dem. De konstrueres som en del av leveransen, produseres én gang – kanskje noen få – og avsluttes sammen med prosjektet. Selv om enkelte design kan gjenbrukes senere, skjer det sjelden uten ny teknisk vurdering og ofte med tilpasninger. I slike miljøer er det mindre opplagt at artikkelnummeret nødvendigvis bør skapes av ERP.
Forskjellen på kataloglogikk og prosjektlogikk
Mye av systemarkitekturen rundt PLM og ERP er formet av katalog‑og serieproduksjon. Der gir det mening at varenummeret er stabilt, uavhengig avprosjekter, og først og fremst styrt av logistikk og økonomi. I prosjektorienterte virksomheter blir dette bildet forskjøvet.
Typiske kjennetegn vi ser i prosjektdrevne miljøer er at:
· varer og komponenter oppstår som følge av konkrete prosjekter
· gjenbruk skjer, men ofte uformelt og etter ny vurdering
· engineering driver beslutningen om hva som skal eksistere
Når man forsøker å bruke samme nummerregime som i katalogproduksjon, oppstår det ofte friksjon. Man ender med flere nummer på detsom i praksis oppleves som samme del, og man må ta ERP‑relaterte beslutninger tidlig i konstruksjonsfasen, ofte før både design og behov er stabilt definert. Over tid kan dette gjøre systemene tunge å jobbe med, særlig for engineering og prosjektgjennomføring.
Der det ofte gir mening at identiteten oppstår i PLM
I mange ingeniørledede ETO‑bedrifter er det konstruksjon som i realiteten avgjør at en komponent eksisterer. Ikke fordi den skal bli en standard lagerartikkel, men fordi prosjektet krever den. I slike tilfeller er det ofte både naturlig og praktisk at artikkelnummeret opprettes i PLM, samtidig med konstruksjonen.
Når delen senere skal kjøpes eller produseres, speiles det samme nummeret inn i ERP. ERP mister ikke kontroll av den grunn, men slipper å etablere en ny identitet for noe som allerede er klart definert. CAD‑filer beholder egne CAD‑nummer, og serienummer håndteres separat som instanser, men selve forretningsidentiteten blir tydelig og gjenkjennelig på tvers av fagområder.
I praksis gir dette ofte:
· færre nummer å forholde seg til i prosjektene
· mindre oversettelse mellom engineering og logistikk
· bedre forståelse mellom PLM, ERP og produksjon
Endringsstyring og modenhet over tid
En vanlig bekymring er at denne modellen svekker styring. Erfaringen er ofte den motsatte. Når PLM eier artikkelnummeret, må PLM også eie beslutningen om hvilken definisjon som er gyldig til enhver tid. Revisjoner, endringer og frigivelse må være tydelig styrt, slik at ERP aldri er i tvil om hva som faktisk skal produseres eller kjøpes. Forskjellen ligger først og fremst i hvor identiteten oppstår, ikke i hvor stramt den forvaltes.
Det er heller ikke slik at alle varer må behandles likt for alltid. Mange prosjektbedrifter lykkes godt med å skille mellom prosjektartikler og mer standardiserte artikler. Prosjektartikler opprettes og styres i PLM og speiles til ERP. Dersom en komponent senere viser seg å være egnet for gjenbruk, kan den promoteres til en mer standardisert kontekst med strengere regler og tydeligere ERP‑forankring.
Oppsummert
Det finnes ingen universell fasit for eierskap til artikkelnummer. I virksomheter med volumproduksjon er ERP fortsatt det naturlige stedet for denne rollen. I prosjektorienterte, ingeniørstyrte ETO‑miljøer ser vi imidlertid ofte at en PLM‑drevet tilnærming gir bedre flyt, færre misforståelser og en nummerstruktur som stemmer bedre med hvordan folk faktisk jobber.
Arkitektur bør støtte forretningen – ikke omvendt. Dersom du kjenner igjen utfordringene som er beskrevet her, kan det være nyttig å løfteblikket og se helhetlig på hvordan nummerering, eierskap og samspill mellom PLM og ERP faktisk fungerer hos dere i dag. Ofte skal det ikke store endringer til før systemene begynner å støtte arbeidsformen bedre. Ta gjerne kontakt med ossfor en uforpliktende prat om hvordan dette kan løses i praksis – gjerne med utgangspunkt i nettopp deres prosjekter og måten dere jobber på.