iLogic oder eine fertige Toolbox? Wann wählen Sie was

Sie kennen den Moment. Zum x-ten Mal arbeiten Sie in Autodesk Inventor dieselbe Reihe von Handgriffen ab: iProperties ausfüllen, Zeichnungen nach PDF und DWG schreiben, eine Stückliste nach Excel exportieren. Und Sie denken: Das muss doch schlauer gehen. Der naheliegende Weg ist iLogic. Sie schreiben ein paar Zeilen Code, hängen eine Schaltfläche daran, fertig. Doch dann wächst es. Aus einem Skript werden fünf, aus fünf werden zehn. Ein Kollege fragt, ob Sie mal eben seine Variante reparieren können. Und eines Tages, meist genau dann, wenn Sie gerade im Urlaub sind, bleibt etwas stehen und jemand fragt: Wer pflegt das hier eigentlich?

Genau an diesem Punkt beginnen viele Konstruktionsabteilungen, nach einer iLogic Alternative zu suchen. Nicht weil iLogic schlecht wäre, es ist ein mächtiges Werkzeug, sondern weil der Eigenbau versteckte Kosten hat, die erst sichtbar werden, wenn das Skript längst tief im Prozess steckt. In diesem Beitrag legen wir die beiden Wege ehrlich nebeneinander: selbst automatisieren mit iLogic und einzelnen Skripten gegenüber einer gepflegten Toolbox wie Thundercad. Kein Verkaufsgerede von der Sorte "Skripten ist dumm", denn das stimmt nicht. Stattdessen eine nüchterne Abwägung von Wartung, Inventor-Updates, Teamabhängigkeit und Zusammenhang, damit Sie für Ihre Situation die richtige Wahl treffen. Beide Wege haben ihre Berechtigung, nur eben nicht für dieselbe Art von Arbeit.

Was iLogic ist und was nicht

iLogic ist die eingebaute Regel-Engine von Inventor. Sie schreiben Regeln (im Kern VB.NET), die Parameter steuern, Elemente unterdrücken, iProperties auslesen und zurückschreiben oder komplette Konfigurationen aufbauen. Für parametrische, produktspezifische Logik ist das Gold wert. Denken Sie an einen Treppenhersteller, der Höhe, Breite und Anzahl der Stufen eingibt und daraus ein komplettes Modell herausrollen lässt. Oder an einen Maschinenbauer mit einem Standardförderband, das in Längen von 1 bis 12 Metern geliefert wird und bei dem sich Rahmen, Anzahl der Stützfüße und Antrieb automatisch anpassen. Das ist iLogic in Bestform: Wissen über Ihr eigenes Produkt, festgehalten in Regeln. Solche Regeln bilden ab, wie Ihr Produkt konstruiert wird, und dafür gibt es kein fertiges Werkzeug von der Stange.

Weniger geeignet ist iLogic für generische, wiederkehrende Produktionsarbeit, die in jedem Projekt gleich abläuft. Alle Zeichnungen einer Baugruppe auf einmal veröffentlichen. Metadaten über sämtliche Dokumenttypen hinweg konsistent verwalten. Eine Baugruppe mit 200 Bauteilen blitzschnell öffnen und danach sauber wieder schließen. Eine Stückliste in eine feste Excel-Vorlage bringen, die der Einkauf direkt einlesen kann. Das sind keine produktspezifischen Regeln, sondern Handgriffe im Arbeitsablauf, die für alle Inventor-Anwender weitgehend gleich aussehen. Jede Abteilung löst dieselben Aufgaben, nur jede für sich und jede ein wenig anders. Und genau dort beginnt der Eigenbau zu klemmen.

Der Unterschied liegt in der Art des Problems. Produktlogik ist einzigartig für Ihr Produkt und gehört zu Ihnen: Niemand sonst kennt Ihre Konfigurationen und Konstruktionsregeln. Die Automatisierung von Arbeitsabläufen ist generisch, denn jede Inventor-Abteilung kämpft mit denselben Exportdialogen und Metadatenfeldern. Bauen Sie das selbst, erfinden Sie das Rad neu und pflegen es anschließend auch selbst weiter.

Die versteckten Kosten des Eigenbaus

Ein Skript zu schreiben ist billig. Ein Skript zu pflegen ist es nicht. Das ist der Kern der Abwägung und der Grund, warum so viele Abteilungen über eine iLogic Alternative nachdenken, sobald ihre erste Skriptsammlung zu einem Knäuel angewachsen ist, das niemand mehr im Ganzen überblickt.

Wartung frisst sich in jede Ecke

