Waarom een machinebouwer pas bij de factuur ziet dat een project van 2.400 uur er 2.870 heeft gekost

De directeur van een machinebouwer met 45 medewerkers krijgt in mei de nacalculatie van een verpakkingslijn die in maart is opgeleverd. De offerte rekende met 2.400 uur. De urenregistratie telt er 2.870. De materiaalkosten kwamen uit zoals gecalculeerd, de klant is tevreden en heeft betaald. Op papier was dit een project van 428.000 euro met 76.000 euro dekkingsbijdrage. Na de nacalculatie bleef daar 38.400 euro van over, en na de 13 procent indirecte kosten die het bedrijf per project moet dragen, staat er onder de streep 17.240 euro verlies.

Twee maanden eerder had hetzelfde bedrijf een vergelijkbare lijn opgeleverd, voor dezelfde klantgroep, met dezelfde monteurs, en die kwam 30 uur onder de calculatie uit. De directeur zoekt de verklaring bij de projectleider en bij de werkvoorbereider die de offerte maakte, en vindt bij allebei een deel van de verklaring.

Het antwoord zit in de afwijking tussen voorcalculatie en nacalculatie, per werkpakket en per projecttype. Wie alleen het totaal per project vergelijkt, ziet de oorzaak van die afwijking niet.

Waarom de voorcalculatie te laag is voordat het project begint

Kahneman en Tversky (1977) beschreven in een technisch rapport voor het Amerikaanse ministerie van Defensie (geen peer review; in 1982 opgenomen in het boek Judgment under Uncertainty) waarom mensen de duur van een taak stelselmatig onderschatten. Ze bouwen de schatting op uit de kenmerken van het geval zelf, en laten liggen wat ze weten over de uitkomsten van vergelijkbare gevallen. Kahneman en Tversky noemen dat de planning fallacy. Buehler, Griffin en Ross (1994) toetsten dit in het Journal of Personality and Social Psychology (peer reviewed) bij studenten die hun eigen scriptie moesten plannen: 29,7 procent was klaar binnen de tijd die ze zelf hadden voorspeld. Zodra de proefpersonen werden gevraagd hun eerdere ervaringen expliciet aan de nieuwe voorspelling te koppelen, verdween de optimistische afwijking.

Een werkvoorbereider die een verpakkingslijn calculeert, doet wat die studenten deden. Hij loopt het ontwerp langs, telt de bewerkingen, schat de montage en telt op. Dat is een schatting van binnenuit. Wat hij niet doet, is de laatste vier lijnen van dit type naast elkaar leggen en kijken hoeveel procent die uitliepen. Flyvbjerg (2006) werkte in het Project Management Journal (peer reviewed) de remedie uit die Kahneman en Tversky voorstelden, onder de naam reference class forecasting. Je kiest een klasse van vergelijkbare afgeronde projecten en bepaalt de verdeling van hun uitkomsten. Het nieuwe project krijgt daarna zijn plaats in die verdeling. Flyvbjerg noemt naast de onbewuste optimistische afwijking ook een bewuste: een schatting wordt laag gehouden om het project boven dat van de concurrent gegund te krijgen. Bij de machinebouwers die wij zien, zijn dat vaak dezelfde persoon en dezelfde offerte.

Wij zien bij machinebouwers en engineeringbedrijven dat de uitkomsten van eerdere projecten wel ergens staan, in de nacalculaties, maar dat niemand ze per projecttype bij elkaar zet voordat de volgende offerte de deur uit gaat. De werkvoorbereider weet uit ervaring dat nieuwe ontwerpen uitlopen. Hoeveel procent, weet hij niet.

Het uurtarief is bij die bedrijven zelden het probleem. Een tariefcijfer voor de machinebouw zelf hebben wij niet gevonden. Het dichtstbijzijnde is de VvDN Marktmonitor over het tweede kwartaal van 2026 (marktrapport van de Vereniging van Detacheerders Nederland, besproken door vakmedium ZiPconomy in augustus 2026): het gemiddelde verkooptarief van detacheerders steeg met 4,5 procent naar 81,02 euro per uur, terwijl de omzet in het vakgebied engineering met 2,9 procent daalde.

