Bring engineering, manufacturing and partners around the product information their work needs. Make access, contribution and feedback part of a deliberate collaboration plan.
Explore product collaborationCollaborative product development connects the people who design, build, source and support a product around its shared information. PLM provides the product context for that work across teams and locations.
A useful discussion identifies the assembly, drawing or document being considered. For example, a manufacturing question about a mounting feature should point to the relevant definition rather than an unexplained screenshot.
Being able to see information does not make someone its author or approver. Establish what each participant can contribute and which owner evaluates the response. Permissions, selected applications and release state shape the available work.
Judge the benefit through a task someone needs to complete. These six perspectives connect product information with a specific decision or handoff, rather than promising the same result for every participant.
Prepare a build around an identifiable product structure. Establish which planning information comes from PLM and which comes from the connected manufacturing or enterprise system.
Which definition is the plan based on?
Explore BOM managementBring a process or prototype concern to the people responsible for the design. Include the relevant drawing and preparation context so the team can investigate the question before repeating the work.
What must be clarified before the next trial?
Explore process managementReach the drawing or instruction relevant to the assigned task. Define how the operator recognizes its applicability and what to do if the information does not match the work in front of them.
Does this instruction apply to this task?
Explore task-based accessConnect an observation with the product and the evidence needed to investigate it. A clear reference helps the responsible team distinguish a question, an issue report and a proposed corrective action.
What evidence will help explain this observation?
Explore quality managementPrepare the specifications a supplier needs for a quotation or response. Identify the recipient, the information being shared and the route for questions so the exchange has a defined boundary.
What does this supplier need to respond?
Explore supplier collaborationLocate supporting information for the product being serviced. Make its configuration recognizable before choosing a drawing or procedure, and agree how field observations return to the product owner.
Which product is being supported in the field?
Explore service process managementStart with one recurring handoff that loses time or context. A drawing review, supplier question or service-information request gives the team a concrete way to assess what needs to change.
Windchill and Windchill Navigate address different parts of the collaboration model. Choose the platform and access applications around the records, participants and tasks your organization needs to support.
WindchillMaintain the product foundation
Manage product information, its relationships and the processes that control it. Begin with the records engineers own and the product context other disciplines need to reference.
Review the data model, publishing setup, collaboration scope and permissions for the proposed environment.
Windchill NavigateBring the task to the participant
Provide focused applications for selected roles and tasks. Start with what a downstream participant needs to find or contribute, then evaluate the supported application around that job.
Application availability, viewing or contribution rights and entitlements depend on the selected setup. Confirm the user journey and any training needed.
For external participation, define the recipient, selected content and exchange process as a separate access decision.
Plan secure supply chain collaborationCollaboration takes shape around the product and the people working on it. These industry situations show where a shared reference can make a conversation more useful. Use the relevant industry guide to explore the wider development context, then choose one review or handoff to evaluate.
An electronics review can bring board, enclosure and software teams together. Make the interface and product references clear so a question about a connection or mounting feature reaches the discipline able to respond.
Which teams need the same interface reference to resolve this design question?
A program may involve several organizations contributing to a shared assembly. Agree the selected information, participant and expected response for a partner review, with a clear owner for the resulting questions.
What product context does this partner need for the review they are contributing to?
A machine design can involve engineering, plant preparation and service teams in different locations. Give a build-preparation discussion an identifiable assembly and drawing so local observations can return to the responsible product team.
How will a plant observation reach the owner of the relevant assembly or drawing?
Clarify the participant, reference and contribution before choosing how information will be shared.
Access, contribution and authoring are separate decisions. For example, a PDM-to-project shared reference is read-only. A PDM checkout creates a project-specific working version and locks the source; a copied document becomes an independent object. Define the action and permissions the work actually needs.
Not inherently. Object types, sharing filters, refresh actions, schedules and access can affect what a project exposes. Agree which version the review uses and how the team will refresh or replace that reference.
A prepared package can deliver a defined collection to a recipient outside the current instance. Supported formats, viewing tools and import capabilities vary. Confirm the recipient’s setup and agree a response channel and update process.
A published product representation can support review without requiring every participant to author in CAD. Available viewing, measurement or markup functions depend on the selected desktop/browser viewer, software release, publishing configuration and licenses; they are not identical in every environment.
Feedback records a question, observation or proposed response. The responsible team evaluates it and follows the required change, review and release process. A comment or markup is distinct from a CAD edit or formal approval.
Show us where a review or partner handoff loses the product reference.
We’ll help shape the access, responsibilities and next step around the work your team needs to do.