Community Tip - Did you get called away in the middle of writing a post? Don't worry you can find your unfinished post later in the Drafts section of your profile page. X
What would be the best procedure for switching revisions schemes between a development phase and a production phase? Our development phase would be alpha characters and at production would switch to numeric.
Solved! Go to Solution.
State based versioning. This requires a change to the configuration of the Windchill server. Start with the help documentation here:
State based versioning. This requires a change to the configuration of the Windchill server. Start with the help documentation here:
What do you use to drive the state change?
Take a look at this picture:
By the way, Mike Lockwood was the one who helped us set this up originally.
Sorry for replying a year late. I am faced with similar debate. I know it can be done, wrestling with should we. Tom, great graphic. I have sites that use this and some that don't. Some are high volume production, others are A&D program based where only a few units gets produced.
The argument for two phase and dual revisions schemes is typically focused around slow change processes that cannot support rapid changes in prototype phase. Once you commit to one way or the other, I believe that all parts you develop would follow same path (numerics in development then alpha in production). A competing requirement I have seen is pushing preliminary BOMs to production to support long lead items. This can lead to releasing a known to be incomplete drawing, leading to the schism between Engineering and MFG. Engineers says they were not done yet so don't make it but MFG needs to order material and cannot wait for Engineering drawings to be completed. I do not believe the solution is to throw process out the window.
Another observation is the percentage of items that truly need a two phase lifecycle. I would think that less than 3% of all "designed" items hang around in development, pre-production phase long enough to justify the more complex process. Most will advance straight to production with few changes after initial release. The goal should be to get things right the first time and release as late as possible. So with two-phase, 97% of items would need to be revised again and released at production revisions. So what drives that trigger? How do you know you are ready for production, on a single item or the whole product?
One would think that after the development units are built, there is some gating process that triggers all development items on the BOM to be reviewed, revised and re-release, mostly without any alteration. I see this is that the bill coming due for kicking the can down the road. By allowing rapid changes with little oversight, would we end up with a higher quality design in the end? Something for the academics to figure out. I have seen cases were if left to their own devices, organizations would shy away from doing that large amount of work at the end when in reality, nothing has changed.
I would be interested to see where the break points are. Is two-phase more suited to high volume mfg? Does it lead to bad behavior, more revisions or poorer quality? When you organization will end up selling off the first prototype as a production unit, does this process not make sense? Is there a case to be made that a simpler system is better?
Jeff, that's exactly what my company does too. Tom Uminn has excellent advice, that would be a good place to start.
We are set up to that today. Alpha are released to a Pre-Production state and numeric revisions are Released state. All controlled by Windchill and the promotion process and Revise.
I have thought long and hard about this - and have presented on it several times at PTC functions. Attached PDF gives some info which may be useful.
Tremendous confusion (in my humble opinion) results from presenting "Promote" and "Revise" transitions on a single line, rather than presenting Promotion as clearly just changing the state of a given object and Revise being a "save as at the next Rev and start working on it." With state-based versioning this becomes infinitely more important because some Revise transitions continue Numbered Rev's and others start or continue lettered Rev's.
State-based versioning with a two-phase lifecycle is a really great feature of Windchill - and very helpful to almost every company. It's just super difficult to dig out of the documentation and examples how it actually works and how to configure for it. Then, the OTB LC template presents an almost unworkable downside - have to release your last development Rev (see attached).
On the last page of the attached pdf, is there a way to go back to numbered revisions after you've gone thru the one-time process change to go to alpha revs?
Nope. Reason being that there is really just one big list of revisions and it's not ever possible to go backwards.
1
2
3
...
99
100
A
B
C
D
...
X
Y
Z
AA
AB
AC
Is that the case with state based versioning as well? From this article (CS241583) it seemed like the way the revisions are defined there should be way to go back to a state (prototype, as an example) and have the revisions go back to the revision scheme used for that state. Did I misunderstand that?
You missed this line in the CS article:
The order of the seeds in the version xml file has to be same as the order of the version switch in your lifecycle PROTOTYPE_VER => RELEASED_VER
The progression is from the Prototype_ver to the Released_ver.
Fair enough! So it's a one way street...
There seems to be a lot of love for state based version schemes out there with the community big hitters. This is interesting.
We don’t currently use them, but I’m guessing if we surveyed all our engineers and asked them cold, “would you like to have them?” I suspect we would get more yes than no. In pre Windchill days some parts of the business did use 2 schemes.
After giving this some thought we recognized that state based version schemes are in essence a semi-intelligent numbering system. Comparisons can be drawn to intelligent part/document numbers. In our case the additional information stored in the intelligent revision number can more easily be captured in the lifecycle state.
For us, not having them simplifies configuration and use of Windchill quite a bit. There are less buttons to click, and a less complicated process to follow in general.
The only problem we have so far encountered with not having state based versions is that many people simply don’t like “the idea” of the first production revision being something other than “1” or “A”.
What do others think? I would be interest to hear the business drivers and perceived pro/cons?
About "smart" or "intelligent" numbering...
Agree that this appears to be the main reason to implement - and in fact I believe it is somewhat helpful.
But the main reason to use it is that different states and state transitions along with different user permissions are in effect for numbered Revisions vs. Letter Revisions. This very elegantly allows for distinct different business processes for the same data as it matures from development to production (along with as complex a one-time process for production release as desired).
For development (which just happens to be identified by Numbered Rev's (OTB - some switch these, esp. in Europe), set things up for minimal oversight / approvals and allow Revise freely.
For production (which just happens to be identified by Lettered Rev's) set things up for use of formal change management, and Revise only with an approved ECR.
Thanks for all the info. Personally, I think not having the character change simplifies things greatly and is just another version of smart part numbering, which was good in its day, but somewhat unnecessary today. Unfortunately, with the nature of the business I am currently connected to, I don't have that option. So it would have to be state driven.
All this is ok, except for the fact that Windchill is not the friendliest piece of software out there. It takes a lot of effort and code writing many times in order to accomplish something rather simple.
My previous experience was with Solidworks PDM Pro where it was very easy to accomplish something like this. In Windchill, not so much. In many cases I know what I want to do, but getting there takes an enormous amount of hurdles.