Waarom de afwijking pas bij de factuur zichtbaar wordt

Little (2006) analyseerde in IEEE Software (peer reviewed vakblad) 106 softwareprojecten van één bedrijf en vond dat de werkelijke doorlooptijd mediaan 1,8 keer de geschatte was. De relatieve onzekerheid over het resterende werk bleef in die projecten gedurende de hele looptijd vrijwel gelijk. De schatting wordt dus niet vanzelf beter naarmate het project vordert. Beter wordt ze pas als iemand het werk dat af is, naast het werk dat gepland was legt. Voor een machinebouwer betekent dat: een project dat in week 12 op schema lijkt omdat er 1.450 van de 2.400 uur zijn geschreven, is in week 12 net zo onzeker als in week 1, tenzij je weet welk werk voor die 1.450 uur is gedaan.

Daar komt de urenregistratie zelf bij. Te Braak, Van Tienoven, Minnen en Glorieux (2023) lieten in Sociological Methodology (peer reviewed) op basis van 8.535 online tijddagboeken van Belgische leraren zien dat de kwaliteit van geregistreerde tijd al enkele uren na de activiteit begint te dalen, veel eerder dan eerder onderzoek aannam. Een monteur die op vrijdagmiddag de uren van maandag invult, reconstrueert ze uit zijn geheugen. Aan het eind van de maand is dat geheugen weg en wordt het een schatting. In beide gevallen belanden de uren op het project dat hem het eerst te binnen schiet, en dat is het project waar hij het langst aan heeft gewerkt of dat de meeste aandacht kreeg. Dat er uren op het verkeerde project belanden, is onze eigen waarneming bij bedrijven waar de registratie per week of per maand gebeurt; wij hebben er geen onderzoek bij gevonden dat dit specifiek voor projectorganisaties meet.

Ook de nacalculatie zelf werkt mee aan het probleem, want die is meestal één getal per project: geoffreerde uren tegenover geschreven uren. Dat getal zegt dat het project 470 uur is uitgelopen. In welk werkpakket dat gebeurde, en waardoor, staat er niet bij.

Rekenvoorbeeld: van 2.400 naar 2.870 uur

In dit rekenvoorbeeld bouwt het bedrijf een verpakkingslijn op klantspecificatie. De voorcalculatie: 2.400 uur tegen een verkooptarief van 105 euro, 252.000 euro, plus 160.000 euro materiaal en uitbesteed werk met 10 procent opslag, 176.000 euro. Verkoopprijs 428.000 euro. De interne kostprijs per uur, loonkosten en directe werkplaatskosten per productief uur, is 80 euro. De gecalculeerde kostprijs is dus 2.400 keer 80 is 192.000 euro plus 160.000 euro materiaal, samen 352.000 euro, en de dekkingsbijdrage 76.000 euro, 17,8 procent van de prijs. Het bedrijf heeft 13 procent dekking per project nodig om de indirecte kosten te dragen: engineering die niet aan een project hangt, verkoop, werkvoorbereiding, kantoor. Op deze offerte blijft daarna 20.360 euro over.

De nacalculatie: 2.870 uur, 470 meer dan gecalculeerd. Tegen 80 euro is dat 37.600 euro extra kostprijs. De dekkingsbijdrage zakt naar 38.400 euro, 9,0 procent. Na de 13 procent indirecte kosten, 55.640 euro, is het resultaat van dit project 17.240 euro negatief. Het materiaal kwam uit op de gecalculeerde 160.000 euro; hoe een staalprijsstijging tussen offerte en inkoop dezelfde som aan de materiaalkant onderuit haalt, staat in Waarom een machinebouwer met vaste prijzen zijn marge verliest aan een staalprijsstijging tussen offerte en inkoop.

