A component goes on allocation. Lead time on a part that shipped in eight weeks last quarter is now quoted at fifty-two. Somebody forwards the distributor notice, somebody else asks how bad it is, and within a day the company is negotiating a spot buy at a price nobody would have approved a month earlier.
It feels like a market event that happened to you. It almost never is. The demand curve was in your own forecast. The lead time was published. The arithmetic that predicted the gap had been sitting in public view for months. Nobody had been assigned to do it.
Why This Happens
In most hardware companies, component risk lives entirely inside procurement, and procurement is measured on cost and on-time delivery for the parts it has already been asked to buy. That's a fundamentally reactive posture. It answers "can we get what's on this PO," not "what breaks eighteen months from now if this part's lead time doubles."
Meanwhile, the information required to answer the second question is scattered across the organization. The BOMs live with engineering. The volume forecast lives with sales. The on-hand and in-transit inventory lives with the contract manufacturer. The lead-time data lives on the distributor's website. No single one of those groups can see the shortage coming, because the shortage only appears when you put all four together.
So the risk surfaces one product at a time, as each individual program hits its own wall. Each hit gets handled as its own emergency. Nobody adds them up. It's common for a company to make a substantial spot buy covering one product's gap without anyone in the room being able to name the other products in the line that run on the same part number.
That's the real failure. Not the shortage, but the inability to answer a basic question about your own product line. If you can't name every product that uses a given part number, and the annual volume of each, in under a minute, you don't have a supply chain posture. You have a series of reactions.
What the Fix Actually Looks Like
Step One — A Cross-Product Component Index
Roll every BOM in the active product line into one queryable table: part number, function, products consuming it, annual volume per product, source count, package, and qualification status. This is unglamorous work and it is the foundation for everything else. Without it, every subsequent question takes a week of email.
Then classify. The parts that matter are the ones that are single-sourced, long-lead, or approaching end of life, and the overlap of those three is your actual risk register. Most of a BOM is passives and connectors you will never think about. A typical telematics product line has maybe six to ten parts that can genuinely stop production, and they are usually the MCU, the GNSS receiver, the cellular module, and the power management devices.
Step Two — Burn It Down Against Published Lead Times
For each critical part, model the same three lines out over eight quarters: forecast demand, on-hand plus committed supply, and the lead time required to replenish. Where the supply line crosses demand is your cliff date. Subtract the lead time and you get the date the decision had to be made, which, in a fifty-two-week environment, is frequently in the past.
Express the output in units, not in adjectives. "We're tight on MCUs" starts a conversation that goes nowhere. "We are short three hundred thousand units by Q3 of next year, and the order to prevent that had to be placed last month" starts a different conversation. The number is what converts a supply chain problem into a leadership decision.
None of the inputs are exotic. Distributor lead times are public. Your forecast already exists. This is a spreadsheet with discipline behind it, not a system that needs to be purchased.
Step Three — Make the Spot Buy Buy Time for Engineering
Spot buys are a legitimate tool. They are a bridge. The failure mode is treating the bridge as the destination: you cover the gap, the burndown chart looks healthy again, and the organization returns to roadmap work having changed nothing structural. Twelve months later you're back at the same table, paying more, with less inventory in the channel.
A spot buy should be authorized alongside the engineering action it is funding: a second source qualified, a pin-compatible alternate designed in, a board spin scheduled, a part rationalized across products so you're buying one MCU family instead of four. The purchase order and the engineering ticket should be approved in the same meeting. If the spot buy happens and the engineering work doesn't, you didn't solve anything. You rented a delay.
That trade is genuinely expensive. Board spins consume the same engineering capacity the roadmap is counting on, and somebody has to decide which features slip. That decision belongs to leadership, made explicitly and in advance, rather than reconstructed later when a program misses for reasons nobody can quite name.
The Real Point
Supply chain risk gets treated as a procurement function because it involves buying things. But the decisions that determine whether a shortage becomes existential are not procurement decisions. Which parts go into which products, how many sources each one carries, when to spin a board, what to build ahead of demand: these are architecture and portfolio choices. They span every product in the line and they play out over years.
That's program management. And the companies that own it programmatically don't experience allocation the way the others do. The fifty-two-week notice lands as a line item they modeled four quarters ago, not as an emergency. The difference between those two companies isn't luck, and it isn't the size of the procurement team. It's whether somebody was doing the arithmetic before the market forced them to.