What Change-Control Rules Belong in a Reorder Programme?

Every running programme changes. A fabric is discontinued, a fastener code ends, a print method is replaced, a packing carton is resized. The question is never whether change happens; it is whether the change is recorded before or after the units it affects are made.

Change control is the rule set that answers that. It classifies changes by risk, assigns an authority to each class, sets a notice period, states what evidence must travel with the proposal, and dictates how the decision is written into the spec file. None of it is complicated; all of it is usually missing.

What Counts as a Change in a Reorder Programme?

Any difference between the registered product and the product being made. That includes a material from a different batch, a component from a different maker, a different machine or line, a different assembly sequence, a different packing method, and a different sub-supplier for a bought-in item.

It also includes changes that sound administrative: a different cutting die because the original wore out, a different needle size because the fabric behaved differently, a different carton because the previous size was unavailable. Each of those can move a measured property, and each belongs in the log.

A useful way to frame the scope is to say what is not a change: a different operator on the same machine, a different pallet in the same warehouse, a different ship on the same route. Those are normal execution and logging them would bury the entries that matter. The line sits between a change to the product and a change to the people making it.

The test for whether something is a change is simple: if a person comparing the next run against the retained reference would notice it, it is a change. That test catches the items that programmes argue about - a different stitch density because a needle size changed, a different panel tension because a feed setting moved - and it excludes the items that genuinely do not matter.

Where the answer is unclear, log it anyway. A log with a few class one entries that turned out to be trivial costs nothing and builds the habit; a log kept short by judging each item on the spot is a log that misses the one item that mattered, because the judgement is always made under time pressure.

How Are Changes Classified by Risk?

Four classes are enough. Class one is cosmetic: a change that does not affect a measured property, a tested claim or a regulated statement. Class two is functional: it affects fit, assembly or a measured property that has a band. Class three is tested: it affects a property covered by a test report. Class four is regulated: it affects a compliance statement or a claim made to the market.

Who May Authorise Each Class of Change?

One named owner on each side, and the class decides whether the owner is asked or informed. Class one is informed. Class two is agreed between the owners. Class three adds a test review. Class four requires the buyer's written acceptance, because the claim being made in the market is theirs.

Name alternates as well. Change control fails most often during a holiday or a staff change, when the person who would have caught the change is not there. A named alternate with the same authority removes that gap for the cost of one line in the document.

How Much Notice Does Each Class Need?

Notice should be measured in calendar time and stated against the production milestone rather than the date. Class two needs notice before cutting. Class three needs notice before sampling, because the change has to be qualified. Class four needs notice before booking, because it may carry a testing or a registration consequence.

Stating notice against the milestone rather than the date is what makes the rule survive a schedule change. A rule that says ten days before production is ambiguous when production moves; a rule that says before cutting is not ambiguous at all.

Notice also has to be reciprocal. The buyer needs to know how long the production side has to respond to a proposed change, and the production side needs to know how long the buyer has to answer. Two numbers, written down, turn a waiting period into a schedule, and they remove the most common source of resentment in a long programme.

Where a programme runs several styles on one calendar, agree a batching rule: changes for the next booking are collected and proposed together rather than one at a time. A single monthly change page is read; eight separate messages in the same month are not, and the unread ones become silent changes by default.

What Evidence Must Accompany a Change?

A change proposal carries five things: what is changing, why, what it changes to, what was compared and by what method, and which of the four outcomes is proposed. Those five fields are the same for every class; only the depth of the comparison changes.

Attach the physical comparison wherever one exists. A retained offcut, a slider, a printed panel: one envelope per change, dated, filed with the log. A proposal with a physical sample attached is decided in a day; a proposal described in words is discussed for a week.

How Does a Change Reach the Spec File?

Through a revision, and only through a revision. The change is agreed, the file moves to the next revision, the field is edited, the revision log records the change and its date, and the purchase order cites the new revision from that point forward. Four steps, and skipping any of them reintroduces the ambiguity the whole system exists to remove.

The step most often skipped is the last one. The file is updated, the cartons are made, and the purchase order still cites the old revision, so six months later nobody can say which version the run followed. Citing the revision on the order is the least costly control in the whole system, and it costs one line on the order.

What Happens to Units Already Made?

A change takes effect on a date, and units made before that date remain inside the old revision. That is the answer, and it needs to be stated, because treating the change as retrospective makes the record unusable for exactly the comparison the record was created to support.

Where a change has to be applied to units already made, that is rework, and it is recorded as rework with its own instruction, its own check and its own sign-off. Blending a rework into a revision log is how a programme loses the ability to say which units were touched.

How Is an Emergency Change Handled?

By naming, in advance, who may decide and what the minimum evidence is. An emergency change is one that would otherwise stop the line, and the rule is that the decision is made by a named person, recorded the same day, and backed by the full evidence as soon as it can be produced - not waived entirely.

The second rule is that an emergency change is reviewed after the run, on the same log, with a note on whether it should have been foreseen. A programme that has three emergency changes in a year does not have bad luck; it has a component register that does not track discontinuation risk.

How Is a Change Communicated to the Buyer?

As one page, before the affected units are made, with the five fields and the physical comparison attached, and with a requested decision rather than an open question. Ask for one of the four outcomes by name; a message that says please advise invites a conversation instead of a decision.

Where the buyer does not respond within the stated period, say what happens. Silence is the most common failure mode in change control, and a rule that says the run pauses after the notice period, or proceeds under a written exception, removes the ambiguity without requiring anyone to be difficult.

What Does a Process Audit of a Reorder Programme Ask?

A process audit of a reorder programme, not a facility audit. It asks four questions: is the component register complete and current; does every change on the log carry the five fields; does the revision cited on each order match the revision in force at the time; and do the retained references still match the registered product.

That audit is a process review of one programme. It is not a facility audit, not a social-compliance review and not a capability study, and it should not be presented as one. Its scope is deliberately narrow: whether the documents that make a reorder predictable exist, are current, and were followed on the runs that shipped.

The audit should end with one written conclusion per question and a date for the next one. Four questions, four answers, one page. A programme that can produce that page on request is a programme that will survive a staff change on either side, which is the practical definition of being under control rather than merely being remembered.

Where an audit finds a silent change, treat it as a non-conformance and record the correction and the root cause on the same log. Programmes that record silent changes honestly find fewer of them next year, because the log starts showing which register lines are loose enough to be substituted without anyone deciding to.

Frequently Asked Questions

People Also Ask