Automatic Baseline Creation for Windchill Part Structures on Release

[BrianSullivan]

Automatic Baseline Creation for Windchill Part Structures on Release:

Best Practice when using Windchill Parts is to Create a Baseline on Release of a Product Structure;  This is a manual step.

Baseline of Released Structure captures how the BOM Structure looked at Release.

This is a Best Practice since Windchill Parts do not have an :AsStored similar to EPMDocuments.

The reason is to Capture what a BOM Structure (Ex 8,000 Componennt Assembly) appears when Released at Rev A (say in 2012); This is Useful in 2014 when for Form/Fit/Function Exceptions where 100's of COmponents could be at higher Revisions.  Used by Engineering/Technical Support/etc... to note differences from Initial Approved Released and Current Configuration of a BOM Structure, via Compare Report Functionality.

Also used by Companies that Create Unique BOMs for Customers such as simulators.. Where they can use baseline to manage the "As Maintained" Configuration of a Customer's BOM.

As this step is Manual, it can be built into Workflow Instructions or Activities..

PRODUCT IDEA:

Workflow in Windchill that will Automatic Build a Baseline using Default Collection when a Part/Part Type reaches a certain State.

(Similar to ERP Connector KickOff  OR can be built into the OOTB Change Notice Process as a Condition Java Expression)  [A preference determines if it is used of not]

This will be useful to new customers who do not realize they need Baselines until 2 years of using Windchill;  Or customers who do not have resources to teach/check users to create Baselines.  Covers the Gap of not having an equavalent AsStored Baseline and not wanting the Overhead of having a Baseline getting created everytime a Part was Checked In.

[GregoryPERASSO]

Hello

interesting idea ... but don't think Baseline is a good choice.

As stored have big gap regarding configuration management ... notably that it is a "static" photo of the product ... And regarding 3F. If changing a sub component without modifiying above levels .. .the as stored baseline is out of date ....

Or may be if only generated and updated from a top level end item.   But not for each assembly levels like CAD as stored baselines.

just my thought, but effectivities is the best for "dynamic" BOM management .  Or even Promotion Request with the embeded baseline

regards

Gregory

[BrianSullivan]

Greg,

  The Baseline Captures the Configuration “as Approved”; You then can Run you comparison Report to find out differences between the Initial Released Baseline and the Current Latest Configuration.

I would like a few Preferences (Part Type such as End Item) would be a useful limiter.  Which fits your idea of running against End Item.

Promotion Request Baseline is limiting since most companies prefer to use the Change Process Only  Having the Change Process build Baseline for the Items (End Items or A Top Level Part Type or All (If Preference Set) Automatically would  allow you to always compare.

If you do not have a BASELINE you can never review your History.  You can Never Pull Up the REV A of a BOM Structure;  You can not Compare Released Rev A to Released Rev B;  Or Rev B Released to Latest;

It is why Manually making Baseline is the PTC Best Practice;  And if it is a Best Practice for Use; Then it should become a possible functionality via preference.

On Your Point of Effectiivities; I can see that being best for Comparing Dynamic Boms if in Compare Report I can compare Effect 2012 June versus Effectivity 2014;  Effectivity however is a lot of Overhead for Smaller Customers who simply want to compare Rev A to Rev B;

Question on Effectivity I have seen is that Windchill Effectivity is an Estimate;  The Real Effectivity is in the MRP system;  Have you opened a Product Idea for Updating Effectivity Dates from MRP?  So many elements need to be updated and we have to Customize/ Make Loaders to update the Windchill Info: 

Brian Sullivan

[GregoryPERASSO]

I'm agree .  promotion request is more a "change mgmt" for small companies.  And agree that effectivities and change is more complicated for SMBs too...

I think that with small customization in Change mgmt, we are able to create your own "as approved baseline"

But do not agree with the fact that "real" effectivities are in MRP.  it is a "dogma" that I meet in most of companies.   But for me, a correct BOM configuration management (ie with effectivities) is managed with a common Change management process accross the 2 Systems. So Change Notice and resulting affectivities are the same in the 2 worlds.

But I assume that eBOMs and mBOMs notably are managed in PLM and sent to ERP ...

At least if only eBOMs are managed in PLM, should also use effectivities.(with open date range)- and in MRP manage mBOMs based on same date.   All mBOMs change without Design impact should only change date in MRP.  but design change that impact production process have to be managed in PLM...

interessting topic !  

[ailli]

My Customer is building a WTPartstructure with existing (Released) WTParts.

In the Structure he is using EPMDocument-Structures, HArdware information, Software Releases and Manuals. Exactly this Structure (with the information Revision and Iteration) is important in the History.

Structure builders have only access to Released Objects and can only Promote the WTPart-Structure that is build in his own Context.

At this point it is necessary to have a filter that shows the "AsStored" Baseline of a specific Revision.

At the moment, we have Rules how the Names of the Baselines have to be defined. In the filter, a search for the Baseline has to be done for each version. Boring.

A Filter with the AsStored Baseline for a specific Revision is a must in the Preference Manager!

(Customer is building mass-produced Articles in safety equipment, this set specially with Software and Hardware Releases is important)

Any change on a item that is member of this structure is not relevant until it is manually replaced in the structure and new promoted.

[ptc-2910807]

I would vote yes to having this robot and also agree that being able to define preferences for the actual "as-viewed".  This would be a huge time saver and ensure the snapshot is produced upon release of each new EBOM revision.

[JeffZemsky]

This is a concept we have discussed with the Technical Committees in the past.  This is one consideration, however we are also looking at using the Change Notice itself as a configuration specification (1 to many) with some considerations to make it easy to gather several around the concept of a release (or even group of related changes).

There is another concept in addition we are looking for the future that we have also discussed with the Technical Committees that we call As-Matured that will also cover many of the use-cases - particularly the one that Brian Sullivan mentions above where I just want to compare Rev A to Rev B.

Both of these are areas I hope to add more detail on in the future.

[OliverDroop]

Hi Greg,

I agree to your point that it makes sense to set effectivity for eBOM in PLM and for mBOM in ERP.

We did some customization that on release we will set the current date as open range.  The old revision effectivty will be closed on release of the new.

If the user has entered a planned effectivity on change task we use this instead to not loose the OOTB capability.

In addition we are creating baselines automatically in the workflow which covers the FFF use case where I hope R&D will deliver this OOTB in the newar future.

The goal is to release all resulting objects of an ECN together, so these should go into the baseline but you might have objects from other ECNs in other contextes which run independently. To ensure now the Business Rules that the lower levels have the same or higher state as the release target you need to wait until the lower level ECN is released OR you exchange in the baseline to a previously released revision. This is valid in FFF logic and speeds up development. The benefit is as well that you can use the baseline for the visualization service to generate correct representations for the release