Skip to main content

Terminology/Glossary


Terminology/Glossary

Key Terms

Key terms for the Empower Database and Modules:

TermDescription
UsersUsers are defined as any end user who requires access to the database to perform a specific task. Tasks can be, new part requests, Change/ECO requests, document viewing, signoff, etc. A user must be created for each individual user who will access the system. When defining a user you can define information such as login name, full name, permissions/permission group, email address, custom properties, etc. Empower uses these user names to track individuals in the database.
User GroupsUser Groups are defined as a set of users who can be classified under a workflow heading or other user-defined classification.
PermissionsPermissions are rules for a user logon that are stored in the database. These rules can control each user's ability to view specific objects or fields as well as define which operations the user has access to perform.
Permission GroupsPermission Groups define a set of specific permissions that can be applied to a user.
ItemsAn Empower Item is an object that contains all relative information related to a physical object that is being managed and tracked. An Item can be an individual component/part, wire/cable, assembly or sub-assembly (BOMs), document, set of documents, etc. All Empower items can contain two key levels of classification: Type and Category, additional classification/granularity can be defined using Attributes.
TypeTypes define a classification of an Item, Change, Quality Object, Project, or Training Object. Type settings/options for all objects are user-defined (Administrator). Type settings are optional; however they can be included in any search or report to help quickly find objects or isolate specific areas of interest.
CategoryCategories represent subclasses of Item Types.
StatusStatus is defined as a property of any Empower object. The Status field for most objects (e.g. Changes, CARs/PARs, and Projects) is automatically controlled and indicates the condition of the object as the system understands it. The Status field on any item is user-defined and can be used to determine an item's current lifecycle condition.
AttributesAttributes are used to associate properties to any Empower object. Attributes have both an Attribute Name and Value. Attributes can represent any associated data that you need to define for an object. For example, attributes can be used to define Behavioral Characteristics, Physical Characteristics, Classification, Responsibilities, and Purchasing Information.
VendorsVendor objects allow you to manage people, companies, and/or resources that supply specific items for your assemblies. You can define different types of vendors: Manufacturers, Suppliers, Distributors, Contractors, Customers, Partners, etc.
Vendor ItemsVendor Items represent objects that are provided by other "Vendors". Vendor Items can be associated with Empower Items or other Vendor Items (e.g. Distributors who provide items for a specific vendor).
DocumentsDocuments represent associated files for any database item. There is no limit to the number of documents that you can assign to any item. Documents can be:
  • Linked - Documents reside in shared areas/folders and the links to these files are managed in Empower.
  • Vaulted - Documents reside within the Empower database. Changes to vaulted documents are controlled by check-out/check-in processes or by a check-in action under a Change/ECO.
ChangesChanges are defined as formal change requests that identify modifications that need to occur to an item in the database. Changes contain "Affected Items". Affected Items represent the items that will be modified once the Change is approved by users. Modifications to the affected items are defined as "Redlines".

Once the Change is approved by all users on the workflow, the system will automatically perform the changes (redlines) defined for each affected item.

Changes can contain a "Type" (such as ECO, ECR, ECN, MCO, Deviation) for classification and rules purposes.
Quality ObjectsQuality Objects define issues or defects to specific items. Quality Objects contain "Affected Items". Affected Items represent the items for which defects have been detected.

Quality Objects can contain "Tasks" that identify steps necessary for closure of the defect/issue. Thus providing a "closed-loop" processor for resolving issues.

Quality Objects can contain a "Type" (such as CAR, PAR, SCAR, NCMR, Customer Complaint) for classification and rules purposes.
Service ObjectsService Objects can represent instances of products (such as Serial Numbers, Lot Numbers, and RMA Numbers) or other resources (such as machines, and test equipment).
ProjectsThe Project Object provides the ability to capture critical project data such as project tasks, actions, and resources (users) responsible for carrying out project tasks. The Project Object tracks timeframes, deadline and deliverables and provides an alerting mechanism to automatically remind users when tasks are nearing (or exceeding) allotted timeframes.
Training ObjectsTraining Objects can represent training or test processes that require users (or other resources) be updated either on a one-time or continual basis.
TasksTasks are used to define actions that users are responsible for completing on any given object. Tasks can contain timeframes that define the start and end date and times allotted for task completion. Tasks can be assigned to Projects, Changes/ECOs, Quality Forms (CAPA), and Training Objects.
WorkflowsWorkflows represent electronic signoff processes. Workflows contain a list of users who are necessary for approval to process an Empower object (e.g. New Part Request, Change/ECO, Defect/Issue, Project, etc.). Workflows can contain "Stages" to control the alerting of users. Workflows can be assigned to objects automatically based on object "conditions".
BOM RoutingsBOM Routings represent the procedures (operations and steps) required to manufacture, assemble, and/or test a product.
ViewsViews are stored queries in the database that enable the end user to run searches or reports on the database to dynamically view specific items and properties. Views can be used by any 3rd party tool that supports ODBC (Open Database Connectivity).