Layered Process Audit

What this tool does

CM8-290 records layered process audits one question at a time. Each row is a single check: who audited, at which layer, in which area, what was asked, whether it passed, what was seen and what still has to change. From that the tool works out the pass rate against your target, the audits completed at each layer, the weakest categories, the questions that keep failing and the overdue actions. Everything runs inside this single file — no account, no upload, no network request — so auditor names, areas and findings stay on the computer you are using.

What a layered process audit is — and what it is not

A layered process audit is a short, frequent check that the standard is being followed at the point of work, carried out by several levels of management rather than by an audit function. A team leader checks a handful of things on their cell daily, a supervisor weekly, a senior manager monthly. The audits take minutes, they happen where the work happens, and much of their value is presence and habit — a manager standing at the station, there when the answer is awkward. A programme where only team leaders audit has lost most of its point while still generating the paperwork.

It is worth being precise about the difference from a management-system audit, because organisations that run those often assume an LPA is a smaller version of the same thing, and it is not. A system audit asks whether a documented process exists, is adequate and is being maintained; it is done by trained auditors against a standard and happens perhaps annually. An LPA asks something narrower and far more useful day to day: is the thing we agreed would happen actually happening, right now, at this station? It has no opinion about whether the procedure is well written. It has one opinion about whether the current revision is on the wall. That narrowness is the point — it turns a standard from a document into an observable fact, often enough that drift is caught in days rather than in a customer complaint.

The three layers, and why layer 3 matters most

Layer 1 is the team leader, daily: five to ten questions on their own area, catching drift within a shift. Layer 2 is the supervisor, weekly — the same question set, often in an area they do not run, as a second pair of eyes on what layer 1 has been passing.

Layer 3 is senior leadership, monthly: fewest audits, and the ones that count for most. The questions a director asks are rarely more penetrating than the team leader's, and that is fine — the questions are not the point at this layer. What matters is that the person who decides budgets has stood at the station and seen the standard: it visibly matters at the top, and the top learns what it is like to follow. A director who has personally found the wrong revision at a station will approve the document-control fix without a business case. Layer 3 is also the first layer to disappear when the month gets busy, which is why an empty layer is coloured red.

Writing questions that are observable and binary

A good LPA question can be answered pass or fail by any competent person standing at the station, without discussion. That rules out most of what people write first:

• Not "is the area tidy?" but "is every tool in its marked location on the shadow board?"
• Not "is quality being checked?" but "is the in-process check sheet complete for the current job?"
• Not "are operators trained?" but "can the operator state the takt time for this cell?"
• Not "is documentation controlled?" but "is the current revision work instruction at the station?"

If two honest auditors could reach different answers, the question is not written yet. Keep the wording identical between audits: the tool groups by question text, so a rephrased question becomes a new one.

Short and frequent beats long and rare

An audit that takes forty minutes will be done when there is time, which is never. An audit of six questions takes six minutes and survives a bad week. Twelve short audits a month sample the process twelve times, across different shifts, jobs and operators; one long audit samples it once, on a day everybody knew was coming. If a layer 1 audit takes more than ten minutes, cut questions rather than frequency.

Fix it now, then decide whether it needs an action

The first response to a failed check should be to put it right while you are standing there: print the missing revision, complete the blank check, restock the PPE point. An auditor who writes a finding and walks away teaches the area that audits produce paperwork.

Then ask whether it needs an action. A one-off slip corrected in thirty seconds can be closed on the spot; something that will recur needs a written action with an owner and a date, and the tool refuses a failed check left with "no action needed". The correction addresses the instance; the action addresses the cause. In the sample data the two are confused — the first action fixed the station rather than the cell — which is why the question failed again five weeks later.

Repeat failures are the real output

A single failed check is a finding. The same question failing twice is information about your system, and worth more than everything else the programme produces. There are only three explanations:

• The standard is wrong — it is no longer how the job is done, or never was.
• The training is wrong — people know an older version, and the route by which changes reach them does not work.
• The standard is impossible — it cannot be followed at the takt time, with the tools provided. People are not ignoring it; they are working around it.

None is fixed by auditing harder. The repeat-failures table and the most-failed-questions chart keep those cases in front of you until somebody decides which of the three it is.

Keeping the question set alive

Question sets decay. A question that has passed forty times in a row is no longer testing anything — it is costing the auditor time and inflating the pass rate. Retire it, and put it back into rotation months later to confirm the gain held.

Add questions after a problem: a complaint, a reject, a near miss should each produce a check that would have caught it, and that check belongs in the layer 1 set until it stops failing. If the same six questions are asked every day for a year, the area learns to pass those six questions — not to follow the standard.

The completion rate — how LPA programmes actually die

Programmes are almost never killed by bad results. They are killed by audits that stop happening: a busy fortnight, layer 3 slips first, then layer 2, then layer 1 becomes a form filled in at the desk. The cadence erodes and six months later there is a binder and no data. That is why the layer 1 tile shows completion against your weekly target rather than the pass rate again. A falling pass rate with a healthy count is a programme doing its job; a rising pass rate with a falling count is a programme going quiet.

The formulas

Excluding not-applicable results is the only honest treatment: counting them as passes flatters the rate, counting them as fails punishes an area for a machine being down. Such a check therefore contributes nothing, which is why the tool insists you say why it did not apply. An audit is one distinct combination of date, auditor and area, so a visit producing six question rows counts once.

The spreadsheet workflow

The question set is the natural thing to hold in a spreadsheet, and it is how most programmes start.

• Spreadsheet template in the toolbar saves a CSV whose headings are exactly this tool's column names, with a guidance row showing what each column expects — the date format and the accepted values for the layer, category, result and status lists.
• Keep a master copy with the question and category columns filled in for each area: that is your question set. Copy it for each audit, add the date, auditor, layer and results, and delete the guidance row before saving.
• Import spreadsheet reads it back. Columns are matched by heading, so their order does not matter and extra columns are ignored. Rows failing a validation check — a fail with no finding, for instance — are skipped and reported by row number.

The file is read in your browser: nothing is uploaded, and importing adds to what is here.

FAQ

How many questions should an audit have? Six to ten for layer 1, no more than fifteen at any layer. If it does not fit on one side of a card, it will not be done daily.

What if the operator disagrees with a fail? Record the fail and the disagreement in the notes, and treat it as a signal about the question. Either the question is ambiguous or the standard is not agreed — both beat a negotiated pass.

Is a 100% pass rate good? Once, yes. Every month, no. A pass rate that never moves means the questions have stopped finding anything, and the fix is a new question set.

Saving your work

Audit results, settings and the report header are written to this browser's local storage as you type — one browser on one computer. Treat Export .json as the real save, which Import .json restores anywhere. Export CSV gives you the results for spreadsheet work. Reset asks twice, then erases everything this tool has stored. There is no undo.

Accuracy & disclaimer

The arithmetic is simple and the tool does it faithfully. The limits are in what an audit can see. An LPA records what one auditor observed at one station at one moment; a pass means the check was satisfied when it was looked at, not that it held all shift. Two auditors asking the same loosely written question can reach different answers, and the pass rate carries that variation.

A pass rate that sits at 100% and never changes is the result to distrust most: it usually means the questions have stopped being useful, not that the process is perfect. This is a record-keeping and analysis aid — not a management-system audit, not a product release decision, and not a substitute for whatever inspection or approval regime your sector, your customers or your regulator require.