Werkvoorbereiding zit op het kruispunt. Engineering levert af, en jij zet die data om naar iets waar de werkplaats, de lasersnijder, de zager en de inkoop mee verder kunnen. Gaat er bovenstrooms iets mis, dan komt het bij jou aan tafel terecht. En meestal pas op het moment dat het echt tijd kost: een stuklijst die niet klopt met de samenstelling, een model vol achtergebleven geometrie, of een PDF met een revisienummer dat al naar de leverancier is gegaan.
De kern van het probleem is bijna nooit slecht vakwerk. Het is rommelige data. Schone data naar productie brengen is precies de schakel waar het misgaat: tussen het Inventor-model van engineering en de productiedocumenten die de vloer op gaan. In dit artikel lopen we de meest voorkomende fouten downstream langs, en laten we zien hoe Model Cleaner, het iProperty Menu, BOM Export en Batch Publish die aan de bron afvangen: in het model, niet in de bestelbon.
Wat er misgaat als engineering rommelige data aanlevert
Niemand levert bewust een rommelig model aan. Maar onder tijdsdruk blijven er dingen achter. Een schets die niet meer wordt gebruikt. Een onderdrukte feature die ooit een variant was. Een materiaalcode die met de hand is overgetypt en net één teken afwijkt van wat de inkoop in het ERP heeft staan. Stuk voor stuk klein. Bij elkaar is het de reden dat jouw werkdag vol zit met controleren in plaats van voorbereiden.
Een paar situaties die je waarschijnlijk herkent:
- De stuklijst klopt niet met het model. Een onderdeel staat er dubbel in, of een aantal is in de parts list met de hand overschreven en is niet meer gelijk aan wat er werkelijk in de samenstelling zit. De werkplaats bestelt te weinig, of juist te veel.
- iProperties zijn half ingevuld of inconsistent. Het ene onderdeel heeft een nette omschrijving, het andere heet nog "Part1". Het materiaal staat soms in de fysieke eigenschappen van het model, soms alleen overgetypt in de titelhoek van de tekening, en die twee spreken elkaar tegen.
- Modellen zijn zwaar en traag. Achtergebleven surfaces, losse schetsen en zwevende constructievlakken zorgen dat een samenstelling traag opent en dat de export struikelt op geometrie die er niet hoort. Een DXF die ineens een extra contour bevat, een STEP die de leverancier niet vertrouwt.
- Productiedocumenten worden handmatig samengesteld. Iemand exporteert per onderdeel een PDF, een DWG, een DXF voor de lasersnijder en een STEP voor de leverancier. Eén vergeten bestand of één verouderde revisie, en de verkeerde versie ligt op de vloer.
De rode draad: een fout die bovenstrooms ontstaat, wordt onderstrooms duurder. Een verkeerde materiaalcode kost engineering tien seconden om recht te zetten. Diezelfde fout die door werkvoorbereiding glipt en bij de inkoop terechtkomt, kost een verkeerde bestelling, een wachttijd op materiaal dat niet binnenkomt, en een telefoontje naar de leverancier dat je liever niet had gepleegd. Daarom wil je fouten zo dicht mogelijk bij de bron afvangen. Hoe verder een fout in de keten doorrolt, hoe meer het kost om hem terug te draaien.
Begin bij de bron: schone modellen met Model Cleaner
Voordat je überhaupt iets exporteert, moet het model zelf op orde zijn. Achtergebleven geometrie is verraderlijk: je ziet het niet altijd in het grafische venster, maar het zit wel in de browser én het komt mee in je export. Surfaces die ooit als hulpgeometrie dienden, schetsen zonder functie, werkvlakken die nergens meer aan vastzitten: het maakt het model zwaar en de uitkomst onvoorspelbaar.
Model Cleaner verwijdert die achtergebleven geometrie en schoont de browser op. Het verschil merk je direct in de praktijk. Een lichter model opent sneller. Een opgeschoonde browser is leesbaar voor de volgende persoon die het bestand openslaat, die hoeft niet eerst tien onderdrukte features en naamloze schetsen weg te denken om te snappen hoe het deel is opgebouwd. En een export struikelt niet meer over geometrie die er niet hoort. Voor werkvoorbereiding betekent dat minder verrassingen op het moment dat je een DXF naar de lasersnijder of een STEP naar de leverancier nodig hebt.
Het mooie is dat het opschonen niet hoeft te wachten tot het bij jou ligt. Draait engineering Model Cleaner voordat ze afronden, dan krijg jij een schoon model binnen. En is er toch iets blijven hangen, dan doe je het zelf in een paar klikken, in plaats van handmatig de hele browser door te spitten op zoek naar wat er niet hoort.
Tip: spreek met engineering af dat Model Cleaner draaien onderdeel is van "klaar". Net als een tekening die je niet vrijgeeft zonder ingevulde titelhoek, geef je een model niet door zonder dat het is opgeschoond. Eén afspraak, structureel minder ruis downstream.
Eén bron van waarheid voor metadata: het iProperty Menu
Materiaal, omschrijving, artikelnummer, leverancier, gewicht: die metadata bepaalt of de rest van de keten kan werken. Het probleem is dat iProperties in Inventor verspreid en inconsistent ingevuld raken. De ene engineer vult het keurig in, de andere laat velden leeg, en een derde typt een materiaalcode die net afwijkt van de standaard. Werkvoorbereiding mag dat vervolgens rechttrekken, onderdeel voor onderdeel.
Het iProperty Menu pakt dit aan met één instelbare datakaart per documenttype. In plaats van dezelfde velden door verschillende tabbladen en dialogen heen te zoeken, krijg je per documenttype dezelfde overzichtelijke kaart. Je ziet in één oogopslag wat is ingevuld en wat ontbreekt. En omdat de kaart instelbaar is, leg je vast welke velden ertoe doen: voor jullie bedrijf, jullie ERP, jullie productie. Een onderdeel, een samenstelling en een tekening hebben elk hun eigen relevante velden; die hoef je niet langer uit je hoofd te kennen, ze staan voor je klaar.
Waarom dit downstream zo veel uitmaakt: de iProperties zijn de bron waar de stuklijst én de productiedocumenten uit putten. Staat het materiaal correct in de iProperty, dan klopt het in de BOM Export naar Excel, dan klopt het op de PDF in de titelhoek, dan klopt het in de bestelling. Eén keer goed aan de bron, en het is overal goed. Eén keer fout aan de bron, en je corrigeert dezelfde fout op vier plekken, en mis je er één, dan loopt er een verkeerde waarde door tot in de productie.
Via het Dashboard kun je dit nog een stap verder trekken en de tools koppelen aan je ERP en andere software. Dan stroomt de metadata niet alleen netjes door Inventor, maar ook naar de systemen erachter, zonder dat iemand artikelnummers overtypt en zonder dat een tikfout zich tussen het model en het ERP nestelt.
Eén datakaart per documenttype, metadata die overal klopt en een model dat schoon de productie in gaat: probeer zelf hoeveel naloopwerk dat scheelt.
Probeer 30 dagen gratisStuklijsten die kloppen: BOM Export naar een vast sjabloon
De stuklijst is het document waar de meeste downstream-fouten samenkomen. Inkoop bestelt erop, de werkplaats werkt ermee, de calculatie rekent ermee. Komt de stuklijst niet één-op-één uit het model maar is hij onderweg met de hand bijgewerkt, dan introduceer je precies daar het risico.
BOM Export haalt de stuklijst rechtstreeks uit Inventor naar Excel, in een vast sjabloon. Dat "vaste sjabloon" is belangrijker dan het klinkt. Het betekent dat elke stuklijst er hetzelfde uitziet: dezelfde kolommen, dezelfde volgorde, dezelfde velden. Inkoop hoeft niet te zoeken waar het artikelnummer staat, want het staat altijd op dezelfde plek. De calculatie kan erop vertrouwen dat de aantallen uit het model komen en niet uit iemands geheugen.
Het verschil met handmatig kopiëren is fundamenteel. Bij overtypen of knippen-en-plakken sluipen er fouten in: een regel overgeslagen, een aantal verkeerd overgenomen, een oude versie hergebruikt omdat niemand meer wist welke de actuele was. Een export uit het model neemt wat er werkelijk in de samenstelling zit. Verandert engineering iets, dan exporteer je opnieuw en heb je de actuele stuklijst, geen detectivewerk om uit te zoeken welke versie nu de juiste is.
Reken eens mee met een voorbeeld. Stel dat je per project tien samenstellingen hebt, en dat het netjes nabewerken van een handmatige stuklijst je gemiddeld een kwartier per stuk kost. Dat is twee en een half uur per project, puur aan stuklijsten kloppend maken. Bij een export naar een vast sjabloon valt het overgrote deel van dat werk weg. Dit is een aanname, geen meting, maar de orde van grootte zal je herkennen, en het loopt op met elk project erbij.
Tip: wijs Excel niet aan als de plek waar je de stuklijst "even" corrigeert. Elke correctie die alleen in Excel staat, is bij de volgende export verdwenen. Klopt er iets niet, fix het in de iProperty of in de samenstelling, dan klopt het bij elke export opnieuw.
Van schoon model naar productie: Batch Publish
Is het model schoon, klopt de metadata en komt de stuklijst uit het model, dan is de laatste stap het uitleveren van de productiedocumenten. Dit is traditioneel het moment waarop handwerk en haast samenkomen: per onderdeel een PDF, een DWG, een DXF voor de lasersnijder, een STEP voor de leverancier. Veel klikken, veel kans op een vergeten bestand of een verouderde revisie die toch meegaat.
Batch Publish doet alle productiedocumenten in één stap: PDF, DWG, DXF en STEP tegelijk, en het werkt samen met Vault. Het bewijs zit in de cijfers die we durven te noemen: 1 klik in plaats van 12 stappen, en 48 PDF's in 6 seconden. Voor werkvoorbereiding betekent dat niet alleen tijdwinst, maar vooral betrouwbaarheid. Eén actie levert een complete, consistente set documenten, geen handmatig samengeraapt mapje waarin de helft een revisie achterloopt en je achteraf moet uitzoeken wat er nu eigenlijk in zit.
Bedrijven als Little Giant Europe, Van Egten, Banzo en Mannen van Staal werken met Thundercad om precies deze stap voorspelbaar te maken: één keer publiceren, en de hele set staat klaar.
Tip: behandel de keten als een volgorde. Eerst Model Cleaner (schoon model), dan het iProperty Menu (kloppende metadata), dan BOM Export (juiste stuklijst), dan Batch Publish (complete documentenset). Elke stap bouwt op de vorige. Schone data is geen los kunstje, het is de volgorde aanhouden.
De keten in één overzicht
Vier tools, vier momenten in de keten. Zo grijpt elke stap in op een fout die anders pas downstream zou opvallen:
| Stap | Tool | Fout die je voorkomt |
|---|
| Schoon model | Model Cleaner | Trage samenstellingen en exports die struikelen op achtergebleven geometrie |
| Kloppende metadata | iProperty Menu | Lege of inconsistente iProperties die fout doorstromen naar BOM, PDF en ERP |
| Juiste stuklijst | BOM Export | Aantallen en artikelnummers die afwijken van het model |
| Complete documentenset | Batch Publish | Vergeten bestanden en verouderde revisies op de vloer |
Het is geen toeval dat de volgorde van boven naar beneden ook de volgorde in je werkproces is. Een stuklijst exporteren uit een model met verkeerde iProperties levert een nette lay-out met foute inhoud. Publiceren vóór je hebt opgeschoond, neemt de rommel mee de productie in. De winst ontstaat juist doordat elke stap op een schone vorige stap rust.
Maak schone data een afspraak, geen toeval
De grootste winst zit niet in één tool, maar in het vastleggen van een werkwijze waarbij schone data de standaard is in plaats van de uitzondering. Spreek af wat "aanleveren" betekent: een opgeschoond model, een ingevulde datakaart, een stuklijst die uit het model komt. Op het moment dat dat de norm is, verschuift jouw rol van controleren-en-corrigeren naar daadwerkelijk voorbereiden.
Dat is het verschil dat schone data naar productie maakt. Niet spectaculair, wel structureel: minder telefoontjes, minder verkeerde bestellingen, minder versies die door elkaar lopen. En een werkdag die gaat over het werk zelf, niet over het rechttrekken van andermans haast. Wil je dieper de losse onderdelen in, kijk dan eens in de kennisbank of bekijk wat Thundercad nog meer in Inventor automatiseert.
Veelgestelde vragen
Wie zou Model Cleaner moeten draaien: engineering of werkvoorbereiding?
Het mooiste is bij de bron: draait engineering Model Cleaner voordat ze afronden, dan krijg jij een schoon model binnen en hoef je niets meer op te ruimen. Maar je kunt het ook zelf doen als er toch iets is blijven hangen. Het kost een paar klikken in plaats van handmatig de browser doorspitten. In de praktijk werkt een afspraak het best: opschonen is onderdeel van "klaar".
Waarom is een vast sjabloon voor de stuklijst zo belangrijk?
Omdat de mensen na jou, inkoop, calculatie, de werkplaats, erop kunnen vertrouwen dat alles altijd op dezelfde plek staat. Geen zoeken naar waar het artikelnummer staat, geen twijfel over de kolomvolgorde. BOM Export haalt de stuklijst rechtstreeks uit Inventor naar Excel in dat vaste sjabloon, dus de inhoud komt uit het model en de vorm is elke keer hetzelfde.
Wat heb ik nodig om Thundercad te gebruiken?
Windows 10 of 11, Autodesk Inventor 2025 of nieuwer en een actief Autodesk-account. Thundercad werkt samen met Autodesk Vault en is via het Dashboard koppelbaar aan je ERP. Je kunt het 30 dagen gratis proberen zonder creditcard. De prijs is daarna EUR 30 per gebruiker per maand, of EUR 300 per gebruiker per jaar (twee maanden gratis), exclusief btw.
Manufacturing engineering sits at the crossroads. Engineering hands off, and you turn that data into something the shop floor, the laser cutter, the saw and purchasing can actually work with. When something goes wrong upstream, it ends up on your desk. And usually only at the moment it really costs time: a bill of materials that does not match the assembly, a model full of leftover geometry, or a PDF with a revision number that has already gone to the supplier.
The heart of the problem is almost never poor craftsmanship. It is messy data. Getting clean data into production is exactly the link where things go wrong: between engineering's Inventor model and the production documents that hit the floor. In this article we walk through the most common downstream errors, and show how Model Cleaner, the iProperty Menu, BOM Export and Batch Publish catch them at the source: in the model, not on the purchase order.
What goes wrong when engineering delivers messy data
Nobody deliberately hands off a messy model. But under time pressure, things get left behind. A sketch that is no longer used. A suppressed feature that was once a variant. A material code typed in by hand that differs by just one character from what purchasing has in the ERP. Each one small on its own. Together they are the reason your workday is full of checking instead of preparing.
A few situations you will probably recognize:
- The bill of materials does not match the model. A part appears twice, or a quantity in the parts list has been overwritten by hand and no longer matches what is actually in the assembly. The shop floor orders too little, or far too much.
- iProperties are half filled in or inconsistent. One part has a tidy description, the other is still called "Part1". The material is sometimes in the physical properties of the model, sometimes only typed into the title block of the drawing, and the two contradict each other.
- Models are heavy and slow. Leftover surfaces, stray sketches and floating work planes make an assembly slow to open and cause the export to trip over geometry that does not belong. A DXF that suddenly contains an extra contour, a STEP the supplier does not trust.
- Production documents are assembled by hand. Someone exports a PDF, a DWG, a DXF for the laser cutter and a STEP for the supplier, one part at a time. One forgotten file or one outdated revision, and the wrong version ends up on the floor.
The common thread: an error that starts upstream gets more expensive downstream. A wrong material code takes engineering ten seconds to correct. That same error slipping through manufacturing engineering and reaching purchasing costs a wrong order, a wait on material that does not arrive, and a phone call to the supplier you would rather not have made. That is why you want to catch errors as close to the source as possible. The further an error rolls down the chain, the more it costs to undo.
Start at the source: clean models with Model Cleaner
Before you export anything at all, the model itself needs to be in order. Leftover geometry is treacherous: you do not always see it in the graphics window, but it is there in the browser and it comes along in your export. Surfaces that once served as construction geometry, sketches with no function, work planes that are no longer attached to anything: they make the model heavy and the result unpredictable.
Model Cleaner removes that leftover geometry and tidies up the browser. You notice the difference straight away in practice. A lighter model opens faster. A cleaned-up browser is readable for the next person who opens the file, who does not first have to mentally set aside ten suppressed features and nameless sketches to understand how the part is built. And an export no longer trips over geometry that does not belong. For manufacturing engineering that means fewer surprises at the moment you need a DXF for the laser cutter or a STEP for the supplier.
The beauty of it is that cleaning up does not have to wait until it lands on your desk. If engineering runs Model Cleaner before they wrap up, you receive a clean model. And if something did get left behind, you do it yourself in a few clicks, instead of manually combing through the entire browser looking for what does not belong.
Tip: agree with engineering that running Model Cleaner is part of "done". Just as you do not release a drawing without a filled-in title block, you do not pass on a model without cleaning it up. One agreement, structurally less noise downstream.
One source of truth for metadata: the iProperty Menu
Material, description, item number, supplier, weight: that metadata determines whether the rest of the chain can work. The problem is that iProperties in Inventor end up scattered and inconsistently filled in. One engineer fills them in neatly, another leaves fields empty, and a third types a material code that deviates slightly from the standard. Manufacturing engineering then gets to straighten that out, part by part.
The iProperty Menu tackles this with one configurable data card per document type. Instead of hunting for the same fields across different tabs and dialogs, you get the same clear card for each document type. You see at a glance what is filled in and what is missing. And because the card is configurable, you define which fields matter: for your company, your ERP, your production. A part, an assembly and a drawing each have their own relevant fields; you no longer need to keep them in your head, they are laid out ready for you.
Why this matters so much downstream: the iProperties are the source the bill of materials and the production documents both draw from. If the material is correct in the iProperty, then it is correct in the BOM Export to Excel, then it is correct on the PDF in the title block, then it is correct on the order. Right once at the source, and it is right everywhere. Wrong once at the source, and you correct the same error in four places, and if you miss one, a wrong value runs all the way through into production.
Through the Dashboard you can take this a step further and connect the tools to your ERP and other software. Then the metadata flows not only neatly through Inventor, but also to the systems behind it, without anyone retyping item numbers and without a typo lodging itself between the model and the ERP.
One data card per document type, metadata that is correct everywhere and a model that goes into production clean: see for yourself how much follow-up work that saves.
Try 30 days freeBills of materials that are correct: BOM Export to a fixed template
The bill of materials is the document where most downstream errors come together. Purchasing orders from it, the shop floor works with it, estimating calculates with it. If the bill of materials does not come one-to-one out of the model but has been updated by hand along the way, that is exactly where you introduce the risk.
BOM Export pulls the bill of materials straight out of Inventor into Excel, in a fixed template. That "fixed template" is more important than it sounds. It means every bill of materials looks the same: the same columns, the same order, the same fields. Purchasing does not have to search for where the item number is, because it is always in the same place. Estimating can rely on the quantities coming from the model and not from someone's memory.
The difference from copying by hand is fundamental. With retyping or cut-and-paste, errors creep in: a line skipped, a quantity copied wrong, an old version reused because nobody remembered which one was current. An export from the model takes what is actually in the assembly. If engineering changes something, you export again and you have the current bill of materials, no detective work to figure out which version is now the right one.
Run the numbers with an example. Suppose you have ten assemblies per project, and that neatly reworking a manual bill of materials costs you on average a quarter of an hour each. That is two and a half hours per project, purely on getting bills of materials right. With an export to a fixed template, the vast majority of that work falls away. This is an assumption, not a measurement, but you will recognize the order of magnitude, and it adds up with every project.
Tip: do not designate Excel as the place where you "quickly" correct the bill of materials. Every correction that lives only in Excel is gone at the next export. If something is not right, fix it in the iProperty or in the assembly, then it is correct at every export again.
From clean model to production: Batch Publish
Once the model is clean, the metadata is correct and the bill of materials comes from the model, the last step is delivering the production documents. This is traditionally the moment where handwork and haste come together: a PDF, a DWG, a DXF for the laser cutter, a STEP for the supplier, one part at a time. Lots of clicks, lots of chance of a forgotten file or an outdated revision tagging along anyway.
Batch Publish produces all production documents in one step: PDF, DWG, DXF and STEP at the same time, and it works together with Vault. The proof is in the numbers we are happy to put on the table: 1 click instead of 12 steps, and 48 PDFs in 6 seconds. For manufacturing engineering that means not just time savings, but above all reliability. One action delivers a complete, consistent set of documents, no hand-assembled folder where half of it lags a revision behind and you have to work out afterward what is actually in it.
Companies like Little Giant Europe, Van Egten, Banzo and Mannen van Staal work with Thundercad to make exactly this step predictable: publish once, and the whole set is ready.
Tip: treat the chain as a sequence. First Model Cleaner (clean model), then the iProperty Menu (correct metadata), then BOM Export (correct bill of materials), then Batch Publish (complete document set). Each step builds on the previous one. Clean data is not a one-off trick, it is keeping to the sequence.
The chain in one overview
Four tools, four moments in the chain. Here is how each step intervenes on an error that would otherwise only surface downstream:
| Step | Tool | Error you prevent |
|---|
| Clean model | Model Cleaner | Slow assemblies and exports that trip over leftover geometry |
| Correct metadata | iProperty Menu | Empty or inconsistent iProperties that flow downstream into BOM, PDF and ERP |
| Correct bill of materials | BOM Export | Quantities and item numbers that deviate from the model |
| Complete document set | Batch Publish | Forgotten files and outdated revisions on the floor |
It is no coincidence that the order from top to bottom is also the order in your workflow. Exporting a bill of materials from a model with wrong iProperties gives you a tidy layout with wrong content. Publishing before you have cleaned up takes the mess along into production. The gain arises precisely because each step rests on a clean previous step.
Make clean data an agreement, not a coincidence
The biggest gain is not in any single tool, but in establishing a way of working where clean data is the standard instead of the exception. Agree on what "handing off" means: a cleaned-up model, a filled-in data card, a bill of materials that comes from the model. The moment that is the norm, your role shifts from checking-and-correcting to actually preparing.
That is the difference clean data into production makes. Not spectacular, but structural: fewer phone calls, fewer wrong orders, fewer versions getting mixed up. And a workday that is about the work itself, not about straightening out someone else's haste. If you want to go deeper into the individual parts, take a look in the knowledge base or see what else Thundercad automates in Inventor.
Frequently asked questions
Who should run Model Cleaner: engineering or manufacturing engineering?
The best place is at the source: if engineering runs Model Cleaner before they wrap up, you receive a clean model and have nothing left to tidy up. But you can also do it yourself if something did get left behind. It takes a few clicks instead of combing through the browser by hand. In practice an agreement works best: cleaning up is part of "done".
Why is a fixed template for the bill of materials so important?
Because the people after you, purchasing, estimating, the shop floor, can rely on everything always being in the same place. No searching for where the item number is, no doubt about the column order. BOM Export pulls the bill of materials straight out of Inventor into Excel in that fixed template, so the content comes from the model and the form is the same every time.
What do I need to use Thundercad?
Windows 10 or 11, Autodesk Inventor 2025 or newer and an active Autodesk account. Thundercad works together with Autodesk Vault and can be connected to your ERP through the Dashboard. You can try it free for 30 days without a credit card. After that the price is EUR 30 per user per month, or EUR 300 per user per year (two months free), excluding VAT.
