Change control needs an impact map before an approval route

An approval chain cannot repair a missing impact assessment

Engineering replaces a balance with a newer model of the same capacity. The purchase and installation approvals are complete. Production later discovers that the interface uses a different unit format, the standard operating procedure shows the old controls and the calibration record has not been linked to the new asset.

The problem is broader than a missing signature. The change was assessed as an equipment purchase while the operating workflow depended on equipment, software, instructions and people. Adding more approvers to the form would help only if they were asked the right impact questions.

Change control in pharma should start with a clear boundary and dependency map. The map identifies what requires assessment, who has the expertise to assess it and which evidence must exist before the changed operation is used. Approval routing follows that understanding.

EU GMP Annex 15 calls for assessment of planned changes across relevant quality, validation, documentation and regulatory effects. Its application depends on the site's context; the proposed mapping method below helps organise the assessment rather than supplying a universal approval checklist. EU GMP Annex 15, change control.

Describe the current and proposed states

Write what exists now, what will exist afterwards and why the change is proposed. Include the physical and functional scope. “Replace balance” is insufficient if the balance also sends data to a dispensing application and prints labels used in a later reconciliation.

Identify the affected product families, sites, equipment, interfaces and records. Record the versions or configurations that define the current state. This gives reviewers something concrete to compare and prevents the scope expanding informally during implementation.

Where information is uncertain, create an assessment action rather than selecting “no impact”. A negative conclusion should have a reason and an accountable reviewer. It is legitimate for a specialist to determine that a dependency is unaffected; it is different to leave the question unanswered.

Map dependencies by the decision they affect

The aim is a usable map, not a diagram containing every system in the company. Start with the changed item and ask what consumes its output, controls its use or supplies evidence about its readiness. Follow the dependencies far enough to identify meaningful operating and quality consequences.

Keep related changes linked. A supplier-site change may require a different assessment from an equipment replacement, but both can affect the same product. The supplier-site change-control guide covers that distinct trigger.

Worked example of a balance replacement

Consider an illustrative dispensing balance that sends weight values to an application. The old interface sends grams as a numeric value with a separate unit field. The replacement can send kilograms. A reading of 1.250 kilograms represents 1,250 grams; interpreting the number 1.250 as grams would create a thousandfold error.

The change record should identify this risk before installation. The integration owner defines the data mapping and rejected-input behaviour. The relevant technical and quality specialists determine the qualification and verification evidence for the intended weighing use. Document owners update affected instructions, and training owners identify the roles that need preparation.

The test set includes the expected unit, the alternative unit, an unstable reading where the interface exposes that state, an unavailable device and a duplicate message. Expected behaviour should come from the approved requirements. A successful connection and one plausible weight do not establish correct operation across those cases.

Now suppose the label printer still displays the old balance identifier. The measurement may be correct, but the downstream record can misidentify the source asset. The impact map should include the printed record and its use in reconciliation, so this issue is resolved before the changed workflow is released.

The final readiness decision brings together the required evidence. It does not rely on the equipment purchase order being closed or the installation technician marking the device operational. Each of those is a milestone within the wider change.

Sequence approvals and implementation deliberately

Separate assessment, authorisation to proceed, execution, verification and closure. Some activities can occur in parallel; others depend on an earlier approved result. Make the dependency explicit so a date-driven project plan cannot accidentally start operational use before the required evidence is accepted.

For example, a procedure can be drafted during configuration work, but its effective version and training dependencies should align with the actual go-live configuration. Training users on an obsolete interface and counting attendance as readiness creates a mismatch the change record should expose.

The computer-system validation guide explains how intended use and risk inform system evidence. The SOP training workflow addresses the relationship between document versions and people who need to use them.

Plan rollback and transitional operation

Ask what happens if installation or verification fails. Can the previous configuration be restored, and what evidence is required before it is used again? Is there an approved alternative process, and can it preserve records and control the relevant risks? These questions should be answered before a production window depends on the change.

Data changes complicate rollback. Restoring old software may not reverse records already created in a new format. Identify the migration or reconciliation steps required and preserve a reliable record of what happened during the transition. A backup file alone is not a complete recovery plan.

Temporary changes also need defined scope and duration. Record the condition for ending the temporary arrangement and the owner who verifies restoration or transition to a permanent solution. Repeated extensions should prompt reassessment of whether the original justification still applies.

Verify the intended result and unintended effects

Implementation evidence should show what was installed or changed, which checks were performed and which deviations remain unresolved. Compare the actual configuration with the approved scope. If implementation introduced a material difference, assess it before treating the original approval as sufficient.

Post-implementation review asks whether the objective was achieved and whether new problems appeared. For the balance example, this could include representative transaction reconciliation and review of interface exceptions under an approved plan. The exact evidence depends on the intended use and risk.

Do not close dependent tasks by implication. An interface test does not close calibration readiness; an effective procedure does not establish that every required role completed its preparation. The change view should expose each remaining condition and the authority responsible for accepting it.

Make the workflow proportionate and maintainable

Use a common set of impact questions with conditional branches for relevant areas. Requiring every department to approve every minor change can create superficial review and delay. Conversely, a narrow form that never asks about interfaces or regulatory effects can miss important dependencies.

Review completed changes for omissions and recurring late discoveries. Use that evidence to improve the assessment questions. The aim is better early identification, not a larger form for its own sake.

A practical implementation with NextEdge Labs can connect asset, document, training and system records around one change type. The acceptance test should demonstrate that a missing dependency blocks the appropriate readiness decision and that an unaffected conclusion remains traceable to its assessment.

Summary and next actions

Change control works when the organisation understands the affected operating system before approving a route through it. Clear scope, expert assessment and verified readiness make approvals meaningful.

• Choose a recent equipment or system change and map its actual downstream dependencies.
• Replace unexplained “no impact” responses with accountable assessments and supporting reasons.
• Sequence implementation, document effectiveness, training and verification around the intended use date.
• Test a failed implementation and a missed dependency before adopting the workflow more broadly.