Voices Needed for an Enhancement (E7697029) to Change Management

[avillanueva]

Is the issue just the checkActivitiesFinished() method or
promoteChangeables()? These kind of workflow expressions are completely
within your control as is the OOTB workflow. I cannot see a case were
you would want to just accept the default. You just need to figure out
how your workflow logic should differ from the OOTB. A little coding is
involved. I rmember one revision of PDMLink changed the behavior of
checkActivitiesFinished() that if no CAs were created, it continued. I
wanted it to stop so I wrote my own to stop and wait for CAs to exist
AND be resolved.



For this particular class (WorkflowProcessHelper), it would be nice if
PTC broke this out of the JAR file and published the source code. The
change2 API is good enough to create your own from scratch though.

[MikeLockwood]

Before getting very deep into code and methods, it's really necessary to clarify as Ken does below in words (maybe supplemented by some diagrams) how the various use cases proceed.

We've been using Windchill change management only since Dec '09, but management has recently directed us to "go back to ground zero and re-think what you're doing here..." (very painful lately). Ref - We're on 9.1 M040.

I'm extremely interested in comparing notes with users of Windchill change management, and what you've done to configure / customize things.

A few fundamental considerations, just for discussion:

- Do you consider it a change to production release something? If so, CR, CN, CT or other?

- Do you consider it a change to make something obsolete? If so, CR, CN, CT or other?

- Is a change completed when the data is updated, or when physical things, purchase orders, rework jobs, etc., etc. are complete? If the change extends to any physical things beyond the data, when does the data go to Released (because as Ken points out below, the data goes to Released when all the Tasks have been completed).

- Do you have Role-based approvers approve what is to be changed before anything is Revised? If so, is this on a CR or a CT? If a CT, do you not Revise until the intent is approved? In any case, what do approvers approve - detailed markups or redlines or just words outlining the intent?

- At what point are all the data items collected (e.g. if someone wants to change note 3 on a drawing, when are the related .prt and WTPart collected and addressed?

- Does it seem odd that one has to fill who is going to do the work and check it when creating a CT BEFORE adding the data? How does this fit with having a plan that is to be approved before revising anything?

We currently start all changes with a CR (Request), with strict routed approvals of redlined printed documents and BOM's, along with full proposed Disposition and Effectivity. Every change also points to an approved "Plan" that outlines the intent and provides a comprehensive checklist by category of all related things that may need to be addressed (e.g. labeling, patents, risk analysis, validation testing, standard costing, user training etc.). We've really struggled so far mapping what we have done with paper forms to Windchill change management objects and processes.

Our list like this goes on and on and we're just starting to really get into this. Not complaining - just trying to understand how to use the tools the best way.

[avillanueva]

I think there should be a Windchill App Store created for PlanetPTC (hey
PTC :-)). We could post our own Workflow Process Helpers there for
others to download. The variation in desired logic in infinite.

[Cosmo]

Hi Mike,
I agree. I would like to know what others are doing with their change management process as well. (Perhaps we need a new thread on this topic.)

I'm a recent addition to my company and joined post-implementation. I found that my company doesn't use the CR process at all. We only create CNs and use the default CN workflow with some minor changes. I think we took out a lot of the notifications because it was simply too many emails to go through and people started to ignore them.
We are implementing some new workflows to handle requests for new custom products from our sales group. These requests result in an Engineering Project (EP) to design the new product. The idea is that a salesperson could create a new object of a specific soft type (call it "EP_Document" for now). This object type would have its own lifecycle and workflow. It would have an EXCEL file as the template object. This EXCEL file is where we calculate things like non-recurring engineering costs, tooling costs, etc. for this EP. The attributes on this EP_Document object would be inputs from the customer that the sales person enters at the beginning of the project and/or at any point thereafter (fields might be number of units sold, related program, description of the project, etc.). Deliverables would then be attached to this EP object as they are created.
So at the end of the process, you would have an object (the EP_Document) that contains all the inputs from the customer (meta data), the calculations required for engineering and tooling cost (the EXCEL file), and attachments to the resulting product design (CAD objects that are manually attached).
The big negative is tracking these EPs through their process stages. Workflows do not appear as if they were intended to be tracked from a high level. So there is no "dashboard" view of workflows where you can see there statuses and where they are in the process. You can try and use lifecycle states but this assumes that everything travels through gates sequentially. We may have five tasks all occurring at the same time. ProjectLink has a nice dashboard feature for looking at all the projects and seeing their status. It would be nice to have something similar for workflows (or rather for reviewing the objects using a particular workflow).
I was just thinking that it would be nice to be able to look at a workflow (like in the process manager/editor) and graphically see the workflow diagram. It would be great if you could see the number of objects that are currently at each activity in the workflow (for example, perhaps there are 35 different objects that are currently in the "MFG review" stage/activity). Then, it would be great to click on an activity and see the list of objects at that stage and continue drilling down.
Because of this lack of visibility, I suspect that implementing our EP process into Windchill using workflows will not stop the constant communication required to keep everyone up to date on the status of an EP. It's just not clear enough to determine what tasks have occurred and which are 50% complete and which have yet to be started. ProjectLink is great for this kind of stuff, but when an EP can take a day or two to process, does it make sense to create a new project in ProjectLink and set up the team, tasks, deliverables, etc.? I'm not sure which is really better yet.
Mike -

