I've an interesting question. It is more about the process, not (at this time) concerned with the customization. We are about to install Windchill 11.0 in a company that has not had it in the past. We will connect it with SAP.
We are working out how to manage our ECN workflow. Currently our idea is for our parts go from In Work to Under Review, then either Prototype, Pilot, or Released. We want the Engineering work to complete on Change Tasks, then some SAP work to be done by various Implementors about the company. Then, when those Implementation tasks are complete, we want the ECN to go to Resolved.
The questionable area is between the completed Engineering work, and the final Resolution of the ECN. I'm calling this the 'in between' phase. The Engineering work is done and the parts are 'Released' yet more SAP must be completed before the ECN is really finished.
The parts need to be in a state that SAP work can be done (typically Released), yet the ECN isn't finished until their SAP tasks are completed. We are mulling over adding another lifecycle state for this , but I really, really don't want to.
Anyone use a process like this? Or have ideas of what best practices might be?
A question to think about would be at what point can another ECN be started on the "Released" item? Is it after engineering is done, or after the SAP work is done and the ECN is resolved? If it is the latter, I would leave it at "Under Review" until the ECN can be resolved and have it go to "Released" when the ECN is closed. Then you have the following ways you can deal with how you want to proceed with the SAP part of the task:
If you can start changing your item before SAP work is done you will want to set to "Released" before allowing for the SAP work. Either way I wouldn't add a new lifecycle state unless you need to clearly define that it is awaiting SAP updates.
Look at ways to make the process better by implementing this in Windchill and not just blindly put in the process that you have. Sometimes the old processes will hinder the system and actual improvements that could be made are missed that way. Then when you get deep into it, changes are harder to make than when you are starting with something fresh.
Thanks, this is a really good response. Since I'm fairly new at this company I'll need to discuss this with others, but at this time it appears the "Released" state would make it available for new ECN's. This is a critical point we have yet to discuss and I really appreciate you bringing it up.
At the moment, we do plan on putting our Implementer tasks in the ECN as separate Change Tasks with an Engineer at the end for final approval.
I'm liking your method, but I also wonder if the SAP tasks can be done while the objects are "Under Review"? I may not have been clear, but our current idea is for when ECN Change Tasks have completed the Engineering work, the objects go to "Released" THEN the ECN Change Tasks for SAP are to be completed. I suppose I need to find another trigger event to send information to SAP.
Finally the last Change Task is for the Engineer to approve the SAP work and the ECN is Resolved. This 'murky' area where parts are "Released" but not really fully completed concerns me. That's why I like your "Under Review" suggestion.
I've been told the objects must be "Released" for the SAP work, but I'm not yet convinced, and your point about new ECN's on these "Released" objects concerns me a lot.
I concur on the change tasks in the ECN. You can also create ECN task templates so these tasks are generated automatically on creation of the ECN plan - you would just have to fill out the responsible party and the reviewers. Also, you can set up policies so certain roles can modify objects at any state. So say you have a role "Planner" (an ootb role, or a custom role that has been created by rebuilding the rbinfo files).
At either the Site, Org, or context level (determine which is appropriate for your scenario) level, you create a policy that grants the role "Planner" to "Modify" & "Modify Content" at the state of "Under Review".
Now, some caveats. The lowest level approve or deny applies, and this gets important if a person serves in multiple roles. Say you have a "Product Manager" who also serves the "Planner" Role. And at the Org (or site) level, you grant "Modify, Modify Content" to the Planner, and at the product level, there is a policy that says the Product Manager has a deny or explicit deny to modify anything at "Under Review" - then the planner would not be able to make changes.
I would map out how you want your process to work, your lifecycle - and how you want to interact with what data, at what states, then decide if you want to have a company policy to restrict people from serving multiple roles, or to define certain role permissions at a higher level so that your grant happens at a lower level and will override the deny.
Once you have this mapped, then you can get an idea on how the lifecycles & policies need to be set up, and guidance to team members can be given so they know what results to expect.