Fundamentals > Navigating the User Interface > Contexts Overview > Context Use Case
  
Context Use Case
Contexts organize a Windchill database in a manner that is consistent with the functional organization of your company. The following fictitious scenario illustrates how different context types are used together in the management of data and processes, as well as how users might interact with the Windchill system.
Scenario
Construction Machinery Corporation (CMC) is a North American company that designs, manufactures, sells, and supports heavy earth-moving equipment. The company has two product families: crawler tractors and wheel loaders. Each product family has multiple product variants with different capacities and capabilities. The company�s competitive advantage is its ability to configure and deliver a product to customer specifications within a short period of time. This allows customers to specify the size and capacity of the machine as well as the suppliers of key components, such as the engine and hydraulics. Items that CMC purchases include: engines, transmissions, cooling systems, air filtration systems, hydraulic components, wheels, and tires. Items that CMC manufactures include: frames, cabs, drive systems, track components, and attachments.
Site and Organization Contexts
Site and organization contexts are automatically created when Windchill is installed.
The Site context provides administrative functions that are used to create and manage the Windchill installation. Only site administrators can create or edit information in the site context.
For more information, see Site Administration.
The Organization context is created beneath the site context. An organization context captures standards and business administrative information are unique to a specific company.
Important business information stored in the organization context includes:
Participant information �Users, groups, and teams.
Numbering and versioning schemes�CMC numbering and versioning standards used to identify product data.
Template administration�Templates unique to CMC that are used to standardize the creation of product and administrative data.
Product, library, and project contexts are created beneath the organization context so that standard practices captured at the organization level can be consistently applied to all contexts beneath the organization.
For more information, see Organization Administration.
Product Contexts
Product contexts contain information that is unique to a specific product or product family. CMC has two product contexts: one for crawler tractors and another for wheel loaders. All product data that is unique to a product line is stored in the product context. For example, there are six welded steel frames for the six models of crawler tractor sold by CMC. They are stored in the crawler tractor product. There are another four welded steel frames for different models of wheel loaders. These are stored in the wheel loader product context.
The Crawler Tractor and Wheel Loader product contexts are created beneath the CMC organization context and inherit cross-functional team roles from the organization context.
A product team at CMC contains the following roles:
Product Manager
Design Supervisor
Designer
Manufacturing Engineer
Quality Engineer
Production Planner
These roles are part of a team template that has been defined in the CMC organization context. Windchill users are assigned to these roles in the Crawler Tractor and Wheel Loader product contexts. When a new part version is created within either product context, these roles identify the team members assigned to develop and release the new part version in production.
Some standard practices vary by product context and must be defined at the product level. For example, the design process for wheel loader parts passes through life cycle states that are different from parts designed for crawler tractors. Therefore, new parts created in each product container utilize life cycle templates defined in the product context rather than the organization context.
The object type, the context where it resides, its life cycle state, and the role assignments defined by the team template all provide the basis for rules that control who is allowed perform actions on data. For example, a user assigned to the Designer role can create, view, and modify CAD documents in the in-work state, but a Manufacturing Engineer in the same context is only permitted to view CAD documents.
* 
Objects in one context can be related to data in other contexts. For example, a custom designed part such as a bracket for mounting a floodlight can be created in the Crawler Tractors product context but used in a part structure of a wheel loader (provided that the members of the Wheel Loaders team have access to view parts within Crawler Tractors). However, the right to modify the bracket design is reserved for a designer on the Crawler Tractors product context team.
For more information, see Product and Library Administration.
Library Contexts
Library contexts hold information that is relevant to several or all products. A special team can be created to approve additions to a library context. Special workflow processes can be created to insure that no acceptable common component already exists prior to the introduction of a new common component. Libraries can contain small component parts like mechanical fasteners, larger custom-designed assemblies, parts supplied by vendors, and other object types such as documents. Libraries are created beneath an organization context.
CMC has created standard components libraries so that common parts can be reused in multiple products. Component reuse results in larger purchase volumes and lower prices. Standard libraries also capture common reference documents such as government standards or company specifications and procedures.
For example, the engine is the most important part of any CMC machine. Customers specify their preferred engine from a list of available choices when they place their order. Standardizing on one engine manufacturer helps the customer reduce inventories of spare parts and lower maintenance costs. CMC has created an Engine library to hold all standard engines from multiple original equipment engine suppliers.
CMC products must comply with all governmental standards. For example, diesel engine exhaust emissions for construction equipment are controlled by a government standard. Standards documents for off-road machinery are stored in the CMC Government Standards library.
For more information, see Product and Library Administration.
Project Contexts
A project is a context to which people are invited to collaborate as a cross-functional team with a specific goal. Project teams include participants with these general roles;
Project Manager
Team Members
Guests
Data created in the project context typically includes:
A project plan with activities, milestones, and associated deliverables.
Project resources such as material and equipment.
Parts, documents, and CAD data created within the project
Parts, documents, and CAD data shared from another project, library, or product.
Sharing provides the ability to copy or reference data contained in product, library, and project contexts to a new project where it can be temporarily used by all project team members. When the project is complete, new and modified data is checked in to products and libraries for release to production through rigorous configuration management processes. Projects are created beneath an organization.
For more information, see Projects and Programs.
CMC has entered into a contractual relationship with a European heavy equipment company, Euro-Track, to design and manufacture a new wheel loader specifically for the European market. The project to design the new wheel loader has been code-named �Phoenix.� The new machine will be smaller and more maneuverable allowing it to operate in narrow streets and confined building sites. Phoenix will also offer an engine option that meets strict European emissions standards. Phoenix will be marketed by both Euro-Track and CMC. The following diagram shows the Phoenix project context created beneath the CMC organization context:
The new Phoenix loader will be based upon an existing CMC design. Diesel Power, the cleaner European engine choice, has been chosen to provide the engine for Phoenix. CMC will offer the Diesel Power engine to the North American market in anticipation of more strict emission control standards currently under consideration by the U.S. government. The design team must make sure that both the European and U.S. standards are met by the Phoenix design.
A cross-functional team made up of CMC, Euro-Track, and Diesel Power employees is invited to participate in the Phoenix project. Data contained in the CMS Wheel Loaders product and the Engines and Government Standards library contexts is shared to the Phoenix project context so that it may be viewed, checked out, and modified as necessary. The following illustration shows the team members and shared data:
For more information about data sharing, see Exchanging Data Between Contexts.
A project plan with assigned activities, a milestone schedule, and specified deliverables is created within the Phoenix project context. Work begins within the project to design the new Phoenix wheel loader. When key milestones are reached, the deliverable data is checked in to the appropriate product and library contexts, making it available for all persons involved in the production release process. When the new product is in production and the Phoenix project is complete, the project context can be assigned a completed status, preserving its content as a record of the collaborative development process.