Innkjøpsordresystem eller ERP-modul: hva passer for en prosjektbasert virksomhet?

Hvis du prøver å få kontroll på innkjøpsordrene, har du sannsynligvis fått presentert to løsninger: å legge innkjøpsmodulen til ERP-systemet dere allerede bruker, eller å ta i bruk et dedikert innkjøpsordresystem som kobles til regnskapet. Begge salgsteamene lover det samme: raskere godkjenning, bedre oversikt og integrerte arbeidsflyter.

Presentasjonene høres like ut, men produktene er det ikke. Det skyldes ikke at den ene kategorien er bedre enn den andre, men at de er laget for ulike typer problemer. Hva som passer, avhenger av hvilken type problem virksomheten din har.

To veier, og valget avhenger av hvordan dere jobber

Den første veien er innkjøpsmodulen i ERP-systemet. Den er et tillegg til systemet som allerede håndterer økonomi, lager og ofte produksjon eller distribusjon. Innkjøp blir én prosess til i det samme systemet, med de samme leverandørregistrene, varedataene og rapportstrukturen.

Den andre veien er et dedikert innkjøpsordresystem. Det er et eget verktøy bygd rundt selve innkjøpsordren: hvem som ber om hva, hvem som godkjenner, og hvilket budsjett kostnaden forplikter. Det kobles til regnskapssystemet i stedet for å erstatte det.

De fleste virksomheter som står overfor dette valget, har vokst ut av noe. Godkjenninger skjer på e-post og er vanskelige å finne igjen. Budsjettene ligger ett sted og bestillingene et annet. Økonomiavdelingen får vite om forpliktelsene når fakturaen kommer. Begge løsningene lover å rette på dette, og derfor høres presentasjonene like ut.

Begge forstår hvilken rolle en innkjøpsordre har. Begge kan sende godkjenninger videre og lage rapporter. Spørsmålet er ikke hvilken som har flest funksjoner, men hvilken som er laget for innkjøp som ligner deres.

Valget handler om type problem, ikke om funksjoner

Ser du en ERP-demo og en demo av et dedikert innkjøpsordresystem rett etter hverandre, legger du merke til at eksemplene er forskjellige. ERP-leverandøren viser en innkjøper som bestiller lagervarer fra en katalog, med mengder styrt av lagernivået. Leverandøren av det dedikerte systemet viser en prosjektleder som sender en enkeltbestilling til en underentreprenør, kodet til et prosjekt og en kostnadskode.

Begge demoene ser gode ut fordi hver leverandør viser problemet produktet er laget for. En sammenligning funksjon for funksjon kan ikke avgjøre valget, fordi samme funksjon betyr ulike ting i ulike sammenhenger. Leverandørstyring betyr prislister og varenumre når innkjøpene går via katalog. I en prosjektvirksomhet betyr det en lang og skiftende liste over underentreprenører, der mange bare brukes én gang i året.

Det samme gjelder rapportering. Begge kategorier sier at de har rapportering i sanntid. I den ene betyr det lagerbeholdning og innkjøpsvolum per avdeling. I den andre betyr det forpliktede kostnader mot hver budsjettlinje i prosjektet. Begge påstandene stemmer, men bare den ene svarer på spørsmålet økonomiavdelingen stiller.

Flytt derfor spørsmålet opp ett nivå: Før du sammenligner funksjoner, finn ut hva slags innkjøp dere har. Fire spørsmål gjør mesteparten av jobben.

Fire spørsmål som avgjør valget

Hvordan ser innkjøpsvolumet ut?

Tell innkjøpsordrene og se på størrelsen. Ti tusen små, gjentatte ordrer i måneden er én type. Ti til noen hundre større ordrer i måneden, hver knyttet til et prosjekt, er en annen.

Innkjøpsmodulen i ERP-systemet er laget for den første typen: håndtering av store volumer, bestilling fra katalog og kobling til lagernivå. Et dedikert innkjøpsordresystem er laget for den andre: oppfølging av hver enkelt ordre, underentrepriser og priser som forhandles fra jobb til jobb.

Hvor varierte er innkjøpene?

Består mesteparten av innkjøpene av gjentatte bestillinger fra en fast leverandørliste, trenger du leverandørregistre, varelister og prisavtaler. Det er ERP-systemets område.

