Custom iProperties in Inventor: wann sinnvoll und wann nicht

Ein CAD-Administrator bei einem Maschinenbauer hat sie nach einem Umbau des Schriftfelds einmal nachgezählt: 41 custom iProperties im Umlauf. Neun davon wurden irgendwo gelesen, vom Schriftfeld, von einem Export oder von der ERP-Anbindung. Der Rest war irgendwann für einen Kunden, ein Projekt oder ein Experiment angelegt worden und danach nie wieder aufgeräumt. Drei Felder hießen fast gleich: Bemerkung, Bemerkungen und Bemerkung2.

So eine Liste ist niemandes Schuld und trotzdem jedermanns Problem. Custom iProperties in Inventor sind in dreißig Sekunden angelegt und quälend langsam wieder loszuwerden. In diesem Artikel bekommen Sie drei Prüffragen, die jedes neue Feld überstehen muss, eine Sanierungsmethode für vorhandenen Wildwuchs und das Argument für eine gepflegte Feldliste je Dokumenttyp. Um die Standardfelder selbst geht es hier nicht; es geht um die Felder, die Sie sich zusätzlich ausdenken. Und darum, wie eine Toolbox wie Thundercad die vereinbarte Liste danach auch tatsächlich gefüllt bekommt.

Warum Wildwuchs niemandes Schuld ist

Jedes custom Feld beginnt mit einem guten Grund. Ein Kunde verlangt einen Zertifikatscode auf der Zeichnung: ein Feld dazu. Die Arbeitsvorbereitung möchte ein Notizfeld für die Sägerei: noch ein Feld dazu. Jemand testet eine Anbindung und legt drei Testfelder an, die nie wieder entfernt werden. Vorlagen kopieren all diese Felder brav in jede neue Datei, und löschen traut sich niemand, denn womöglich liest sie ja doch noch jemand.

Nach ein paar Jahren hat die Liste drei Arten von Bewohnern: Felder, die wirklich funktionieren, Duplikate von Standardfeldern (ein eigenes Feld „Gewicht“ neben der Masse, die Inventor ohnehin schon führt) und Geisterfelder, deren Zweck niemand mehr kennt. Welche Standardfelder es bereits gibt und wie Sie diese konsequent gefüllt halten, lesen Sie in iProperties in Inventor verwalten, ohne Chaos; denselben Wert doppelt zu führen ist so gut wie immer die falsche Antwort.

Drei Fragen, die jedes neue Feld überstehen muss

Wildwuchs verhindern Sie nicht mit einem Verbot, sondern mit einer Prüfung. Drei Fragen, und bei jedem „nein“ oder „weiß nicht“ wird das Feld nicht angelegt:

1. Liest ein System es? Ein Schriftfeld, ein Stücklisten-Export, eine Suche in Vault, die ERP-Anbindung: irgendetwas muss das Feld nachweislich nutzen. „Praktisch, das dabeizuhaben“ zählt nicht; wenn nichts es liest, ist das Feld totes Gewicht.
2. Wer füllt es, und zu welchem Zeitpunkt? Ein Feld ohne Verantwortlichen und ohne festen Zeitpunkt bleibt leer. „Der Konstrukteur, bei der Freigabe“ ist eine Antwort; „alle ein bisschen“ heißt niemand.
3. Wer entscheidet damit etwas? Hinter jedes Feld gehört eine Handlung: Der Einkauf bestellt nach dem Lieferantencode, die Arbeitsvorbereitung plant nach der Oberflächenbehandlung. Ein Feld, mit dem niemand etwas tut, ist Rauschen, das jede Woche Pflege verlangt.

Stellen Sie danach noch eine Kontrollfrage: Deckt ein Standardfeld die Sache bereits ab? Ein vorhandenes Feld weiterzuverwenden ist fast immer besser, als eine neue Variante danebenzustellen.

Wann ein custom Feld seine Berechtigung hat

Mit dieser Prüfung in der Hand bleiben gute Gründe für eigene Felder übrig. Drei Beispiele aus der Praxis:

