A slow-selling spare part appears on the cut list. The COO wants fewer products to manage; the CFO wants less cash tied up in stock. Before approving retirement, both need one answer: which customers still depend on this exact item?

SKU rationalization means deciding which stock-keeping units to retain, improve, or retire. AI can assist by organizing evidence for that decision. Low sales alone should trigger investigation: the item may support equipment customers still operate.

This is general implementation guidance, not a verified Jovis product workflow.

Set a customer-dependency gate

Select one product family and a proposed retirement date. Ask the commercial and product owners to establish four things:

  • Who depends on it? Link recent orders, installed equipment where recorded, open quotes, and service commitments to stable customer and item identifiers. A quiet ordering period does not prove demand has ended.
  • What can replace it? Require documented compatibility and any necessary customer acceptance. Similar descriptions or frequent purchases together do not establish interchangeability.
  • What remains promised? Review open orders, agreements, warranties, and approved exceptions. Have the appropriate contract owner resolve uncertain commitments.
  • What happens to remaining stock? Separate saleable inventory, service reserves, supplier commitments, and obsolete units. Name an owner for each disposition.

Oracle’s replenishment documentation distinguishes substitution from supersession and allows directional relationships. That is a useful warning: a replacement relationship need not work both ways. Product specialists must validate the actual application.

The inventory forecasting guide addresses how much to replenish. This review decides whether the item should remain available at all.

Example: retire in stages

Consider a hypothetical industrial distributor reviewing an old seal kit. Only three customers bought it this year. A newer kit looks equivalent in the catalog.

The review finds that one customer has approved the replacement, another needs an engineering check, and the third still operates equipment incompatible with it. The third customer also has an active service commitment.

A blanket stop would conceal three different decisions. Instead, leadership could approve migration for the first customer, assign a validation deadline for the second, and retain a defined service reserve for the third. Finance then compares the cost of that reserve with other feasible ways to meet the commitment.

The result is a conditional retirement plan with owners and dates. The contract-obligation tracking guide helps structure the evidence behind continuing promises.

Give AI an evidence task

An illustrative request:

Using these approved records, list customers dependent on this item. Show documented replacements, unresolved compatibility questions, open commitments, and missing evidence. Cite each source. Do not infer technical compatibility or change item status.

The expected output is one decision page: customer, dependency, replacement evidence, unresolved question, accountable owner, and earliest supported transition date. Keep unmatched identifiers visible for review.

Test whether the workflow catches an incompatible replacement and a commitment hidden in an amendment. Missing records should produce an explicit gap.

Approve separate milestones

Set distinct dates for stopping new sales, stopping replenishment, and ending support where applicable. Cisco’s end-of-life policy illustrates the distinction between end of sale and last support; its timelines are specific to Cisco.

The COO approves operational readiness, the commercial leader owns customer communication, and finance validates the economics. Keep item changes and external notices with authorized owners.

Start with one family whose records people can independently check. Plan a bounded AI pilot before applying the method across the catalog.