[dtkach1]

You can use Project Template. Identify all phases, document templates,
teams for each type of the project that you usually have.
So every time when you have certain type of the project you can create
Project using Project Template with all required configuration already
in place.


Thanks,
Dmitry

[AL_ANDERSON]

Mike,

We are not yet live with PDMLink. Instead, we are approaching the final
stages of going from Windchill Foundation PDM with heavy customizations to
PDMLink 9.1 with significantly fewer customizations.

We are struggling with some of the same questions you are.

Our current plan is this.

We will have two basic categories of ECR.

One category of ECR will use the basic ECR workflow. It is intended for
use when making a change request that needs some investigation and
approval before beginning work. This will ultimately result in one or
more ECNs. It may or may not be the result of one or more Problem
Reports. This category of ECR will complete automatically via a workflow
when all ECNs under it are completed or cancelled or disassociated. We
currently plan to have a few site-specific ECR attributes on the out of
the box ECR type in the type manager.

Our second category of ECR will be for collecting related ECNs for block
changes (one ECR per block change), sales orders (one ECR per sales
order), etc.. For example, we have created a subtype of ECR for
collecting Sales Order changes that uses a different lifecycle then the
standard ECR. That lifecycle has no workflow associated with it. It is
created in an Implementation state, and it will be manually closed using
set state whenever an authorized member of the sales order group manually
sets its state to complete. As long as this ECR is in Implementation,
users will start new sales order changes directly from the "Create ECN"
action or icon, and then reference the Sales Order ECR in the 5th step of
the ECN creation wizard.

Using an out of the box preference setting, it will be possible in our
system for one ECN to reference more than one ECR. This allows for a
change to fulfill a requirement on a standard ECR, as well as to be
associated with one or more sales orders and/or be implemented on a
specific block change.

You could probably use attributes, or contexts, or part references, or
document references, or package objects or even projects in project link
to do the collection of related ECNs, but the use of an ECR should easier
since you can create an ECN directly from a document or drawing revision,
get an auto-created task associated with that object, and have a 5th step
in the ECN creation wizard to reference any ECR(s) from the new ECN. If
you ever want to move an ECN and its associated drawing release(s) from
one ECR (i.e. one sales order or one block change) to another ECR, then
you can easily redirect your ECN - to - ECR links in order to accommodate
the change. In cases where you have multiple drawing revisions as tasks
on a single ECN, as well as in cases where you have multiple drawing
revisions on a single ECT, then moving individual objects from one ECR
collector to another would be very difficult. That is why I suspect that
many groups will likely gravitate to a one drawing revision per ECN
release process.

Our "drawing revision" will actually be a WTDocument with PDF and TIFF
file attachments (one primary, on secondary) that is generated from one of
multiple CAD systems. Our Pro/E drawing EPMDocuments will auto-generate
those images and place them in a WTDocument using a state-driven workflow
that activates a publishing program we wrote on the server's Pro/E CAD
worker. Other sources of drawings have more manual TIFF/PDF file creation
processes that result in a manual upload of the CAD-neutral files to a
WTDocument for release on an ECT as part of an ECN.

In general, we pay the greatest attention to the release drawing
revisions, not the release of part revisions. RTP of part revisions to
our ERP system happens in advance of our drawing release for data set up,
although our business practice requires a released drawing prior to
purchasing parts. We will use a Promotion Request to kick off the RTP of
a part version in advance of a drawing release.

As for other types of objects (parts, documents, etc.) attached to PRs,
ECRs, and ECTs, we expect users to apply good judgement based on the
nature of the change. A PR might be associated with a drawing revision or
part revision that has a problem. An ECR will reference drawings,
documents, and/or parts that require investigation and change. And a task
will have all of the original data versions associated with a drawing
change that will result in new data versions. Typically, however, this
will be old drawing revisions to new drawing revisions.

As for using ECNs to release initial release objects, we plan to use that
approach for initial drawing revisions in order to use a common release
process associated with the ECT workflow. We also plan to use ECNs for
the initial release of any other documents that require formal review,
approval, and sign off before release - again, to use a common release
process associated with the ECT workflow instead of having to "Promote"
when new and "Change" when revising - only to use the same workflow in
both cases. We expect that it will make reporting and statusing easier if
we have ECNs and ECTs for both new and changed drawing releases.

Does this help at all?

Al Anderson
Solar Turbines Incorporated





"Lockwood,Mike,IRVINE,R&D" <mike.lockwood@alconlabs.com>
08/19/2010 12:31 PM
Please respond to
"Lockwood,Mike,IRVINE,R&D" <mike.lockwood@alconlabs.com>


To
"Villanueva, Antonio" <->, Keir Pritchard
<kpritchard@westport.com>
cc
"-" <->
Subject
[solutions] - RE: Voices Needed for an Enhancement (E7697029) to Change
Management

[HugoHermans]

Hi Al,

A very comprehensive description of your upcoming implementation. Do you have the feeling to evolve towards a slimmed down project management based on change management objects? And have you already an idea how to make available comprehensive task overviews, kind of handsome and conventient todo-lists for day-by-day use?

Best regards, Hugo.

<< ProE WF3 M230 - PDMLink9.1 M050 >>