Die Verwaltung von Revisionen und Freigaben in Autodesk Vault gleicht einem komplexen Puzzle - vor allem, wenn gemeinsame Teile mehrere Baugruppen verbinden. Auf den ersten Blick scheint der Prozess einfach zu sein, aber was passiert beim Übergang von Work in Progress (WIP) zu Released? Das Unerwartete: gesperrte Dateien, verwirrende Fehlermeldungen und Datenabweichungen, über die sich die Teams nur den Kopf zerbrechen können.
In diesem Artikel gehen wir auf ein reales Szenario ein, um die Ursache für diese Herausforderungen aufzudecken und umsetzbare Erkenntnisse zur Vereinfachung Ihrer Arbeitsabläufe zu gewinnen. Außerdem erfahren Sie, wie Tools wie powerJobs den Prozess automatisieren und Ihnen dabei helfen können, selbst die kniffligsten Genehmigungshindernisse zu überwinden.
Eine häufige Frage bei unseren Workflow-Beratungen ist: „Warum kann ich Dateien nicht reibungslos freigeben, wenn ich Revisionen in den Übergängen WIP → Freigegeben verschiebe?“ Die Antwort liegt in der Art und Weise, wie Autodesk Vault Abhängigkeiten verwaltet und die Datengenauigkeit sicherstellt, was zu gesperrten Dateien und sich wiederholenden Aktualisierungsanforderungen führen kann, wenn gemeinsame Teile in Baugruppen verwendet werden.
Um das Problem besser zu verstehen, lassen Sie uns ein spezifisches Szenario betrachten.
Stellen Sie sich vor, Sie haben zwei Baugruppen, sm01.iam und sm03.iam, die beide auf gemeinsame Teile verweisen, sm01.ipt und sm02.ipt. Hier ist eine schrittweise Aufschlüsselung der möglichen Fallstricke:
1. Ersteinrichtung:
sm01.iam enthält sm01.ipt.
sm03.iam enthält sowohl sm01.ipt als auch sm02.ipt.
Alle Teile und Baugruppen sind derzeit in Revision A (Rel.A) und befinden sich im Status „Work in Progress“.
2. Erster Freigabeprozess:
Der Benutzer gibt sm01.iam zusammen mit sm01.ipt frei.
Diese Aktion versetzt sm01.iam und sm01.ipt in den Status „Freigegeben“, wobei sm01.ipt in die Revision B (Rel.B) übergeht..
3. Aktueller Stand, nach der Korrektur in Inventor:
sm01.iam Rel.B Freigegeben
sm01.ipt Rel.B Freigegeben
sm03.iam Rel.B Freigegeben
sm01.ipt Rel.B Freigegeben
sm02.ipt Rel.B Freigegeben
Angenommen, der Benutzer ändert sm01.iam und sm03.iam von Freigegeben zurück auf In Arbeit, nimmt eine Änderung in sm01.ipt vor, gibt sm01.iam wieder frei und erstellt Revision C (Rel.C).
Das Ergebnis wird sein:
sm01.iam Rel.C Freigegeben
sm01.ipt Rel.C Freigegeben
sm03.iam Rel.B Laufende Arbeiten
sm01.ipt Rel.B Laufende Arbeiten
sm02.ipt Rel.A Laufende Arbeiten
Wenn der Benutzer nun sm03.iam freigibt, wird das Ergebnis fälschlicherweise wie folgt aussehen:
sm03.iam Rel.C Freigegeben
sm01.ipt Rel.B Freigegeben
Dieses Ergebnis ist weder logisch noch zu erwarten, da sm03.iam auf die neueste sm01.ipt-Revision (Rel.C) verweisen sollte, Vault aber stattdessen die zuvor freigegebene sm01.ipt Rel.B fand und verwendete.
Bei diesem Problem handelt es sich nicht um einen Fehler in Vault, sondern um die Folge eines Arbeitsablaufs, der mit den logischen Revisionsregeln von Vault in Konflikt steht. Durch das Befolgen dieses Arbeitsablaufs schaffen Benutzer ungewollt Inkonsistenzen, die die Systemlogik von Vault nicht intuitiv lösen kann.
Häufige manuelle Updates für Abhängigkeiten
Die Freigabe von Baugruppen mit gemeinsam genutzten Teilen erfordert häufig manuelle Aktualisierungen, um sicherzustellen, dass jede Baugruppe auf die neueste Teilerevision verweist. Bei Projekten mit vielen Baugruppen kann dies die Arbeitsabläufe erheblich verlangsamen und zu einem schwer zu verwaltenden Engpass führen, insbesondere in Umgebungen mit hohen Abhängigkeiten.
Dateninkonsistenz und Probleme mit der Versionskontrolle
Wenn Aktualisierungen versäumt werden, können Baugruppen auf veraltete Teilerevisionen verweisen, was zu inkonsistenten Daten in allen Baugruppen führt. Wenn beispielsweise eine Baugruppe wie sm03.iam freigegeben wird, ohne ihren Verweis auf die neueste Teilerevision zu aktualisieren, zieht Vault möglicherweise eine ältere Version heran, was in der Produktion zu ungenauen Informationen führt. Diese Inkonsistenz erschwert die Verfolgung von Änderungen, die Verwaltung der Dokumentation und die Gewährleistung einer genauen Versionskontrolle in der Produktion.
Erhöhte Workflow-Komplexität
Der Standard-Revisions-Workflow von Autodesk Vault erwartet, dass Revisionen beim Übergang Freigegeben → WIP zusammenstoßen. Das Aneinanderstoßen von Revisionen beim Übergang WIP → Freigegeben führt zu widersprüchlichen Verhaltensweisen, für die Vault nicht optimiert ist, was die Komplexität erhöht und das Risiko von Fehlern im Prozess steigert.
Leistungsprobleme in großen Tresorumgebungen
Bei der Automatisierung von Aktualisierungen von Abhängigkeiten (z. B. durch powerJobs) muss Vault alle Baugruppen scannen, die auf ein neu freigegebenes Teil verweisen. Bei großen Datensätzen kann dieser Prozess die Systemleistung verlangsamen und die Serverlast erhöhen, was die Produktivität von Teams mit engen Zeitplänen beeinträchtigt.
Für Kunden, die diesen Arbeitsablauf unbedingt benötigen, kann die Automatisierung durch powerJobs eine gewisse Erleichterung bieten. powerJobs kann so konfiguriert werden, dass es nach allen Baugruppen sucht, die auf ein neu freigegebenes Teil verweisen, und deren Abhängigkeiten auf die neueste Revision aktualisiert. Dieser Ansatz ist jedoch mit Einschränkungen verbunden:
Ressourcenintensität: Jedes Mal, wenn ein Teil freigegeben wird, müsste powerJobs den gesamten Vault nach Abhängigkeiten durchsuchen, was insbesondere bei großen Datensätzen zeitaufwändig sein kann.
Mögliche Auswirkungen auf die Leistung: Die Ausführung von powerJobs bei jedem Freigabeereignis könnte die Systemleistung beeinträchtigen, abhängig von der Größe des Vault und der Anzahl der betroffenen Baugruppen.
PowerJobs kann zwar einen Teil der manuellen Arbeit abmildern, sollte aber eher als letzter Ausweg denn als bevorzugte Lösung betrachtet werden. Den meisten Kunden empfehlen wir, sich an den von Vault vorgesehenen Arbeitsabläufen zu orientieren, um diese Herausforderungen ganz zu vermeiden.
Der Standard-Workflow von Autodesk Vault ist darauf ausgelegt, Revisionen während des Übergangs Freigegeben → WIP zu verschieben.
Dieser Ansatz gewährleistet eine konsistente Versionskontrolle für Baugruppen und Teile mit gemeinsamen Abhängigkeiten und reduziert das Risiko gesperrter Dateien, manueller Aktualisierungen und Dateninkonsistenzen.
Im Gegensatz dazu kann das Verschieben von Revisionen beim Übergang WIP → Freigegeben die Logik von Vault stören und zu Konflikten und falsch ausgerichteten Referenzen führen, insbesondere wenn mehrere Baugruppen Teile gemeinsam nutzen.
Empfehlung: Vermeiden Sie das Verschieben von Revisionen am Übergang WIP → Freigegeben wann immer möglich. Das Befolgen des von Vault vorgesehenen Arbeitsablaufs bewahrt die Datenintegrität und vereinfacht die Verwaltung von Abhängigkeiten. Wenn dieser alternative Arbeitsablauf erforderlich ist, können Automatisierungstools wie powerJobs dabei helfen, die Aktualisierungen zu automatisieren, was jedoch die Systemleistung beeinträchtigen kann.