| Users |
Users 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. Omnify uses these user names to track individuals in the database. |
| User Groups |
User Groups are defined as a set of users who can be classified under a workflow heading or other user-defined classification. |
| Permissions |
Permissions 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 Groups |
Permission Groups define a set of specific permissions that can be applied to a user. |
| Items |
An Omnify 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 Omnify items can contain two key levels of classification: Type and Category, additional classification/granularity can be defined using Attributes. |
| Type |
Types 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. |
| Category |
Categories represent subclasses of Item Types. |
| Status |
Status is defined as a property of any Omnify 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 items current lifecycle condition. |
| Attributes |
Attributes are used to associate properties to any Omnify 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. |
| Vendors |
Vendor objects allow you to 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 Items |
Vendor Items represent objects that are provided by other "Vendors". Vendor Items can be associated with Omnify Items or other Vendor Items (e.g. Distributors who provide items for a specific vendor). |
| Documents |
|
Documents 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 Omnify. |
| |
• Vaulted |
- Documents reside within the Omnify database. Changes to vaulted documents are controlled by check-out/check-in processes or by a check-in action under a Change/ECO. |
|
| Changes |
Changes 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 Objects |
Quality 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 Objects |
Service Objects can represent instances of products (such as Serial Numbers, Lot Numbers, and RMA Numbers) or other resources (such as machines, and test equipment). |
| Projects |
The 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 Objects |
Training Objects can represent training or test processes that require users (or other resources) be updated either on a one-time or continual basis. |
| Tasks |
Tasks 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 a tasks completion. Tasks can be assigned to Projects, Changes/ECOs, Quality Forms (CAPA), and Training Objects. |
| Workflows |
Workflows represent electronic signoff processes. Workflows contain a list of users who are necessary for approval to process an Omnify 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 Routings |
BOM Routings represent the procedures (operations and steps) required to manufacture, assemble, and/or test a product. |
| Views |
Views 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). |