Datei-Kollaboration im Engineering: Teamübergreifende Workflows

Engineering-Kollaboration scheitert, wenn Teams unterschiedliche Regeln für dieselben Dateien anwenden. Das Maschinenbauteam speichert in einem lokalen Vault, das Elektrikteam committet in Git und die Firmware-Entwickler hängen Binärdateien an Jira-Tickets. Währenddessen wartet ein Fertigungsingenieur in Prag auf die aktuelle Gehäuse-STEP-Datei und erhält drei widersprüchliche Versionen über Slack. Die DSGVO verschärft das Problem: Werden personenbezogene Daten von Mitarbeitern oder externen Auftragnehmern in technischen Dokumenten mitgeführt, gelten nach BDSG und TTDSG Anforderungen an Übertragungssicherheit und Löschfristen. Effektive teamübergreifende Workflows kombinieren eine klare Quelle der Wahrheit, explizite Übergabepunkte und Übertragungstools, die für alle funktionieren – einschließlich externer Auftragnehmer ohne Zugang zum internen PLM.

Warum Engineering-Dateien normaler Versionskontrolle widerstehen

Git verwaltet Textdateien hervorragend, kämpft aber mit binären CAD-Dateien, FPGA-Bitstreams und PCB-Layouts. Eine 500-MB-SolidWorks-Baugruppe bläht ein Git-Repository schnell auf, und Diffs sind ohne CAD-Viewer bedeutungslos. Git LFS hilft, indem Zeiger gespeichert und Binärdateien in Objektspeicher ausgelagert werden, aber es bleibt umständlich für jemanden, der in Features und Konfigurationen denkt statt in Commits. Dedizierte Systeme wie PTC Windchill, Siemens Teamcenter, Autodesk Vault und Aras Innovator nutzen Check-in/Check-out-Sperren, um zu verhindern, dass zwei Ingenieure dasselbe Teil gleichzeitig bearbeiten. Für kleine Teams bieten Onshape oder Fusion Team cloud-native kollaborative Bearbeitung mit automatischer Versionierung.

Quelle der Wahrheit pro Fachbereich

Wählen Sie ein System pro Fachbereich und machen Sie es zur Regel. Mechanische Konstruktionen leben in Vault oder Windchill. Elektrische Schaltpläne in Altium 365 oder KiCad mit Git. Firmware in Git mit semantischer Versionierung. Mechanische Zeichnungen werden bei jedem Release als PDF exportiert und in einem gemeinsamen Review-Ordner abgelegt. Anforderungen und Testverfahren leben in Polarion, Jama oder DOORS. Die Regel lautet: Links zwischen Systemen zeigen auf spezifische Revisionen, nicht auf den neuesten Stand. Eine Anforderung, die auf „Gehäuse gemäß MECH-4512 Rev C" verweist, ist prüffähig – „Gehäuse gemäß neuester Vault-Version" ist es nicht.

Übergabepunkte zwischen Fachbereichen

Reibung entsteht an den Schnittstellen. Mechanik übergibt eine Halterung an Elektrik, damit Kabelführungsabstände berücksichtigt werden können. Elektrik übergibt eine PCB-Kontur an Mechanik für Gehäuse-Passformprüfungen. Firmware übergibt ein Flash-Image an Test. Diese Übergaben erfordern ein Formatprotokoll. Für MCAD-ECAD ist IDX (ProStep) das Neutral-Format; STEP AP242 mit PMI funktioniert für einfache Passformprüfungen. Für Firmware-Lieferungen enthält eine .hex- oder .bin-Datei mit eingebettetem Versions-String, Build-Zeitstempel und Git-Commit-SHA alle Informationen für die QA-Rückverfolgung. Jede Übergabe sollte eine Prüfsumme (SHA-256) und eine signierte Nachricht wie einen Git-Tag oder eine PGP-signierte Release-Note tragen.

Review-Workflows, die tatsächlich abgezeichnet werden

Änderungsreviews im Engineering degenerieren schnell zu E-Mail-Threads. Ein strukturierter Ablauf sieht so aus: Der Autor lädt das Paket hoch, Reviewer erhalten einen Link mit einem Ablaufdatum entsprechend der Review-Frist, Reviewer laden die Dateien herunter und markieren sie, Kommentare werden in einem einzigen Dokument konsolidiert, der Autor veröffentlicht Rev B. Tools wie Bluebeam Revu und PDF-Annotation in Adobe Acrobat übernehmen die Kommentarkonsolidierung für Zeichnungen. Für Code dienen Pull-Requests in GitHub oder GitLab demselben Zweck. Für disziplinübergreifende Reviews, bei denen Reviewer unterschiedliche Tools verwenden, funktioniert ein abgeflachtes PDF mit Kommentarrechten und einem gemeinsamen Übertragungslink oft besser als alle auf eine Plattform zu zwingen.

