Product Development Versioning Scheme

Tom,

While I’m not sure I can give an answer satisfactory to your particular environment, I’ll give it a go.

Rather than address each point by itself, I’m just going to throw what looks like a complete overview of what you’re trying to accomplish. Keep in mind I’m making some educated guesses here, which may also be pronounced “assumptions”. And we know what assumptions will get us from time to time.

It looks like you want the product development phase have its own release and revise system in place. The problem with this is the three lifecycle states mean you end up with parts at ‘Released’ while still in product development. You may have to entertain the idea of adding more life cycle states.

Try this:

Production LC States

In Work -> Released -> Obsolete

What this does is allows you to have a product development phase, complete with “releases” during this time in the form of the Prototype life cycle state. Engineering can check out and work on objects at “Concept”. When a particular milestone is reached, or when product development parts have to be ordered or manufactured, they can be promoted to the “Prototype” LC state.

Once product development is completed, the files get promoted to “Released”. After this point, they enter the loop of “In Work”, “Released” and “Obsolete”.

It looks like this will allow you to keep meet all the criteria you’re looking for: same file number, continuous history, no duplicate models, engraving in place, cost tracking measures maintained, etc.

To me, the biggest hurdle is going to be the workflows, with two separate workflows necessary. One for product development to loop through “Concept” and “Prototype”, and another workflow for the production loop (“In Work”, “Released” and “Obsolete”.)

While I didn’t answer your list of questions specifically, I believe this method should handle all the issues you’re trying to address.

In Reply to Tom Uminn:

Long... key questions in last paragraph.

I am looking for ideas on different ways to deal with the large number of revisions that occur during product development, but aren't necessarily relevant once a product goes into production.

Right now we are using lettered revisions, numbered iterations, and three lifecycle states - "In Work", "Released", and "Obsolete". Although not fully implemented yet, the intended functionality is to have only Engineering be able to see objects at the "In Work" state. Once an object is approved it is then promoted to "Released" and becomes visible for the manufacturing department to build the tool. When changes are required, Engineering would create a new revision. This revision would stay at "In Work" until approved, at which point it would move to "Released" (and become visible/available to manufacturing). At the same time this newest revision becomes released, the previous revision would be promoted to "Obsolete".

The Goals
1.) Keep in work items invisible to the manufacturing department until they have been approved and released.
2.) Prevent engineering from making changes to items after they have been released.
3.) Minimize the large number of revisions that occur during product development.

The problem we are running into is how do we meet these competing goals at the same time? Right now there are two schools of thought here on how to handle goal #3.
a.) Do not revise items during the development phase but only after development is complete.
b.) Have two copies of each part. Develop on the first one, and then after development, save-a-copy to a new production part.

Option 'A' problems
- A system purge will destroy all development history, since each "development version" is at the same revision.
- No ability to insure that only the latest version is visible to the manufacturing department.
- No approval process would be needed.

Option 'B' problems
- Object history is messy - not continuous in one model
- Duplicate models in Windchill
- Once items go into projection, they aren't re-made. They will still be engraved with the filename of the original development tool.
- Cost tracking measures are complicated by double items.

The same basic issues apply to part prints. Often during development there are many changes to a print - how things are dimensioned, what characteristics need to be checked, etc. Once the part goes into production, those changes aren't relevant, only changes that happened after production began should be tracked on the print.

How do you do this? Is there any way to deploy a revision scheme that is dependent on life cycle state (development/production)? Or maybe one lifecycle state set within another? (Both development and production states have sub-states of in-work, released, and obsolete.) Or, is there a way to promote individual iterations and still allow new subsequent iterations at the same revision? Will I lose the control I'm looking for keeping everything at the same revision? What is the right way to do this? Thanks.

Tom Uminn
Engineering Systems Analyst
trans-matic Mfg.

Good point on the revise layout. Since it was handled within workflow (that I was not involved with), I can only assume two different actions within the workflows were used. One to go between Concept/Prototype and another for In Work/Released/Obsolete. It may have been a simple promotion process that moved it back and forth through Concept and Prototype, but I can not say for certain.

To answer the second question, no, revise doesn't take it back to the "first" life cycle state. In manipulating the 'Released' LC State simply set the 'Revise' action to go back to 'In Work'. In short, you get to choose the LC that 'Revise' sets those objects to.

In Reply to Tom Uminn:

Is "revise" always life cycle state independent? It seems like in the suggestion you laid out (Concept -> Prototype -> In Work -> Released -> Obsolete), If we revise to go back and forth between concept and prototype, then once we move to in work we will still be at the latest revision that occurred during the development phase. Would we not revise at all until we've reached released?
Also, does the "revise" functionality in Windchill always take an object back to the first life cycle state or can its behavior be adjusted so revise from prototype goes back to concept while revise from released or obsolete goes back to in work?

Tom U.