Assessing Product and Process Changes

Record the existing and proposed configuration, the reason for change and affected models or lots. Include material, geometry, component, process, location and software changes. Avoid descriptions such as “equivalent replacement” unless the basis of equivalence is documented. A small physical change can alter a safety function or invalidate an assumption in earlier evidence.

Review the requirement register and identify which provisions depend on the changed characteristic. Include regulations, adopted standards, certification conditions and contract requirements. A change may affect more than the immediately visible function. For example, a control firmware revision can influence radio behavior, energy performance or protective functions depending on the product.

Identify the tests, analyses, approvals and supplier records that supported the previous configuration. Determine which remain applicable and why. Do not assume that an unchanged model number preserves every report’s relevance. Where testing is proposed, define the technical question and acceptance criterion first so the result can support an explicit decision.

Some changes can trigger notification, amended certification, additional testing or a new regulatory submission. The applicable program determines the action. Consult the relevant authority or certification organization where needed. An internal engineering approval does not automatically amend an external authorization, and a customer’s agreement does not waive a mandatory requirement.

Define the effective configuration, first affected lot or software release, inventory treatment and document updates. Coordinate drawings, purchasing data, instructions and labels. Retain the ability to distinguish products made before and after the change. Without this boundary, a later complaint or test result may be difficult to connect to the responsible configuration.

Record the completed verification, outstanding conditions and release authority. Monitor relevant production or field information after implementation when the risk warrants it. Use the Change Impact Review and Source and Version Register. A closed change record should explain the acceptance basis, not merely show that a workflow was completed.