Beste Practice regarding lifecycle states & maturity states

[Mȁrk]

Currently we have a internal debate and we are looking for some lessons learned / best practices regarding implementing Maturity states on WT Parts.

Currently we have more or less the default Lifecycle states for "all" objects (Parts, Documents, etc):

In Work - Released - Obsolete - Under review

We would like to introduce Maturity States for our WT Parts and we have vision on 2 options:

• Introduce Maturity as a global attribute on WT.Part. (Simple to implement, but lacking some control mechanisms)
• Implement a lifecycle for Part which reflect the maturity states. But keep the existing lifecycle on the other objects. (More complex to implement but seems to be more in line with Windchill designed usage)

Is there anybody that would like to share some experience with this issue? Lessons learned from a similar implementation? Pros/Cons? Maybe other options? Should lifecycle states be used to reflect maturity states at all? Some reference documentation? Would it be best to keep the lifecycle states as default as possible to prevent a headache somewhere else or can you go wild with them?

Specifically we are wondering what the impact would be having different lifecycle states for different objects. Can you still promote these in the same change notice/promotion request?

Anything is welcome and thanks in advance!

[avillanueva]

I think we might need more information on examples of your maturity states. The first option will require check out/in iterations to implement and be more complicated to automate. So, you could have a case where a part is Released but the maturity state needs to update which might require those with access to update released parts to do. Most users would not be allowed to checked out released parts I would think. There are also cases where the two are in conflict where it should not be possible to have a lifecycle state with a certain maturity state value. 

Lifecycle states can be used but you would need to ensure that all Parts would need to be updated to use the latest template. Not difficult to do this as a mass change. Keeping all existing states would make things not fail in workflows. So long as the Part still has those same states, the workflows would not error out trying to change to a state that does not exist. You also need to think about ACLs as well. Introducing the new states might require updates to ensure that folks have access to the parts in those states. This will require updates to all context areas. Again, not impossible but something to consider.

I have opted to keep things simple in our company. I do not have elaborate states for prototype or pre-production, just In Work, Under Review, Released, Superseded and Obsolete. Every place is different but this worked for our manner of design and mfg. I have gaps for things like "Not for New Design" or GIDEP alert parts. Not everything can be crammed into states. 

[Mȁrk]

---

So, you could have a case where a part is Released but the maturity state needs to update.

---

True in this case the Part would have to go to 'in work' (by set state or revise), the maturity be edited and then promoted/released again. As it is also a request to have the maturity on the 3D/2D cad drawings, so these need to update as well, which requires a new iteration, which means this also have to go to in work & re-released right? Having everything going through the same flow does not sound not like a bad thing.

In our erp currently we always/only use 'latest released'. Only 1 version of a part exists. And all revisions need to be backwards compatible and if not a new part needs to be introduced.

The lifecycle state 'Released' also has the meaning 'is send to ERP'. When having a Part in maturity=Prototype, lifecycle=Released, we know this version is been send to erp. A in work version of prototype is not been send to ERP. When we remove the lifecycle, we would have to get a new method to see which version went to ERP and which not. Also triggering when to send to erp or not, need to be redefined.

If there is just:
A.1                    A.2                      A.3
Prototype --> Prototype --> Prototype

Which of these is/need to be send to ERP for buying a actual prototype?

A.1             -->   A.2            -->       A.3
Prototype --> Prototype --> Prototype
In Work    --> Released  -->  In Work

Here i see that A.2 went to ERP.

How would advise to solve that problem having only the maturity?

"I have opted to keep things simple in our company &
Not everything can be crammed into states."

Keeping things simple is a major argument, here as well. The design work itself is already complex enough.

Thanks for your reply!

[d_graham]

@Mȁrk 

I just want to point out that if you use say a Boolean attribute to indicate Maturity (Yes/No) there are a couple of things to consider.

Let's say you're at A.3 and the Maturity attribute is set to Yes.  If someone checks out/checkin to create A.4 Maturity will also be set to Yes on A.4 unless the user set it to No.  If the user checks in A.4 and then remembers that they should have set maturity to No there's no OOTB way for them to edit A.4.  They can check out and make A.5 and set Maturity to No on A.5 but they can't change A.4.

Likewise, if you revise A.3 Maturity Yes to B.1, B.1 will also have Maturity Yes and if you're revising it's unlikely that B.1 is intended to be mature.

