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

Show previous replies
T
tbusch1-Visitor
1-Visitor
January 14, 2010
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>
P
patrick.chin11-Visitor
1-Visitor
January 15, 2010

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.

P
patrick.chin11-Visitor
1-Visitor
January 15, 2010

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.

P
patrick.chin11-Visitor
1-Visitor
January 15, 2010
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.
P
patrick.chin11-Visitor
1-Visitor
March 26, 2010

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.

E
egifford12-Amethyst
12-Amethyst
August 16, 2010

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.

M
22-Sapphire I
MikeLockwood22-Sapphire I
22-Sapphire I
August 16, 2010
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.
A
achukwuka1-Visitor
1-Visitor
August 16, 2010
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 [
E
egifford12-Amethyst
12-Amethyst
August 16, 2010

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

D
davehaigh13-Aquamarine
13-Aquamarine
August 16, 2010
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
Show more replies
Terms & ConditionsCookie settingsAccessibility statement