iLogic of een kant-en-klare toolbox? Wanneer kies je wat

Je kent het moment wel. Voor de zoveelste keer loop je in Autodesk Inventor hetzelfde rijtje handelingen af: iProperties invullen, tekeningen naar PDF en DWG zetten, een stuklijst naar Excel exporteren. En je denkt: dit moet slimmer kunnen. De voor de hand liggende route is iLogic. Je schrijft een paar regels code, koppelt er een knop aan, klaar. Maar dan groeit het. Het ene script wordt er tien. Een collega vraagt of jij even zijn variant kunt fixen. En op een dag, meestal als jij net op vakantie bent, valt er iets stil en vraagt iemand: wie onderhoudt dit eigenlijk?

Dat is precies het punt waarop veel engineering-afdelingen gaan zoeken naar een iLogic alternatief. Niet omdat iLogic slecht is, het is een krachtig stuk gereedschap, maar omdat zelf bouwen verborgen kosten heeft die pas zichtbaar worden als het script al diep in je proces zit. In dit artikel leggen we de twee routes eerlijk naast elkaar: zelf automatiseren met iLogic en losse scripts versus een onderhouden toolbox als Thundercad. Geen verkooppraatje van "scripten is dom", want dat is het niet. Wel een nuchtere afweging van onderhoud, Inventor-updates, teamafhankelijkheid en samenhang, zodat je voor jouw situatie de juiste keuze maakt.

Wat iLogic wél en niet is

iLogic is de ingebouwde regel-engine van Inventor. Je schrijft regels (in feite VB.NET) die parameters aansturen, features onderdrukken, iProperties uitlezen en wegschrijven, of complete configuraties opbouwen. Voor parametrische, productspecifieke logica is dat goud waard. Denk aan een trappenfabrikant die hoogte, breedte en aantal treden invoert en daar een compleet model uit laat rollen. Of een machinebouwer met een standaard transportband die in lengtes van 1 tot 12 meter geleverd wordt, waarbij het frame, het aantal steunpoten en de aandrijving zich automatisch aanpassen. Dat is iLogic op zijn best: kennis over jóuw product, vastgelegd in regels.

Waar iLogic minder geschikt voor is, is generiek, terugkerend productiewerk dat bij élk project hetzelfde is. Alle tekeningen van een samenstelling in één keer publiceren. Metadata consistent beheren over al je documenttypes heen. Een samenstelling van 200 onderdelen razendsnel openen en daarna weer netjes sluiten. Een stuklijst in een vast Excel-sjabloon krijgen dat inkoop direct kan inlezen. Dat zijn geen productspecifieke regels, maar workflow-handelingen die voor iedere Inventor-gebruiker grotendeels hetzelfde zijn. En juist daar gaat zelfbouw vaak wringen.

Het verschil zit in de aard van het probleem. Productlogica is uniek voor jouw product en hoort bij jou thuis: niemand anders kent jouw configuraties en bouwregels. Workflow-automatisering is generiek; elke Inventor-afdeling worstelt met dezelfde exportdialogen en metadata-velden. Bouw je dat zelf, dan ben je het wiel opnieuw aan het uitvinden, en blijf je het daarna ook zelf onderhouden.

De verborgen kosten van zelf bouwen

Een script schrijven is goedkoop. Een script onderhouden is dat niet. Dat is de kern van de afweging, en de reden dat zoveel afdelingen een iLogic alternatief overwegen zodra hun eerste verzameling scripts is uitgegroeid tot een kluwen die niemand meer in zijn geheel overziet.

Onderhoud kruipt waar het niet gaan kan

Het eerste script werkt perfect. Het tweede ook. Bij het zevende ontdek je dat ze elkaar in de weg zitten: de ene gebruiker draait een aangepaste versie, de andere de originele, en niemand weet meer welke de "echte" is. Iemand wijzigt de mapstructuur op de server en de helft van de export-scripts struikelt over een pad dat niet meer bestaat. Een sjabloon krijgt een extra iProperty-veld en je BOM-script gooit ineens lege kolommen uit. Onderhoud aan zelfgebouwde automatisering is geen project met een einddatum: het is een vaste kostenpost die nooit verdwijnt. En hij hindert juist op de drukste momenten, want fouten vallen pas op als je onder druk een set moet uitleveren.

Updates van Inventor breken dingen

