Whether Before When / Applicability Before Effectivity
The Change Implementation Board has been running for two hours. Half the room is debating whether the proposed change affects Variant B at all. The other half is pushing for a specific serial number break-in point before the Q3 production ramp. Neither group is wrong to raise their concern. But both conversations cannot happen productively at the same time, and forcing them into a single meeting is precisely why neither gets resolved.
This is not a facilitation problem. It is a conceptual problem. Two structurally distinct questions have been collapsed into a single agenda item, and the meeting cannot move forward until someone recognizes they must be answered in sequence. The people debating scope are asking one question: does this item belong in this configuration? The people debating timing are asking a different question: from which serial number, date, or lot is the new part cut into production? These questions have names. They are applicability and effectivity. And more importantly, they have an order.
Two Concepts, One Persistent Confusion
EIA-649C, standard for configuration management practice, defines effectivity as: “A designation, defining the product range; e.g., serial numbers, block numbers, batch numbers, lot numbers, model, dates or event, at which a specific product configuration applies, a change is to be or has been affected, or to which a variance applies.” The definition does two different things. “Defining the product range… at which a specific product configuration applies” is scope language: it specifies which products, which variants, which configurations the designation covers. “At which a change is to be or has been affected” is timing language: it covers when the change takes effect. Both concepts are present in a single term. The confusion begins when practitioners carry this into multi-variant environments, where the scope question and the timing question have different inputs, different owners, and, most importantly, require answers at different points in the change process.
Applicability describes which configurations a part, document, or specification belongs to. It is a structural property of an item in a product family: relatively stable, established during design, and typically managed in the product structure layer of a PLM system. Effectivity describes when an approved change takes physical effect in production. It is a temporal property tied to a specific change notice, set during the CIB review, and executed in ERP. Different properties, different owners, different governance steps, and critically, different points in the change process at which each must be confirmed. Separating them clarifies sequence.
What Applicability Actually Does
The clearest way to understand applicability is through the 150% BOM. The 150% BOM is a superset structure containing every possible option, variant, and configuration across an entire product family. No single unit is ever built to the full 150% BOM. Applicability is the set of rules that filters that superset into a specific, buildable production BOM for a given configuration or customer order. Model B with Option Pack 3 gets these items. Model A with the standard configuration gets those items. The filtering logic is encoded in the product structure, determined during design, and remains unchanged until the product family architecture itself changes.
Applicability also functions as the essential input for conducting a detailed impact assessment. Before the full scope of a change can be assessed, you need to know which products you are assessing it against. A change that appears minor against one variant may have significant implications across the full product family. The applicability scope defined at the start is not a conclusion; it is the precondition for reaching one.
What Effectivity Actually Does
Effectivity is the physical incorporation point. EIA-649C defines it as “a designation, defining the product range at which a specific product configuration applies.” MIL-HDBK-61B §5.2 requires organizations to maintain effectivity and incorporation status for every approved change as a configuration status accounting record requirement, making it an auditable commitment, not just a planning note.
Applicability has both a structural and a change-specific dimension. Its structural layer, covering which parts and documents belong to which configurations and variants, is relatively stable. But for every proposed change, its applicability must also be evaluated: to which products should it apply? All variants, or only a defined subset? That determination directly defines the scope of the impact assessment. Effectivity is different in kind. It only becomes relevant when an approved change requires a new part to be cut into production, and setting that cut-in point requires the production schedule, inventory position, interchangeability determination, and logistics of any field retrofit. These are manufacturing and supply chain inputs drawn from ERP and CIB negotiations, not from the product structure layer where applicability is established.
Effectivity also has a lifecycle within the change process. The desired effectivity on the change request is provided as a need towards the CIB as input for the implementation planning. The planned effectivity on the change notice is the commitment, as a result of the implementation plan. The actual effectivity recorded in ERP is what was physically executed.
The Prerequisite No One Writes Down
The most important structural property of the applicability-effectivity relationship is a sequencing dependency. Applicability is a prerequisite for effectivity. You cannot define when a part is cut into production if you have not first confirmed whether it belongs in that configuration at all. The two concepts must be answered in order. Most CM processes never make this explicit, which is why most CIBs conflate them.
The dependency is both logical and operational. Before you can evaluate the consequences of a change, you need to know which products you are assessing. An assessment run against the wrong scope produces a cost estimate, a risk profile, and an effectivity recommendation that are all structurally wrong. Effectivity can only be determined when the full impact is clear. Compressing both into a single act results in commitments made on incomplete evidence.
Take a concrete case: an improved thermal component is proposed for the high-end model only. The CIB sets a cut-in point at serial 1850 before formally closing the question of which models the change applies to. The intent was high-end only. That determination was never documented and confirmed.
Production starts. After serial 1850, because no validated applicability rule has been recorded, all units receive it. The configuration record shows the change as incorporated. This is a phantom configuration: the record is internally consistent, but it was built against a scope that was never confirmed. The result: margin erosion for low- and mid-end products. Or, even worse, the improved thermal component is heavier and requires a bracket that is currently available only on high-end products, resulting in higher failure rates on low- and mid-end products.
The organization invests in setting effectivity dates and break-in points. It fails to confirm applicability first. The result is a configuration record that is internally consistent but incorrect with respect to the physical product. No audit catches it because the audit verifies that effectivity was set, not that the scope it was set for was ever validated. CM2 prevents this through its closed-loop change process, which requires scope confirmation before effectivity commitment.
How the CCB Dysfunction Forms
Configuration management is fundamentally change control. In most organizations, a single board handles the full change decision. Whatever it is called (CCB, Change Control Board, or simply “the board”), it is typically asked to do both jobs in one session: review scope, confirm which products the change applies to, approve the change, and commit to a cut-in date. These are structurally different questions that require different inputs, different participants, and answers at different points in the process. A single board cannot answer both cleanly at the same time.
The organizational consequence is predictable. Engineering representatives cannot close the scope question while a cut-in date is being pushed. Manufacturing representatives cannot commit to a serial number break-in point against a scope that is still being debated. The board runs long, produces conditional decisions, and adjourns with open actions on both dimensions. The effectivity is eventually set, but it is set against a scope that was never formally confirmed. The phantom configuration waiting on the other side of that decision is invisible until something breaks. When it does, the cost lands in manufacturing, field service, and warranty. These are functions that were not in the room when the sequencing failure was made.
CM2 resolves this structurally. The Change Review Board handles scope and decision: it confirms applicability, and approves the change. The Change Implementation Board handles execution planning: it inherits the confirmed scope and plans the cut-in against production reality. Neither board is burdened with the other’s question. The CCB dysfunction is not a facilitation problem. It is a structural problem that requires a structural solution.
Separating the Questions in Practice
The applicability review begins with a direct question: which products are affected by this change? Every product whose structure, bill of materials, or documentation is touched belongs in the scope, and establishing that set is the starting point of the analysis, not its conclusion.
The harder question follows: should this change apply to all affected products, or only to a subset? When engineering limits applicability to a specific model or variant, that decision has structural consequences that cannot be left implicit. The affected parts must be managed through part re-identification or through variant management logic in the PLM system. Either approach is valid; the choice depends on the degree and expected duration of configuration divergence. What is not valid is leaving the subset undefined. An undefined applicability scope means the effectivity decision that follows will be set against an incomplete baseline.
CM2’s impact analysis framework enforces the applicability-first discipline through the Enterprise Change Assessment (ECA) phase. During impact assessment, the scope is resolved: which configurations, which variants, which baselines are affected, and to which of them the change actually applies? This happens before the Change Review Board convenes, and it produces a documented applicability baseline that the CIB inherits. By the time the CIB meets to plan implementation, scope is settled. The only question on the table is when. That sequence is not a convention but the direct reasoning behind separating assessment, decision, and implementation as distinct governance moments.
Interchangeability and traceability sit at the boundary between the two questions. Whether a change is interchangeable shapes what effectivity needs to track. A non-interchangeable change requires serial-number effectivity because units in the old and new configurations must be distinguishable and auditable. The applicability determination sets the conditions under which that question arises.
Two Questions. One Right Order.
The CIB meeting that runs for two hours without resolution is almost always a meeting where both questions are live at the same time. Separate them. Answer “whether” first: which products are affected, to which of them does the change apply, and is that scope formally documented and closed? Treat that as the precondition for the next conversation.
Then answer “when”: from which serial number, lot, or date is the new part cut into production? Record the desired effectivity on the change request. Revise it to planned effectivity on the change notice once scope and feasibility are confirmed. Record actual effectivity in ERP when the change is physically executed. Maintain it when production schedules change, because an effectivity set once and forgotten is how organizations accumulate configurations they cannot audit.
CM2, as developed by IpX, builds this discipline into its governance architecture through the ECA, CRB, and CIB separation. The ECA resolves scope and completes the impact assessment. The CRB approves the change and provides implementation guidance, e.g., a desired effectivity. The CIB confirms and locks the cut-in against physical and logistical reality. Each board answers a specific question in a specific sequence, and none of them can do their job cleanly if an earlier question was left open. Whether before when. In that order. With a named person accountable for each answer.
What does your organization’s change process look like today? Does it formally separate the applicability confirmation from the effectivity assignment, or do both land in the CIB meeting as open questions? The answer is worth examining before the next two-hour board meeting runs out of time without a decision.
Ready to go deeper?
Use code Martijn10 for 10% off training—and don’t forget to tell them Martijn sent you 😉.
Copyrights by the Institute for Process Excellence
This article was originally published on ipxhq.com & mdux.net.