Windchill Configuration Change Management (2011 PlanetPTC Follow Up)

[ChrisRussell]

To deploy Windchill PDMLink, my group has created a unique business process and create an accompanying administrative Product Structure of Windchill PDMLink command files (OIRs, Lifecycles, Workflows, Profiles, Types). I presented at PlanetPTC (see attached) to communicate our observations, challenges, and to understand if we were alone. This thread is a follow up conversation for others finding the same observations and challenges.

[JimWoyciesjes]

I think a good point to start the discussion is:

What is an appropriate structure for the files to be managed (there are many ways to skin the cat...)?

On Slide 17 of Chris' presentation it shows two examples of structures, the Prodcut Context Folder view and a BOM structure representation.

What are some suggestions for groupings of files and information that make sthe most sense? Does PTC have any input on this? A standardized/recommended format would be good and helpful for the future (troubleshooting, migrations, sharing of ideas, etc.)

Chris, Are you putting the files int he Folders of the context as well as building the BOM structure and attaching the appropriate documents to the corresponding WTParts? Could you post a shot of what the WTPart structure looks like while showing the associated documents?

Also, can you explain your naming convention...OOTB, I assume is the original file(s), SNL indicateds file(s) you changed for you instance...what is the "002401" number?

What is the benefit of having a Context Folder structure and WTPart structure? Why not dump all of the files into a sindle Context Folder and just use the WTPart structure with the appropriate associations?

What about using the Windchill folder structure as it is for the Folder Context sturcture? Then associate the documents to the appropriate WTParts?

[ChrisRussell]

Jim,

For now I'll have to answer your questions with words instead of graphics. I've got to get approval to send those graphics to this public domain.

You wrote: What is an appropriate structure for the files to be managed (there are many ways to skin the cat...)?

Love the "Cat" pun. Yes there are. Good question. I don't know what's the best solution. I can just convey what we're trying.

We chose after several conversations and re-thinks to decide we couldn't really decide the absolute best without coming up with something and running it through it's paces. Our Folder structure has four main segments:

1. Business Process
   
   1. Contains the Hows and Whats on obtaining and maintaining... Customer Agreements, User Support, PDMLink DEV/QUAL/PROD Configurations, Metrics, etc.
      
2. PDMLink Business Objects
   
   1. Contains a plethora of sub folders for individual WTObject "Control files" (i.e. Lifecycles, Workflows, ACLs per LC, OIRs, etc. on a per WTObject basis...WTPart, EPM Doc, WTDoc, and so on.
      
3. WTPart Folder
   
   1. Simply a location for the ~130 WTParts that represent our Product Configuration.
      
4. System Administration
   
   1. A location for "Builds" and their Baselines.
      

You wrote: Are you putting the files in the Folders of the context as well as building the BOM structure and attaching the appropriate documents to the corresponding WTParts?

Yes - We have a structure that is intend to represent just the "Build" and not all of the decision data (e.g. PR, CR, CN, impact analysis, requirement affirmation, build specs, validation/test, presentations, etc.).

You wrote: Could you post a shot of what the WTPart structure looks like while showing the associated documents?

Will do as soon as my bosses give the okay.

You wrote: Can you explain your naming convention...OOTB, I assume is the original file(s), SNL indicateds file(s) you changed for you instance...what is the "002401" number?

You are correct. We made a choice to segregate these items instead of accepting the "OOTB" as A.1 because we entered this effort midstream...that's to say we already had "SNL" verisons as separate files a "no right or wrong" decision made early on at my site.

You Wrote: What is the benefit of having a Context Folder structure and WTPart structure? Why not dump all of the files into a sindle Context Folder and just use the WTPart structure with the appropriate associations?

To help the human behavior of compartmentalization, filtering, and pattern recognition -AND- for "non-build" process data artifacts. Thus far, we have ~400 individual files and during the corraling effort thought folder bins would help us get things organized and keep them that way...so far so good.

You Wrote: What about using the Windchill folder structure as it is for the Folder Context sturcture? Then associate the documents to the appropriate WTParts?

Beyond what I've mentioned above, for the WTObject "Command Files" we where attempting to go for a Unified Modeling Language like "Class" diagram (http://en.wikipedia.org/wiki/Unified_Modeling_Language) in our Product Structure and just let the Folder Structure be organized in WTObject relative piles. Having said that I'm not certian we achived the UML goal but, we got to the point where we need to call the approach "good enough" and begin using it.

Make sense?