How many contexts?

[ptc-6810695]

We have been working with Windchill PDMLink (10.1) since 2012. Until now we have been using Windchill only for CAD, but now we want to incorporate everything into Windchill. We are therefore reviewing our routines and trying to adapt the "Windchill mindset". In this case, what is the Windchill philosophy regarding contexts?

• We have many different customers and projects in our organization. Should we create a new product context for each new project? (Our products is often “one of a kind”)
• Until now we have been using only one product context, with a folder structure representing our customers. Is there any downside to keep working this way?

Thanks,

Ørjan

[kpritchard]

(In my opinion) One of the main drivers for how many/what Contexts is about participation. In Windchill-speak this would be the make-up of the Context Team, and comes into play much more significantly when you start to use Change Management. The routing of the workflow is best done by resolving membership of a Context Team Role (rather than embedding a specific User in a workflow task).

There are other considerations, such as different access permissions.

Don't be shy about leveraging the linking capabilities in Windchill that enable relationships between data objects in different Contexts. An example of this might be Manufacturing Documents in separate Context "M", but linked to Parts within Context A.

I'd recommend having a look at starting to use the WTPart... very powerful. It's also a fairly big paradigm shift from "CAD is the thing" to the "Part is the thing, and CAD is one way of describing it".