Simple Promotion versus Change Notice??

[ddemay]

Hello,



I noted Steve's posting today and I just have to inquire about opinions
about alternatives to Promote in general.



We are about to deploy Windchill 10.1 M010 in January 2013 give or take a
few weeks. It will use PDMLink and PartsLink with a roadmap to incorporate
other modules quickly.



Who out there does not use Promotion for initial release or to transition
between prototype, pre-production, PPAP, service, etc?



I have a very long standing debate with a consultant for over a year. They
naturally do not really ever go to PTCUser or ever participate in the user
groups as they see it as "free consulting" and totally missing the value it
provides all of us.



Their stance on Promotion is it is an incomplete user interface for
companies who use the system more like Intralink and not for full scale PDM
or PLM.



I'm posting this because again, I naturally disagree. The same consultant
argues that the "big" companies use change notices for all types of releases
or phase/gate reviews/changes.



Not once, did this consultant show the customer promote, how it works, or
how it may be configured. It seems to be a very self-centered solution.
Customer has no idea of what they may gain/lose out on.



More detail/complicating factors.



Our customer, engineering doesn't get the concept of WTParts quite well yet.
This consultant got to get the first opportunity to not only advise in a
workshop how to use them, but due to this rapport, singlehandedly design and
configure the future PDMLink for our company. Naturally, I'm a little
peeved because I'll have to support it and it is not robust at all.
However, what really has me bothered to where I'm losing sleep is using soft
typed change notices as replacements for promotion processes.



The biggest issue the WTPart, and EPMDocument (CAD Document) lifecycles have
different names for the same states but the reason is only because they
everyone to clearly know the drawing is not the part. It is a
representation in a relevant associated document and nothing more. I agree
on this point. But to have different lifecycle states??? Naturally, for
those still paying attention (thank you), but this also prevents any real
potential use of the promotion processes due to different states. So
collectors become less valuable.



The information still shows up in maturity history supposedly (have not
confirmed), but you get an extra set of data. You see in the change notice
wizard replacing promote, the classic affected and resulting items tables.
You get to see that yeah here is what it was in pre-production or prototype,
here is what it is now (resulting). Or, here is what it was in production,
here is what is as a service part (resulting).





I really see this as backward because now all the data is getting mixed up
together in one big bucket. Everything is a change notice. What if
PTC continues to improve Promote? How could this hurt us in upgrade
times? Just some initial thoughts. Everybody is very excited that it is
not customization. Customization is really bad apparently (internal
politics), but if you use the system in a way not tested on intended by PTC,
what risks are we taking? It may have changed any code or required a
computer programmer, but it is still custom and not typical.





My big point is that I think if PTC wanted customers to not use Promote, it
would not be in the product.



I do not think PTC would condone using Change Notice instead of Promote.





I am looking forward to any feedback. Agree or disagree, I want to use it
for internal discussion. I appreciate any responses. Thanks in advance.






Regards,

David DeMay

[sdrzewiczewski]

We now use Soft-Typed Change Notices for all of our changes here at iRobot. We used Promotion Notices up until 2010. We worked with PTC to build standard functionality to allow for Rework of a Promotion Notice. But if the collection ever needed to be added to or removed, you just couldn't do it with Promotion Notices.

What I've liked about the all Change Notice approach is the end user has the same experience for creation no matter the state. Some of our ECNs only Configuration Management can create and must be created because of an ECR.

The biggest challenge in all of this was making the Change Activity workflow do the right thing. What was a very simple workflow, now is much more complicated to handle all of the different ways the various Change Notices route.

Another big thing we did was stepped away from using the transitions to define the destination state. We may go back post 10.1 upgrade. Currently the ECN Type itself and possibly an attribute on some types (called Target State) are used to set the resulting objects programmatically. This has worked very well for us to date.

We still have a lot of optimization to do in our processes, but as a whole I am happy that we transitioned to using ECNs instead of Promotions. We do use Promotions for document approvals that are non-BOM related types of documents.

Steve D.

[ericstarkman]

Hi Dave,



Your company may want to consider this book from Deloitte when selecting a
consultant, it's a classic (~2002), and one I strive to live by. Maybe you
can find a consultant that is a better fit for your company.




