Windchill の基本操作 > ユーザーインタフェースのナビゲーション > コンテキストの概要 > コンテキスト使用事例
  
コンテキスト使用事例
コンテキストは会社の機能的組織と一致する方法で Windchill データベースを整理します。次の架空のシナリオは、データとプロセスの管理においてさまざまなコンテキストタイプが使用され、各ユーザーが Windchill システムをどのように利用しているかを示しています。
シナリオ
Construction Machinery Corporation (CMC) は土工重機の設計、製造、販売、保守を行う北米の会社です。この会社にはクローラートラクターとホイールローダーの 2 つの製品ファミリーがあります。各製品ファミリーには、容量と機能がそれぞれ異なる複数の製品バリエーションがあります。この会社の競争上の強みは、顧客の仕様に沿った製品を短期間で構築および納入できる点にあります。これにより、顧客はマシンのサイズや容量だけでなく、エンジンや油圧系統などの主要構成部品のサプライヤも指定できます。CMC が購入するアイテムには、エンジン、トランスミッション、冷却システム、エアフィルタシステム、油圧系統構成部品、ホイール、タイヤなどがあります。CMC が製造するアイテムには、フレーム、運転室、駆動システム、クローラー構成部品、アタッチメントなどがあります。
サイトコンテキスト と組織コンテキスト
サイトコンテキストと組織コンテキストは Windchill のインストール時に自動的に作成されます。
「サイト」 コンテキストでは Windchill 環境の作成と管理に使用する管理機能が提供されます。サイトコンテキストではサイト管理者だけが情報を作成および編集できます。
詳細については、サイト管理を参照してください。
「組織」 コンテキストはサイトコンテキストの下に作成されます。組織コンテキストには、各会社に一意の規格とビジネス管理情報が取り込まれます。
組織コンテキストに保管される重要なビジネス情報には次のものがあります。
参加者情報 - ユーザー、グループ、チーム。
番号付けとバージョンのスキーム - 製品データの識別に使用される CMC の番号付けとバージョンの規格。
テンプレート管理 - 製品データと管理データの作成を標準化するために使用される、CMC に一意のテンプレート。
製品コンテキスト、ライブラリコンテキスト、プロジェクトコンテキストは組織コンテキストの下に作成され、組織レベルで取り込まれた標準作業手順をその組織の下のすべてのコンテキストに一貫して適用できます。
詳細については、組織管理を参照してください。
製品コンテキスト
製品コンテキストには特定の製品または製品ファミリーに一意の情報が含まれます。CMC にはクローラートラクターとホイールローダーの 2 つの製品コンテキストがあります。ある製品ラインに一意のすべての製品データが製品コンテキストに保管されます。たとえば、CMC が販売する 6 つのモデルのクローラートラクター用に 6 つの溶接スチールフレームがあります。これらはクローラートラクター製品に保管されています。各種モデルのホイールローダー用に 4 つの溶接スチールフレームがあります。これらはホイールローダー製品コンテキストに保管されています。
クローラートラクター製品コンテキストとホイールローダー製品コンテキストは CMC 組織コンテキストの下に作成されており、部門を越えて活動するチームの役割は組織コンテキストから継承します。
CMC の製品チームには次の役割があります。
製品マネージャ
設計監督者
デザイナー
製造技術者
品質工学エンジニア
生産計画担当者
これらの役割は CMC 組織コンテキストで定義されているチームテンプレートに含まれています。Windchill ユーザーはクローラートラクター製品コンテキストとホイールローダー製品コンテキストでこれらの役割に割り当てられます。いずれかの製品コンテキストで新しい部品バージョンが作成されると、これらの役割に基づいて、新規部品バージョンを開発して生産にリリースするチームメンバーが特定されます。
一部の標準作業手順は製品コンテキストによって異なり、製品レベルで定義する必要があります。たとえば、ホイールローダーの部品の設計プロセスは、クローラートラクター用に設計される部品とは異なるライフサイクル状態を遷移します。したがって、各製品コンテナで作成された新規部品では、組織コンテキストではなく製品コンテキストで定義されたライフサイクルテンプレートが使用されます。
オブジェクトタイプ、オブジェクトが存在するコンテキスト、オブジェクトのライフサイクル状態、チームテンプレートによって定義されている役割の割当すべてが、データに対して誰が操作を実行可能であるかを制御する規則の基準となります。たとえば、デザイナーの役割に割り当てられているユーザーは作業中状態の CAD ドキュメントを作成、表示、修正できますが、同じコンテキスト内の製造技術者は CAD ドキュメントを表示することだけが許可されます。
* 
あるコンテキスト内のオブジェクトを別のコンテキスト内のデータに関連付けることができます。たとえば、照明灯取り付けブラケットなどのカスタム設計部品をクローラートラクター製品コンテキストで作成し、ホイールローダーの部品構造で使用できます (ホイールローダーチームのメンバーがクローラートラクター内の部品を表示するためのアクセス権を持っている場合)。ただし、ブラケットの設計を修正する権限は、クローラートラクター製品コンテキストチームのデザイナーだけに制限されています。
詳細については、製品とライブラリの管理を参照してください。
ライブラリコンテキスト
ライブラリコンテキストには一部またはすべての製品に関連する情報が含まれます。ライブラリコンテキストへの追加を承認する特別なチームを作成できます。共通構成部品を新たに導入する前に許容可能な共通構成部品がまだ存在しないことを確認する特別なワークフロープロセスを作成できます。ライブラリには、メカニカルファスナーのような小さな構成部品、カスタム設計の大きなアセンブリ、ベンダー供給部品、ドキュメントなどのその他のタイプのオブジェクトを格納できます。ライブラリは組織コンテキストの下に作成されます。
CMC は標準構成部品ライブラリを作成して、複数の製品で共通部品を再利用できるようにしました。構成部品を再利用することによって、購買量が増え、価格が低下します。標準ライブラリには、政府規格や会社の仕様および手順などの共通の参考文書も取り込まれます。
たとえば、エンジンはすべての CMC マシンで最も重要な部品です。顧客は発注時にオプションのリストから好みのエンジンを指定できます。エンジン製造メーカーを 1 つに標準化することで、顧客はスペア部品の在庫を減らしてメンテナンス費用を削減できます。CMC は複数の OEM エンジンサプライヤから提供されるすべての標準エンジンを保管するエンジンライブラリを作成しました。
CMC の製品はすべての政府規格に準拠している必要があります。たとえば、建設機械用ディーゼルエンジンの排気エミッションは政府規格によって規制されています。産業機械用の規格ドキュメントは CMC 政府規格ライブラリに保管されています。
詳細については、製品とライブラリの管理を参照してください。
プロジェクトコンテキスト
プロジェクトは、特定の目標を持った、部門を越えて活動するチームとして協働するようユーザーを招待するためのコンテキストです。プロジェクトチームの参加者には次のような一般的な役割が割り当てられます。
プロジェクトマネージャ
チームメンバー
ゲスト
プロジェクトコンテキストでは一般的に次のようなデータが作成されます。
アクティビティ、マイルストーン、関連付けられている成果物があるプロジェクト計画。
材料や装置などのプロジェクトリソース。
プロジェクト内で作成された部品、ドキュメント、CAD データ。
別のプロジェクト、ライブラリ、または製品と共有される部品、ドキュメント、CAD データ。
共有することで、製品コンテキスト、ライブラリコンテキスト、プロジェクトコンテキストに含まれているデータを参照したり新しいプロジェクトにコピーしたりして、そこですべてのプロジェクトチームメンバーが一時的にそのデータを使用できます。プロジェクトが完了すると、新しいデータと修正されたデータは製品とライブラリにチェックインされ、堅牢なコンフィギュレーション管理プロセスを介して生産にリリースされます。プロジェクトは組織の下に作成されます。
詳細については、プロジェクトとプログラムを参照してください。
CMC はヨーロッパの重機会社である Euro-Track と契約関係を結び、ヨーロッパの市場向けに新しいホイールローダーを設計および製造することになりました。この新しいホイールローダーを設計するプロジェクトには "Phoenix" というコードネームが付きました。新しいマシンはより小型で機動性が高いので、狭い道路や建築現場で作業できます。Phoenix はヨーロッパの厳格な排ガス規制を満たすエンジンのオプションも提供します。Phoenix は Euro-Track と CMC の両方から販売されます。次の図では、Phoenix プロジェクトコンテキストが CMC 組織コンテキストの下に作成されています。
新しい Phoenix ホイールローダーは CMC の既存の設計をベースにしています。Phoenix のエンジンには、よりクリーンなヨーロッパ用のエンジンとして、Diesel Power が選択されました。CMC は、米国政府によってさらに厳しい排ガス規制が検討されていることを見込んで、北米でも Diesel Power のエンジンを提供する予定です。設計チームは Phoenix の設計がヨーロッパと米国の両方の規格を満たすようにする必要があります。
CMC、Euro-Track、Diesel Power の従業員から構成される、部門を越えて活動するチームが、Phoenix プロジェクトへの参加を要請されました。CMS ホイールローダー製品コンテキストとエンジンおよび政府規格のライブラリコンテキストに含まれているデータは Phoenix プロジェクトコンテキストと共有されているため、これらのデータを必要に応じて表示、チェックアウト、修正できます。次の図に、チームメンバーと共有データを示します。
データ共有の詳細については、コンテキスト間でのデータの交換を参照してください。
アクティビティとマイルストーンスケジュールが割り当てられて成果物が指定されているプロジェクト計画が Phoenix プロジェクトコンテキスト内に作成されています。このプロジェクトにおける作業は、新しい Phoenix ホイールローダーの設計から始まります。キーマイルストーンを達成すると、成果物データが適切な製品コンテキストとライブラリコンテキストにチェックインされ、生産リリースプロセスに関与するすべての人がそのデータにアクセス可能になります。新しい製品が生産されて Phoenix プロジェクトが完了すると、プロジェクトのコンテンツは共同開発プロセスのレコードとして残したまま、プロジェクトコンテキストに完了ステータスを割り当てることができます。