De projectleider heeft na oplevering de 470 uur uitgezocht aan de hand van de weekstaten, de wijzigingsmails van de klant, de inkooporders en de werkplaatsplanning. In het voorbeeld komen ze uit op vier posten.

Elke post heeft een andere eigenaar. De wijzigingen zijn een commerciële vraag: 190 uur tegen 105 euro is 19.950 euro omzet die nooit is gevraagd, en of je dat aan een klant in rekening brengt, beslis je tijdens het project. De wachttijd hoort bij inkoop en planning, het herstelwerk bij engineering, en allebei vragen ze om een andere maatregel dan een hogere opslag in de offerte. De 75 uur van het andere project zijn geen kosten van dit project, en zonder die correctie krijgt de retrofit ernaast een nacalculatie die te mooi is, waardoor de volgende retrofit te scherp wordt geoffreerd.

Ghaffari en Emsley (2015) beschrijven in Surveys in Operations Research and Management Science (peer reviewed) in een overzicht van 140 studies naar Goldratts Critical Chain (1997, boek, geen vrije versie online) dat die methode multitasking tussen projecten niet toestaat, en dat de veiligheidsmarges in een planning in de praktijk inefficiënt worden gebruikt. Wat een wissel tussen projecten in een werkplaats kost, staat in het voorbeeld bij de 95 uur wachten en omschakelen: 7.600 euro op één project. Hoe een buffer in een calculatie wordt opgemaakt voordat hij nodig is, en wat je daar met earned value tegen doet, is voor een IT-project uitgewerkt in Waarom vaste-prijsdeals in IT-projecten vaker verlies opleveren dan je denkt; in een werkplaats zien wij hetzelfde mechanisme.

Wat je in week 12 al had kunnen zien

Het project liep 26 weken. In week 12 stonden er 1.450 uur op de urenregistratie, 60 procent van de 2.400. De projectleider schatte het project op "ongeveer 60 procent klaar", de prognose was daarmee 1.450 gedeeld door 0,60 is 2.417 uur, en daar maakte niemand zich zorgen over.

Batselier en Vanhoucke (2015) vergeleken in het International Journal of Project Management (peer reviewed) op 23 echte projecten de nauwkeurigheid en tijdigheid van voorspelmethoden die zijn gebaseerd op earned value management. De gedachte daarachter: je baseert de prognose voor het hele project op de verhouding tussen het werk dat af is en de kosten die daarvoor zijn gemaakt, in plaats van op de verhouding tussen bestede en gebudgetteerde uren. Voor een machinebouwer is de doe-het-zelf-versie daarvan een tabel per werkpakket.

Het werk dat af is, vertegenwoordigt 1.290 gecalculeerde uren, 54 procent van het project. Daar zijn 1.450 uur voor geschreven. Elk gecalculeerd uur kost tot nu toe 1.450 gedeeld door 1.290 is 1,124 uur, en de prognose voor het hele project is 2.400 keer 1,124 is afgerond 2.700 uur. Dat is 300 uur boven de calculatie, in week 12, met 14 weken te gaan. De klantwijzigingen van de laatste maanden kwamen daar nog bij en brachten het op 2.870. Het verschil tussen de prognose van de projectleider (2.417) en die van de werkpakketten (2.700) zit in de engineering: 820 uur voor werk dat op 700 stond, en dat wist het bedrijf in week 8 al, als iemand het had opgeteld.

Wat je in week 12 nog kunt doen en in week 26 niet meer: de maatfout uit engineering opsporen voordat het frame is gebouwd, de wijzigingen van de klant vanaf dat moment als meerwerk vastleggen, de servomotoren najagen voordat de monteurs stilstaan, en de monteurs op dit project laten in plaats van ze twee keer te verplaatsen. In dit rekenvoorbeeld had dat van de 470 uur de 110 uur herstelwerk gescheeld, plus een deel van de 190 uur wijzigingen.

