Active Sensing, Inc.
		Acseni® Configuration & Data Management System

Workflow & Process Management

Formal changes to document records are "encapsulated" in change actions. These actions define which document records are being changed, how to change them (that is, issue/void variations and move variations on/off structures), and who must approve the changes. There are four basic actions, each of which performs a specific role in informing Acseni users of pending document changes. The types of action are:

• A Waiver accepts a specified number of already-produced items that do not conform to the design documentation, but are acceptable for use (or will be acceptable after approved rework is performed).
• An Engineering Change Request (ECR) is the formal notice that an item within the system may require modification.
• An Engineering Change Proposal secures the acceptance of document changes prior to altering the original documents.
• The Engineering Change Notice documents the implementation milestone. That is, a signed-off ECN demonstrates that the documents listed on it have been updated and may be used in accordance with the effective dates listed. The ECN also provides information on the cost of the change: the expenses associated with scrapping or reworking old parts, and retooling and implementing new ones.

Implementing Action

Although all actions provide information about document changes, only the implementing action (which Acseni calls the engineering change notice, or ECN) makes permanent document record changes. This implementing action, when it is formally approved, modifies all pending variation and structure records according to the instructions of the action and the CM user. In other words, a user can issue or void variations, and take variations on or off structures, by specifying these activities on the implementing action. Then, after all groups have approved it, the action is used as a "script" to make the changes that the user listed. When an ECN receives Accepted status, pending changes to variations are converted (as appropriate) to issued and voided, and variations are formally placed on or off the affected structures.

Non-implementing actions, like ECRs, do not actually make any changes—they inform users how items will be changed by the implementing action.

Action Status

Each action has a current status, from development through completion. Certain functions can only be performed at a particular status:

• develop The action is being created. Users can build lists of variations that are to be issued or voided, and to be added on or taken off structures. ECRs and deviations can only list changes to issued variations; ECOs and ECNs can indicate changes to both pending and issued variations. When ready, the action’s "owner" should set the status to technical comment or submit to the CM group for clerical check.
• comment The action’s owner is soliciting informal technical review prior to formally submitting the action. For instance, users with technical review responsibilities could search each morning for all actions at this status. Acseni still treats this as "in development." The action can be withdrawn to develop further, or moved to clerical check.
• check The action will be checked that it conforms to CM standards. For example, drawing redlines will be verified against the variation change list and structure markups will be checked against the structure change list. The CM group also creates the approval groups list. The action can be sent back to develop or comment status, or a CM group signer can submit the action for approval.
• submit One of the CM group’s authorized signers has reviewed the action, and agrees that all required information has been included and the action meets approved CM practice. After the CM signer has submitted the action, each group’s authorized signers may approve or disapprove the action, or may request clarification.
• clarify At least one group’s authorized signer has questions that prevent a simple "approved" or "disapproved" response.
• reject At least one group signer has disapproved the action, and CM has formally rejected the action. Until the action’s status is changed to rejected, an individual group can change its decision. Once formally rejected, an action cannot be suspended.
• accept All groups have approved the action, and CM has formally accepted the action. Once accepted, an action cannot be suspended nor can a group’s decision be changed.

There are two special action status directives:

• suspend Until an action has been accepted or rejected, it can be suspended at any time during its development. Once an action is suspended, it is "locked" at its current status. A suspended action can be "unlocked," which returns it to the develop status and resets all approval groups’ decisions back to pending.
• revise An accepted action can be revised if you discover that the action has a clerical error. All of the original action’s fields, as well as the original approval group list (which is reset to pending), are copied to the revised action. The original action is not changed at all. You can modify the revised action’s fields, but you cannot add any variation or structure changes.

Approval paths and their stages

Acseni allows you to define how documents will be controlled in your CM system. The definition is constructed of one or more approval paths, which are specified arrangements of stages, actions, and approval groups. After you’ve constructed your approval paths, DocTypes may be assigned to these paths for specific programs.

Each new variation of a document that is assigned to a particular approval path will be changed according to the approval path rules.

A document is promoted from stage X to stage Y, or revised at stage Y, in conformance with its approval path. Each promotion into a stage, or revision at that stage, uses the same sequence of actions, each with the same list of approval groups. It is the target stage (i.e., the destination) that determines the set of rules that are applied.

For example, consider a path that has 3 stages (prototype, produce, and obsolete). To promote a document from prototype to produce, or to revise a document already at the produce stage, 2 actions are required: a change request (ECR) and an implementing action (ECN). The ECR may have only one approval group—engineering—while the ECN may require both engineering and manufacturing to approve it.

Since the promotion from prototype to produce stage, and the revision at produce stage, both have the same target stage (produce), they both follow the same rules. Therefore, ECR A and ECR C have the same approval group (engineering). Likewise, ECN B and ECN D have the same approval groups (engineering and manufacturing).

Further assume that the obsolete stage needs only one action, an ECN, with the approval of the engineering and product planning groups. Although this single action is all that is needed to move a document to obsolete stage, both an ECR and ECN would be needed if the document must be brought back to produce stage.

Once one or more actions have been assigned to each stage on the path, the groups are specified that must approve each action. For instance, an ECN at produce stage may have a different approval list than an ECN at obsolete stage.

Assigning DocTypes to approval paths

There are two ways a DocType can be put onto an approval path:

• as a standard DocType with a default path, or
• as a program DocType.

An approval path defines the rules for any number of standard DocTypes and program/DocType combinations.

A standard DocType does not need a program when it is first defined, because it’s assigned to a default path. The default path defines how that standard DocType will be controlled: which stages are valid, which actions are used at each stage, and which groups must approve each action. So, by "standard DocType," we mean a document type that has no specific approval program.

A program and DocType, as a pair, can be assigned to a single approval path.

Programs are also used for grouping related master records, and on an action to identify which products will be affected by that action. A new approval path need not be created simply because a program is defined. It makes sense to assign a master record to a program only when a special approval path is required for that master.

Technical Support for current users

ACSENI has been replaced by PDXpert Product Lifecycle Management software

Copyright © 1996-2006 by Active Sensing, Inc. All Rights Reserved. The information here is believed to be accurate at time of first publication. However, all product features, capabilities and prices are subject to change without notice. Acseni is a registered trademark of Active Sensing, Inc.