Skip to main content
S
sdrzewiczewski10-Marble
10-Marble
December 28, 2009
Question

Project, Products and Libraries - how do you define their uses?

  • December 28, 2009
  • 21 replies
  • 8872 views

I had a user recently ask how they should be using the three different types of contexts. We have some legacy contexts that don't necessarily make sense, or at least aren't consistent with how we currently use them. So I'm looking to give them some more concrete guidelines of how to use them. Plus in the process hopefully clean up some of the older contexts and consolidate our active context list.

Thanks,
Steve D.

21 replies

Z
ZacharyAlexande1-Visitor
1-Visitor
January 4, 2010
PTC defines each of the separate containers

*Product* containers are intended to be used to manage product specific data
• Examples of product containers: drill, engine, cellular phone, combine
harvester, bicycle etc.
Organization Administrators and users in the Product Creator role can create
new product
containers
• Product container is hosted by the organization that the user who created
it is affiliated to


*Library *containers are intended to be used to manage general documentation
or reusable product
information such as standards and templates
• Examples of library containers: Marketing Documents, Supplier Information,
Industry
Standards, Shared CAD components, Drawing templates, etc.
Organization Administrators and users in the Library Creators role can
create new libraries
• Library container is hosted by the organization that the user who created
it is affiliated to


A *project *is an on-line work area used to collect information that teams
need to track, collaborate,
and manage as well as plan work activities to meet a specific objective.
• For example, you could create a project to coordinate the deliverables and
activities
associated with the blade design for one or more bulldozers.
• The project provides the context in which you collaborate to manage this
information, where
only those with defined roles have access to the information.
Projects are application containers, and are created in the container
hierarchy in the same way
as products, libraries and programs

Hope this helps,



On Mon, Dec 28, 2009 at 2:56 PM, Stephen Drzewiczewski <
-> wrote:

> I had a user recently ask how they should be using the three different
> types of contexts. We have some legacy contexts that don't necessarily make
> sense, or at least aren't consistent with how we currently use them. So I'm
> looking to give them some more concrete guidelines of how to use them. Plus
> in the process hopefully clean up some of the older contexts and consolidate
> our active context list.
>
> Thanks,
> Steve D.
>
R
rmp.pe1-Visitor
1-Visitor
January 6, 2010

The things Zachary mentions are all correct. We use them the same way. The challenge is how granular you make them.

Ideally, each context has a team assigned, and that team is then used to manage workflows and approvals... it eliminates the need to manually assign your CRB/CIB, etc. However, PTC has said for years that you shouldn't have too many products or libraries as it will impact performance. If you are a large company that has hundreds (even thousands) of products, you don't want to have an individual product context for each one. Besides performance, the other benefit is less administration, both from the standpoint of fewer locations to add new users to as well asfewer contexts to apply ACL and OIR changes when you make a system-wide change. Also, you want to try to avoid changes that impact multiple contexts at the same time, as approvals can become a nightmare.

We have tried to find a balance by grouping multiple End Items (products) into a single product container. Using Zachary's examples, under the "Engines" product I might have a 289 engine, 302 engine , 351W, 351C, 390, 427, 428SCJ and 429 (can you tell I'm a Ford guy? 🙂 ) instead of an individual product context for each engine. This works for us because all Engines are typically manufactured at the same location, hence they all follow the same design control procedures and will be administered by the same Change Admin 1/Doc Control Coordinator. How you decide to group them is up to you. You will have to consider the usability of the context once created.

Regards,

Bob Priest

Engineering Manager

STERIS Corporation

H
HugoHermans12-Amethyst
12-Amethyst
January 6, 2010
Hi Bob,



1/

What would you do when a product is being redesigned significantly, a new generation? Would you set up a new container?



2/

I've seen an approach where CAD-parts had their libraries, low-level assemblies and drawings had other libraries, and top-level assemblies and drawings were organised in products. Rather weird to my opinion, but these people felt confortable with it.



Kindest regards,

Mit freundlichen Grüßen,

Met vriendelijke groeten,



Hugo Hermans





- <">mailto:->



NV Michel Van de Wiele

Michel Vandewielestraat 7

8510 Kortrijk (Marke)

Tel : +32 56 243 211

Fax: +32 56 243 540

BTW BE 0405 450 595

RPR Kortrijk


Z
ZacharyAlexande1-Visitor
1-Visitor
January 6, 2010
Hugo,
1/What would you do when a product is being redesigned significantly, a new
generation? Would you set up a new container?

In Windchill, each part has it's own version which it a combination of
revision.iteration (i.e., A.1 -> A.2 -> B.1). Major changes can be
distinguished by a change in revision while small changes only change the
iteration. Windchill keeps tracks of all changes and still allows access to
the previous versions. Is this what you were looking for or are you looking
for a more drastic way to show that a major change has occured?

2/I’ve seen an approach where CAD-parts had their libraries, low-level
assemblies and drawings had other libraries, and top-level assemblies and
drawings were organised in products. Rather weird to my opinion, but these
people felt confortable with it

