One scheduling standard across aerospace sites that actually rolls up

Why the numbers do not roll up

The complaint is always phrased as a data problem and is almost always a definition problem. Ask three sites for last quarter's non-destructive test rejection rate and you will get three numbers computed three ways. One divides rejected parts by parts inspected. Another divides indications recorded by parts inspected, which counts a part with four indications four times. A third excludes parts that were reworked and passed, on the reasonable grounds that they shipped. All three are honest; none of them can be summed into a group figure.

On-time performance is worse, because there are at least three defensible clocks: the date the customer or the production plan needed the part, the date the shop promised it, and the date the part physically arrived in the inspection area. A site that measures from arrival will always look better than a site that measures from need, and the difference has nothing to do with performance. Until the group picks one clock and applies it everywhere, comparing sites is comparing measurement conventions.

The consequence of leaving this unresolved is not just bad reporting. It is that improvement effort gets aimed at whichever site has the least flattering convention, and genuine problems at the site with the most generous convention stay invisible. A scheduling module can enforce a shared definition at the point where the event is recorded, which is the only place enforcement actually works.

Due dates in cycles, hours and calendar, whichever comes first

A scheduling engine built on calendar dates is structurally wrong for aerospace MRO. Damage tolerance derived inspections are expressed in flight cycles. Systems tasks are often in flight hours. Corrosion prevention and control tasks are usually calendar. Airworthiness directives issued under 14 CFR Part 39 routinely combine them, with a compliance threshold in one unit and a repeat in another, qualified by whichever comes first. Any of these can also carry a tolerance whose application rule matters.

The engine therefore needs three things at once: utilisation data per serialised unit, a due rule that evaluates multiple unit types together and returns the earliest, and an explicit statement of which basis triggered the due item. That last point is often skipped and is essential in practice, because a planner arguing about a due date needs to know whether it came from hours, cycles or the calendar before the argument can be resolved.

Tolerance handling is the subtle multi-site trap. If a task is performed inside its tolerance, does the next due date compute from the actual performance date or from the original scheduled date? Both rules exist in the industry and both are used legitimately. What cannot be tolerated is sites applying different rules under one group compliance report, because the same task will drift apart over several intervals and nobody will be able to explain why.

One taxonomy, many technique sheets

Standardisation programmes usually fail by attempting too much. They try to impose a single technique sheet library across sites and collide immediately with the fact that a written non-destructive testing technique is approved by a responsible Level 3 at a specific facility, against that facility's equipment, and audited there under Nadcap. The centre cannot approve on their behalf, and telling a Level 3 that a corporate document supersedes their approval is both unwelcome and, in accreditation terms, wrong.

The workable split is between requirement and method. The group standardises what must be inspected, on what basis, to which customer or industry specification, with what acceptance criteria, and how the result is classified and counted. The site standardises how it is achieved: technique number, revision, equipment, reference standards, and the Level 3 who approved it. The schedule then holds both, so a group report can aggregate by requirement while an audit can trace to the local technique in force on the day.

Export control makes this more than a governance nicety. Technique sheets and detailed process data can be controlled technical data, and a naive corporate document library that replicates everything to every site can create a compliance problem that has nothing to do with quality. Systems used across borders need to keep the requirement layer shareable and the technique layer site-scoped by design.

Certification currency is a scheduling constraint, not a report

Under NAS 410 and its European counterpart EN 4179, non-destructive test personnel are qualified and certified by the employer through a responsible Level 3, with documented training, experience and examination, an annual near-vision and colour or contrast differentiation check, and periodic recertification. This is not an HR matter that runs beside the schedule. It determines who may legitimately perform which examination on which day.

When currency lives in local spreadsheets, three things go wrong at group level. Capacity by method is unknown, so load balancing between sites is guesswork. Lapses are discovered by audit rather than by planning. And work occasionally gets performed by someone whose currency had expired, which turns a scheduling oversight into a product integrity question and potentially a re-inspection of everything processed in the interval.

Holding certification in the same system as the schedule fixes all three at once. The planner sees available certified hours by method and by site. The system refuses to allocate an examination to a technician whose method certification or vision check expires before the planned completion date. Recertification and vision checks become scheduled items with lead time, so they are booked before they bite. None of this is sophisticated; it is simply the consequence of putting currency where the allocation decision is made.

Process control checks are scheduled work too

Penetrant and magnetic particle lines carry their own recurring verification obligations, and the standards are specific about them. Liquid penetrant system performance checks and magnetic particle system verification, along with light meter readings, bath concentration and equipment calibration, run on cadences that are part of the process, not an adjunct to it. Nadcap auditors examine them closely, because they are the evidence that a result means anything.

The multi-site issue here is cadence and record. One site runs a check every shift, another daily, a third at line start-up. All may satisfy the requirement, but a group process control compliance figure computed across them is not a meaningful number. Worse, some systems record only that a check was performed, not its result, which makes the important question unanswerable: what happened to the parts processed between a failed check and the last known good one.

Putting these micro-schedules on the same engine as the inspections themselves solves the traceability problem structurally. The check has an owner, a due time, a result and a link to the line. Parts processed on that line inherit the bracketing checks. When a check fails, the affected population is a query rather than an investigation, and the containment decision can be made in an hour rather than a week.

Evidence: what an auditor asks every site for on the same day

A Nadcap or customer audit is largely an exercise in tracing samples. The auditor picks a part, and asks who inspected it, what their certification status was on that date, which technique and revision applied, what equipment was used and when it was last verified, what the process control checks around that shift showed, and how the disposition was recorded and approved. Every site answers the same question; the variation is entirely in how long it takes them.

Sites that assemble this by hand typically need a day or more per sample, pulling from a certification spreadsheet, a technique library, a calibration system, a line logbook and a quality record. Sites where the scheduling and execution system holds the links answer in minutes and, more importantly, answer identically. Audit preparation time is a good proxy for whether standardisation has actually happened, and it is measurable without any new instrumentation.

This also changes what accreditation cycles cost. A site whose evidence is assembled continuously as a by-product of scheduling and execution enters an audit in a fundamentally different posture from one that begins preparing six weeks out. The work is the same work; the difference is whether the system captured it as it happened or whether people have to reconstruct it afterwards from artefacts that were never designed to be joined.

Evaluating a multi-site inspection scheduling module

Start with the due engine, because it is the part that cannot be worked around. Ask the vendor to configure a task with a threshold in flight cycles, a repeat in flight hours and a calendar backstop, apply a tolerance, and show what happens to the next due date under both tolerance rules. If cycles and hours turn out to be custom fields with a report on top, the product is a calendar and every site will build its own shadow system around it.

Second, test the taxonomy split. Can a central requirement be published to five sites, each attaching its own technique number, revision and approving Level 3, while a single group report still aggregates by requirement? Can a site be blocked from executing against a superseded technique revision? Third, test currency as a constraint: try to allocate work to a technician whose certification expires mid-job and see whether the system stops you or merely notes it.

Fourth, ask for the same KPI computed at two sites with different local practice and check that the denominator is genuinely identical. Atlantis NDT builds this layer on an Odoo foundation, which keeps the schedule, the personnel certification register, the technique control records, the process control checks and the inspection results in one dataset rather than five, and lets a group standard be enforced where the record is created. A working session against your own site data and one real audit trace is available on request through info@atlantisndt.com.

Request a consultation