Består mesteparten av enkeltbestillinger til en skiftende gruppe underentreprenører og spesialleverandører, trenger du fleksibilitet. Hver bestilling kan være den eneste du sender til den leverandøren i år. Et innkjøpsordresystem laget for prosjekter håndterer dette uten å presse hver bestilling inn i en katalogstruktur.

Hva rapporterer dere på?

Dette er det tydeligste skillet av de fire. Rapporterer dere kostnader per vare, lager og avdeling, eller per prosjekt, fase og kostnadskode?

Trenger du en rapport som viser «£340K forpliktet til underentreprise på disse tre prosjektene dette kvartalet», vil en modul bygd for lagerregnskap gjøre det vanskelig. Dataene kan hentes ut, men hver rapport blir en eksport og et regneark. Et system bygd rundt prosjekter lager rapporten direkte, også rapportering av budsjett vs forpliktet per prosjektlinje.

Hvem godkjenner?

I de fleste innkjøpsmoduler i ERP-systemer ligger godkjenningen hos økonomiavdelingen eller en sentral innkjøpsavdeling som behandler ordrene i en kø. I prosjektbaserte virksomheter er det som regel prosjektlederen som er best egnet til å godkjenne, fordi hun eller han vet om ordren trengs og hva den gjør med prosjektbudsjettet.

Godkjenningsbildet må tilpasses den som godkjenner. En medarbeider i økonomiavdelingen som jobber i en ERP-kø, trenger annen informasjon enn en prosjektleder på byggeplassen. Hva godkjenningsbildet bør vise, går vi gjennom i hva som betyr noe i programvare for godkjenning av innkjøpsordrer.

Når innkjøpsmodulen i ERP-systemet er riktig valg

For noen virksomheter er modulen det opplagte valget, og de trenger ikke lete videre. Profilen er tydelig:

• Volum: store volumer av gjentatte innkjøp, ofte over 1 000 innkjøpsordrer i måneden.
• Leverandører: en fast leverandørbase med avtalte priser og varelister.
• Styres av: lagernivå og bestillingspunkter.
• Rapportering: kostnadssteder organisert etter avdeling, vare og lokasjon.
• Bruk: et ERP-system som er godt innarbeidet og som de fleste i virksomheten bruker hver dag.

Industri-, distribusjons- og handelsvirksomheter passer ofte inn i denne profilen. For dem er den integrerte innkjøpsmodulen riktig svar. Innkjøpene ligger sammen med lager og økonomi, datamodellen passer, og det er ikke noe ekstra system å vedlikeholde. ERP-leverandøren villeder deg ikke. Alle gevinstene ved et innkjøpsordresystem gjelder, levert i systemet dere allerede har.

Når et dedikert innkjøpsordresystem er riktig valg

Den motsatte profilen er like tydelig:

• Volum: færre og større innkjøpsordrer, typisk et sted mellom 10 og 200 i måneden.
• Leverandører: en variert blanding av underentreprenører og spesialleverandører som skifter fra prosjekt til prosjekt.
• Styres av: prosjektets omfang, med innkjøp besluttet av dem som leder arbeidet.
• Rapportering: kostnader per prosjekt, fase og kostnadskode, med budsjetter per prosjekt og ikke per avdeling.
• Bruk: prosjektledere som må godkjenne med prosjektbudsjettet foran seg.

Virksomheter innen bygg og anlegg, rådgivende ingeniørfag, maritim virksomhet, energi og arrangement passer ofte inn i denne profilen. For dem er et dedikert innkjøpsordresystem riktig svar. Det fungerer som et system for kostnadskontroll i prosjekter og ikke som et verktøy for innkjøpsavdelingen, og det passer måten arbeidet faktisk er organisert på.

Hva et dedikert innkjøpsordresystem gjør som en ERP-modul ikke gjør

For virksomheter med prosjektprofilen er det fire egenskaper som utgjør forskjellen.