People organize data in a lot of different ways. A lot of companies
organized it this way when using commonspaces. You keep commonly used small
parts and assemblies in a Library so that everyone who needs them can use
them and put them in a Project. It saves a lot of trouble having one place
to be able to pull store all the parts you may need for top-level
assemblies.

Hope this helps,
Zack



On Wed, Jan 6, 2010 at 10:19 AM, Hermans Hugo <->
wrote:
>
> Hi Bob,
>
>
>
> 1/
>
> What would you do when a product is being redesigned significantly, a new
generation? Would you set up a new container?
>
>
>
> 2/
>
> I’ve seen an approach where CAD-parts had their libraries, low-level
assemblies and drawings had other libraries, and top-level assemblies and
drawings were organised in products. Rather weird to my opinion, but these
people felt confortable with it.
>
>
>
> Kindest regards,
>
> Mit freundlichen Grüßen,
>
> Met vriendelijke groeten,
>
>
>
> Hugo Hermans
>
>
>
>
>
> -
>
>
>
> NV Michel Van de Wiele
>
> Michel Vandewielestraat 7
>
> 8510 Kortrijk (Marke)
>
> Tel : +32 56 243 211
>
R
rmp.pe1-Visitor
1-Visitor
January 6, 2010
Zack,
Generally for us, iterations are used for design history when working on a particular version of a part (it records the checkout/checkin process history). Once that version is approved and in a "released" state, it is no longer iterated (released items are locked), and we create a new revision in the "in work" state. Our manufacturing group can only use parts in the "Released" state... they can use nothing that can be checked out and modified.

Hugo,
1/
That depends on the nature of the redesign.

*
If you are simply making improvements to an existing product, you would revise the top-level product and keep the same end item number (and thus same location).
*
If you are creating a whole new end item and it is "new and improved" over the current product, but has the same basic functionality, I'd keep it in the same product container as well (i.e. if I have an existing 351 motor but want to create a new one with dual overhead cams, I'd keep it in the same "engines" product container). You'll be re-using most of the parts from the old engine in the new one, so there is a benefit to have it all in the same place.
*
If you are creating a new product that doesn't fit into the existing product schema, you might want a new product container (or move it to another existing one with a better fit). For example if I had a 351 gasoline engine and wanted to make an electric motor to replace it, I might move it from "Engines" to my "Electric Motors" product container.

Again, the granularity is going to be company-specific. You may have "Engines" broken into "Small Engines" and "Large Engines", or "Gas" and "Diesel", or "4-cylinder", "6-cylinder" and "8-cylinder".

