A pre-built app that allow users create audit cards, select from them at random, indicate pass/fail and track corrective actions.
Process auditing is a common manufacturing practice to ensure adherence to an ever-changing list of normal operating conditions and expectations. Most often used for safety or quality control purposes, process auditing can take the form of checklists, kamishibai cards, or other methods. Non-conformances are recorded, categorized, and aggregated. Corrective actions are managed by operations staff. This application provides a simple, easy-to-maintain process for managing and executing audits.
General Process Overview
This application works immediately “out-of-the-box”. There are no adjustments necessary to begin using the app but you will need to create your own analytics. You may choose to embellish the application with your logo or connect it to other applications.
Getting Started - Application Overview
We recommend that you start with a small group of auditors who will register their mobile devices with the Tulip player. Users all have the same privileges within the app: Create New Audits, Manage Audits, Perform Audits, View Results, and Open Actions.
Create New Audits
Here you will give your audit a Title, Instructions, Location, and an Image. Every audit can be thought of as a “card”. When you create an audit you are adding a new card to your deck. The location will allow you to audit specific areas of your factory. For example, you may only want to perform audits on a single cell, where others may choose to audit the entire facility.
You may use your cell phone camera to take a picture or you may choose to upload a picture from your device
As time goes on you may decide that some audits no longer need to be performed. You don’t want to delete the audit card entirely, but you may choose to remove this audit from the deck for some undetermined amount of time.
On this screen you’re able to view all of your audits and activate/ deactivate them. You can also filter by whether or not they are active
After selecting an audit location you will be presented with a screen that displays a single audit card at a time. These cards will be chosen at random from the deck of available cards. The audit process is to follow the instructions on the card and indicate whether or not the item is in compliance by pressing the green or red button.
Cards will be drawn from the deck until there are no more audit cards left, at which point they will be reshuffled.
All of the audit data will be stored in the system and can be downloaded into other systems if you’d like. Two paretos will be generated automatically within the application: failed audits by location and failed audits by audit title
This provides a very simple way for you to review which areas and audits are failing most often. You may choose to edit this screen so that you can also visualize trends in audit compliance following corrective actions.
Whenever there is a non-conformance there will be an within the Tulip platform and can be viewed in other apps, dashboards, or systems. This is where your team can review the open actions from the audit findings and assign ownership.
There are three statuses by default: REVIEW, IN PROCESS, and CLOSED. Closed actions will not be displayed here. You can edit the drop downs to include your team members or other statuses.
Users can also write comments on the actions as a way of tracking activity.
This section describes the construction of this application and how some key elements function. We will focus primarily on the way that the tables are used to store card information and the trigger logic used to manipulate the tables. We will also review the connector functions being used to serve cards at random and cycle through them. Tulip basics, such as how a table is built or how buttons and variables are created will not be documented in this guide.
This application relies on three tables *Audits and *Audit Actions and *Locations
The *Audits table uses data stored within it to auto-increment the Audit ID (AUDIT1, AUDIT2…). For example, if you were to create an audit card in location “Inspection station” the result would be three-fold:
- The “Number” field in the “All Audits” record would increment by 1 and store this new number as the next audit card (ex: “AUDIT2”).
- “Inspection Station” would be listed under the Location field in the *Audits table for AUDIT2
- “AUDIT 2” would be added to the id=All Audits “Title” record, separated by a comma, from the other audits.
- In the *Locations table the station “Inspection Station” would be added as the ID
- If the station was new, it would also be added to the “Location” field for the id=All Locations
- The “AUDIT2” would be added to the Audits field for the “Inspection Station”
Example of *Audits table after adding a new card:
And *Locations Table would look like this:
Refer to the Trigger Logic and Connectors section of this guide for an explanation of how these comma separated values are used to perform card cycling. The Audit Actions table is much simpler than the Audits table. It is a record of non-conformances. The redundant data copied over from the Audits table is to make displaying audit card related information simpler when data is exported or displayed in analytics.
Trigger Logic and Connectors
Cycling Through Cards
Though individual cards and their content are stored in records of the *Audits Table, we will need a way to select these cards and view them one at a time. We rely on comma separated text values to accomplish this. Below is a diagram of the overall logic and operational flow.
We’ll now review this workflow in greater detail. First, a location is selected and the following trigger is run:
The *Audits Table is loaded into the table record placeholder based on the selected location. In this example, let’s use “All Locations”.
The value in the “Title” field are “AUDIT1,AUDIT2” , AUDIT3” which represents all of the Active cards in the system. When they are passed into the next function “Quickstart - remove from csv at random”, the function is looking at the list, splitting it into its parts, selecting one of the elements at random, and returning a new comma-separated with the remainder. This remainder is stored as a variable that represents the “deck” of remaining cards.
When we load the next step “Perform Audit” we are going to be looking at the card that we’ve selected at random from the deck.
“Value removed” is the value that was returned as the selected card from the deck. It is being used to load the audit table record. We then store the title and location of the audit in variables for easy access after the application completes.
When the audit is passed (green check mark is pressed) we send the remaining items of the deck back into the connector and retrieve another card at random. We then store a 1 under a variable named “pass fail” and a 1 under a variable indicating that an audit has been performed. These will be used when calculating analytics.
Finally, to repeat the process, we check to see if we are at the end of our deck
If the value of the card that was selected from the remaining deck is blank then there are no more audit cards to process. The app will complete and return the user to the main screen. If there is another card selected then the app will complete and return to itself, repeating the process.
Creating New Cards
Card creation is slightly more complicated than just adding a new table record, because we must create and edit other records when cards are created. An example of this is described in the Table Structures section, above. Here we will discuss the trigger functions we use.
Since “All Locations” and “All Audits” always exists, we load these records first as part of the “App Started” triggers. It stores the auto-incrementing number identifier that is appended to the audit card (ex: “AUDIT2”). We increment this field and create/load a record using the concatenated values to create the placeholder for our new card.
Then, “csv add (unique a-z)” connector function is executed. This function provides us a simple way to add an item to a comma separated value string without having to worry about sorting them or managing duplicate entries. We use this to add our location (if a new one was created) “All Locations” record in the *Locations table by sending the existing CSV into the connector along with the new value and saving the returned CSV in its place. This ensures that we have an up to date list of locations that we can update automatically for use in our drop down menu.
The location is then loaded into its own record placeholder in the *Locations table. We will want to enable users to know which cards are specific to their location and this enables us to accomplish that. Using the same connector method, we write the unique audit card IDs into both the “All Locations” record and the location’s specific record.
Finally, we save the card information to the card record (not shown)
To create a pareto of non-conformances from our audits we need to use the values being stored when the application performs a completion. The key variables here are “pass fail” and “audit flag” . Every time an audit is performed we set the audit flag to 1. This enables the app to complete on other occasions without impacting our audit tracking analytics.
When the audit passes “pass fail” is 1 and when it fails “pass fail” is 0. We can take the sum of “pass fail” divided by the sum of “audit flag” to get a percentage of compliance for each audit card. Alternatively, you could calculate the inverse using a similar method.
Beyond these two variables, you can categorize your audits by location, title, or user performing the audit. You can also generate other trending information such as audits performed each day and percent compliance each day.
Interested? Reach out to email@example.com or the Chat in the bottom right and we will get you this application imported to your site.