Stumble it Post to del.icio.us Digg this Alexa TrafficRank Furl it Seed Newsvine Simpify! Yahoo MyWeb

What's the difference between Item Revision State and Item Lifecycle Phase?

PDXpert PLM software supports various data revision approaches, including traditional pre-production numeric and production alphabetic formats. Nonetheless, this topic explains why these traditional approaches should be considered obsolete. We describe how using only one revision format (alphabetic or numeric), coupled with PDXpert software's built-in item lifecycle phase attribute, provides fine-grained control over product life cycle business rules while reducing the cost and risk of managing item revisions. We believe that using a single revision format regardless of the item's lifecycle phase is current best practice.

Item records, whether for document or part, must have one or more revisions. An item revision represents the technical content at a specific point in time; a released revision represents an item's approved technical content at a point in time.

Separately, items have a lifecycle: they're conceived, designed, prototyped, validated, produced, serviced, disposed of, and (when no longer commercially viable) declared obsolete.

In PDXpert PLM software, an item's revision release state and the item's lifecycle phase are independent attributes. Multiple item revisions may share a common lifecycle phase, and a particular item revision can move through several lifecycle phases.

Document and part revision states

Revision states reflect the availability, or "readiness for use", of a specific item revision. PDXpert PLM software defines exactly 3 release states for any item revision:

  1. Pending (unreleased, pre-release, created, originated, etc.)
  2. Released (issued, authorized for use, active, in-use, etc.)
  3. Canceled¹ (superseded, obsolete, invalidated, void, removed from use, inactive, etc.)

At any point in time, each item in PDXpert software may have no more than one Pending revision and no more than one Released revision, and zero or more Canceled revisions.

These business rules are applied regardless of the product data management process used:

  • Users can discard an item revision in Pending state without effect or penalty.
  • Users can use the revision in Released state according to the appropriate item lifecycle business rules.
  • Users may not use a revision in Canceled state, and the revision must be retained to provide a historical reference.

Note that the only state that's relevant for production purposes is the Released state. And there are some corollary rules:

  • Each released or canceled item revision must have an associated implementing change (typically called an "engineering change notice" or "engineering change order"). A pending revision need not be associated with a change.
  • For an item structure ("bill of materials"):
    • A child component's pending revision may only appear on an assembly's pending revision. An unreleased child revision can never be used on a released or canceled parent assembly revision.
    • Released items can appear as child components on a released parent assembly revision, as well as on pending and canceled revisions of parent assemblies.
    • A canceled item revision may only appear on a canceled parent revision.

The three release states represent the simple life cycle of a specific item record revision, but do not say anything about what business rules apply to the item while the revision is in its released state.

Document and part lifecycle phases

The item lifecycle phase identifies a set of company-specific business rules that are used as the item moves from conception through to production, and is finally retired.

Any number of item lifecycle phases can be defined, and each may be applied to documents or parts or both. PDXpert software generally follows the enumerations² in the IPC-2570 standards, which other PLM software suppliers also use. These phases are specified by IPC-2570 but aren't defined, presumably because each organization will create its own set of business rules.

Here are a few examples of item lifecycle phases with business rules:

  • Design  Document intended for internal use only. It is not approved for external distribution and may not be used to acquire parts.
  • Prototype  Information and the items created from it may only be used in very limited quantities to validate the design.
  • Pilot  Part may be acquired in limited quantities for proof-of-concept production, product support, and field testing.
  • Production  Product design information may be used to produce items without restriction.
  • Service-only  Part may not be used for new designs. Part may only be purchased for servicing previously produced items.
  • Obsolete  Item may not be used for any purpose.

Prototype ("alpha") and Pilot ("beta") phases in particular are often assigned more specific business rules regarding maximum quantity permitted, design approvals required, and tooling and fixture decisions. Contractual obligations or marketing policies may dictate business rules, such as setting tight inventory stock thresholds and tooling availability, for items at a Service-only phase. The Obsolete phase may incorporate disposal & recycling business rules, and inventory write-off procedures. Clearly, each company will approach the set of lifecycle phase definitions according to product complexity, industry norms, marketing considerations and internal accounting policies.

Item lifecycle business rules are only applied by the organization and its supply chain partners to currently-released item revisions, and are irrelevant to pending and canceled revisions.

Relative maturity of an item lifecycle phase

PDXpert software defines a relative maturity lifecycle attribute, which we believe can be very useful. The relative maturity value allows you to test whether a child item on a BOM has a lifecycle phase that's compatible with its parent.

By definition, a zero value represents unrestricted production. Negative values are pre-production, and positive values are post-production. For example, a component at a Prototype lifecycle (RM=-20) should not be used on an assembly at a Production lifecycle (RM=0); however, the relation would be valid if a Production component was used on a Prototype assembly. Likewise, an item at Service-only phase (RM=+60) obviously should not be used on a Production (RM=0) assembly, but the reverse is perfectly acceptable.

Benefits of keeping revision states and lifecycle phases separate

In many older engineering document control processes, an engineering drawing revision did double duty, indicating both a specific technical iteration and the business rules currently applicable to the engineering drawing. Numeric ("01"), dash ("-"), and date ("22 Oct 1992") formats were recommended³ prior to production release, and alphabetic revisions ("A") were used for production revisions. In the pre-computer era, this was understandable because methods for informing a item's user of its lifecycle phase were quite limited and lifecycle business rules weren't terribly sophisticated.

However, one paid a significant price for this scheme:

  1. At the critical moment of moving the product into production, every engineering drawing had to be modified to change the pre-production revision format to production format. At a project's most critical juncture, the last thing you want to do is run every drawing though the CAD system one more time to update the revision block. It's a time-consuming distraction that adds little value and, with an unnoticed flick of the mouse, can actually damage previously-validated information.
  2. There was a practical limit to the number of lifecycle phases that could be represented by a pre-production drawing revision and, in most cases, there was no ability to distinguish any lifecycle phase after production.
  3. Within a specific lifecycle phase, changing a drawing revision indicated that the technical contents of the document had changed. But changing the revision format to indicate a new lifecycle phase left an ambiguity: did the document contents change at the same time as the lifecycle phase changed?

By separating the item revision from its lifecycle phase, PDXpert PLM software avoids these difficulties. Importantly, a single revision format can now be used through the item's lifecycle. Incrementing the revision value exclusively indicates an interchangeable change to a physical part, or a change which affects only the document contents. The engineering document process can also support an unlimited number of lifecycle phases anywhere between item concept and obsolescence, with each phase having a distinct set of business rules.

While PDXpert software can correctly increment separate pre-production and production revision formats (and can support manual revision formats like dash and date), there is no longer any reason to maintain more than one revision format over the life of an item.

Notes:

1. Items no longer in use may be superseded (replaced with a newer item) or obsolete (not replaced); see Samaras, Thomas: Configuration Management Deskbook, AACI (1988), page 137. We looked for generic term to accommodate both concepts and settled on canceled. Although we try to follow much of the nomenclature used in the IPC-2570 series of standards, unfortunately "Obsolete" is one of the Item element's Global Life Cycle Phase Code enumerations (see IPC-2578 section 4.1). We adopted Pending/Released/Canceled for revision states rather than Pending/Released/Obsolete because we wanted to avoid confusion between the invalidated revision state and the "no longer in use" item phase.

2. IPC-2578 globalLifeCyclePhaseCode (section 4.1) and globalManufacturerPartStatusCode (section 9.1).

3. See, for example, Watts, Frank: Engineering Document Control Handbook, Noyes Publications (1993), page 132.

071111.1930