Teilen mit externen Partnern und Auftragnehmern

Internes PLM erstreckt sich selten sauber auf externe Auftragnehmer, Prüflabore oder Lieferanten-Engineering-Teams. Für ein dreiwöchiges Beratungsmandat möchte man keine Windchill-Lizenz bereitstellen. Übertragungstools schließen diese Lücke. Senden Sie ein gebündeltes Release – eine .zip mit STEP, PDF-Zeichnungen, Stückliste als .csv und einem signierten Readme – an den externen Partner über einen Ende-zu-Ende-verschlüsselten Link. Setzen Sie den Link so, dass er zum Vertragsende abläuft. Führen Sie intern ein Protokoll jeder externen Übertragung für IP-Audit-Zwecke – insbesondere wichtig bei exportkontrollpflichtigem und proprietärem Material, bei dem Compliance-Beauftragte chronologische Aufzeichnungen benötigen.

Benennung, Tagging und Metadaten-Hygiene

Konsistente Benennung verhindert mehr Verwirrung als jedes Tool. Ein Schema wie PROJEKT_BAUGRUPPE_TEILENR_REV_DATUM.ext (z.B. EV2_BATT_PN55421_B_2026-11-09.step) macht Sortierung und Suche trivial. Versehen Sie jedes Release mit einem signierten Git-Tag oder einem PLM-Release-Label. Speichern Sie Metadaten – Autor, Reviewer, Genehmiger, Release-Datum – in einer Sidecar-JSON- oder YAML-Datei neben binären Assets. Vermeiden Sie Personennamen in Dateinamen, außer für den verantwortlichen Ingenieur. In Schriftfeldern verwenden Sie Rollenkennzeichnungen (ME Lead, Mech Reviewer) statt Personennamen, damit Personalwechsel keine Zeichnungsrevisionen erfordern.

Große Testdaten zugänglich halten ohne Systeme zu überlasten

Umweltprüfberichte von einem Schwingungsprüfstand können 10 bis 100 GB Rohdaten erzeugen. Thermografieaufnahmen aus einem Zuverlässigkeitstest kommen hinzu. PLM-Systeme kollabieren unter diesem Volumen und sind ohnehin nicht für Zeitreihendaten konzipiert. Speichern Sie Rohdaten in Objektspeicher wie AWS S3, Backblaze B2 oder Wasabi zu etwa 5 bis 24 Euro pro TB und Monat, und halten Sie Zeiger im Prüfbericht. Teilen Sie Zugang mit spezifischen Teams über zeitbegrenzte signierte URLs, oder verschieben Sie Teilmengen per Ende-zu-Ende-verschlüsselter Übertragung, wenn Mitarbeiter außerhalb Ihres Cloud-Kontos sind. TTL- und Lifecycle-Richtlinien verschieben veraltete Daten automatisch in Glacier oder Archivtarife.

Globale Koordinationsmuster über Zeitzonen hinweg

Globale Engineering-Teams arbeiten in Drei- oder Vier-Zeitzonen-Staffeln. Ein Maschinenbauingenieur in München committet um 17:00 Uhr MEZ, damit das Simulationsteam in Bangalore um 20:30 Uhr IST übernimmt, über Nacht rechnet und dem Konstruktionsteam um 09:00 Uhr MEZ Ergebnisse liefert. Übertragungstools und PLM-Check-ins müssen außerhalb der Geschäftszeiten ohne manuellen Eingriff zuverlässig funktionieren. Upload-Warteschlangen mit Wiederholungslogik und serverseitigen Benachrichtigungen per Webhook oder E-Mail ermöglichen Übergaben ohne ständige Echtzeit-Pings. Halten Sie die Übergabe in einem schriftlichen Hinweis im Commit-Text fest: was sich geändert hat, was noch zu überprüfen ist, wer den nächsten Schritt besitzt.

Tools wählen ohne alle einzusperren

Große Unternehmen investieren in vollständige PLM-Suiten. Startups und kleine Teams kombinieren Git, Cloud-CAD und Übertragungstools. Der pragmatische Mittelweg nutzt Vault oder Onshape intern und verschlüsselte Übertragungsdienste für jede externe Übergabe. HexaTransfer bietet client-seitige AES-256-GCM-Verschlüsselung und 10-GB-Gratistransfers ohne Kontopflicht für Empfänger – was den externen Auftragnehmer-Anwendungsfall gut abdeckt.

Kostenlos ausprobieren auf hexatransfer.com — kein Konto erforderlich, bis zu 10 GB.