• Kostnadsstruktur som starter i prosjektet. Hver innkjøpsordre kodes til prosjekt, fase og kostnadskode når den opprettes. Avdeling og vare kommer i andre rekke, om i det hele tatt.
• Forpliktelsen registreres mot prosjektbudsjettet. Når en innkjøpsordre godkjennes, registreres forpliktelsen mot budsjettlinjen med en gang. Det er dette oppfølging av forpliktede kostnader betyr i praksis, og det gjør systemet til et verktøy for kostnadsoppfølging og ikke bare en ordrelogg.
• Integrasjon med regnskapssystemet, ikke erstatning. Innkjøpsordresystemet sender data til hovedboken, mens regnskapssystemet fortsatt eier regnskapet. Ingenting må flyttes ut av systemet økonomiavdelingen allerede stoler på.
• Godkjenning som når prosjektlederne på byggeplassen. De som godkjenner, sitter ikke bare i økonomiavdelingen. Det er prosjektledere som må kunne godkjenne fra mobilen, med budsjettlinjen synlig, mellom møtene på byggeplassen.

Ingenting av dette fungerer hvis budsjettene er uklare. Et prosjektbudsjett med tre linjer sier lite om forpliktelsene som inngås mot det, så god praksis for prosjektbudsjettering kommer først.

CostTrackers innkjøpsordresystem er laget for denne typen problem: prosjektbaserte virksomheter med enkeltbestillinger til varierte underentreprenører, rapportering per kostnadskode og godkjenning ledet av prosjektlederne. Det fungerer sammen med budsjettkontroll i prosjekter og kobles til regnskapssystemet gjennom integrasjoner med regnskapssystemer i stedet for å erstatte det.

Det tredje alternativet ingen nevner: regneark

Mange velfungerende virksomheter styrer innkjøpene i et regneark, og mange av dem bør fortsette med det. Et regneark er gratis, alle kan bruke det, og det kan tilpasses det virksomheten trenger denne uken. Under en viss størrelse finnes det lite som er bedre.

Spørsmålet er hvor den grensen går. Bildet endrer seg som regel når virksomheten passerer noen terskler:

• Flere enn fem aktive prosjekter samtidig. Å holde forpliktelsene oppdatert manuelt på tvers av så mange budsjetter blir en jobb i seg selv.
• Flere enn tre personer som godkjenner innkjøp. Alle som godkjenner, trenger den samme oppdaterte oversikten, og en delt fil gir dem sjelden det.
• Godkjenninger der mye står på spill. Når én innkjøpsordre kan endre prosjektmarginen vesentlig, blir det dyrere å bruke et tall som ikke er oppdatert.
• Flere personer som trenger samme budsjettlinje i sanntid. To personer som jobber i hver sin versjon av et regneark, er der feilene begynner.

Under disse tersklene er et regneark billigere, raskere og enklere. Over dem begynner det å skape de avvikene det skulle forhindre, og tiden det tar å holde det oppdatert, blir en av de skjulte kostnadene ved manuelle innkjøp. Tersklene er retningslinjer, ikke regler. En enklere test er tid: Tenk på sist noen spurte hvor mye av et prosjektbudsjett som allerede var forpliktet. Tok svaret noen sekunder, gjør regnearket jobben sin. Tok det en ettermiddag med telefoner til prosjektlederne, gjør det ikke det. Er dere under tersklene og regnearket fungerer, bør dere beholde det.

Velg verktøy etter problemet, ikke etter brosjyren

Det nyttige spørsmålet er ikke «ERP eller innkjøpsordresystem?», men hva slags problem dere skal løse.

Noen virksomheter har begge deler. En entreprenør med eget verksted kan ha katalogbaserte innkjøp på den ene siden og prosjektinnkjøp på den andre. Se da på hvor pengene går. Ligger mesteparten av kostnadene i prosjektene, bør prosjektprofilen avgjøre valget av verktøy, mens lagerdelen kan bli der den er.

Er innkjøpene preget av store volumer, katalogbestillinger og kobling til lager, passer innkjøpsmodulen i ERP-systemet. Er de prosjektbaserte, med mange underentreprenører og rapportering per kostnadskode, passer et dedikert innkjøpsordresystem. Er virksomheten så liten at én person har oversikt over alle budsjettene, passer et regneark. Alle tre er riktige svar i riktig sammenheng.

For prosjektbaserte virksomheter viser valget seg til slutt i tallene. Et system som registrerer forpliktelsene mot prosjektbudsjettene når de godkjennes, gir et pålitelig anslag for sluttkostnad, fordi kostnaden så langt inkluderer alt som allerede er avtalt og ikke bare det som er fakturert.

Velg verktøy etter problemet, ikke etter brosjyren. Passer virksomheten din profilen for et dedikert innkjøpsordresystem, kan du se hva CostTrackers innkjøpsordresystem gjør.