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

[sdrzewiczewski]

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.

[ZacharyAlexande]

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

[rmp.pe]

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

[HugoHermans]

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

[ZacharyAlexande]

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
>

[rmp.pe]

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

[patrick.chin1]

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.

[patrick.chin1]

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.

[patrick.chin1]

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.

[tbusch]

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

[HugoHermans]

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

[tbusch]

Right, but what would a program represent, business-wise? A product line?

-Thomas R. Busch
Sr. Software Developer
Stryker Instruments
(269) 323-7700 x4014
tom.busch@stryker.com<">mailto:tom.busch@stryker.com>

[patrick.chin1]

Mit is abosutely right that a program is a collection of projects. In Program management, the Program can have anetwork of projects delivering many components of the top product or different lifecycle states of the Program. This Program functionality goes beyond the simplistic methodologies of PIM/PMP which follows a cascading approach and single project. If you use projects to manage your ECNs of the major components and link then to Program, your program managers and management is going to love you.

[patrick.chin1]

Sure, I’ll prepare a little slide for you. It will take some time though but it’s the overall solution. The worst thing to do in Windchill Projects is to manage every little object. The best practice is to have actually Projects manage ECNs which is a package of objects that are being released. I could draw that architecture with you and show you with Program and ProjectLink. You will probably have a top ECN to create and release the overall Product. After the TOP ECN is release which is tied to a Project of Product Development Product A, you can create another TOP ECN called Product Sustaining Product A, then Product Obsolescence Product A. Under these top Projects, you can have groups of major components that are tied to bunch of ECNs to deliver that product. Like I said, most program managers and projects managers like to know the risk of not making the timeline. They would like to know what is causing the delay and cost. With CMII and monitoring each cost of ECN packages with reports of object changes, they don’t have the time to look at the details just help alleviate or make executive decisions to move forward.

The last sides are very important. Most companies place one enterprise ECN. Those are mostly ERP biased or focused. Most engineering focused companies like aerospace and military are document centric. So you don't want to change those documentation based on a manufacturing or supply change. This is actually bad practice, because the volume of documentation is the inverted triangle shown on page 9 of 9 of my attachment. If you catagorize your ECNs by the various organization functions it would be easier to manage deliver the ECNs at the point in time of the Programs and Projects. Most marketing or requirements (RCNS) would be the start of most Programs and Project.

When completed, the engineering will commense with an approval of an ECN. This is in page 8 of 9 of my attachment. This way, the functional groups in the down stream will be informed and probably be in the approval process of the Change notices up the process path.

The Program Functionality of PTC's PDMLink and ProjectLink is probably the most value tool in any PLM tool for management staff. I don't believe any other PLM tool can have that complete solution of managing from objects, ECNs, projects, to programs. If integrate ProjectLink with ProjectServer for resource allocation tied to the roles, wow. We have not done that integration yet, but it is definitely in the wood works. It is really important that you have also top down release with PTC ECNs that will release the entire package of associated CAD with their describing or related CAD and create baselines at each release with a report of what their states were previously before the ECN forced the release. Like I said, there are some executive decisions that are made to release packages with the knowlege of items that were not completely reviewed.

[patrick.chin1]

Just to clarify, I meant it was bad practice to create an 1 encompassing enterprise ECN which are ERP focused. Most aerospace, automotive, military use different functional change notices to group and separate the changes of information within the organization.

[patrick.chin1]

Here is the basic concept of Programs, Projects, Products and Libraries.

See attached PDFs.

This is what I meant by having the ECRs and ECNs packages to be the milestones of the schedules. You can title them by componet level or product.

[egifford]

Good thread. I'm currently getting Windchill PDMlink set up on a pair of virtual servers to work the kinks out of the process. The way the PTC training and trainer described Organizations, Products, etc had me thinking I'd have to have 7 or 8 Organizations to cover our different product enginering departments (different families of product), manufacturing engineering, machine shop etc. who all use Pro/E...followed by a "product" for each shippable P/N under each Org....it started to look unecessarily difficult to set up and manage. From this and after talking to an applications engineer it would seem I would be better off creating one company "organization", establishing each engineering department or group as a Product and organizing the data below that in folders (similar to what we have in Intralink 3.4 - folders to organize library data, a folder for each job (shippable P/N) etc. ). I just wanted to bounce this off some others out there to make sure I'm reading this correctly and heading down the right path.

Thanks

Erik Gifford

G.W. Lisk Co., Inc.

[MikeLockwood]

It takes some real effort to modify the approach from Intralink 3.x, but pays off later in many areas.

Strong recommendation is set up Product contexts mapped to what you manufacture and sell to customers, not at all by department or internal function - teams later on can be set up by department or internal function. Each Product Context can be a "product line" with many actual end items / complete product assemblies.

Note

- Product contexts have a filter on the Details page for "End Items" which are the products that you sell, with the intent that you can drill down from there.

- Libraries differ from Products pretty much only in that they do not include the End Item functionality. Use Libraries in general for shared items, along with Drawing Format files, etc.

Another major consideration is whether to put all needed user permissions (ACLs) in each Product/Library or move all that are common one level higher (the Organization). More flexible to have them in each Product/Library and this is how they are OTB, but a maintenance nightmare results.

