Enhanced scalability of Change Management

[Pekholm]

A change can be everything from a misspelling in a document (activity) to a complete new design of a product (Project). With current functionality, Windchill Change Management is too cumbersome to manage small changes and too weak to manage larger projects.

For small changes, it should be possible to configure a simple ECN with one embedded task. For large changes, it should be possible to use a project (ProjectLink) as implementation plan (or get same functionality as you have in ProjectLink). A projectLink license shall be needed.

This means that the ECN configuration has to be controlled at the type-level, instead of preferences.

[BrianToussaint]

My suggestion would be not to use OOTB change functionality and come up with some custom workflows.  Have you looked at custom workflows?

We have two types of ECN's currently.  One has a very simple routing and is for when we have failures to a CREO assembly when we call it up, or the user needs to add a datum, point or axis for assembly purposes.  Then we have a more complex one with routings based off of "type" of change chosen by the user.  The routing then will go different routes and skip some routes if necessary.  New functionality in 10.2, which I haven't gotten to try yet, lets you set up templates for changes that will automatically add the change activities that have been setup.

The power of customizing your workflows unlocks a lot of avenues.  You can even setup document subtypes to have workflows that are specific to them.

[Pekholm]

Hi Brian

Thanks for your reply. Yes, I agree that the process need to be different, but its also GUI and functionallity differences are required. For simple changes, embedded change tasks are nice, but customers like to have different GUI configurations dependent of change complexity. When it comes to very large changes, project management and resource management capabillities is more important.

[JeffZemsky]

Per,

Please resubmit as two separate enhancements with better description of use case, rather then technology.  As an example - for a simple CN with embedded task - what are the needs and use case today?

For a more complex process - what are the use cases rather than technology.

Per - You are aware that with typing these can both be configured to change the process to be simple or complex as needed.  For example a embedded change task will automatically switch to a normal CN with more than 1 Change Task added.

[JørnAHansen]

Jeffrey Zemsky wrote:

For example a embedded change task will automatically switch to a normal CN with more than 1 Change Task added.

‌wow! I wasn't aware of that. I in fact didn't even bother trying the embedded preference because of the 10% of cases where we would need more than one Change Task. Now it sounds like I can have both simple for most cases and powerful when needed In the same product context. Can't wait to take that for a test drive tomorrow