Obsolescence Management System
Will the stock outlast the exposure?
Obsolescence management across the asset lifecycle for physical items and for software, firmware, operating systems, licences and support agreements. The application governs manufacturer notices, cases, criticality and deterministic risk, equivalence, inventory exposure and lifetime-buy decisions, aligned with IEC 62402.
- 0
- Canonical lifecycle states
- 0
- Report families
- 0
- Governed datasets
- 0
- Business domains
Eight states between working and unsupportable.
Obsolescence is not binary. An item may progress through several lifecycle conditions before discontinuation, so the lifecycle position is maintained as a governed state supported by verified evidence rather than as an informal status field.
Active. In production and fully supported. The baseline against which every later state is a deterioration.
Status is a conclusion drawn from verified evidence.
Lifecycle status is derived from verified evidence. Superseded events cease to govern; verified events take effect from their effective date; the most severe in-force state determines the current position; and where no qualifying evidence exists, the status is reported as unknown rather than assumed active.
Ingested evidence waits until somebody checks it.
Newly recorded and imported events arrive in a queue and do not move any status until they are checked against their source.
- Only a verified event can move a status
- A superseded event stops counting from the moment it is superseded
- No qualifying event resolves to unknown rather than to a null
Nineteen report families, each written for somebody specific.
Executive and management; programme; risk and criticality; lifecycle intelligence; equivalence; installed base; inventory and planning; supplier intelligence; software and firmware; and programme-performance reports. Each states its intended audience, reporting basis and available output formats.
A report is configured for scope and period, previewed, then generated as a numbered revision that can be issued.
- Where used, answeredA component is traced through bills of material to the installations that depend on it, so exposure is a count rather than an impression.
- Physical and software togetherAn unsupported controller and an unsupported operating system carry the same lifecycle model, because they fail the same audit.
- Aligned to IEC 62402The programme follows the obsolescence-management standard’s structure. Alignment is stated as alignment, never as certification.
Risk is derived, not scored in a workshop.
Criticality says what the loss would mean. Lifecycle position says how likely the loss is to arrive. Risk is the deterministic combination of the two, so it changes when a manufacturer notice arrives rather than when the next review meeting happens.
A programme, an installed base and a decision at the end of it.
The application's own navigation, from notices and cases through assets, assessments and inventory to the evidence beneath them. Every chip is a page.
The obsolescence programme
Manufacturer product-change and discontinuation notices with their intake, obsolescence cases moving through workflow states, and the lifecycle position each item actually holds.
- Cases
- Notices
- Notice Intake
- Lifecycle
- OEM Monitoring
Assets and installed base
The hierarchy, equipment and tags that say what is actually installed, with items, product families, bills of material, installations and a where-used view that answers what depends on what.
- Hierarchy
- Equipment
- Tags
- Items
- Product Families
- BOMs
- Installations
- Where Used
Assessments
Equivalence for alternatives, criticality for what the loss would mean, and deterministic risk derived from the two rather than scored by judgement at the time.
- Equivalence
- Criticality
- Risk
Inventory and forecasts
Stock held, demand against it, depletion forecasts and the lifetime-buy decision; the point at which the programme becomes a purchase order with a number on it.
- Inventory
- Demand
- Forecasts
- Lifetime Buy
- Exposure
Software and firmware
Operating systems, firmware, licences and support agreements carried in the same obsolescence model as physical items, because an unsupported controller and an unsupported operating system fail the same audit.
- Software & Firmware
- Integrations
- Integration Health
Evidence and governance
Documents, transmittals and technical records, with governance, configuration, reference data, metadata, data management and data quality beneath the programme.
- Documents
- Transmittals
- Technical Records
- Governance
- Reference Data
- Data Quality
Screen the bill of material, or manage what is already installed.
Project mode screens an engineering bill of material before handover, so obsolescence is found while it is still a design decision. Operations mode manages the installed base, where it is a stock and equivalence decision instead. Same model, different question.
- Project mode for engineering, procurement and package engineers
- Operations mode for reliability, maintenance and materials
- Field lookup for checking an item where it is installed
Four rules that decide every lifecycle state.
An obsolescence programme is trusted or ignored on the strength of these. They are stated in the application itself rather than buried in a methodology document.
Only verified events count
Ingested evidence does not move a status until somebody checks it against its source. Unverified and rejected events are excluded from the decision entirely.
Correction, not erasure
A superseded event stops counting; a correction replaces it without erasing it. The event that caused a status change is always open to read.
The most severe in-force state governs
Where several events are in force, the most severe wins and ties go to the latest effective date, then to the latest verification. The rule is stated, not implied.
Unknown is a real answer
Where no qualifying event exists the state is unknown; not a null, and never quietly treated as active.
More of what the application covers.
- Project mode for screening a bill of materials before handover
- Operations mode for the installed base
- Where-used across installations and bills of material
- Equivalence assessment for qualified alternatives
- Depletion forecasts against recorded demand
- Supplier and manufacturer intelligence
- Field lookup for checking an item where it is installed
- Documents, transmittals and technical records as evidence
Supportability, beside the systems that hold and buy the parts.
- SPIRSPIR: Spare Parts Interchangeability Record Management SystemSpares interchangeability and vendor records; OMS decides whether the spare will still exist.
- EAMSEAMS: Enterprise Asset Management SystemMaintenance execution and stock; OMS governs the supportability of what is being maintained.
- AIRMSAIRMS: Asset Integrity & Reliability Management SystemIntegrity of the equipment whose supportability OMS assesses.
- PMSPMS: Procurement Management SystemProcurement, where a lifetime-buy decision becomes an order.
See OMS with one of your installed bills of material.
Bring one bill of material and its manufacturer notices. We will show the lifecycle states it resolves to, the criticality behind them and whether the stock outlasts the exposure.