Likewise, if the user sets attribute Maturity to Yes by mistake and check in. They can't go back to that checked in iteration and correct their error.  Yes, it would be possible to make a custom action that would allow you to edit the Maturity attribute on any iteration without checkout/check in but that not OOTB.  No problem to do it but it is extra.

With these stumbling blocks in mind, you can use an attribute, but you will need a means of fixing errors without iterating the object,

Something to think about,

David

[d_graham]

What’s the purpose of this maturity state at your company?

• Access control?
• Configuration?
• Just a flag to let everyone know the WTPart is “mature”?

Can tell us how you intend to use this maturity state? What do you intend it to bring to the party? Knowing the intend use case will allow us to better advise you.

That said, without knowing more I’d definitely go with a state rather than an attribute.

As @avillanueva mentioned, adding a new state and update existing objects to use the latest iteration of the lifecycle template is no big deal. This can be easily automated.

[Mȁrk]

---

What’s the purpose of this maturity state at your company?

---

The purpose would mainly be;

•  Communicate the maturity to other departments like purchase, logistics. e.g. A prototype should only be bought in small quantities and doesn't need a big storage location. Where a mature part could be bought in 100's pieces and requires more storage space.
• Minimum required product data. e.g. a prototype would not need much documents, (meta)-data, etc. Where a mature part would need to contain some minimum required (meta)-data.

---

Can tell us how you intend to use this maturity state? What do you intend it to bring to the party? Knowing the intend use case will allow us to better advise you.

---

When promoting a set of (cad) documents & parts, this will be released to ERP. In the ERP we would like to have some more kind of maturity flag coming from Windchill to make some business decisions.In that sense it's "Just a flag to let everyone know the WTPart is "Mature" like you mentioned.

User Experience and minimizing bureaucracy is important here. Windchill is already complex enough and we don't wanna make this more complex then needed. A big downside we see currently is that as far as we know, it's not possible to Promote Items together that use different lifecycle states or go to a different lifecycle state. Therefore a promotion of;

Technical specs doc in work --> Released
CAD Document in work --> Released

WTPart prototype --> Engineering Release

Would not be possible in 1 promotion, but would require at least 2 promotions if we would use different life cycles. Is this assumption correct? On attribute seems there to be more 'user friendly' in that sense. Also allowing to 'skip' maturities Or maturing different parts to different maturities at the same time.

---

adding a new state and update existing objects to use the latest iteration of the lifecycle template is no big deal. This can be easily automated.

---

Yea but here is more for us to consider then 'just' updating the existing objects with the latest lifecycle template. We have;

• Business Rules
• ESI triggers
• Workflows
• Interface between Windchill & ERP.
• Interfaces between Windchill & Client Applications.
• Existing .pdf's from CAD drawings with certain states on it, that have a meaning for our suppliers.
• Access Control
• And more...

All using the existing states in one way or the other. Changing the lifecycle state is therefore a whole lot more work & time, then 'just' creating an attribute. We can do this work and accept a longer rollout, but then it should also offer a lot more. This is what we are trying to figure out; How much does on lifecycle off more then on attribute, considering the time & effort needed to implement?

[joe_morton]

It's really interesting to hear about this now, as my company is in the middle of a review with our PTC reseller to evaluate our current processes and get recommendations for improvements.

Currently we have a life cycle state for just about every step of maturity (at least 5 different release states!). The reseller identified this approach as "monolithic," According to them, this is not regarded as best practice. The recommendation is that all the other processes are moved into parallel workstreams, and that they don't affect or update the WTPart's life cycle state. 

The recommendations did allow for use of a life cycle they called "staging" that could be used for prototyping. We're still waiting for the full report of how everything would come together. All of the reseller recommendations are based on this concept of "part centricity." I'm not sure how common that concept is, but it seems to make a lot of sense to me. (In case you're interested in that: https://www.youtube.com/watch?v=ejSi4JAqOus)

So all that to say that we'll soon be working toward making our system more like yours with fewer release states. I'd definitely like to hear what others have done in this area.

[d_graham]

@Mȁrk ,

In answer to your question, "How much does on lifecycle off(er) more then on attribute".

I'd say the big feature the lifecycle state is going to bring is very granular access control.

Who can see.

Who can modify it.

Who can download it.

etc.

You can also automatically start a workflow when the object enters the state.

But to be honest, it's also possible to start a workflow when an attribute's value is set to a specific value. Not OOTB mind you, but it is certainly doable.

David