Optimierte Änderungen und Neuentwicklungen mit Fusion Manage
Vom definierten Übergabepunkt zur gesteuerten Unternehmensarchitektur
Ein mechanischer Konstrukteur klickt auf „Freigegeben". Wochen Entwicklungsarbeit liegen hinter ihm – das Modell ist versioniert, die Stückliste vollständig, technisch ist alles sauber. Und jetzt?
Was in diesem Moment im Unternehmen passiert, ist die eigentliche Frage. Wer übermittelt? Wer ist verantwortlich? Welche Version gilt unternehmensweit? Die typische Realität: E-Mail-Verteiler werden gestartet, Abstimmungsmeetings angesetzt, PDFs verschickt, Excel-Tabellen manuell gepflegt – mehrere Versionen im Umlauf, keine echte Revisionssicherheit, keine Systemlogik. Die Daten sind sauber. Der Übergang ist es nicht.
In dieser Session zeigen wir, wie Vault und Fusion Manage gemeinsam diesen Übergabemoment strukturieren – und wie Change von einem operativen Formular zur unternehmensweiten Steuerungsebene wird.
Kein Datentransfer – echte Synchronisation
Mit der Freigabe in Vault passiert mehr als Dateimanagement. Die Synchronisation erzeugt in Fusion Manage ein Artikel-Objekt – keine Kopie, kein loses Dokument, sondern ein systemisch verknüpftes Entscheidungsobjekt. Hier beginnt der digitale Prozess: nicht weil ein Formular ausgefüllt wurde, sondern weil ein strukturierter Übergabepunkt existiert.
Ändert sich eine relevante Information in Vault, wird sie in Fusion Manage synchronisiert – und umgekehrt gilt das genauso. Das ist keine Einbahnstraße. Zwei Anwendungen arbeiten in einem gemeinsamen Informationsraum. Aus einer Datei wird ein kontextbezogenes Objekt. Aus isolierter Konstruktion wird integrierte Unternehmenssteuerung.
Vault und Fusion Manage arbeiten innerhalb derselben Plattform-Architektur – kein Patchwork, kein Add-on, das beim nächsten Update bricht. Zwei Welten, aber ein gemeinsamer Blick. Und damit enden die Zeiten paralleler Wahrheiten.
Change ist kein Konstruktionstool – er ist Unternehmenssteuerung
Wenn über Änderungen gesprochen wird, denken viele zunächst an die Konstruktion: eine Zeichnungsänderung, eine neue Revision. Und ja, dort entstehen viele Change Tasks. Aber Change ist kein Konstruktionstool. Eine Änderung bleibt nicht in einer Abteilung – sie durchzieht das gesamte Unternehmen.
Change hat viele Erzeuger: Ein Problem kann im Service entstehen, in der Produktion, im Einkauf, beim Kunden. Und genauso hat Change Abnehmer: Die Konstruktion setzt um, der Einkauf bestellt neu, die Produktion passt Abläufe an, der Service informiert Kunden. Kommt diese Information per Zuruf, per Mail, per Teams oder Excel, entsteht wieder Unsicherheit: Ist das für mich relevant? Wo finde ich die gültige Version? Ist das verbindlich?
Wenn Change nur in der Konstruktion gedacht wird, bleibt er operativ. Wenn er unternehmensweit gedacht wird, wird er strategisch. Das ist der Unterschied zwischen Revisionen verwalten und ein Unternehmen steuern.
Vom Design Review bis zur Umsetzung – strukturiert, nicht auf Zuruf
Änderungen beginnen nicht immer gleich. Heute bewegen wir uns bewusst am frühen Übergang von Entwicklung zu Industrialisierung – dem Moment, in dem Strukturen noch überschaubar und Abhängigkeiten noch kontrollierbar sind. Je später eine Änderung entsteht, desto komplexer und teurer wird sie.
Der Prozess läuft in klar definierten Schritten:
- Design Review: Eine Beobachtung entsteht – eine Kollision, eine Unstimmigkeit. Sie wird direkt am Objekt kommentiert und verankert. Nicht im separaten Protokoll, sondern exakt dort, wo sie relevant ist. Das Modell bleibt im Mittelpunkt, nicht das Dokument. Aus der Markierung entsteht eine Aufgabe: klar zugewiesen, terminiert, mit Status.
- Change Request: Die visuelle Erkenntnis wird strukturiert bewertet. Was ist die Ursache? Welche Artikel sind betroffen? Welche Auswirkungen entstehen – technisch, organisatorisch, terminlich, kostenbezogen? Hier wird aus der Beobachtung eine Entscheidungsgrundlage.
- Change Order: Genehmigungsworkflow, Change Control Board, Freigaben, Prioritäten, Zeitplanung. Aus technischen Anpassungen wird eine unternehmerische Entscheidung.
- Change Task: Die konkrete Aufgabe landet in der Umsetzung – zugewiesen, terminiert, im Kontext. Nicht auf Zuruf, sondern als Bestandteil eines gesteuerten Prozesses.
Der Prozess kommt zum Menschen – nicht der Mensch zum Prozess
Der Konstrukteur bleibt in Inventor, in seiner gewohnten Umgebung. Er sieht direkt, welche Änderung ihm zugewiesen wurde, welcher Kontext dahinter steht und welcher Artikel betroffen ist. Er kann den betroffenen Artikel direkt öffnen – kein Suchen, keine falsche Artikelnummer, kein Systemwechsel, kein Medienbruch.
Mit dem Check-in wird der Prozess automatisch fortgeführt: Status aktualisiert, nächste Rolle informiert, Workflow schreitet voran – ohne manuelle Abstimmung. Inventor für die Facharbeit, Fusion Manage für die Steuerung. Und dennoch entsteht ein gemeinsamer Status, eine unternehmensweite Sicht.
Was wir hier sehen, ist kein Tool. Es ist ein Reifegrad. Von isolierter Konstruktion zur gesteuerten Unternehmensarchitektur. Status ist eindeutig und sichtbar, Verantwortung ist klar – wer prüft, wer entscheidet, wer setzt um. Diskussionen werden kürzer, Entscheidungen klarer, Unsicherheit verschwindet. Das ist unternehmerische Reife.
Kontakt aufnehmen
Haben Sie Fragen oder wünschen Sie weitere Informationen, Angebote oder Beratung?
Unser Team freut sich über Ihre Nachricht.