Op het titelblok staat revisie B, de bestandsnaam eindigt op "revC-def", en in de mail naar de klant heet hetzelfde bestand "laatste versie". Drie bronnen, drie antwoorden op één simpele vraag: welke revisie is dit eigenlijk? Wie in de werkplaats of bij inkoop het verkeerde antwoord kiest, zaagt, bestelt of monteert op verouderde informatie.
Dat is geen kwestie van slordige collega's, maar van ontbrekende afspraken. Goed revisiebeheer in Inventor draait om drie vragen: wat ís een revisie, waar leg je hem vast, en hoe hoort de rest van het bedrijf dat er iets veranderd is. In dit artikel zetten we een minimale, houdbare werkwijze neer die een kleine afdeling ook echt volhoudt. Gereedschap zoals het iProperty Panel uit de toolbox Thundercad maakt het bijhouden makkelijker, maar de afspraken komen eerst.
Wat een revisie is, en wat vooral niet
Niet elke wijziging is een revisie. Zolang een onderdeel nog in ontwerp is, schuift er van alles: maten, materiaal, complete features. Dat zijn gewoon werkversies, en die hoeven geen administratie. Een revisie begint pas te tellen na de eerste vrijgave: het moment waarop anderen, productie, inkoop, de klant, op het document zijn gaan bouwen.
Een bruikbare definitie: een revisie is een vrijgegeven wijziging van een al vrijgegeven document. Alles daarvoor is voorwerk. Wie ook ontwerpiteraties een revisieletter geeft, zit voor de eerste bestelling al op revisie F en heeft de nummering uitgehold voordat ze iets betekent.
Even belangrijk is de grens aan de andere kant: niet elke wijziging aan een vrijgegeven onderdeel mag een revisie heten. De klassieke vuistregel is uitwisselbaarheid. Past en functioneert het gewijzigde onderdeel overal waar het oude zat, dan is het een nieuwe revisie van hetzelfde nummer. Is het niet meer uitwisselbaar, dan hoort er een nieuw artikelnummer bij, geen revisieophoging. Die ene regel voorkomt de beruchte situatie dat magazijnvoorraad met dezelfde code in twee niet-uitwisselbare smaken bestaat.
Waar je de revisie vastlegt: één bron, de rest volgt
De chaos uit de intro ontstaat doordat de revisie op meerdere plekken los van elkaar wordt bijgehouden. De oplossing is niet harder opletten, maar één bron aanwijzen waar alle andere plekken uit putten:
| Plek | Rol | Valkuil |
|---|---|---|
| Revisie-iProperty | De bron: hier wordt de revisie bijgewerkt | Veld vergeten bij vrijgave |
| Titelblok | Toont de iProperty automatisch | Handmatig overtypen naast de bron |
| Revisietabel op de tekening | Geschiedenis: wat, waarom, wanneer | Leeg laten of dichttimmeren met vakjargon |
| Bestandsnaam | Geen: naam blijft gelijk over revisies | "revC-def" die de bron tegenspreekt |
De revisie-iProperty is de logische bron: elke tekening kan hem tonen, elk exportprofiel kan hem meenemen en elke zoekopdracht kan erop filteren. Het titelblok leest dat veld uit en is daarmee nooit meer in tegenspraak met het model. De bestandsnaam blijft door de jaren heen gelijk; een revisie in de naam veroudert gegarandeerd en breekt bovendien verwijzingen tussen bestanden.
Het zwakke punt in dit rijtje is het mensenwerk: het veld moet wél worden bijgewerkt. Daar helpt het iProperty Panel van Thundercad: een instelbare datakaart per documenttype die de velden toont die er bij jullie toe doen. Staat de revisie daar prominent tussen, dan is hij bij elke vrijgave één klik en dus moeilijk te vergeten.
Samenstellingen versus onderdelen
Bij een los onderdeel is de vraag nog overzichtelijk. Spannend wordt het bij samenstellingen: moet de hoofdsamenstelling een nieuwe revisie krijgen omdat ergens drie niveaus diep een plaatje is gewijzigd? Wie hier geen afspraak over maakt, krijgt óf een samenstelling die bij elk wissewasje ophoogt, óf een samenstelling die al jaren op revisie A staat terwijl eronder alles is veranderd.
Een houdbare middenweg in drie regels:
- Een onderdeel dat wijzigt, krijgt zijn eigen nieuwe revisie. Altijd.
- De samenstelling hoogt alleen op als er op dat niveau iets verandert: de stuklijst (aantallen, posities, vervangen onderdelen), de montage of de maatvoering op de samenstellingstekening.
- Een onderliggende wijziging die uitwisselbaar is, laat de samenstelling dus met rust; de nieuwe onderdeelrevisie is via het onderdeel zelf te herleiden.
Zo blijft de revisie van elke laag betekenisvol: hij zegt iets over dát document, niet over alles eronder. En productie leert dat een ongewijzigde samenstellingsrevisie niet betekent dat er nergens iets veranderd is, maar dat monteren volgens dezelfde tekening kan.
Revisies bijhouden staat of valt met iProperties die kloppen. Met het iProperty Panel werk je ze per documenttype gestructureerd bij, en met Batch Publish zet je na een revisiewissel alle geraakte tekeningen in één run opnieuw naar PDF of STEP.
Probeer 30 dagen gratisEen revisiewissel communiceren naar productie en inkoop
Een revisie die alleen in het CAD-systeem bestaat, bestaat niet. De werkplaats zaagt van een print of een PDF, inkoop bestelt van een STEP of een tekening bij de leverancier. Een revisiewissel is dus pas af als drie dingen geregeld zijn: de nieuwe informatie is verspreid, de oude is weggehaald, en de betrokkenen weten wat ze met lopend werk en voorraad moeten.
Dat laatste vergt één zin discipline per revisie. Schrijf in de revisietabel niet alleen "gat verplaatst", maar ook wat de ontvanger ermee moet: oude voorraad opmaken mag, of juist blokkeren; lopende bestelling aanpassen of laten lopen. Die ene zin scheelt drie telefoontjes en één verkeerde beslissing.
Het weghalen van oude exports is de stap die het vaakst wordt overgeslagen, en precies de stap waarmee revisie A maanden later alsnog in de werkplaats opduikt. Hoe je die schoonmaak organiseert, van exportmap tot mailbijlagen, lees je in Oude exports opruimen, zodat productie nooit met revisie A werkt.
De minimale werkwijze op een rij
Meer dan dit hoeft het niet te zijn:
- Revisies beginnen pas na de eerste vrijgave; daarvoor bestaan alleen werkversies.
- De revisie-iProperty is de enige bron; titelblok en revisietabel volgen daaruit, de bestandsnaam blijft leeg van revisies.
- Bij elke wijziging eerst de uitwisselbaarheidsvraag: nieuwe revisie of nieuw nummer.
- Onderdelen revideren zelfstandig; samenstellingen alleen bij wijzigingen op hun eigen niveau.
- Elke revisie krijgt één regel in de revisietabel: wat, waarom, en wat productie en inkoop ermee moeten.
- Na vrijgave: nieuwe exports verspreiden, oude weghalen.
Wie daarnaast wil vastleggen wélke documenten wanneer vrijgegeven zijn en wie dat mag doen, komt uit bij statusbeheer. Dat is een eigen onderwerp, met eigen valkuilen; we schreven er eerder over in Lifecycles en statussen in Vault: pragmatisch, niet meer dan nodig.
Veelgestelde vragen
Moet elke kleine wijziging een nieuwe revisie worden?
Na vrijgave wel, hoe klein ook: een wijziging zonder revisieophoging is onzichtbaar voor iedereen die met het document werkt. Vóór de eerste vrijgave juist niet; dan is het gewoon ontwerpwerk. De grens ligt dus niet bij de grootte van de wijziging, maar bij de vraag of anderen al op het document bouwen.
Waarom hoort de revisie niet in de bestandsnaam?
Omdat de naam dan gegarandeerd een keer achterloopt op de inhoud, en omdat hernoemen de verwijzingen tussen onderdelen, samenstellingen en tekeningen breekt. Het bestand houdt één naam; de revisie leeft in de iProperty en is daarmee zichtbaar op het titelblok, in exports en in zoekopdrachten. Voor exportbestanden zoals PDF's ligt dat anders, want die zijn wegwerpkopieën per revisie.
Kan Thundercad revisies automatisch bijhouden?
Het beoordelen en ophogen blijft mensenwerk, en dat is maar goed ook. De toolbox maakt het bijhouden wel sneller en zichtbaarder: de revisie staat als vast veld op de datakaart van het iProperty Panel, en na een wissel vernieuw je alle geraakte exports in één run. Uitproberen kan een maand gratis via de downloadpagina.