ENOVIA

WHAT IS PLANNED TO ADDRESS THE GAPS IN MANAGEMENT OF “OBSOLETE” SPECS IN ENOVIA?
CURRENT, THRU V6R2011X, NO STRATEGIES ARE IN PLACE TO ADDRESS THE SPECIFICATION AND DOCUMENTATION LIFECYCLE PAST “RELEASE”, LEAVING A HUGE HOLE FROM A CONFIGURATION AND DATA MANAGEMENT POINT OF VIEW. THESE LIFECYCLE STATES SHOULD INCLUDE INACTIVE, CANCELED, SUPERSEDED AND OBSOLETE.

1. I agree that many customers do have business process that is linked to Document maturity after Release
a. We can certainly consider adding an additional state to track this behavior. There is no one way that all customers do this
b. This has never been a critical problem in the past
2. Typically, customers that are interested in post release lifecycle, take one of the two following approaches:
a. They add their specific policy states after Release
b. Or, they define a unique policy that is used for post Release tracking