Stage of office documents

[tpfueller]

Hello,

I have a question regarding management of office documents.

Imagine a document that has two stages or maturity levels like "draft" and "final version".

Both draft and final versions undergo an approval process. At first user creates the document and it has the stage draft. The user edits the document via check in and check out and when he has finished, he puts it into an approval workflow. The document gets released after approval and the user creates a new version chain (=version increases to 2.0 and lifecycle stage changes back to working) and works on the same document again, but this time it will be the final version. After completing his work, user puts the final version into the same approval workflow and the final version gets approved.

Given this situation I want to manage all this document creation process by using soft attribute to express stages "draft" and "final version", version like 1.0 or 2.0 and life cycle status like working or released.

It would look like this:

1) Initial document creation

Stage: Draft

Version: 1.0

Lifecycle: working

2) Daily check in and check out

Stage: Draft

Version: 1.xxxx

Lifecycle: working

3) Approval "Draft"

Stage: Draft

Version: 1.xxxx

Lifecycle: released

4) New version chain and stage change

Stage: Final version

Version: 2.0

Lifecycle: working

5) Daily check in and check out

Stage: Final version

Version: 2.xxxx

Lifecycle: working

6) Approal "final version"

Stage: Final version

Version: 2.xxxx

Lifecycle: released

My question is:

Would that be common practice to manage the STAGE of a document in a soft attribute like i have outlined above? Or would it be better to manage everything with the life cycle status. In such a case I would have to define more life cycle states like "Approved Draft" and "Approved Final Version" and I need two workflows, because I can not use the same WF for Draft and Final version.

What is your experience?

[bsindelar]

Here's what I would do (using the numbering similar to your question):

1. Have the initial life cycle state upon creation of the brand-new object to be something like "Working Draft", revision 1.
2. Daily check in and check out, object stays at revision 1 and life cycle state "Working Draft".
3. Use a Promotion Request object to promote the object through an approval workflow to keep the same revision and iteration at which it was at, and the final promoted state would be "Released Draft".
4. When object is ready to undergo new revision change, have the existing revision 1 at "Released Draft" be the affected item on a Change Task in a Change Notice, and revise that object to be a resulting item in that same Change Task (this is OOTB behavior).  The object would now be at revision 2, initial iteration, with a state like "Working Final Version".
5. Daily check in and check out in preparation to release Change Notice/Task, object stays at revision 2 and life cycle state "Working Final Version".
6. The workflow of the Change Notice/Task will eventually drive the "change" transition on the resulting item, which can be set to put it to a state like "Released Final Version" once that happens.

A few items to note:

• For the life cycle states, it may be better to use "Production" than "Final Version" in steps 4-6 because if you ever need to go to revision 3, 4, etc then the words "Final Version" become meaningless.
• I would not use any sort of IBAs to determine "draft vs final" because this can be done with configuring custom life cycle states as I listed here.

My company is highly experienced in all things Windchill.  Feel free to send me a response at robert.sindelar@eccellent.com or check out or website at www.eccellent.com for more information if you'd be interested in working with us on this or any other Windchill projects you may have.

[tpfueller]

Dear Bob,

sorry for late reply and thank you very much for detailed explanation.

We will actually try out both the soft attribute and the customized life cycles. We let the user decide which to use.

My only concern when using customized life cycle states is the following: What happens if a document has five stages? Then I have to define 10 to 15 customized life cycle states (e.g. working stage 1, under review 1, approved 1..... approved 5). And another document may have different stages with different names, so that the name of the custom life cycle states can not be re-used for the other document and new life cycle states have to be defined.

So my doubt is that we would have to manage many life cycle states in case we have many documents with many different stages.

Setting up new life cycles is much more complex than defining soft attributes. Also from this point of view using soft attributes would be more convenient.

But as I said we will ask the users, because at the end they must be convenient with the solution.

Again, thank you very much and kind regards.

Tom

[bsindelar]

Tom,

The primary purpose of the life cycle template and states as far as Windchill is concerned is to govern the general release process of the object (and to make that easily visible to the Windchill users) as well as drive access control rules on the document (lock objects from modification when under review, only allow certain users to conduct a new revision but not check-out on released objects, etc).

In my experience with customers, typically the release process can span anywhere from about 3 to 7-8 life cycle states for one template.  Though I haven't specifically tried, I don't see why a template with 15 life cycle states couldn't exist.

That being said:

• You mention the scenario where a document has 5 "stages" ... what are you referring to as a "stage"?  Using your first example it looks like a "two-stage" example, where the next revision signifies the next stage.  You could just have a life cycle of 3 states and use the up-revise function to go to the next stage as necessary.  You can still use an attribute to govern the "text" definition of the stage (revision) you are in, if desired.
• You could also make that template of 15 or whatever the maximum number of states you think you would need and use that template on your objects, and you can use change/promotion objects as necessary to navigate to the stages as needed, skipping some along the way if necessary on an object-by-object basis.

There are two main reasons I would vote in favor of the life cycle states vs the attributes:

1. Access control mechanism is governed by life cycle states.  If you use attributes to denote "Draft" vs "Final Working", you cannot tie those attributes to any behavior to allow or restrict certain actions on those objects (without customization), and thus you will still be using the life cycle state of the object anyway to control that access.
2. Life cycle state changes can be built in a more system-controlled way to navigate through workflows and change processes, resulting in a more sound change process overall incorporating input from other users and not requiring an up-iteration of the object.  If the final state was only governed by an attribute, any user with regular "modify" access could change the value of this attribute without anyone else knowing, and it would raise the iteration of the object (meaning a user could "sneak in" an unapproved change if inclined to do so).

I'm not trying to imply that you CAN'T use attributes or that you SHOULDN'T .... only offering my two cents.  Feel free to contact me directly if you're interested in a deeper explanation or would like to bounce more ideas/thoughts off of me.