Das erste Skript läuft perfekt. Das zweite auch. Beim siebten stellen Sie fest, dass sie sich gegenseitig im Weg stehen: Der eine Anwender fährt eine angepasste Fassung, der andere die ursprüngliche, und niemand weiß mehr, welche die "echte" ist. Jemand ändert die Ordnerstruktur auf dem Server, und die Hälfte der Exportskripte stolpert über einen Pfad, den es gar nicht mehr gibt. Eine Vorlage bekommt ein zusätzliches iProperty-Feld, und Ihr BOM-Skript wirft plötzlich leere Spalten aus. Die Wartung selbst gebauter Automatisierung ist kein Projekt mit Enddatum, sondern ein fester Kostenposten, der nie verschwindet. Und er stört ausgerechnet in den vollsten Wochen, denn Fehler fallen erst auf, wenn Sie unter Druck einen Satz ausliefern müssen. Rechnen Sie diese Stunden deshalb nicht als einmaliges Projekt, sondern als dauerhafte Belastung Ihres Teams.

Inventor-Updates machen Dinge kaputt

Autodesk bringt jedes Jahr eine neue Inventor-Version heraus. Mal ändert sich die API, mal verhält sich eine Methode etwas anders, mal fällt eine Funktion ganz weg. Bei einer gepflegten Toolbox ist das die Sorge des Anbieters: Er testet gegen die neue Version und liefert ein Update aus. Bei eigenen Skripten ist es Ihre Sorge, und meist zum denkbar schlechtesten Zeitpunkt. Angenommen, die ganze Abteilung ist gerade auf die neue Version umgestiegen, weil ein Kunde ein Modell darin verlangt hat, und dann läuft Ihr Publish-Skript nicht mehr. Jetzt haben Sie eine wartende Fertigung und einen Kollegen, der zwischen seinen eigenen Fristen herausfinden muss, welcher API-Aufruf sich geändert hat. Diese Rechnung lässt sich vorab schwer abschätzen, aber sie kommt jedes Jahr zurück. Planen Sie den Aufwand deshalb fest in jede Umstellung auf eine neue Version ein, statt darauf zu hoffen, dass diesmal alles auf Anhieb läuft.

Teamabhängigkeit: der Bus-Faktor

Das ist der leiseste und gefährlichste Kostenposten. Oft gibt es einen Kollegen, nennen wir ihn den Skripthelden, der alles gebaut hat und als Einziger versteht, wie es zusammenhängt. Solange er da ist, läuft es. Aber was, wenn er zwei Wochen im Urlaub ist, krank wird oder eine andere Stelle findet? Dann steht Code im Einsatz, den niemand anzufassen wagt, mit Variablennamen, die nur er verstanden hat, und ohne eine einzige Zeile Erklärung. Wir nennen das den Bus-Faktor: Wie viele Menschen dürfen unter den sprichwörtlichen Bus geraten, bevor Ihr Prozess stillsteht? Bei vielen Eigenbaulösungen lautet die Antwort: einer. Und das ist ein Risiko, das kein Leiter einer Konstruktionsabteilung bewusst wählen würde, wenn er es schwarz auf weiß vor sich sähe. Eine saubere Dokumentation senkt die Gefahr, verschwindet aber erfahrungsgemäß als Erstes, sobald es eilig wird.

Der Zusammenhang fehlt

Einzelne Skripte sind genau das: einzeln. Jedes Skript hat seine eigene Schaltfläche, seine eigene Logik, seine eigenen Annahmen über Ordner, Namen und Einstellungen. Es gibt keine gemeinsame Konfiguration, keine einheitliche Oberfläche, keine übergreifende Verwaltung. Ein neuer Mitarbeiter muss Stück für Stück lernen, welche Schaltfläche was tut, welche Reihenfolge stimmt und wo die Fallstricke liegen, meist indem er einmal etwas falsch macht. Eine Toolbox, die als zusammenhängendes Ganzes entworfen wurde, bietet eine einzige Arbeitsweise über alle Werkzeuge hinweg: gleiche Einstellungen, gleiche Logik, gleiches Verhalten. Das spart enorm viel Einarbeitungszeit und verhindert jene Art von Fehlern, die entsteht, weil ein Werkzeug eben doch anders funktioniert als das nächste. Diese Einheitlichkeit wirkt unscheinbar, entscheidet aber darüber, wie schnell ein Team eine neue Arbeitsweise wirklich übernimmt.

iLogic Alternative in der Praxis: der direkte Vergleich