• Oberflächenbehandlung bei Blechteilen. „Feuerverzinken“ oder „Pulverbeschichten“ mit Farbcode: Der Konstrukteur füllt das Feld bei der Freigabe, die Arbeitsvorbereitung liest es für die Vergabe nach außen. System, Ausfüller und Leser sind benannt, also verdient das Feld seinen Platz.
• Lieferantencode bei Kaufteilen. Gefüllt vom Einkauf oder vom Konstrukteur beim Anlegen des Kaufteils, gelesen vom Besteller und vom Stücklisten-Export Richtung ERP.
• Zertifikatspflicht bei tragenden Bauteilen. Die Konstruktion markiert, welche Bauteile ein Materialzertifikat brauchen; der Einkauf bestellt auf dieser Grundlage. Ein Feld, eine Frage, eine Entscheidung.

Was diese drei gemeinsam haben: Sie beschreiben das Bauteil, nicht den Prozess von heute. Felder wie „Eilt“ oder „NochPrüfen“ gehören nicht in die iProperties; das ist Arbeitsvorrat, und Arbeitsvorrat altert schneller als Ihre Dateien.

Sanierung: die vorhandene Liste zurückschneiden

Besteht der Wildwuchs bereits, dann dient dieselbe Prüfung als Sanierungsmethode. Erfassen Sie zuerst alle custom Felder, die im Umlauf sind, und notieren Sie je Feld zwei Dinge: Was liest es, und wie oft ist es gefüllt? Dieser Füllgrad ist der ehrlichste Richter; wie Sie solche Zahlen aus Ihren Dateien holen, haben wir in Wie gesund sind Ihre CAD-Daten? So messen Sie die Qualität Ihrer Metadaten beschrieben.

Teilen Sie die Liste danach in vier Gruppen ein: behalten (hat Leser und Ausfüller), zusammenführen (Duplikate wie die drei Bemerkung-Varianten), abschaffen (nichts liest es) und einfrieren (Zweifelsfälle: ein paar Wochen stehen lassen und schauen, wer sich meldet). Nehmen Sie die abgeschafften Felder auf jeden Fall aus Ihren Vorlagen, damit neue Arbeit sauber startet; alte Dateien müssen Sie nicht rückwirkend säubern, die nehmen Sie mit, sobald Sie sie ohnehin bearbeiten. Und kommunizieren Sie die neue Liste einmal deutlich: Welche Felder gibt es noch, und wo ist der Rest geblieben?

Eine Feldliste je Dokumenttyp

Die dauerhafte Lösung ist eine kurze, gepflegte Liste je Dokumenttyp. Ein Bauteil braucht andere Felder als eine Baugruppe oder eine Zeichnung: Eine Oberflächenbehandlung gehört zum Bauteil, eine Projektreferenz eher zur Baugruppe. Halten Sie je Dokumenttyp fest, welche Felder es gibt, wer sie füllt, wer sie liest und wie ein gültiger Wert aussieht. Eine Seite je Typ reicht, mit einem Verantwortlichen: Neue Felder kommen nur über diese Liste dazu.

So eine Liste bleibt nur am Leben, wenn sie auch in Inventor sichtbar ist. Dabei hilft das iProperty Panel: Die Datenkarte je Dokumenttyp ist einstellbar, also stehen die vereinbarten Felder bei jeder Datei in derselben Reihenfolge vor Ihnen, ohne Suchen durch Registerkarten. Die Liste auf Papier und die Karte am Bildschirm sind dann dasselbe, und genau das ist der Sinn der Sache.

Häufig gestellte Fragen

Wie viele custom iProperties sind normal?

Es gibt keine magische Zahl, aber wer streng prüft, kommt selten über zehn bis fünfzehn je Dokumenttyp hinaus. Ab zwanzig wird die Karte unübersichtlich und der Füllgrad sinkt von allein. Der Maßstab ist nicht die Anzahl, sondern ob jedes Feld einen benannten Ausfüller und einen benannten Leser hat.

Kann ich ein überflüssiges Feld einfach löschen?

Prüfen Sie zuerst, was das Feld liest: Schriftfelder, Vorlagen, Exporte und Anbindungen können sich still darauf stützen. Nehmen Sie es danach aus den Vorlagen, damit neue Dateien sauber starten. Bestehende Dateien müssen Sie nicht alle nacharbeiten; die räumen Sie in dem Moment auf, in dem Sie sie ohnehin bearbeiten.

Wie verhindere ich, dass der Wildwuchs zurückkommt?

Ein Verantwortlicher für die Feldliste, jedes neue Feld durch die drei Prüffragen, und das Ausfüllen so einfach wie möglich machen. Mit dem iProperty Panel bringen Sie die vereinbarten Felder als Datenkarte auf den Bildschirm; Sie testen es zusammen mit dem Rest von Thundercad 30 Tage kostenlos.