Et ERP til byggeri skal styre sager, ikke ordrer. Det lyder som en detalje, men det er den grundlæggende forskel, der gør, at systemer bygget til handel eller serieproduktion sjældent passer til en entreprenør eller en byggeleverandør. En sag løber over måneder, økonomien skal opgøres undervejs, og både materialer, timer og underleverandører skal knyttes til den rigtige sag hele vejen.
Vi ser ofte, at virksomheder i branchen ender med et system, der bogfører fint, men som ikke kan fortælle, hvad der reelt tjenes på den enkelte sag, før den er afsluttet. Denne artikel gennemgår de områder, der afgør, om systemet passer til byggeriet.
Af Partner, Sander Dyrvig
Den vigtigste forskel er tidshorisonten. Hvor en handelsvirksomhed afslutter en ordre på få dage, kan en byggesag løbe i månedsvis eller længere, og i hele den periode skal virksomheden vide, hvor den står økonomisk. Det kræver, at systemet kan opgøre igangværende arbejder løbende, altså hvad der er brugt, hvad der er faktureret, og hvad der mangler at blive udført.
Den anden forskel er, at hver sag er unik. Selv når to opgaver ligner hinanden, er der forskellige forhold på pladsen, forskellige underleverandører og forskellige aftaler. Derfor findes der sjældent en fast stykliste, der kan genbruges direkte, og kalkulationen bliver et selvstændigt arbejde for hver sag.
Endelig er en stor del af arbejdet ude på pladsen, ikke i virksomheden. Timer, materialeforbrug og ændringer opstår, hvor arbejdet udføres, og hvis registreringen først sker på kontoret ugen efter, er både faktureringen og styringen bagud.
I et system til byggeri er sagen den bærende enhed, som alt andet hænger op på. Det gælder tilbuddet, indkøbene, timerne, materialerne, underleverandøraftalerne, ekstraarbejderne og faktureringen. Kan systemet ikke samle det hele under samme sag, ender virksomheden med at føre sagsregnskabet i regneark ved siden af.
Ofte skal sagen desuden kunne deles op. Store opgaver består af flere delentrepriser eller etaper, og de skal kunne følges hver for sig, samtidig med at sagen kan ses samlet. Systemet bør derfor kunne håndtere en struktur med under-sager frem for kun ét niveau, ellers mister ledelsen overblikket, når opgaverne vokser.
Vi ser ofte, at netop sagsstrukturen er den beslutning, der er sværest at ændre bagefter. Vælges den for simpelt fra start, bliver rapporteringen upræcis i årevis, og derfor bør den designes ud fra, hvordan virksomheden reelt styrer sine opgaver.
Kalkulationen er der, hvor pengene tjenes eller tabes, og den bør ikke ligge løsrevet fra systemet. Et tilbud bygges op af poster med materialer, timer, underleverandører og et dækningsbidrag, og når opgaven vindes, bør kalkulationen kunne bruges direkte som budget på sagen.
Det er koblingen bagud, der giver den reelle værdi. Uden en efterkalkulation, hvor det faktiske forbrug holdes op mod det kalkulerede, gentages de samme fejlskøn på næste tilbud. Kan systemet vise, hvor kalkulationen typisk rammer forkert, bliver det et styringsredskab og ikke kun et regnskab. Det forudsætter dog, at timer og materialer registreres på den rigtige sag i hverdagen, og der er det ofte disciplinen og ikke systemet, der er flaskehalsen.
Byggeri faktureres sjældent på én gang. Der faktureres aconto efter stadeopgørelser eller efter en betalingsplan, og indtægten skal periodiseres, så regnskabet viser et retvisende billede undervejs. Systemet skal derfor kunne opgøre igangværende arbejder og håndtere færdiggørelsesgraden på den enkelte sag.
Hertil kommer tilbageholdte beløb og garantiforpligtelser, som følger sagen længe efter, at arbejdet er udført. Håndteres det manuelt, opstår der let uoverensstemmelser mellem sagsregnskabet og finansbogholderiet, og så bliver månedsrapporteringen en øvelse i afstemning frem for i styring. Det er en af de mest oversete poster i en kravspecifikation.
Ændringer er reglen frem for undtagelsen i byggeriet, og de er samtidig en hyppig kilde til tab. Aftales et ekstraarbejde mundtligt på pladsen og udføres uden at blive registreret, er det svært at få betaling for det bagefter.
Et system, der understøtter branchen, skal derfor kunne oprette ekstraarbejder som en del af sagen, med en godkendelse, en pris og en kobling til den oprindelige aftale. Jo tættere registreringen ligger på det tidspunkt, hvor ændringen aftales, jo større er sandsynligheden for, at den faktureres. Det er sjældent et spørgsmål om avanceret funktionalitet, men om at gøre registreringen så enkel, at den faktisk bliver gjort.
Timeregistrering på sag er fundamentet under både løn, fakturering og efterkalkulation. Systemet skal kunne knytte timen til den rigtige sag og gerne til den rigtige delopgave, og det skal kunne håndtere de særlige lønforhold i branchen, herunder tillæg, kørsel og akkordafregning.
Registreringen skal desuden fungere ude på pladsen, hvor der ikke altid er en computer eller stabil forbindelse. En simpel løsning på telefonen, der kan bruges med arbejdshandsker på, giver bedre data end et avanceret system, ingen når at bruge. Erfaringen fra andre brancher gælder også her: er registreringen besværlig, bliver den udskudt, og så bliver tallene upålidelige.
En stor del af værdien i en byggesag købes udefra. Underleverandøraftaler, materialeleverancer og leje af materiel skal derfor kunne knyttes direkte til sagen, så forbruget ses, efterhånden som det opstår, og ikke først når fakturaen kommer.
Det kræver et gennemtænkt flow for indkøb og fakturagodkendelse. Bestilles der på pladsen uden en indkøbsordre, ved økonomiafdelingen ikke, hvad der er på vej, og sagens økonomi ser bedre ud, end den er. En del af arbejdet med at få styr på det ligger i processerne frem for i systemet, og det er netop det, business process management handler om.
Selv når hver sag er unik, hviler den på stamdata, der går igen. Det gælder varenumre og prislister, timearter og lønarter, sagstyper, leverandører og de kalkulationsposter, tilbuddene bygges op af. Er de ikke ensartede, kan sager ikke sammenlignes, og så mister nøgletallene deres værdi.
Vi ser ofte, at en sagsbaseret virksomhed har flere års ophobede varianter af de samme oplysninger, fordi hver afdeling har oprettet sit eget. Derfor bør arbejdet med masterdata begynde tidligt i et systemprojekt, og den løbende datakvalitet skal have en ejer, ellers forfalder strukturen igen.
Markedet rummer både brede ERP-systemer med et projektmodul og mere specialiserede branchesystemer til byggeri og installation. Begge dele kan fungere, og valget afhænger af, hvor kompleks sagsstyringen er, hvor mange andre dele af forretningen systemet skal dække, og hvor meget virksomheden ønsker at tilpasse.
Et bredt system giver typisk mere sammenhæng med økonomi, indkøb og lager, men kan kræve tilpasning for at følge branchens arbejdsgange. Et branchesystem passer bedre fra start, men kan være smallere på de øvrige områder. Det afgørende er at prøve løsningen af på en rigtig sag: byg et tilbud, vind det, registrer timer og materialer, opret et ekstraarbejde, og lav en aconto-fakturering. Det er den øvelse, der afslører forskellene, ikke funktionslisten. Vi bruger den samme tilgang i vores arbejde med valg af IT-system.
Et systemskifte i en sagsbaseret virksomhed lykkes sjældent på teknikken, men på om sagsmodellen passer til den måde, arbejdet reelt styres på. Start derfor med at kortlægge, hvordan en sag i dag går fra tilbud til afsluttet regnskab, og hvor de manuelle mellemregninger opstår undervejs.
Kortlægningen oversættes derefter til krav, der kan bruges i dialogen med leverandørerne, og det arbejde er kernen i en forretningsanalyse, hvor forretningsmodel, processer, data og systemer ses i sammenhæng. Har processerne udviklet sig forskelligt fra afdeling til afdeling, giver det ofte mening at rette dem, før de bygges ind i et nyt system.
Det er et forretningssystem, der er tilpasset virksomheder, som køber og videresælger varer. Tyngden ligger på lagerstyring, indkøb, prisaftaler og ordrehåndtering frem for på produktion. Systemet skal give et præcist overblik over beholdning og aftaler i realtid.
En ordre afsluttes typisk hurtigt og har en fast varelinje. En sag løber over længere tid og består af timer, materialer, underleverandører og ændringer. Derfor skal økonomien kunne opgøres undervejs frem for kun ved afslutningen.
Det er opgørelsen af, hvad der er udført, men endnu ikke faktureret. Systemet skal kunne periodisere indtægt og omkostning på sagen. Uden den opgørelse viser regnskabet ikke et retvisende billede undervejs.
Efterkalkulationen viser, hvor det faktiske forbrug afveg fra tilbuddet. Uden den gentages de samme fejlskøn på næste opgave. Den forudsætter, at timer og materialer registreres på den rigtige sag.
Ekstraarbejdet bør oprettes på sagen med pris og godkendelse, så snart det aftales. Jo tættere registreringen ligger på aftalen, jo større er chancen for at få betaling. Aftales det kun mundtligt, bliver det svært at fakturere.
Begge dele kan fungere, og valget afhænger af sagsstyringens kompleksitet og behovet på de øvrige områder. Et bredt system giver mere sammenhæng, et branchesystem passer bedre fra start. Prøv løsningen af på en rigtig sag frem for at vurdere den på funktionslisten.
Byggeri og entreprenørforretning stiller egne krav til ERP, fra sagsstruktur og kalkulation til igangværende arbejder og registrering på pladsen. Som uvildige rådgivere har vi hverken præference for bestemte systemer eller partnere, og vi kortlægger forretningen, før vi vurderer løsninger. Palsgaard Spær er en af Danmarks ældste spærfabrikker og leverer træbaserede løsninger fra design til levering. Da deres implementering af Dynamics 365 Finance & Operations gik i stå i 2023, overtog vi projektstyringen, skar scope til, og de kom i mål inden for tid og budget efter 11 måneder. I kan bruge os som rådgivere, som assisterende projektledelse eller med det fulde ansvar for leverancen.
Sander Dyrvig
Med erfaring fra projektledelse af større transformationsprojekter i +10 år, varetager Sander typisk program- og projektledelsen af større og komplekse projekter.
Inden skiftet til Cornerstones varetog Sander forskellige lederstillinger indenfor forretningsudvikling for VKR Gruppen og Bestseller.
