Wie teilen Teams SOLIDWORKS-Dateien mit Lieferanten, ohne die Versionskontrolle zu verlieren? Der Artikel zeigt Methoden, die geistiges Eigentum schĂĽtzen und Fehler reduzieren.
Lieferanten‑Collaboration ist der Punkt, an dem SOLIDWORKS‑Workflows oft aus dem Ruder laufen: RFQs, DFM‑Feedback, Werkzeugänderungen und Fertigungsfragen erzeugen schnelle Iterationszyklen. Die Herausforderung ist, das richtige Dateipaket zur richtigen Zeit mit den richtigen Personen zu teilen — ohne die IP‑Kontrolle oder den Überblick darüber zu verlieren, welche Revision der Lieferant gerade nutzt.
Das Versenden per E‑Mail oder generischem Cloud‑Speicher wirkt zunächst einfach, führt aber schnell zu widersprüchlichen Versionen, veraltetem Feedback und teuren Fehlern. NIST‑Forschung zur standardsbasierten Interoperabilität in Lieferketten zeigt, dass inkonsistenter Modellaustausch manuelle Rekonstruktion und Downstream‑Fehler erhöht und damit Nacharbeit, Kosten und Durchlaufzeiten treibt (NIST GCR 15‑1009). In Multi‑CAD‑Umgebungen wird es zusätzlich komplex. Unten steht ein praktischer Entscheidungsleitfaden: gängige Methoden, wofür sie wirklich taugen, und wie man nach Lieferzweck auswählt.
🖼️
Image placeholder — Visual: Diagramm einer SOLIDWORKS‑Baugruppe (.SLDASM) mit referenzierten Dateien (.SLDPRT, Unterbaugruppen). Alt: „SOLIDWORKS‑Baugruppenstruktur mit externen Referenzen“.
Kernproblem: Warum SOLIDWORKS‑Freigabe schwierig ist
SOLIDWORKS‑Dateien sind keine PDFs. Eine Baugruppe (.SLDASM) referenziert viele Teile (.SLDPRT) und Unterbaugruppen. Wenn man nur die Top‑Level‑Baugruppe verschickt, fehlen dem Empfänger oft Referenzen — die Datei lässt sich nicht sauber öffnen. Diese Komplexität ist die Wurzel vieler Sharing‑Fehler und macht generische Tools riskant.
Gängige Methoden und Tradeoffs
1) ZIP per E‑Mail mit „Pack and Go“
Prozess: Pack and Go sammelt eine Baugruppe und ihre referenzierten Dateien in einem Ordner für den Transfer (SOLIDWORKS‑Dokumentation). Das ist reine Paketierung — es entsteht keinen kontrollierten Review‑Workflow (Berechtigungen, In‑Context‑Annotations, widerrufbarer Zugriff, Revisionshistorie).
3) Neutrale oder View‑Only‑Formate (STEP, eDrawings)
Tradeoffs:
STEP eignet sich gut für Geometrie‑Austausch (Angebot). Modernes STEP (AP242) kann Struktur, Attribute und PMI tragen, bewahrt aber nicht die volle SOLIDWORKS‑Feature‑Historie/Design‑Intention.
eDrawings ist gut für Review (Schnitt, Explode, Markup) und — wenn vom Publisher aktiviert — Messen. Es ist eine exportierte Kopie; Änderungen am Source‑Modell erfordern erneutes Publizieren.
In beiden Fällen muss Feedback ins SOLIDWORKS‑Quellmodell übertragen werden.
Auswahl nach Lieferzweck
Bedarf des Lieferanten
Geeignete Methode
Einmaliges Angebot
STEP, PDF oder Pack and Go
Review ohne CAD‑Lizenz
eDrawings oder Browser‑CAD‑Viewer
Kontinuierliches Feedback + Revisions‑Tracking
Cloud‑PDM mit Gast‑Sharing pro Datei
Lieferant muss Source‑Dateien bearbeiten
Projekt‑Collaborator‑Zugriff (nur wenn nötig)
FertigungsĂĽbergabe
„Released“-Paket an eine konkrete Revision gebunden
Für Iteration mit Lieferanten braucht es kontrollierten Zugriff, Browser‑Review und Revisions‑Traceability.
Kernfunktionen (Beispiel: CAD ROOMS)
Zentrale Datenquelle.
Guest Sharing auf Datei‑Ebene: Gäste erhalten read‑only Zugriff auf eine konkrete Datei (kein Workspace/Projekt‑Zugang). Sie können ansehen, messen, kommentieren, annotieren; nicht hochladen, ändern oder releasen. Zugriff ist sofort widerrufbar.
Project Collaborator (seltener): nur wenn ein Lieferant Source‑Files beitragen muss.
Browser‑Viewer + In‑Context‑Annotations.
Versioning ĂĽber Revisionen.
Empfohlenes Workflow (Guest Sharing)
Intern Datei(en) + Revision festlegen.
Datei per Guest Sharing teilen (read‑only Link).
Lieferant reviewt im Browser und annotiert.
Intern wird in SOLIDWORKS iteriert, neue Revision entsteht.
Benachrichtigen / neu teilen, wenn Referenz‑Revision wechselt oder eine „released“ Revision bereit ist.
Zugriff am Ende widerrufen.
Hinweis zu File Release
Ein manueller File Release promoted eine geeignete Minor‑Revision zu einem Major‑Release als offizielles Downstream‑Record (z. B. Fertigung). Das bedeutet nicht, dass das Design nie wieder geändert werden darf; Änderungen laufen über neue Revisionen oder ECO‑Prozesse.
FAQ
F: Wann ist Pack and Go sinnvoll? A: Für einmalige Übergaben. Pack and Go sammelt Referenzen (SOLIDWORKS), schafft aber keinen kontrollierten Review‑Workflow oder Widerruf.
F: Wie greifen externe Lieferanten zu? A: Empfohlen ist Guest Sharing: Sie teilen eine konkrete Datei (nicht das gesamte Projekt) als read‑only Link. Lieferanten können im Browser ansehen, messen, kommentieren und annotieren, aber keine Dateien hochladen, ändern oder releasen. Das reduziert das IP‑Risiko und verhindert “zu breite” Berechtigungen. Wenn die Zusammenarbeit endet, können Sie den Zugriff sofort widerrufen.
F: Was bringt der Web‑Viewer? A: Der CAD Viewer ist die zentrale Review‑Oberfläche: Lieferanten können Modelle prüfen (Navigation, Schnitte, Explode etc.) und messen — ohne SOLIDWORKS‑Lizenz. Wichtig ist der Kontext: Feedback wird direkt am Modell hinterlegt und ist an die richtige Revision gekoppelt. Dadurch entsteht weniger “Screenshot‑Chaos”, und Änderungen lassen sich sauber in die nächste Revision überführen.
F: Was bedeutet „released“? A: Ein manueller File Release markiert eine Revision als offiziellen Referenzstand (z. B. für Fertigung, Kundenfreigabe oder Supplier‑Handoff). Das “friert” nicht die gesamte Entwicklung ein: Sie können weiterhin neue Revisionen erstellen. Der Nutzen ist Klarheit: Alle Beteiligten wissen, welche Version für den jeweiligen Zweck gültig ist — und vermeiden Fertigung/Review auf Basis eines Work‑in‑Progress‑Stands.
WeiterfĂĽhrende Links (optional)
Wichtige Quellen sind inline verlinkt. Hier gesammelt:
Ich bin Christina Rebel, CEO von CAD ROOMS. Seit über zehn Jahren arbeite ich an der Schnittstelle von Cloud‑Engineering‑Collaboration, digitaler Fertigung und verteilter Produktentwicklung.
Ich unterstütze Engineering‑ und Manufacturing‑Teams bei CAD‑Datenmanagement, Revisionskontrolle, Lieferanten‑Collaboration und browserbasierter Design‑Review. Zudem schreibe ich über Engineering‑Collaboration, u. a. mit Beiträgen bei Design News und DEVELOP3D.