Initial Release of Parts to production (Change or simple Promote)

[vmcdaniel]

I'm beginning tio investigate our Initial part release process and creating WC workflows to handle it. Currently we are entirely paper based.

We do not currently use Change Management in WC (9.1 m040 BTW). We currently do not make WTparts either. We usePromote on EPMDocs to get from WIP to Released.

When initially releasing a part should be looking at configuring Promote, or is this better handled with Change objects?

[HugoHermans]

It all depends on what you want to achieve, and the way you want to go.

Until now, we still use Promote to get EPMDocs in the Released state,
although we have Change Management (CM) in place. But since CM is only
a recent implementation, I considered it as a practical approach to
promote for the time being. One of the next steps will be to use the
change tasks to get EPMDocs promoted, but only after a testperiod and an
evaluation by our key users.

Regarding WTParts, what withheld you from implementation? When we
upgraded from Intralink 3.4 to Windchill 8.0, 4 years ago, we immediatly
introduced WTParts. There was resistance, at first, but after a meeting
with all the stakeholders, where I got the chance to motivate the burden
of creation and association of WTParts, we went on with it. With
success, I think. To my opinion, it's an essential element in your
information management.

Met vriendelijke groeten,
Kindest regards,

Hugo Hermans

-

NV Michel Van de Wiele
Michel Vandewielestraat 7
B-8510 Kortrijk (Marke) - Belgium
Tel : +32 56 243 211
Fax: +32 56 243 540
BTW BE 0405 450 595
RPR Kortrijk

[sdrzewiczewski]

For engineering controlled states we currently use Promotion Requests. In
the next few weeks we are using a soft-ECN to do what Promotion Request
are doing today. We've already moved to a soft-ECN for our Initial
Release.

In the promotion request replacement process, we are not using Change
Tasks. We have logic in the Change Activity workflow to skip the tasks and
resolve after the ecn has been approved.

The big benefits to using the ECNs are the following:
- Ability to rework the items on the ecn. No need to reject a promotion
because you can't add or remove.
- Support for IBA's on the ECN object that are automatically exposed to
the user interface
- Support for Affected and Resulting Data, disposition and effectivity
capture.
- Attachment support. I know promotions can have a notebook but this now
stays consistent with other parts of the ui.
- Ease of collection of items. Ability to Copy and Paste, add non-related
items to an ECN, unlike the pain to collect items for Promotion Requests.

Hope this helps,
Steve D.

> It all depends on what you want to achieve, and the way you want to go.
>
> Until now, we still use Promote to get EPMDocs in the Released state,
> although we have Change Management (CM) in place. But since CM is only
> a recent implementation, I considered it as a practical approach to
> promote for the time being. One of the next steps will be to use the
> change tasks to get EPMDocs promoted, but only after a testperiod and an
> evaluation by our key users.
>
> Regarding WTParts, what withheld you from implementation? When we
> upgraded from Intralink 3.4 to Windchill 8.0, 4 years ago, we immediatly
> introduced WTParts. There was resistance, at first, but after a meeting
> with all the stakeholders, where I got the chance to motivate the burden
> of creation and association of WTParts, we went on with it. With
> success, I think. To my opinion, it's an essential element in your
> information management.
>
> Met vriendelijke groeten,
> Kindest regards,
>
> Hugo Hermans
>
> -
>
> NV Michel Van de Wiele
> Michel Vandewielestraat 7
> B-8510 Kortrijk (Marke) - Belgium
> Tel : +32 56 243 211
> Fax: +32 56 243 540
> BTW BE 0405 450 595
> RPR Kortrijk
>

[MikeLockwood]

We're doing essentially the same.

Promotion would absolutely be the logical thing to use but it has a huge number of drawbacks / constraints / missing functionality, forcing you to use change objects for just a state change. Would be nice if PTC either
a) Created a (set of) Change objects / processes for just accomplishing a state change following routed approval, OR
b) Beefed up Promotion to include the missing functionality.

[DarrenStorey]

Hugo, Mike it’s interesting for me to hear how you are using CM for setting the “released” state on documents via the change transition as an alternative to promotions. I appreciate most of the benefits you have mentioned plus several more on reflection. Thanks for giving me some food for thought today.

Can I ask if you considered using a soft type of Change Activity or at least a customized Change Activity workflow? Superficially this would seem to offer more flexibility than modification to the Change Notice directly; maybe IÂ’m overlooking a gotcha here.

Another interesting point is whether you consider the ability to rework documents without rejecting a promotion (or equivalent unlocking step) as a pro or a con. While the ability to iterate objects at will during the approval process gives rework flexibility, it also poses some risks for less disciplined. I know my company feel reassured that objects under promotion cannot be changed while authorization is pending and willingly implement the promotion lock state. To this end I wonder if anybody knows a simple way to apply a lock to the affected objects from the Change Notice or Change Activity workflow, perhaps by temporary set state?

[HugoHermans]

Hi Darren,

1/
We indeed softtyped the change activity, change notice and the change
request. And indeed, we customize the workflows of these objects. Our
approach is to let the configuration grow, step by step, along with the
organisation. So, the flexibility to adapt the workflows according our
new wishes and agreements is very important.

2/
At the moment, we don't have a review status, yet. A document is in
work as long as it isn't released. And most documents will never be
released. We still have a long way to go, there. And probably, we will
never consider to lock documents in an under review status, since
locking means some kind of limitation. I think people have to speak
with each other, systems are there only to support the communication.
Since all changes are traceable, it's discussable why you should lock
something?
Just a thought from the moment.

Met vriendelijke groeten,
Kindest regards,

Hugo Hermans

-

NV Michel Van de Wiele
Michel Vandewielestraat 7
B-8510 Kortrijk (Marke) - Belgium
Tel : +32 56 243 211
Fax: +32 56 243 540
BTW BE 0405 450 595
RPR Kortrijk