Autodesk brengt elk jaar een nieuwe Inventor-versie uit. Soms verandert de API, soms gedraagt een methode zich net anders, soms verdwijnt een functie. Bij een onderhouden toolbox is dat de zorg van de leverancier: die test tegen de nieuwe versie en levert een update uit. Bij eigen scripts is dat jouw zorg, en meestal op het slechtst denkbare moment. Stel: de hele afdeling is net overgestapt naar de nieuwe versie omdat een klant daar een model in vroeg, en dan blijkt dat je publish-script niet meer draait. Nu zit je met productie die wacht en een collega die tussen zijn eigen deadlines door moet uitzoeken welke API-aanroep is veranderd. Die rekening is lastig vooraf in te schatten, maar hij komt elk jaar terug.

Teamafhankelijkheid: de bus-factor

Dit is de stilste en gevaarlijkste kostenpost. Vaak is er één collega, laten we hem de scriptheld noemen, die alles heeft gebouwd en als enige snapt hoe het in elkaar zit. Zolang hij er is, loopt het. Maar wat als hij twee weken op vakantie is, ziek wordt, of een andere baan vindt? Dan staat er code in productie die niemand durft aan te raken, met variabelennamen die alleen hij begreep en zonder een regel uitleg erbij. We noemen dat de bus-factor: hoeveel mensen mogen er onder de spreekwoordelijke bus komen voordat je proces stilvalt? Bij veel zelfbouw-oplossingen is het antwoord: één. En dat is een risico dat geen enkele engineering-manager bewust zou kiezen als hij het zwart op wit zag staan.

Samenhang ontbreekt

Losse scripts zijn precies dat: los. Elk script heeft zijn eigen knop, zijn eigen logica, zijn eigen aannames over mappen, namen en instellingen. Er is geen gedeelde configuratie, geen consistente interface, geen overkoepelend beheer. Een nieuwe medewerker moet stuk voor stuk leren welk knopje wat doet, welke volgorde klopt en waar de valkuilen zitten, meestal door één keer iets fout te doen. Een toolbox die als samenhangend geheel is ontworpen, biedt één manier van werken over alle tools heen: dezelfde instellingen, dezelfde logica, hetzelfde gedrag. Dat scheelt enorm in inwerktijd en in het soort fouten dat ontstaat doordat de ene tool nét anders werkt dan de andere.

iLogic alternatief in de praktijk: de directe vergelijking

Genoeg theorie. Laten we de twee routes naast elkaar leggen op de punten die er in de dagelijkse praktijk toe doen. Onderstaande tabel vat samen wat je krijgt en wat het je kost: niet alleen in euro's, maar in tijd, risico en gemoedsrust.

De tabel maakt iets duidelijk: het is geen kwestie van goed versus slecht, maar van het juiste gereedschap voor het juiste probleem. iLogic wint op productspecifieke logica. Een toolbox wint op generiek, terugkerend productiewerk waar samenhang en onderhoud zwaarder wegen dan maatwerk. De fout die afdelingen maken is niet dat ze iLogic gebruiken, maar dat ze iLogic óók inzetten voor generiek werk waar het geen voordeel biedt en wel een onderhoudslast oplevert.

Reken eens mee: wat kost zelfbouw echt

Laten we een voorbeeld nemen, duidelijk als aanname gepresenteerd. Stel dat een engineer twee dagen besteedt aan het bouwen van een batch-publish-script dat tekeningen naar PDF, DWG en DXF zet. Dat lijkt eenmalig en daarmee "gratis na de eerste investering". Maar reken eens verder mee. Elke nieuwe Inventor-versie kost zeg een halve dag aanpassen en testen. Een gewijzigde mapstructuur of een nieuw sjabloon kost nog eens een paar uur. Een collega wil een extra formaat erbij: weer een middag. En als de bouwer vertrekt, kost het inwerken van een opvolger, of het script helemaal opnieuw bouwen, al snel meerdere dagen.

Tel je dat over een paar jaar op, dan is "twee dagen" allang geen twee dagen meer. En dat zijn engineering-uren: de duurste en schaarste uren in huis, die je liever aan ontwerp besteedt dan aan het repareren van een PDF-exportscript. Bij een toolbox als Thundercad doe je Batch Publish in één klik in plaats van twaalf stappen, en zet je bijvoorbeeld 48 PDF's in 6 seconden weg, inclusief samenwerking met Autodesk Vault. Geen onderhoud, geen versie-stress, geen afhankelijkheid van één persoon. Of het abonnement het waard is hangt af van je situatie, maar de rekensom valt vaak heel anders uit dan het onderbuikgevoel dat "zelf bouwen gratis is".

Wat een onderhouden toolbox concreet dekt

Om het tastbaar te maken: een toolbox neemt juist die generieke, terugkerende handelingen uit handen waar zelfbouw het meeste onderhoud vraagt. Bij Thundercad gaat het onder meer om:

