Background
The Audit and Compliance Kit in the GainSeeker Platform Library includes a sample data set. This sample data is a collection of installable GainSeeker Inspections and Dashboards that users can use out of the box, or adapt to their specific situation. This page provides detailed notes on the design assumptions used in implementing these tools.
Assumptions
Here are the assumptions that were used when developing the sample data set:
- An Audit Event is an activity that may include multiple steps. Each Audit Event is the equivalent of an Auditor picking up a printed inspection checklist and walking around a manufacturing plant to complete the check list. Audit Events are built in GainSeeker using GainSeeker Inspections.
- By default, the Audit and Compliance Kit is installed as a separate user configuration in your GainSeeker deployment. This keeps all the data separate from your production system. This choice can be over-ridden during installation.
- Audits are built primarily on GainSeeker defect data. They may include recording measurement data, but the core data set is stored as defect data.
- Each type of Audit is its own GainSeeker Defect Process. If you’re auditing for ESD, 5S, and Safety you’d have three GainSeeker Processes (ESD, 5S, and Safety). Each Process has its own set of defect reasons.
- While each question in a specific audit could be assigned to its own Defect Reason, we designed these Inspections so that a collection of questions share a defect reason, and the actual question is recorded in another traceability field. This gives users more flexibility when they want to analyze audit and compliance data.
- We assume that users want to track high level information about Audit Events. This makes it possible to answer questions like:
- Were the required audits done in all areas
- Were audits completed in the required time frames?
- We also assume that users want to track detailed information about the findings on each Audit Event. This makes it possible to answer questions like:
- What areas/questions are we struggling with most in compliance?
- What training does my staff need?
- Are there any open issues that my staff needs to deal with?
- This High Level/Detailed Information structure means that Inspections create two types of records for each Audit Event.
- A Parent Record documents that an Audit Event of a specific type (5S, ESD, …) took place at a specific time, along with who did it, where they did it, and so forth.
- A Child Record documents the detailed results of the audit, including the findings for specific questions. For each Parent record there are multiple Child records (a Many-to-One relationship.)
- All Audit questions are framed positively so that a No answer means the Auditor found an issue.
- Each question in an Inspection process is stored as a single Defect Data Record.
Data Structure
To implement sample solutions that met these assumptions, the Audit and Compliance Kit structures the GainSeeker Defect database as follows:
| GainSeeker Defect System Field | Setting | Notes |
| Defect Part Number | “Audit” | All data stored through these kits is stored with a single part number: Audit. This makes these tools more usable in a wide variety of settings. |
| Defect Process (Audit Type) | Examples “ESD”, “5S”, “Safety” | Each Audit Type is a unique Defect Process. Examples include “ESD”, “5S”, and “Safety”. |
| Defect | List by Audit Type | Each Audit Type has a unique list of defects. |
| Sample Size | 0 or 1 | Parent Records store a 1 in this field to indicate that an Audit Event took place.
Child Records store a 0 in this field so that detailed information about audit findings can be stored without distorting the information about Audit Events. |
| NCU | 0 or 1 | Parent Records store a 0 if all questions were answered positively. Parent Records store a 1 if the answer to any question is No.
Child Records store a 0 in this field. |
| Trace 1 = Audit Frequency | Examples “Hourly,” “Shift”, “Lot”, “Daily”, “Weekly”, “Monthly”… | Frequency of Audit |
| Trace 2 | Not Used | |
| Trace 3 = Department | Examples “Front Office”, “Paint Department”, “Production”, “Shipping”… |
What department is being audited. |
| Trace 4 | Depends on Audit | Sub-Inspection. Used when an Audit has multiple stages or sections. For example, a 5S audit might have a group of questions around Sort or Shine. Each group of questions would be a Sub-Inspection, and possible assigned to a single defect reason. If the audit has only one section, then there is only one Sub-Inspection. This field is required and setup during installation. |
| Trace 5 | Test Name (required – setup during installation) | |
| Trace 6 | Auditor | |
| Trace 7 | Question text. Please note this is the first 30 characters of the question text, unless you set the field length to a different length. If you make it too long and wish to see the question on a Pareto Chart, you find that GainSeeker shrinks the text so it fits on the Pareto Chart and may be unreadable. |