[achukwuka]

I completely agree with Mike on this. In my environment, products are setup along the lines of what we manufacture and sell to customers, i.e series engines and etc. Then we created libraries that corresponds to each product for document management.


Thanks

Alexius C. Chukwuka
IT Analyst, PDP Systems
John Deere Power Systems
Product Engineering Center
*Voice: 319-292-8575
*Mobile: 319-429-5336
*Fax:319-292-6282
*E-Mail: -
CONFIDENTIALITY. This electronic mail and any files transmitted with it may contain information proprietary to Deere & Company, or one of its subsidiaries or affiliates, and are intended solely for the use of the individual or entity to whom they are addressed, shall be maintained in confidence and not disclosed to third parties without the written consent of the sender. If you are not the intended recipient or the person responsible for delivering the electronic mail to the intended recipient, be advised that you have received this electronic mail in error and that any use, dissemination, forwarding, printing, or copying of this electronic mail is strictly prohibited. If you have received this electronic mail in error, please immediately notify the sender by return mail.
From: Lockwood,Mike,IRVINE,R&D [

[egifford]

Mike - I think half the battle is what you stated first, trying to understand the best approach intended with Windchill vs. just trying to closely duplicate what we have in Intralink 3.4.

Our intralink strucure basically reflects our company structure. A folder for each product group, with sub-folders to organize into jobs, libraries etc. It works.In our case each product group typically serves a different idustry segment or has a different product type (i.e. Military and Aerospace Solenoids & Valves, Diesel and Commercial Valves, AC & Hazardous Duty Solenoids, LVDTs....etc) and the access rights flow accordinglywith groups of usersto isolate who can do what where and allowingread-onlycross-utilization of components between groups (i.e. an AC group coil on a Commercial Group Valve, an LVDT on a Military & Aerospace Valve system). There is also a company-wide library of shared hardware for basic items like fasteners, magnet wire, epoxy and such that everyone uses, but only certain users have rights to modify.

What I need to do in Windchill is organize all the information so that users can easily see the data for the group they work in, find the data they need from other groups, but not have to wade through a bunch of extraneous "products" to do either. Keep in mind that each engineering group could have several thousand products in the sense of a product being an end-item sold to a customer in addition to their own library of components.Theidea of teams is a little gray too, in the sense that for a particular end-item, the CAD data can be worked on by anyone in the designer / drafter role within that group. The person assigned as project manager,engineer, QA approver, regulatory signoffetc are generally pretty fixed from when the job is initially assigned, but the associated functionality within Windchill (electronic approvals by role etc) is something we don't plan to implement for quite some time, but I want to be able to accomdate later.

So, again, it comes back to do I have multiple organizations or one? With one organization and "products" being the end item, wouldn't I have one flat structure of 12-15 thousand products and have to buildgroups of usersand teams to isolate the access rights accordingly? If I have multiple organizations how difficult / easy is it to have the necessary inter-group cross-utilization?

Thanks!

Erik

[davehaigh]

One thing I didn't see anyone mention is even if have one Organization, you can create multiple Product Templates. Each Engineering group can have their own template with their own groups of users assigned to various team roles. That way when they create a new product all the roles are already assigned. You just add and remove users from the groups to give them access to the products created with that template. Each template can have its own lifecycle also. I'd suggest that they all have the same release states, but the process of approval could be different for each one.

The other reason to have a product for each product line is in your Product template you can set up default folders for various soft types. If you set up the OIR's for these types, you can segregate documents into folders based on their type. This makes it easier for a casual user to browse for say, a quote, or an ECN.

David Haigh

[RandyJones]

On 08/16/10 13:13, Erik Gifford wrote:
> Good thread. I'm currently getting Windchill PDMlink set up on a pair of
> virtual servers to work the kinks out of the process. The way the PTC training
> and trainer described Organizations, Products, etc had me thinking I'd have to
> have 7 or 8 Organizations to cover our different product enginering departments
> (different families of product), manufacturing engineering, machine shop etc.
> who all use Pro/E...followed by a "product" for each shippable P/N under each
> Org....it started to look unecessarily difficult to set up and manage. From this
> and after talking to an applications engineer it would seem I would be better
> off creating one company "organization", establishing each engineering
> department or group as a Product and organizing the data below that in folders
> (similar to what we have in Intralink 3.4 - folders to organize library data, a
> folder for each job (shippable P/N) etc. ). I just wanted to bounce this off
> some others out there to make sure I'm reading this correctly and heading down
> the right path.

That is what we are doing. One Product for each engineering group. One Library
for the Pro/Engineer library data. Basically Products (and Libraries) are more
about the team than about the product. We would have a bazillion Products if
we had a (WindChill) Product for each product we make.

>
> Thanks
>
> Erik Gifford
>
> G.W. Lisk Co., Inc.
>
>


--
------------------------------------------------------------------------
Randy Jones
Systems Administrator
Great Plains Mfg., Inc.
1525 E North St
PO Box 5060
Salina, KS USA 67401
email: -
Phone: 785-823-3276
Fax: 785-667-2695
------------------------------------------------------------------------