Genug Theorie. Legen wir die beiden Wege an den Punkten nebeneinander, auf die es im Alltag ankommt. Die folgende Tabelle fasst zusammen, was Sie bekommen und was es Sie kostet: nicht nur an Geld, sondern an Zeit, Risiko und Ruhe im Kopf. Lesen Sie die Zeilen am besten als Fragen an Ihre eigene Abteilung.

Die Tabelle macht eines deutlich: Es ist keine Frage von gut gegen schlecht, sondern des richtigen Werkzeugs für das richtige Problem. iLogic gewinnt bei produktspezifischer Logik. Eine Toolbox gewinnt bei generischer, wiederkehrender Produktionsarbeit, bei der Zusammenhang und Wartung schwerer wiegen als Maßarbeit. Der Fehler, den Abteilungen machen, ist nicht der Einsatz von iLogic, sondern dass sie iLogic auch für generische Arbeit einsetzen, wo es keinen Vorteil bringt, wohl aber eine Wartungslast erzeugt.

Rechnen Sie mit: was der Eigenbau wirklich kostet

Nehmen wir ein Beispiel, klar als Annahme gekennzeichnet. Angenommen, ein Konstrukteur wendet zwei Tage auf, um ein Batch-Publish-Skript zu bauen, das Zeichnungen nach PDF, DWG und DXF schreibt. Das wirkt einmalig und damit "gratis nach der ersten Investition". Doch rechnen Sie ruhig weiter mit. Jede neue Inventor-Version kostet, sagen wir, einen halben Tag Anpassen und Testen. Eine geänderte Ordnerstruktur oder eine neue Vorlage kostet noch einmal ein paar Stunden. Ein Kollege möchte ein zusätzliches Format dazu: wieder ein Nachmittag. Und wenn der Erbauer geht, kostet das Einarbeiten eines Nachfolgers oder der komplette Neubau des Skripts schnell mehrere Tage. Diese Zahlen sind keine Messwerte, sondern eine Rechnung zum Nachvollziehen mit Ihren eigenen Stunden.

Zählen Sie das über ein paar Jahre zusammen, dann sind aus "zwei Tagen" längst keine zwei Tage mehr. Und es handelt sich um Konstruktionsstunden: die teuersten und knappsten Stunden im Haus, die Sie lieber in den Entwurf stecken als in die Reparatur eines PDF-Exportskripts. Mit einer Toolbox wie Thundercad erledigen Sie Batch Publish in einem Klick statt in zwölf Schritten und legen zum Beispiel 48 PDF-Dateien in 6 Sekunden ab, inklusive Zusammenspiel mit Autodesk Vault. Keine Wartung, kein Versionsstress, keine Abhängigkeit von einer einzigen Person. Ob sich das Abonnement lohnt, hängt von Ihrer Lage ab, doch die Rechnung fällt oft ganz anders aus als das Bauchgefühl, Eigenbau sei kostenlos.

Was eine gepflegte Toolbox konkret abdeckt

Um es greifbar zu machen: Eine Toolbox nimmt genau die generischen, wiederkehrenden Handgriffe ab, bei denen der Eigenbau die meiste Wartung verlangt. Bei Thundercad geht es unter anderem um:

• iProperty Menu: Metadaten und iProperties über eine einstellbare Datenkarte je Dokumenttyp verwalten, statt über einzelne Skripte oder von Hand.
• Batch Publish: alle Fertigungsdokumente in einem Schritt: PDF, DWG, DXF und STEP, im Zusammenspiel mit Vault.
• BOM Export: Stücklisten nach Excel in einer festen Vorlage, ohne dass Sie die Exportlogik selbst pflegen müssen.
• Batch Open & Close: Dateien in Baugruppen schnell öffnen und wieder sauber schließen.
• Quick Save / Load: Arbeit parken und exakt so zurückholen, wie Sie sie verlassen haben.
• Model Cleaner: liegen gebliebene Geometrie entfernen und den Browser aufräumen.
• Sheet Buttons: Blattformat eine Stufe hoch- oder herabsetzen und drehen.
• Dashboard: Werkzeuge aktivieren und verwalten und an Ihr ERP oder andere Software anbinden.

Der letzte Punkt, das Dashboard mit Anbindung an ERP, zeigt, wo sich die beiden Welten berühren. Eine Toolbox schließt die Tür nicht vor Maßarbeit, sie gibt Ihnen eine gepflegte Grundlage, an die Sie Ihre eigenen Integrationen anhängen. Sie behalten also die Freiheit, Ihre echte Produktlogik mit iLogic zu bauen, während die generische Arbeit drumherum abgedeckt ist. Die Grenze verläuft also nicht zwischen den Werkzeugen, sondern zwischen den Aufgaben. Unternehmen wie Little Giant Europe, Van Egten, Banzo und Mannen van Staal arbeiten bereits damit, um genau diese sich wiederholende Arbeit aus ihrem Konstruktionsprozess zu nehmen.

