Kontext-Anwendungsfall
Kontexte organisieren eine Windchill Datenbank so, dass sie mit der funktionalen Organisation Ihres Unternehmens im Einklang steht. Das folgende fiktive Szenario zeigt, wie unterschiedliche Kontexttypen gemeinsam bei der Verwaltung von Daten und Prozessen verwendet werden und wie Benutzer mit dem Windchill System interagieren können.
Situation
Construction Machinery Corporation (CMC) ist ein nordamerikanisches Unternehmen, das Erdbaumaschinen konstruiert, fertigt, verkauft und unterstützt. Das Unternehmen hat zwei Produktfamilien: Raupenschlepper und Radlader. Jede Produktfamilie hat mehrere Produktvarianten mit anderen Kapazitäten und Funktionen. Der Wettbewerbsvorteil des Unternehmens besteht darin, dass es ein Produkt gemäß den Kundenspezifikationen innerhalb einer kurzen Zeitspanne konfigurieren und liefern kann. Dies ermöglicht Kunden, die Größe und Kapazität der Maschine sowie die Zulieferer von Schlüsselkomponenten (wie Motor und Hydraulik) anzugeben. CMC kauft unter anderem folgende Komponenten ein: Motoren, Getriebe, Kühlsysteme, Luftfiltersysteme, hydraulische Komponenten, Räder und Reifen. CMC fertigt unter anderem Folgendes: Rahmen, Fahrerkabinen, Antriebssysteme, Kettenkomponenten und Befestigungen.
Kontexte "Standort" und "Organisation"
Die Kontexte "Standort" und "Organisation" werden automatisch erstellt, wenn Windchill installiert ist.
Der Kontext Standort stellt Verwaltungsfunktionen bereit, die verwendet werden, um die Windchill Installation zu erstellen und zu verwalten. Nur Standort-Administratoren können Informationen im Kontext "Standort" erstellen oder bearbeiten.
Weitere Informationen finden Sie unter Site-Verwaltung.
Der Kontext Organisation wird unter dem Kontext "Standort" erstellt. Der Kontext "Organisation" erfasst Standards und Unternehmensverwaltungsinformationen, die für ein bestimmtes Unternehmen spezifisch sind.
Wichtige im Kontext "Organisation" gespeicherte Unternehmensinformationen umfassen:
Teilnehmerinformationen – Benutzer, Gruppen und Teams.
Nummerierungs- und Versionierungsschemas – Standards für die CMC-Nummerierung und -Versionierung zur Identifizierung von Produktdaten.
Vorlagenverwaltung – Spezifische CMC-Vorlagen, die für die Standardisierung der Erstellung von Produkt- und Verwaltungsdaten verwendet werden.
Die Kontexte "Produkt", "Bibliothek" und "Projekt" werden unter dem Kontext "Organisation" erstellt, sodass auf Organisationsebene erfasste Standardmethoden konsistent auf alle Kontexte unter der Organisation angewendet werden können.
Weitere Informationen finden Sie unter Organisationsverwaltung.
Produktkontexte
Produktkontexte enthalten Informationen, die für ein bestimmtes Produkt oder eine bestimmte Produktfamilie spezifisch sind. CMC hat zwei Produktkontexte: einen für Raupenschlepper und einen für Radlader. Alle Produktdaten, die für eine Produktlinie spezifisch sind, werden im Produktkontext gespeichert. Beispielsweise gibt es sechs geschweißte Stahlrahmen für die sechs Raupenschlepper-Modelle, die von CMC verkauft werden. Sie werden im Raupenschlepper-Produkt gespeichert. Es gibt weitere vier geschweißte Stahlrahmen für unterschiedliche Radlader-Modelle. Diese werden im Radladerproduktkontext gespeichert.
Die Raupenschlepper- und Radladerproduktkontexte werden unter dem CMC-Organisationskontext erstellt und erben Rollen des funktionsübergreifenden Teams vom Organisationskontext.
Ein Produktteam bei CMC umfasst die folgenden Rollen:
Produktmanager
Design Supervisor
Designer
Fertigungsingenieur
Qualitätsingenieur
Produktionsplaner
Diese Rollen sind Teil einer Teamvorlage, die im CMC-Organisationskontext festgelegt wurde. Windchill Benutzer werden diesen Rollen in den Raupenschlepper- und Radladerproduktkontexten zugewiesen. Wenn eine neue Teileversion innerhalb eines Produktkontexts erstellt wird, identifizieren diese Rollen die Team-Mitglieder, die zugewiesen sind, um die neue Teileversion in der Produktion zu entwickeln und zu veröffentlichen.
Einige Standardmethoden variieren je nach Produktkontext und müssen auf Produktebene festgelegt werden. Beispielsweise durchläuft der Konstruktionsprozess für Radladerteile Lebenszyklusstatus, die sich von denen für Raupenschlepperteile unterscheiden. Daher werden für neue im jeweiligen Produktcontainer erstellte Teile Lebenszyklusvorlagen verwendet, die im Produktkontext und nicht im Organisationskontext definiert sind.
Der Objekttyp, der Kontext, in dem er sich befindet, sein Lebenszyklusstatus und die durch die Teamvorlage festgelegten Rollenzuweisungen bilden die Grundlage für Regeln, die steuern, wer Aktionen für Daten ausführen darf. Beispielsweise kann ein Benutzer mit der Designerrolle CAD-Dokumente mit dem Status "In Bearbeitung" erstellen, anzeigen und ändern, ein Fertigungsingenieur im selben Kontext jedoch nur CAD-Dokumente anzeigen.
* 
Objekte in einem Kontext können mit Daten in anderen Kontexten verbunden sein. Beispiel: Ein angepasstes Teil (wie eine Konsole für die Montage eines Scheinwerfers) kann im Raupenschlepper-Produktkontext erstellt, jedoch in einer Teilestruktur eines Radladers verwendet werden (vorausgesetzt, dass die Mitglieder des Radladerteams Raupenschlepperteile anzeigen können). Die Konsolenkonstruktion kann allerdings nur von einem Designer des Raupenschlepper-Produktkontextteams geändert werden.
Weitere Informationen finden Sie unter Produkt- und Bibliotheksverwaltung.
Bibliothekskontexte
Bibliothekskontexte enthalten Informationen, die für mehrere oder alle Produkte wichtig sind. Ein spezielles Team kann erstellt werden, das Zusätze zu einem Bibliothekskontext genehmigen darf. Spezielle Workflow-Prozesse können erstellt werden, um sicherzustellen, dass keine annehmbare allgemeine Komponente vor der Einführung einer neuen allgemeinen Komponente vorhanden ist. Bibliotheken können kleine Komponententeile umfassen (wie mechanische Befestigungen), größere angepasste Baugruppen, von Händlern bereitgestellte Teile und andere Objekttypen (wie Dokumente). Bibliotheken werden unter einem Organisationskontext erstellt.
CMC hat Standard-Komponentenbibliotheken erstellt, sodass allgemeine Teile in mehreren Produkten wiederverwendet werden können. Die Wiederverwendung von Komponenten führt zu größeren Kaufvolumen und niedrigeren Preisen. Standardbibliotheken erfassen auch allgemeine Referenzdokumente wie gesetzliche Standards oder Unternehmensspezifikationen und -verfahren.
Beispiel: Der Motor ist das wichtigste Teil jeder CMC-Maschine. Kunden geben ihren bevorzugten Motor aus einer Liste der verfügbaren Motoren an, wenn sie ihren Auftrag erteilen. Die Standardisierung auf einen Motorhersteller hilft dem Kunden, Ersatzteilbestände und Wartungskosten zu reduzieren. CMC hat eine Motorbibliothek mit allen Standardmotoren verschiedener Originalteilzulieferer erstellt.
CMC-Produkte müssen alle gesetzlichen Standards erfüllen. Beispielsweise sind die Dieselmotor-Abgasemissionen für Baugeräte über einen gesetzlichen Standard geregelt. Standarddokumente für Arbeitsmaschinen sind in der CMC-Bibliothek mit gesetzlichen Standards gespeichert.
Weitere Informationen finden Sie unter Produkt- und Bibliotheksverwaltung.
Projektkontexte
Ein Projekt ist ein Kontext, zu dem Personen eingeladen werden, um als funktionsübergreifendes Team an einem bestimmten Ziel zusammenzuarbeiten. Projektteams schließen Teilnehmer mit diesen allgemeinen Rollen ein:
Projektmanager
Team-Mitglieder
Gäste
Im Projektkontext erstellte Daten, umfassen in der Regel:
Projektplan mit Aktivitäten, Meilensteinen und zugeordneten Lieferbestandteilen.
Projektressourcen wie Material und Zubehör.
Innerhalb des Projekts erstellte Teile, Dokumente und CAD-Daten
Teile, Dokumente und CAD-Daten, die auch von anderen Projekten, Bibliotheken oder Produkten genutzt werden.
Durch die gemeinsame Nutzung können Daten in Produkt-, Bibliotheks- und Projektkontexten in ein neues Projekt kopiert und dort referenziert sowie temporär von allen Projektteam-Mitgliedern verwendet werden. Wenn das Projekt abgeschlossen ist, werden neue und geänderte Daten über strenge Konfigurationsmanagementprozesse in Produkte und Bibliotheken für die Produktionsfreigabe eingecheckt. Projekte werden unter einer Organisation erstellt.
Weitere Informationen finden Sie unter Projekte und Programme.
CMC arbeitet mit dem europäischen Baumaschinenunternehmen, Euro-Track, zusammen, um einen neuen Radlader spezifisch für den europäischen Markt zu konstruieren und zu fertigen. Das Projekt zur Konstruktion des neuen Radladers hat den Codenamen "Phoenix".Die neue Maschine soll kleiner und manövrierfähiger sein, um auf schmalen Straßen und beengten Baustellen eingesetzt werden zu können. Der Phoenix bietet auch eine Motoroption, die die strengen europäischen Emissionsstandards erfüllt. Der Phoenix wird sowohl von Euro-Track als auch von CMC vertrieben. Im folgenden Diagramm ist der unter dem CMC-Organisationskontext erstellte Projektkontext "Phoenix" dargestellt:
Der neue Phoenix-Lader basiert auf einer vorhandenen CMC-Konstruktion. Das europäische Unternehmen Diesel Power liefert den Motor für Phoenix, da dies die sauberere Wahl ist. CMC bietet den Diesel Power-Motor auf dem nordamerikanischen Markt an, da die US-Regierung aktuell strengere Abgas-Kontrollstandards in Betracht zieht. Das Konstruktionsteam muss sicherstellen, dass sowohl die europäischen als auch die US-amerikanischen Standards vom Phoenix erfüllt werden.
Ein funktionsübergreifendes Team aus CMC-, Euro-Track- und Diesel Power-Mitarbeitern wird eingeladen, am Phoenix-Projekt teilzunehmen. Daten im CMS-Radladerproduktkontext und den Bibliothekskontexten für Motoren und gesetzliche Standards können auch vom Phoenix-Projektkontext genutzt werden, sodass sie bei Bedarf angezeigt, ausgecheckt und geändert werden können. Die folgende Illustration zeigt die Team-Mitglieder und gemeinsam genutzten Daten:
Weitere Informationen über die gemeinsame Datennutzung finden Sie unter Daten zwischen Kontexten austauschen.
Ein Projektplan mit zugewiesenen Aktivitäten, ein Meilensteinplan und angegebene Lieferbestandteile werden innerhalb des Phoenix-Projektkontexts erstellt. Die Arbeit beginnt innerhalb des Projekts (Konstruktion des neuen Phoenix-Radladers). Wenn Schlüsselmeilensteine erreicht werden, werden die Lieferbestandteildaten in die entsprechenden Produkt- und Bibliothekskontexte eingecheckt, sodass sie für alle am Produktionsfreigabeprozess Beteiligten bereitstehen. Wenn sich das neue Produkt in Produktion befindet und das Phoenix-Projekt abgeschlossen ist, kann dem Projektkontext der Status "Abgeschlossen" zugewiesen werden. Sein Inhalt wird als Datensatz des gemeinsamen Entwicklungsprozesses beibehalten.
War dies hilfreich?