right?), if you wind up overloading lots of meaning on them (e.g. it's
always an ECN, but there are all these different kinds of ECN, and it means
this in this situation and that in that situation...), it may actually be
more clear to have separate objects with separate meanings. Also, Promotion
request...

[ddemay]

Eric et. al,



Thank you for the pointers on consulting and to everyone who responded. I
have had to accept the path we are going as the customer has grown
accustomed to the approach demoed. Since the customer is happy, the
consultant stays and we will fix any issues later. There are reasons why
which I am not allowed to discuss here. However, I do see value in
contributing to the community and helping others. I reach out to try and
have an open mind. As Jeff Zemsky replied earlier: "If Promotion Request
meets your business needs there is no reason not to use it, but using a CN
is not a crime either."



As for introducing WTParts, it was a big shocker at first. So much so, I
was afraid when I started they did not quite grasp how to use them and did
have them postponed for our 9.1 M050 system. In this system its CAD data
and promotions only. I architected it to be able to roll out additional
functionality. The problem is, new employees started who did not want to
learn what I have done, and so we have gone completely back to the drawing
board. Others were not happy that I made the recommendation to delay use of
the WTPart. So it is one reason we are not upgrading anymore and we have
started from scratch. The wasted effort is sad, but it is what it is.



It is good, reassuring, to see others using change notices or a combination
of promotions. A combination is what I thought would be good to do, but was
never consulted or involved. I was hesitant at first due to it being a
"change" ergo CMII and not just "maturity". I have yet to evaluate how
many change notices on average will be created per year, but I think there
will be plenty as the users adjust. I am worried about how pending
changes, hanging changes, how long it will take to load all of the changes
in UI (performance/patience), and how to deal with generating reports for
various reasons. I do have concerns about the technicalities in a few years
when database tables get filled with extra data (still need more analysis)
and we have to compensate.



The consultant did leverage the release transitions option (I left that out
for keeping things open minded at first). Verbs were used (resource bundle
tweak) to let the user select the action they wanted. Spectacular
functionality, now put it on the promotion request?

Or abandon current promotion requests, for one close to a CN. Thinking out
loud there. Per other usage/benefits mentioned by Jeff Zemsky: "Companies
that use promote in the early development cycle come in all shapes and
sizes. That being said I also have customers that use CN (particularly CN
without CR) for this as well - primarily due to the flexibility it affords -
eg. Update Resulting Data after creation, multiple transition support,
Resulting Data always at latest iteration for the at Revision" I do think
all of these are very valid reasons to consider, but does make me question
why Promote cannot yet offer this? Does it make sense to eventually
condense and make the system more configurable via preferences? Could we
even just end/resolve the issue this way? A good thing for discussion in
BOCA and TC's.





As for the different lifecycle states, there was another reason, but even
then, it still was odd (intent?) and I think some of this was changed by
upper management. I only mentioned it as concern for using promote.





Thanks again to all who replied.

David DeMay

[MikeLockwood]

Promotion accomplishes:

* Product data state change

Change process accomplishes:

* New Revision of product data (on CT)

* Editing of product data, resulting in at least one Iteration at the new Revision (on CT)

* Product data state change (when CN is approved)

If you only use Promotion, then you sort of have no choice but to allow people to Revise and Iterate outside of any controlled change process, then control only the state change that allows the new Revision to be used. With single Word documents, this is not too bad, but with CAD and all the relationships, it can be disaster.

[pwilliams-3]

Mike,
How are you able to restrict the Revise operation to be contained within the CT and not allowed outside the CT?

Patrick Williams | Engineering Systems | c: 616.947.2110
[cid:image002.jpg@01CD9D78.064DA2C0]

From: Lockwood,Mike,IRVINE,R&D [

[MikeLockwood]

Two phase Lifecycle and use of Numbered Revisions, then Letter Revisions.
Large group can Revise (product data) when at Numbered Revisions and the states that are used with them; only a subgroup can Revise to go to Lettered Revisions (initial release) and changes after that.

The configuration is actually by state; who (what role/group) has Revise permission at the states. This took a while to figure out 7 years ago; has worked out very well for us. Not so easy to add after being live I would think.

From: Williams, Patrick [