Wat het gemiddelde wegmiddelt

Het bedrijf uit het voorbeeld doet twaalf projecten per jaar, samen goed voor ongeveer 3,0 miljoen euro omzet. Over die twaalf projecten zijn 16.900 uur gecalculeerd en 19.160 geschreven: 13,4 procent uitloop, 2.260 uur, tegen 80 euro is dat 180.800 euro kostprijs die in de offertes niet zat. De directeur die dit getal ziet, zet 13 procent op alle uren in de volgende offertes.

Het bedrijf deelt zijn projecten in naar hoeveel ervan al eerder is gebouwd, van een nieuw ontwerp op klantspecificatie tot een retrofit van een bestaande machine. Per projecttype ziet dezelfde uitloop er zo uit.

Een opslag van 13 procent op alles past in dit voorbeeld op geen enkel projecttype. Een variant van 1.100 uur gaat er voor 1.243 uur mee de deur uit, waar de eigen nacalculaties 1.122 zeggen: 121 uur en 12.705 euro tegen verkooptarief te duur, en dat op het projecttype waarop het bedrijf concurreert met bedrijven die het ontwerp al hebben. Een nieuw ontwerp krijgt 13 procent waar het er 19,6 nodig had, en komt per project van 2.400 uur nog altijd 158 uur tekort, 12.640 euro.

Binnen de vier nieuwe ontwerpen is de spreiding groter. Drie daarvan liepen 24 tot 32 procent uit, de vierde kwam 4 procent onder calculatie uit. Bij de retrofits speelt het omgekeerde: daar zit het project waarop in de laatste maand 75 uur te weinig is geschreven, de 75 uur uit de eerste tabel die op de verpakkingslijn belandden. Een nacalculatie die dat niet corrigeert, leert het bedrijf dat retrofits soms meevallen, en offreert de volgende retrofit 75 uur te scherp.

Wat acceptabel is en op welk moment

Een afwijking van nul is geen doel. Een nieuw ontwerp op klantspecificatie bevat werk dat niemand eerder heeft gedaan, en een nacalculatie die daar op de uur nauwkeurig op uitkomt, is toeval. Dit is wat wij bij klanten als werkbaar zien, per moment in het project.

Het moment dat het meeste oplevert, is de offerte. Een prijs die op 2.400 uur is gebouwd, corrigeer je niet meer als de opdracht is getekend. Alles wat daarna komt, beperkt de schade of verbetert de volgende offerte.

Hoe je de nacalculatie per project zelf opzet

De zuivere methode begint bij de structuur: de voorcalculatie en de nacalculatie gebruiken dezelfde werkpakketten, en de urenregistratie kent per project alleen die werkpakketten. In de projectmanagementliteratuur heet die structuur een work breakdown structure. Zonder gedeelde structuur is de vergelijking achteraf een puzzel: de calculatie zegt "montage 1.100 uur" en de urenregistratie zegt "werkplaats 1.890 uur", en daar zit ook de inbedrijfstelling in. Daarnaast krijgt de urenregistratie vier codes naast het werkpakket: regulier, wijziging klant, wachten en omschakelen, herstel. Een monteur die een dag heeft gewacht op servomotoren, schrijft acht uur op montage met de code wachten. De projectleider vult elke week per werkpakket het percentage gereed in, en het systeem rekent de prognose uit. Het inrichten hiervan in het ERP- of projectpakket, en het discipline erin houden, is werk dat wij bij onze klanten doen, en waar wij dus ook ons geld mee verdienen.

De doe-het-zelf-variant kost een middag met de nacalculaties van de laatste twee jaar en een spreadsheet, en geeft de opslagfactor per projecttype waarmee de volgende offerte al beter is dan de vorige.

Stap 1: zet elk afgerond project van de laatste twee jaar op een regel, met projecttype, klant, gecalculeerde uren en geschreven uren. In het voorbeeld: twaalf regels voor dit jaar, en de twaalf van vorig jaar erbij.

