Skip to main content
M
mdebower18-Opal
18-Opal
June 26, 2014
Question

Defining Lifecycles: Help!

  • June 26, 2014
  • 10 replies
  • 4803 views

We are currently on Windchill 10.1 and are running a pretty OOTB configuration. We are also starting a project looking at configuration changes and small customizations that we can do to make life easier.

One of the things we "THINK" we would like to change is our OOTB lifecycle. I know the mechanics of the lifecycles, states, promotes, revising, etc.. But not the WHY part of it.

So for example, in the design process we start with alphabetic revisions and then switch to numeric revisions at release to production.

Most of the engineers want a very simple lifecycle [Design][Released][Canceled].

I am trying to make the arguement that since our business needs are to have a 2 phase revision scheme that we need a 2 phase lifecycle with alpha first and then numeric. [Design][Alpha Released][Numeric Released][Canceled].

I lack the knowledge to give them sufficient reason to accept the more complex lifecycle. Any information or resources I could go look at that will help to answer the question: WHY?

-marc

10 replies

M
MikeLockwood22-Sapphire I
22-Sapphire I
June 26, 2014

We have had this in production for 7+ years (state-based versioning with two-phase lifecycle). Unfortunately, a bit complex to set up, but critical to the business to get right.

I've done multiple PTC/User presenations on this - can send you some files.

Don't know how to do so here yet - easy with the exploder - which is going away. email me direct if you like: mike.lockwood@alcon.com

    M
    mdebower18-OpalAuthor
    18-Opal
    June 26, 2014

    Mike,

    Thanks for answering, I know it is critical. But the question I am getting is why is it critical?

    -marc

    K
    kpritchard1-Visitor
    1-Visitor
    June 26, 2014

    I've looked at state based versioning before but not implemented because previous WC versions did not (to my knowledge) bump the Revision when the State changed (i.e. Object was "Promoted"). Another factor was that sometimes you just want to get to the end game (Numeric Rev in your case). That being said, it is attractive in that you can get away from the file based Revision Sequence and the Documentation does show how to do an automatic Revision.

    Are you sure you need different States for Alpha and Numeric Revisions? Does State="Released" + Rev="A", and State="Released" + Rev="1" communicate the same thing as State="Alpha Released" + Rev="A" and State="Numeric Released" + Rev="1"?

    If the end goal is to differentiate editable - not editable - dead, then the Lifecycle you have probably does the job.

    As an adder, I recommend using "In Work" instead of "Design" if you ever get to WTParts because then users, especially casual ones get confused between the Design State and the (Design) View.

    L
    LoriSood23-Emerald II
    23-Emerald II
    June 30, 2014

    Hi Mark,

    It looks like Mike and Keir gave some pretty useful information here. Was it enough to get you what you needed? If so, it would be great if we could mark this thread as answered with the answer provided.

    Thanks!

    Lori

    M
    mdebower18-OpalAuthor
    18-Opal
    June 30, 2014

    Lorry,

    I agree, great information so far and I have a couple of additional questions:

    1. What are the benefits of creating a more complicated lifecycle over a more simplified one?
    2. Can someone provide some examples of what a complicated lifecycle allows them to do?

    -marc

    K
    kpritchard1-Visitor
    1-Visitor
    June 30, 2014

    Marc - there are many ways of "complicating" Lifecycles. The answer may depend on what you mean.

    Advanced Lifecycles allow you to attach a Workflow to a Given Phase (State) and Gate, as opposed to Basic Lifecycles that do not have a Workflow capability. Typically Objects with a Basic Lifecycle (which is different than the Lifecycle named "Basic") have States changed by either or both of Change Management Objects/Workflow or Promotion Request. Benefits of "Advanced Lifecycles from enabling a Document specific Workflow so that a Document can be Reviewed and "Released" outside of a Change notice or building your entire Enterprise product Development Process into the Phases and gates of a Product or project Lifecycle.

    If more complicated means adding States... then ultimately the benefit of the additional States would be to communicate the level of believability of something and/or control access permissions for different Users. An example of this would be a Multi-Phase Development Lifecycle where the each State is communicating a level of maturity. If your company does not use a Multi-Phase Development Lifecycle then there is no audience expecting that levels of maturity be communicated, so simpler is probably better.

    Terms & ConditionsAccessibility statement