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.

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 are automatically created when Windchill is installed.

For more information, see Site Administration.

Important business information stored in the organization context includes:

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 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:

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.

For more information, see Product and Library Administration.

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.

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;

Data created in the project context typically includes:

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.