Stap 2: markeer de projecten waarvan je weet dat de uren niet kloppen, omdat er in dezelfde periode een project naast liep dat verdacht ver boven of onder calculatie uitkwam. Zet die twee tegen elkaar en verschuif wat aantoonbaar verkeerd zit. In het voorbeeld: 75 uur van de verpakkingslijn terug naar de retrofit.

Stap 3: bereken per projecttype de verhouding geschreven uren gedeeld door gecalculeerde uren, en neem daarvan het gemiddelde; een project dat door een faillissement van een leverancier 60 procent uitliep, laat je buiten de klasse, omdat het anders alle offertes van dat type omhoog trekt. In het voorbeeld komt een nieuw ontwerp zo op 1,196 en een variant op 1,02; een retrofit zit met 1,15 daartussen.

Stap 4: zet die factor in de calculatiesheet als aparte regel onder de uren van binnenuit, met de naam van het projecttype erbij. Een offerte laat dan twee getallen zien: 2.400 uur volgens het ontwerp, 2.870 uur volgens de eigen geschiedenis. Wie voor 2.400 wil offreren om de order te winnen, doet dat dan met open ogen en weet dat het verschil 49.350 euro is, 11,5 procent van de prijs.

Stap 5: houd bij elk nieuw project vanaf de eerste week de uren per werkpakket bij, ook als het systeem dat nog niet kan; een tabel op papier met vier werkpakketten en een kolom "procent gereed" is genoeg om de prognose van week 12 te maken.

Wie dit heeft gedaan, weet per projecttype welke opslag er in de offerte hoort, en dat is het verschil tussen 13 procent op alles en 2 tot 20 procent op het juiste type. De toerekening per werkpakket, die laat zien waar binnen een project de uren weglekken, komt daarna.

Wanneer dit rekenvoorbeeld niet opgaat

Het model gaat uit van een bedrijf dat tegen een vaste prijs per project werkt, met eigen engineering en eigen montage, en met meerdere projecttypes door dezelfde mensen. Voor een aantal bedrijven ligt het anders.

Een bedrijf dat op regiebasis werkt, dus alle uren factureert, heeft de afwijking tussen voor- en nacalculatie in de eerste plaats als probleem van de klant. Het probleem verschuift dan naar de discussie bij de factuur, en naar de vraag of de klant de volgende keer weer belt. De tabel met vier posten is daar nog steeds bruikbaar, maar de euro's erachter zijn dan omzet die je niet hebt gefactureerd.

Een bedrijf met projecten onder de 200 uur heeft aan werkpakketten weinig. De registratie kost dan meer dan ze oplevert, en de opslagfactor per projecttype uit stap 3 is het enige dat overblijft.

Een toeleverancier die per order één bewerking doet, verspanen bijvoorbeeld, heeft geen werkpakketten maar bewerkingen, en de afwijking zit in de eerste-stuk-problemen: programmeren, opspannen, inmeten, de eerste maat die niet klopt. Daar is het onderscheid tussen enkelstuks en herhaalorder wat in dit artikel het onderscheid tussen nieuw ontwerp en variant is, en de rest van de methode werkt hetzelfde.

En het model rekent met een vaste kostprijs van 80 euro per uur. Een bedrijf dat in het hoogseizoen monteurs inleent tegen 95 euro per uur, heeft in die maanden een andere kostprijs per uur dan de 80 euro van eigen mensen, en dan is een uur uitloop in de zomer duurder dan een uur uitloop in de winter. Hoe de bezetting van de eigen mensen zich verhoudt tot wat er wordt verkocht, staat in Utilization rate vs. winstgevendheid, de metric die bureaus vergeten.

Hoe je voor- en nacalculatie in de maakindustrie op elkaar krijgt

Bereken de opslagfactor per projecttype met de vijf stappen hierboven, en zet die als aparte regel in elke offerte. In het voorbeeld verandert de calculatie van een nieuw ontwerp daardoor van 2.400 naar 2.870 uur, en van een variant van 1.100 naar 1.122.