Auf der Roadmap stehen übrigens weitere Werkzeuge, die heute typischerweise per Eigenbau gelöst werden: Batch Flat Pattern, Find Item, ein Drawing Checker/Cleaner und ein Drawing Updater. Noch nicht verfügbar, aber sie zeigen die Richtung: Immer mehr generische Handarbeit wandert in ein gepflegtes Ganzes.

Wann wählen Sie also was?

Die ehrliche Schlussfolgerung lautet weder "immer dies" noch "immer das". Es ist eine Abwägung, und sie fällt je nach Art der Arbeit anders aus. Hier eine Faustregel, die Sie sofort auf Ihre eigene Skriptsammlung anwenden können.

Wählen Sie iLogic und Eigenbau, wenn:

• es um produktspezifische Logik geht, die einzigartig für Ihr Produkt ist: Konfiguratoren, parametrische Familien, Konstruktionsregeln, die sonst niemand kennt.
• Sie dauerhaft jemanden im Haus haben, der das bauen und auch pflegen kann, und Sie diese Abhängigkeit bewusst annehmen und dokumentieren.
• das Problem so speziell ist, dass kein vorhandenes Produkt es abdeckt und Maßarbeit wirklich einen Vorsprung im Wettbewerb bringt.

Wählen Sie eine gepflegte Toolbox, wenn:

• es um generische Produktionsarbeit geht, die in jedem Projekt gleich ist: veröffentlichen, exportieren, Metadaten verwalten, Baugruppen öffnen und schließen.
• Sie Wartung, Inventor-Updates und Teamabhängigkeit lieber nicht selbst tragen.
• Ihnen Zusammenhang und eine einheitliche Arbeitsweise im ganzen Team wichtig sind.
• Sie möchten, dass ein neuer Kollege schnell produktiv ist, ohne dass ihm erst jemand die Fallstricke erklären muss.

In der Praxis entscheiden sich viele Abteilungen für beides: iLogic für die echte Maßarbeit, die ihr Produkt auszeichnet, und eine Toolbox für alles darum herum. So stecken Sie Ihre knappen Konstruktionsstunden dorthin, wo sie den Unterschied machen, in den Entwurf, den Ihr Kunde kauft, und nicht in ein PDF-Exportskript, das bei jedem Update brechen kann. Das Schöne daran: Sie müssen das nicht vorab in einer Tabelle beweisen, Sie testen es an Ihren eigenen Projekten, bevor Sie irgendetwas an Ihrem Prozess ändern. Das Ergebnis dieser Aufteilung ist meist spürbar weniger Wartung bei gleichem Funktionsumfang.

Häufig gestellte Fragen

Ist eine Toolbox ein Ersatz für iLogic?

Nein, und das ist auch nicht die Absicht. iLogic ist stark bei produktspezifischer Logik wie Konfiguratoren und parametrischen Familien. Eine Toolbox wie Thundercad deckt generische, wiederkehrende Produktionsarbeit ab, etwa veröffentlichen, exportieren und Metadaten verwalten. Viele Abteilungen setzen beides nebeneinander ein: iLogic für die Maßarbeit, die Toolbox für den täglichen Arbeitsablauf drumherum.

Was passiert mit meinen vorhandenen iLogic-Skripten?

Die können Sie einfach weiter nutzen. Eine Toolbox ersetzt nicht Ihre Produktlogik, sondern übernimmt die generischen Handgriffe, für die Sie heute einzelne Skripte pflegen. Sie können also schrittweise umsteigen: Beginnen Sie mit den Skripten, die die meiste Wartung kosten oder das größte Bus-Faktor-Risiko tragen, und geben Sie diese zuerst ab. Sie müssen nichts auf einen Schlag umbauen.

Was, wenn ich an unsere eigene Software oder an ERP anbinden will?

Das geht über das Dashboard, mit dem Sie Werkzeuge verwalten und an ERP sowie an andere Software anbinden. So behalten Sie eine gepflegte Grundlage für die generische Arbeit und hängen Ihre eigenen Integrationen und Ihre Maßarbeit daran an. Wollen Sie es selbst erleben? Sie können Thundercad 30 Tage kostenlos testen, ohne Kreditkarte, in Ihrer eigenen Inventor-Umgebung und an Ihren Projekten.