Je opent een samenstelling van een collega en je ziet het meteen: het ene onderdeel heeft een keurig tekeningnummer in het iProperty-veld, het andere heeft de bestandsnaam in het titelveld, en bij een derde staat de materiaalsoort half ingevuld als "S235" en half als "staal S235JR". Dat is geen detail. Dat is het begin van een dure keten van fouten. iProperties beheren in Inventor klinkt als administratie, maar in de praktijk bepaalt het of je stuklijst klopt, of je PDF's de juiste titel krijgen en of je ERP-koppeling überhaupt werkt.
In dit artikel lees je waarom inconsistente metadata downstream zoveel pijn doet, hoe je iProperties verstandig structureert, en hoe je dat structureren afdwingt in plaats van hopen dat iedereen het zelf goed doet.
Waarom iProperties beheren in Inventor meer is dan netjes invullen
iProperties zijn de metadata van je Inventor-bestanden: tekeningnummer, omschrijving, materiaal, gewicht, projectnummer, opdrachtgever, revisie, status. Inventor kent standaardvelden (zoals Title, Part Number, Description, Material) en custom properties die je zelf toevoegt. Op zich logisch. Het probleem zit niet in de velden, maar in wie ze hoe invult.
Want die iProperties blijven niet in het modelbestand zitten. Ze stromen door naar overal:
- Tekeningen trekken via tekstvelden automatisch het tekeningnummer, de omschrijving en het materiaal in het titelblok.
- Stuklijsten (BOM) lezen Part Number en Description rechtstreeks uit de iProperties van elk onderdeel.
- Productiedocumenten zoals PDF, DWG, DXF en STEP krijgen vaak een bestandsnaam of titel die op iProperties is gebaseerd.
- ERP en PDM zoals Autodesk Vault gebruiken die velden om bestanden te koppelen, te zoeken en door te zetten naar inkoop en planning.
Eén veld dat niet klopt, vermenigvuldigt zich dus door de hele keten. Een verkeerd materiaal in de iProperty van een plaatdeel betekent een verkeerd materiaal in het titelblok, een verkeerde regel in de stuklijst, en een verkeerde bestelling bij de leverancier. Niet omdat iemand slordig was bij het bestellen, maar omdat de bron al fout was.
Wat inconsistente metadata downstream kost
Het sluipt erin. Bij een handjevol onderdelen merk je het niet. Bij een machine met 400 componenten en drie engineers die ieder hun eigen gewoonte hebben, wordt het een tijdbom. Een paar herkenbare situaties:
De stuklijst die niet optelt
Werkvoorbereiding exporteert de BOM naar Excel om te bestellen. Twee identieke boutjes staan als twee verschillende regels omdat de ene "M8x30 DIN933" heet en de andere "Bout M8 x 30". Inventor ziet ze als verschillende artikelen. Je bestelt dubbel, of je mist er één. Iemand moet de lijst handmatig nalopen en ontdubbelen, elke keer opnieuw.
Het titelblok dat niet vult
De tekening is af, maar het materiaalveld in het titelblok blijft leeg omdat de iProperty Material niet was ingevuld op het model. De engineer typt het er met de hand bij. Snel even. Tot er een revisie komt, het materiaal wijzigt op het model, en de handmatige tekst in de tekening blijft staan. Nu spreken model en tekening elkaar tegen.
De Vault-zoekopdracht die niets vindt
Een collega zoekt in Vault op projectnummer, maar de helft van de bestanden komt niet boven omdat het projectnummer in een ander custom veld stond, of helemaal niet was ingevuld. Het bestand bestaat, maar is onvindbaar. Iemand gaat handmatig mappen doorspitten.
Reken eens mee. Stel dat een engineer per dag tien keer een iProperty-veld handmatig corrigeert of nakijkt, en dat elke correctie inclusief context-switch een minuut kost. Dat is bijna een uur per week per persoon, alleen aan metadata-herstelwerk. Bij vijf engineers is dat een halve werkdag per week die je kwijt bent aan iets wat aan de bron voorkomen had kunnen worden.
Het venijnige is dat dit werk onzichtbaar is. Het staat op geen enkele urenstaat als "metadata opschonen". Het verdwijnt in de marges van elke tekening, elke export, elke bestelling. En het ondermijnt het vertrouwen: als de stuklijst een keer fout was, gaat iedereen hem voortaan dubbelchecken. Dan ben je de winst van automatisering kwijt voordat je hem hebt.
Hoe je iProperties beheren in Inventor structureert
Voordat je iets gaat automatiseren, moet je weten wát je wilt vastleggen. Goede metadata begint bij afspraken, niet bij tools. Een paar principes die in machinebouw en staalconstructie goed werken:
1. Bepaal welke velden verplicht zijn per documenttype
Een onderdeel (.ipt) heeft andere relevante velden dan een samenstelling (.iam) of een tekening (.idw/.dwg). Voor een plaatdeel wil je materiaal, dikte en tekeningnummer; voor een samenstelling wil je projectnummer, opdrachtgever en revisie. Maak per documenttype een vaste set: wat is verplicht, wat is optioneel, en wat moet je gewoon niet invullen omdat het automatisch wordt afgeleid.
2. Spreek één schrijfwijze af en leg die vast
"S235JR" of "staal S235JR"? "M8x30" of "M8 x 30"? Het maakt niet uit welke je kiest, als iedereen maar dezelfde kiest. Leg de notatie vast in een korte standaard en zorg dat nieuwe medewerkers die meekrijgen. Hoe minder vrije tekstvelden waar mensen zelf iets kunnen verzinnen, hoe consistenter je data.
3. Vul aan de bron in, niet aan het eind
Metadata invullen op het moment dat je het model maakt is goedkoop. Metadata achteraf repareren over honderden bestanden is duur. Maak het invullen van iProperties onderdeel van je standaard werkwijze, niet een aparte taak die je "later nog wel even doet".
4. Gebruik velden die downstream ook echt worden gelezen
Het heeft geen zin om een custom property "Klantreferentie" te bedenken als je tekening-titelblok, je BOM-export en je ERP daar niets mee doen. Stem je veldenset af op wat de keten erna nodig heeft. Begin bij de output (stuklijst, titelblok, ERP) en werk terug naar welke iProperties je daarvoor moet vastleggen.
Tot zover de theorie. Het lastige is niet het bedénken van deze structuur, maar het afdwingen ervan. Want zodra het van handmatige discipline afhangt, zakt het in. Mensen hebben haast, vergeten een veld, of typen het net even anders. Daar komt standaardisatie via een tool om de hoek kijken.
Stop met iProperties handmatig nalopen en corrigeren. Met het iProperty Menu van Thundercad vul je metadata gestructureerd in via één instelbare datakaart per documenttype, zodat de bron altijd klopt.
Probeer 30 dagen gratisStandaardiseren met datakaarten: het iProperty Menu
Het standaard iProperties-venster in Inventor toont alle velden door elkaar, ongeacht of je er iets mee doet. Het maakt geen onderscheid tussen "dit moet je invullen" en "dit gebeurt automatisch". En het dwingt niets af. Iedereen kan overal van alles intypen.
Het iProperty Menu van Thundercad draait dat om. In plaats van een rommelig standaardvenster werk je met één instelbare datakaart per documenttype. Een datakaart is in feite een formulier dat jij vooraf inricht: welke velden zie je, in welke volgorde, met welke labels, en welke zijn verplicht.
Concreet betekent dat:
- Eén kaart per documenttype. Voor een onderdeel zie je de velden die voor een onderdeel relevant zijn, voor een samenstelling de velden die daarvoor gelden. Geen ruis, geen twijfel over wat waar hoort.
- Vaste structuur voor iedereen. Of een junior of een senior het bestand opent, ze zien dezelfde kaart met dezelfde velden. De afspraak die je hierboven hebt gemaakt, staat nu in de tool in plaats van in iemands hoofd.
- Invullen wordt sturen in plaats van zelf verzinnen. Doordat de kaart precies aangeeft welk veld waarvoor is, vult iedereen op dezelfde plek hetzelfde in. Dat is precies wat je nodig hebt om die schrijfwijze-afspraken ook echt vast te houden.
Het effect zit hem in de bron. Als de iProperties al gestructureerd en consistent het model in gaan, klopt alles wat erna komt. Het titelblok vult zich vanzelf goed. De BOM Export naar Excel levert een lijst zonder dubbele regels die je niet meer hoeft te ontdubbelen. Batch Publish zet je PDF's, DWG's en STEP-bestanden weg met de juiste namen. En je Vault- of ERP-koppeling krijgt schone, vindbare data binnen.
Begin klein. Richt eerst de datakaart in voor je meest voorkomende documenttype: meestal het onderdeel. Bepaal welke velden verplicht zijn, leg de schrijfwijze vast, en rol het uit. Als dat loopt, breid je uit naar samenstellingen en tekeningen. Eén goede kaart die iedereen gebruikt is meer waard dan vijf kaarten die niemand begrijpt.
iProperties beheren in Inventor: van losse discipline naar afgedwongen standaard
De winst van iProperties beheren in Inventor zit niet in mooiere velden, maar in een keten die je kunt vertrouwen. Als de metadata aan de bron klopt, hoef je stuklijsten niet meer dubbel te checken, hoef je titelblokken niet meer handmatig bij te werken, en kun je tools als Batch Publish en BOM Export echt op de automaat zetten. Dat is het verschil tussen "we hebben een tool die het zou moeten doen" en "het gebeurt gewoon, elke keer, goed".
Het iProperty Menu maakt van een afspraak die in de hoofden van je engineers zit een structuur die in de software vastligt. En daar zit de echte tijdwinst: niet in het sneller invullen, maar in het niet meer hoeven corrigeren. Bedrijven als Little Giant Europe, Van Egten, Banzo en Mannen van Staal werken al met Thundercad om dit soort repetitief werk uit hun engineeringproces te halen.
Wil je zien hoe het bij jouw documenttypes uitpakt? Je kunt Thundercad 30 dagen gratis proberen, zonder creditcard. Meer achtergrond over de losse functies vind je in de kennisbank.
Veelgestelde vragen
Werkt het iProperty Menu samen met Autodesk Vault?
Ja. Thundercad werkt samen met Autodesk Vault, en het Dashboard is koppelbaar aan je ERP en andere software. Doordat je iProperties via de datakaart consistent invult, komt er ook schone, vindbare data in Vault en je ERP terecht.
Moet ik al mijn bestaande bestanden eerst opschonen?
Nee, je hoeft niet eerst alles te repareren voordat je begint. Het iProperty Menu zorgt ervoor dat nieuwe en bewerkte bestanden vanaf nu gestructureerd worden ingevuld. Bestaande bestanden pak je gaandeweg mee wanneer je ze toch onder handen hebt. Wel handig om te weten: Thundercad vereist Windows 10/11 en Autodesk Inventor 2025 of nieuwer met een actief Autodesk-account.
Wat kost Thundercad?
Thundercad kost EUR 30 per gebruiker per maand of EUR 300 per gebruiker per jaar (dat zijn twee maanden gratis), exclusief btw, per seat voor 1 tot 99 gebruikers. Je kunt het eerst 30 dagen gratis proberen, zonder creditcard.