Laat de voorcalculatie en de urenregistratie dezelfde werkpakketten gebruiken. Bij de maakbedrijven die wij zien, kost die afspraak geen software, maar zonder die afspraak is de vergelijking per werkpakket achteraf niet te maken.

Uren schrijf je op de dag zelf, en je controleert het op vrijdag. Te Braak en collega's (2023) laten zien dat de kwaliteit van geregistreerde tijd al na enkele uren daalt; een weekstaat die op vrijdag wordt gereconstrueerd, geeft per project een getal dat ernaast zit, en de nacalculatie erft die fout.

Geef de urenregistratie vier codes naast het werkpakket: regulier, wijziging klant, wachten, herstel. In het voorbeeld verdeelt dat de 470 uur in 190, 95, 110 en 75, en elk van die vier heeft een andere eigenaar in het bedrijf.

De projectleider geeft elke week per werkpakket het percentage gereed op, en daaruit reken je de prognose in verdiende uren. In het voorbeeld gaf dat in week 12 een prognose van 2.700 uur tegen 2.417 volgens de bestede uren, en het verschil van 283 uur was het verschil tussen ingrijpen en achteraf uitzoeken.

Leg elke wijziging van de klant op de dag zelf vast met uren erbij, ook als je besluit hem niet te factureren. In het voorbeeld is dat 190 uur, 19.950 euro tegen verkooptarief, en dan beslist de directie of het wordt weggegeven, in plaats van de monteur die ja zei.

Kijk elk kwartaal naar de projecten met de laagste dekkingsbijdrage in euro's na nacalculatie, en leg ze naast de projecten met de hoogste. In het voorbeeld zit het verschil tussen de verpakkingslijn en de lijn van twee maanden eerder in 190 uur wijzigingen en een maatfout, en dat zijn beide dingen die bij de volgende lijn anders kunnen. Welk deel van je projectportefeuille het resultaat draagt en welk deel het opeet, staat uitgewerkt in Het Pareto-principe is ook een risicometer voor je bedrijf; hoe je een project van calculatie tot evaluatie volgt, in Projecten winstgevend houden: van calculatie tot evaluatie.

Veelgestelde vragen over nacalculatie per project in de machinebouw

Waarom verdien ik op het ene project wel en op het andere niet, terwijl de offertes hetzelfde waren?

De afwijking tussen voorcalculatie en nacalculatie bestaat per project uit verschillende posten, en in het totaal zie je die niet. In het rekenvoorbeeld zit een uitloop van 470 uur in 190 uur klantwijzigingen, 95 uur wachten op onderdelen, 110 uur herstelwerk en 75 uur die op het verkeerde project zijn geschreven. Het project van twee maanden eerder had die wijzigingen en die maatfout niet, en kwam 30 uur onder calculatie uit met dezelfde monteurs.

Waarom kost een project meer uren dan de voorcalculatie?

Kahneman en Tversky (1977) beschreven dat een schatting die is opgebouwd uit het geval zelf stelselmatig te laag uitvalt, omdat de uitkomsten van vergelijkbare eerdere gevallen buiten beschouwing blijven; Buehler, Griffin en Ross (1994) vonden dat 29,7 procent van de scriptiestudenten de eigen planning haalde. Daar komen in een werkplaats de oorzaken bij die pas tijdens het project ontstaan: wijzigingen van de klant, wachttijd, herstelwerk en uren die op het verkeerde project belanden. De eerste oorzaak los je op met een opslag per projecttype uit je eigen nacalculaties, de andere vier met codes in de urenregistratie.

Hoe maak ik een nacalculatie per project en vergelijk ik die met de voorcalculatie?

