Layered process audits: layers, questions, follow-up and measures

The two answer different questions and neither replaces the other:

Because an LPA happens while the work is running, it can catch a deviation before bad output is finished. Write both purposes into the procedure. A good audit result does not allow skipping a required inspection, and a good inspection result does not excuse a deviation the auditor saw.

Each layer brings a different level of authority to the same core checks. A starting design to adapt, not a required schedule:

A small site may need fewer layers than a large multi-shift operation. Do not add titles just to make the schedule look complete; every layer needs a purpose.

Keep a shared core of process questions across layers so results are comparable. Managers can add questions about open actions or resource gaps, but those should not replace direct observation. A manager reviewing a dashboard has not done the same thing as a manager watching the process.

LPAs fail when quality is left to run everything. Spread the work:

Decide what the program must protect before writing any question. A four-field planning sheet makes the link explicit:

Each selected check should have a clear reason to exist. If nobody can name the failure it prevents, leave it out.

Five sources cover most of what is worth auditing:

Prioritize rather than copying everything in. Keep mandatory checks, and drop optional questions that have no clear purpose or cannot be answered reliably.

1. 1

   Pick a manageable starting scope. One process or area with clear standards. List the equipment, stations, products and shifts included, and what is left out, so nobody mistakes a pilot for full coverage. Agree what the pilot should test, such as whether auditors read questions the same way.

2. 2

   Confirm the standard first. Each requirement must be approved, current, accessible and understood. Resolve conflicting instructions through document control, not by asking auditors to choose. Walk the checks with the people who do the work.

3. 3

   Write questions and define evidence. One target per question, with its reference and what a satisfactory answer looks like. Test each one at the workstation; if trained reviewers disagree, rewrite it.

4. 4

   Set schedule and escalation rules. Named auditors, audit windows, coverage across shifts and backups. Define how missed audits are recorded and rescheduled, and who receives each type of finding. Urgent issues go through the site's normal escalation, not to the next meeting.

5. 5

   Observe and record facts. Auditors check real conditions, not memory. The displayed program did not match the approved setup reference is a finding; the operator was careless is a judgment.

6. 6

   Respond, assign and verify. Restore the correct condition, then record the action needed to stop it happening again, with an owner, a due date and the evidence that will show it worked. Larger problems go to the formal corrective action process, such as 8D.

7. 7

   Review the pilot before expanding. Compare recorded results with what is happening at the process. Check question clarity, time taken, missed coverage and open findings. Each new area needs its own questions, not a copied checklist.

Original example questions to adapt. Replace the general terms with your document references, equipment numbers and acceptance criteria:

• Avoid broad prompts: Is everything correct? leaves the answer to each auditor's interpretation. Another trained person should be able to find the same requirement and look at the same evidence.
• Split compound questions: One question about a gauge's identity, calibration, storage and use produces an unclear no. Separate checks show which part failed.
• Fix the answer options: Conforming, nonconforming, not applicable and not observed, with a note required for the last two. Missing evidence is never a pass.
• Keep a short header: Process, station, date, shift, auditor, layer, and the checklist ID and revision.
• Give findings their own fields: Question ID, result, evidence, immediate response, owner, due date, escalation, verification and closure date.

Decide who can edit findings and who can approve closure, and keep personal or customer information out of widely visible records.

An illustrative assembly process has an approved setup sheet and a selectable equipment program:

1. 1

   The finding. The audit question asks whether the active program matches the setup sheet. The auditor sees a mismatch and records the equipment ID, production order, displayed program and setup reference.

2. 2

   The immediate response. The auditor follows the reaction procedure and notifies the leader. An authorized person decides on containment, including any output that might be affected. Changing the program alone does not resolve everything.

3. 3

   The investigation. The action owner asks how the mismatch was possible. Were program names confusing? Were access controls right? Was setup confirmation clear? These are prompts, not assumed causes. The five whys help here.

4. 4

   Implementation check. A later audit confirms the revised control is in use.

5. 5

   Effectiveness check. A broader review of recurrence and conditions over the following weeks. Do not close the issue just because a revised instruction was uploaded.

Training should prepare people to do the audit, not just explain the terms. Build it around the real process and checklist. A compact training pack holds:

• Program overview: Scope, layers, responsibilities and schedule.
• Annotated checklist: The reference and expected evidence for each question.
• Finding examples: Clear findings next to vague ones that need rewriting.
• Reaction instructions: The escalation and containment steps for this area.
• Practice exercise: Conforming, nonconforming and unobservable conditions to judge.
• Supervised audit: A first real audit with an experienced auditor and recorded feedback.

Have trainees judge the same example on their own, then compare. Where they disagree, find out whether the cause is wording, missing evidence guidance or knowledge, and fix the system as well as coaching the person.

Assess how auditors treat people. They should explain what they are checking, invite the operator to show the work and never interrupt a critical task. An LPA checks the process, not the person.

An LPA board should coordinate follow-up, not display completed forms. Four sections cover most needs:

Keep audit complete and action closed as separate states. An audit can be complete while its finding is still open, and an action can be done but not yet verified. A green status should never hide unfinished work.

Many sites run the schedule on a kamishibai board, with a card for each audit that flips from red to green. Never use the board to rank people by how few findings they report; that teaches auditors to stop finding things.

Completion shows participation. These show whether the audits are doing their job:

Write the counting rules before comparing departments: how rescheduled audits, canceled production, duplicate findings and reopened actions are treated. Otherwise differences reflect reporting habits, not performance.

If defects fall after launch, check what else changed, such as equipment, materials or inspection, before crediting the audits. A link is a reason to investigate, not proof.

Choose the format after deciding how the program will run:

The example checklist and record fields above work as a free starting template. Replace every generic example with a verified requirement before use.

1. 1

   Treating the LPA as inspection. Checking parts instead of the controls that make them.

2. 2

   Copying a checklist from another site. Questions must come from this process's risks.

3. 3

   Adding a question after every incident. First ask whether the process needs a better control, clearer instructions or training. A growing checklist does not fix a process.

4. 4

   Counting completion as success. A perfect schedule with repeat findings means the follow-up is failing.

5. 5

   Delegating the management layers. The point is leaders seeing the work themselves.

6. 6

   Blaming operators. Findings describe a condition, never a person's character.