Voices Needed for an Enhancement (E7697029) to Change Management
I'm asking for as many voices as possible in the Use community to join into get PTC's attention and hopefully resolve what I believe to be a circular logic trap inherent in Change Management. The difficulties arise when extending CM Workflow beyone Design Engineering. Change Tasks (wtChangeActivity2) all complete simultaneously viaa synchronization robot that calls"WorkflowProcessHelper.checkActivitiesFinished" and the Change Transition is executed on the Resulting Objects via an expressionrobot that calls "WorkflowProcessHelper.promoteChangeables". Now try and get your Manufacturing Team so complete their Change Tasks without Design having done so first (mBOM is complete and accurate based on a moving target eBOM!) or getting Supply Chain to get a quote on a drawing that has not yet been "Released".
I've scoured the JavaDoc for other Workflow Process Helpers that might allow me to soft-type wtChangeActivity2 into Design, Manufacturing, Supply Chain, Service Engineering and pass thesub-type to same-but-different Helpers thatare able to differentiate between Change Task Types. This would allow for Designactivities to complete and Released documents to be available for downstream implementation activities. Ad Hoc activities might be useful for addressing some "action only"activities, but they get delivered upon completion ofcreation (would be better if there were a built in trigger that could be connected to other WF events)
Ifanyone can see that I'vemissed something here, by all means please let me know! If anyone has run into this and has a solution, please let me know! I honestly believe that anyoneattempting toleverage Windchill utility to the extent of the sold capabilities will eventually run into this if they have not already.
- Addressing by creating additional Change Notices(Tech Support's answer) related to an upstream Change Request is unacceptable. These elements are all part of the same implementation, not a separate Change Implementation related by Reason or Request.
- unReleased Documents are not communicated externally
- Concurrent start is OK, in fact good... part of shortening development timelines
- It's reasonableto expect firm inputs (eBOM's) before signing off on complete and accurate outputs (mBOM's)
- If enough customers submit enhancement requests, the need will be recognized and Windchill will have much greater useability Out-of-the-Box
We have addressed this problem a little differently and I think with a little less complexity. We added an attribute (via soft typing) to the WTChangeActivity2 object called ActivityType. We use this to branch the workflow down different paths depending on the type of activity. To handle the concurrency issue, we added another attribute called PrerequisiteActivity. We then established a Sync robot that checks to see whether the prerequisite activity (i.e. Design Engineering) is complete before launching the supporting activities. In our case, we have a custom front-end that establishes the activities and sets the value of the attributes.