2/
I've heard of different ways to organize data as well, including the one you mention below. We choose to have all information needed to manufacture, maintain and service a product in the product container. So we have parts/end items, assemblies, CAD docs, manufacturing assembly instructions, work instructions, labeling, manuals, etc all in the Product Container. We then have site specific libraries for documentation that does not directly impact our ability to manufacture and maintain our products. Each site library has reports, procedures, protocols, quality plans, etc. The R&D library also contains design history files, test reports, etc. The average Joe on the shop floor doesn't need access to the items in the various libraries other than perhaps the one for their site. This allows us to maintain security around this data (particularly for the R&D data which we don't want shared with people outside of R&D). We do also have a library set up for all of our Pro/E forms and templates however and that works well. Everyone sets their config.pro to find the formats in Windchill in that library and everyone is using the same files.

Regards,
Robert M. Priest, PE, PMP
Engineering Manager
STERIS Corporation

Phone: +1 440 392 7740
Email: -<blocked::<a style="COLOR:" blue;=" text-decoration:=" underline&quot;=" target="_BLANK" href="mailto:-">">mailto:->
P
patrick.chin11-Visitor
1-Visitor
January 7, 2010
Projects
• are usually to manage sharing of data between ODM/OEMs
• are also used to manage updates to MSProject Schedules for tracking of ECNs and ECRs. Most Program Managers only care about the the delivery of the top and what is causing the delay which is usually packaged in ECNs and ECRs. It is extremely difficult to manage every object of the package in a MS Schedule. Most Project Manager would just like to know if it is done.
Libraries
• multiple libraries are created for each functional group
o electrical
o mechanical
o RF
o technical publications
o legal
o manufacturing
o marketing
o purchase components (external intellectual property like nuts, resistors, etc)
o standards/documentation library (specifications, formats, configuration)
o etc
• usually these libraries have specific functional group data for people who can review and approve because it's their specific focus of expertise
• I usually place the mechanical representation of electrical components in the electrical library because it requires the approval from the electrical team for layouts and board sizing.
• most items here can be reused by the functional groups - if there is a require need to create a more secure group of items, place in a sub folder and create access domains.
• for these library specific functional groups, specialized users/approvers like purchasing agents can be assigned to the roles so that there is no need to assign these roles.
• IP owned Mechanical component Parts CAD can stay in 3 Libraries like Mechanical, Electrical and Purchase Components. Supplier or OEM CAD can stay in their own Organizational context libraries tied to their own organization id. (You may need supplier management to create MFG parts). Of course top secret items should really get their own libraries/organizations. ITAR stuff can be placed in ITAR respective libraries such as ITAR_Mechanical, ITAR_Electrical, etc.
Products
• This really needs the help of PartsLink to classify and categorize your Products.
• If you don't have PartsLink, I usually create a Product containers base on their top level family, then create sub-level folders to handle the model types.
• In our workflows we usually use setup participants for ECNs and object level. Sometimes it is a revolving door of development and sustaining people. If the group is static, you can create teams and select from teams. For every product context you create, it will create a product part object. The question is do you need to release it or assignments will start building up. The difficultly of having too much product containers, libraries and projects/programs is that it is difficult for people to collaborate and reuse because you have to constantly manage the team with in each context. There are instances where there will be hundreds of product containers and it becomes extremely difficult to reapply security controls and searching for products becomes the same as searching a part in a large itemized folder. Thus, the need to classify your products/parts in PartsLink.

Here's a MSProject Schedule that I use to usually structure the implementations. If you are thinking from an Pro/I perspective, you have to break your train of thought. PLM will manage all functional group documentation moving forward. Like shared network drives, every department likes to have their own folder/library where they can constantly have access to update and improve designs/documentation. There is really many other ways you can slice this solution, it all depends on the level of implementation.
P
patrick.chin11-Visitor
1-Visitor
January 8, 2010

Hopefully doing this in IE hasa better format

Projects
· are usually to manage sharing of data between ODM/OEMs
· are also used to manage updates to MSProject Schedules for tracking of ECNs and ECRs. Most Program Managers only care about the the delivery of the top and what is causing the delay which is usually packaged in ECNs and ECRs. It is extremely difficult to manage every object of the package in a MS Schedule. Most Project Manager would just like to know if it is done.
Libraries
· multiple libraries are created for each functional group
o electrical
o mechanical
o RF
o technical publications
o legal
o manufacturing
o marketing
o purchase components (external intellectual property like nuts, resistors, etc)
o standards/documentation library (specifications, formats, configuration)
o etc
· usually these libraries have specific functional group data for people who can review and approve because it's their specific focus of expertise
· I usually place the mechanical representation of electrical components in the electrical library because it requires the approval from the electrical team for layouts and board sizing.
· most items here can be reused by the functional groups - if there is a require need to create a more secure group of items, place in a sub folder and create access domains.
· for these library specific functional groups, specialized users/approvers like purchasing agents can be assigned to the roles so that there is no need to assign these roles.
· IP owned Mechanical component Parts CAD can stay in 3 Libraries like Mechanical, Electrical and Purchase Components. Supplier or OEM CAD can stay in their own Organizational context libraries tied to their own organization id. (You may need supplier management to create MFG parts). Of course top secret items should really get their own libraries/organizations. ITAR stuff can be placed in ITAR respective libraries such as ITAR_Mechanical, ITAR_Electrical, etc.
Products
· This really needs the help of PartsLink to classify and categorize your Products.
· If you don't have PartsLink, I usually create a Product containers base on their top level family, then create sub-level folders to handle the model types.
· In our workflows we usually use setup participants for ECNs and object level. Sometimes it is a revolving door of development and sustaining people. If the group is static, you can create teams and select from teams. For every product context you create, it will create a product part object. The question is do you need to release it or assignments will start building up. The difficultly of having too much product containers, libraries and projects/programs is that it is difficult for people to collaborate and reuse because you have to constantly manage the team with in each context. There are instances where there will be hundreds of product containers and it becomes extremely difficult to reapply security controls and searching for products becomes the same as searching a part in a large itemized folder. Thus, the need to classify your products/parts in PartsLink.

Here's a MSProject Schedule that I use to usually structure the implementations. If you are thinking from an Pro/I perspective, you have to break your train of thought. PLM will manage all functional group documentation moving forward. Like shared network drives, every department likes to have their own folder/library where they can constantly have access to update and improve designs/documentation. There is really many other ways you can slice this solution, it all depends on the level of implementation.

P
patrick.chin11-Visitor
1-Visitor
January 8, 2010
Here are the access controls I usually work out with each functional group in terms of Policy Administration and Lifecycle/Workflow. It takes a while to complete. But once done, life is so much easier to administrate.
T
tbusch1-Visitor
1-Visitor
January 14, 2010

This is a great thread, lots of interesting information on an area I've also been trying to figure out. Does anyone have any insight on how to use Programs effectively in this context?

-Tom

H
HugoHermans12-Amethyst
12-Amethyst
January 14, 2010
I've read in the Business Admin guide that a Program is a collection of Projects.



Kindest regards,

Mit freundlichen Grüßen,

Met vriendelijke groeten,



Hugo Hermans





- <">mailto:->



NV Michel Van de Wiele

Michel Vandewielestraat 7

8510 Kortrijk (Marke)

Tel : +32 56 243 211

Fax: +32 56 243 540

BTW BE 0405 450 595

RPR Kortrijk


Show more replies
Terms & ConditionsCookie settingsAccessibility statement