Gebruik dezelfde werkpakketten als in de voorcalculatie, zet per werkpakket de gecalculeerde en de geschreven uren naast elkaar, en verdeel het verschil over vier codes: regulier, wijziging klant, wachten, herstel. Corrigeer daarna de uren die aantoonbaar op een ander project horen. In het voorbeeld: engineering 700 gecalculeerd en 820 geschreven, montage 1.100 tegen 1.380, en de 470 uur verschil in vier posten met elk een eigenaar.

Wat is een acceptabele afwijking tussen voorcalculatie en nacalculatie?

Dat hangt af van het projecttype. Wij zien bij machinebouwers dat een nieuw ontwerp op klantspecificatie binnen 15 procent van de calculatie een goed resultaat is, een variant op een bestaand ontwerp binnen 5 procent, een retrofit binnen 10 procent, en een offerte die bewust lager is geprijsd binnen wat daar toen over is afgesproken. Belangrijker dan de afwijking zelf is of hij vooraf in de offerte zat: in het rekenvoorbeeld loopt een nieuw ontwerp gemiddeld 19,6 procent uit, en een offerte die daarmee rekent, heeft die uitloop al in de prijs zitten.

Hoe zie ik tijdens een project of de uren uit de hand lopen?

Door per werkpakket wekelijks het percentage gereed op te geven en de prognose te berekenen uit verdiende uren in plaats van uit bestede uren. In het voorbeeld stonden er in week 12 1.450 uur geschreven op werk dat 1.290 gecalculeerde uren vertegenwoordigde; 2.400 keer 1.450 gedeeld door 1.290 geeft een prognose van 2.700 uur, en dat was 300 uur boven de calculatie op een moment dat de projectleider nog "op schema" zei. Batselier en Vanhoucke (2015) vergeleken op 23 echte projecten hoe nauwkeurig en hoe vroeg zulke earned-valuemethoden de einduitkomst voorspellen.

Hoeveel opslag moet ik op de geoffreerde uren zetten?

De opslag die uit je eigen nacalculaties per projecttype komt. In het rekenvoorbeeld is dat 19,6 procent op een nieuw ontwerp en 2 procent op een variant; een retrofit zit daar met 15 procent tussenin, steeds met het gemiddelde over de laatste twee jaar als basis. Flyvbjerg (2006) noemt die methode reference class forecasting. Eén opslag van 13 procent op alles maakt in het voorbeeld een variant van 1.100 uur 12.705 euro te duur en laat op elk nieuw ontwerp nog 12.640 euro liggen.

Waarom klopt mijn urenregistratie per project niet?

Uren die niet op de dag zelf worden geschreven, worden gereconstrueerd. Te Braak en collega's (2023) lieten op 8.535 tijddagboeken zien dat de kwaliteit van geregistreerde tijd al enkele uren na de activiteit begint te dalen. Wij zien bij bedrijven waar de weekstaat op vrijdag of aan het eind van de maand wordt ingevuld dat uren op het project belanden dat het meest in het geheugen zit, en in het rekenvoorbeeld is dat 75 uur die een retrofit te mooi en een verpakkingslijn te slecht laten lijken.

Wat is een goede dekkingsbijdrage per project in de machinebouw?

Minstens het percentage dat je nodig hebt om de indirecte kosten te dragen. In het rekenvoorbeeld is dat 13 procent, en een project dat na nacalculatie op 9,0 procent uitkomt, kost 17.240 euro. Wij zien bij machinebouwers in het MKB dat het benodigde percentage per bedrijf sterk verschilt, en dat de spreiding tussen projecten na nacalculatie groter is dan de directeur verwacht. Het projecttype waarop het percentage wordt gehaald, zegt daarom meer dan het percentage zelf.

Meer lezen: Waarom een machinebouwer met vaste prijzen zijn marge verliest aan een staalprijsstijging tussen offerte en inkoop, Waarom vaste-prijsdeals in IT-projecten vaker verlies opleveren dan je denkt, Projecten winstgevend houden: van calculatie tot evaluatie en Utilization rate vs. winstgevendheid, de metric die bureaus vergeten.

← Terug naar kennisbank