• iProperty Menu: metadata en iProperties beheren via één instelbare datakaart per documenttype, in plaats van per script of per hand.
• Batch Publish: alle productiedocumenten in één stap: PDF, DWG, DXF en STEP, werkend met Vault.
• BOM Export: stuklijsten naar Excel in een vast sjabloon, zonder dat je de export-logica zelf hoeft te onderhouden.
• Batch Open & Close: bestanden in samenstellingen snel openen en weer netjes sluiten.
• Quick Save / Load: werk parkeren en het exact terughalen zoals je het achterliet.
• Model Cleaner: achtergebleven geometrie verwijderen en de browser opschonen.
• Sheet Buttons: bladformaat omhoog of omlaag zetten en roteren.
• Dashboard: tools activeren en beheren, en koppelen aan je ERP of andere software.

Dat laatste, het Dashboard met koppeling aan ERP, laat zien waar de twee werelden elkaar raken. Een toolbox sluit de deur niet voor maatwerk; hij geeft je een onderhouden basis waarop je je eigen integraties kunt aanhaken. Je houdt dus de vrijheid om met iLogic je echte productlogica te bouwen, terwijl het generieke werk eromheen is afgedekt. Bedrijven als Little Giant Europe, Van Egten, Banzo en Mannen van Staal werken er al mee om precies dat repetitieve werk uit hun engineeringproces te halen.

Op de roadmap staan trouwens nog meer tools die nu typisch met zelfbouw worden opgelost: Batch Flat Pattern, Find Item, een Drawing Checker/Cleaner en een Drawing Updater. Nog niet beschikbaar, maar ze laten de richting zien: steeds meer generiek handwerk verschuift naar een onderhouden geheel.

Wanneer kies je dan wat?

De eerlijke conclusie is geen "altijd dit" of "altijd dat". Het is een afweging, en die valt per type werk anders uit. Hieronder een vuistregel die je direct kunt toepassen op je eigen scriptverzameling.

Kies voor iLogic / zelf bouwen als:

• het gaat om productspecifieke logica die uniek is voor jouw product: configuratoren, parametrische families, bouwregels die niemand anders kent.
• je in huis structureel iemand hebt die dit kan bouwen én onderhouden, en je die afhankelijkheid bewust accepteert en documenteert.
• het probleem zo specifiek is dat geen enkel bestaand product het dekt en maatwerk echt een onderscheidend voordeel oplevert.

Kies voor een onderhouden toolbox als:

• het gaat om generiek productiewerk dat bij elk project hetzelfde is: publiceren, exporteren, metadata beheren, samenstellingen openen en sluiten.
• je onderhoud, Inventor-updates en teamafhankelijkheid liever niet zelf draagt.
• je samenhang en een consistente werkwijze over je hele team belangrijk vindt.
• je wilt dat een nieuwe collega snel productief is zonder dat iemand eerst de valkuilen moet komen uitleggen.

In de praktijk kiezen veel afdelingen voor beide: iLogic voor het echte maatwerk dat hun product onderscheidt, en een toolbox voor alles eromheen. Zo besteed je je schaarse engineering-uren aan waar ze het verschil maken, aan het ontwerp dat je klant koopt, en niet aan een PDF-exportscript dat bij elke update kan breken. Het mooie is dat je dat niet vooraf hoeft te bewijzen op een spreadsheet: je test het op je eigen projecten voordat je iets aan je proces verandert.

Veelgestelde vragen

Is een toolbox een vervanging voor iLogic?

Nee, en dat is ook niet de bedoeling. iLogic is sterk in productspecifieke logica zoals configuratoren en parametrische families; een toolbox als Thundercad dekt generiek, terugkerend productiewerk zoals publiceren, exporteren en metadata beheren. Veel afdelingen gebruiken ze naast elkaar: iLogic voor het maatwerk, de toolbox voor de dagelijkse workflow eromheen.

Wat gebeurt er met mijn bestaande iLogic-scripts?

Die kun je gewoon blijven gebruiken. Een toolbox vervangt niet je productlogica, maar neemt de generieke handelingen over waar je nu losse scripts voor onderhoudt. Je kunt dus geleidelijk overstappen: begin met de scripts die het meeste onderhoud kosten of het grootste bus-factor-risico vormen, en laat die als eerste los. Je hoeft niets in één keer om te bouwen.

Wat als ik wil koppelen aan onze eigen software of ERP?

Dat kan via het Dashboard, waarmee je tools beheert en koppelt aan ERP en andere software. Zo houd je een onderhouden basis voor het generieke werk en haak je je eigen integraties en maatwerk daarop aan. Wil je het zelf ervaren? Je kunt Thundercad 30 dagen gratis proberen zonder creditcard, op je eigen Inventor-omgeving en projecten.