Module

Shortage Radar

What you run out of, on what date, and the one action that still lands in time.

Beta — live for pilot tenants₹25,000 / month
See pricing

What it produces

  • Every material projected to go short inside ninety days, soonest first
  • The date, the shortfall at its worst point, and the balance day by day
  • One action per material — expedite, order, transfer, or move the date
  • Materials that could not be projected, named with what is missing

A worked example

RM-4410 — short from 14 Sep, 3,180 KG
820 on hand, 4,000 committed and 0 inbound over 90 days
lead time 34 days against 21 available
→ order today and call the customer: it lands 13 days after the promise
9 materials could not be projected at all — listed, not hidden

Illustrative figures. On your tenant the same page shows yours.

Why it is hard

The part that is not a report.

Knowing you will run out is not the useful part. The useful part is knowing on what date, and whether an action still exists that lands before it — expedite, substitute, split the order, or tell the customer now rather than in three weeks. That depends on real supplier lead times rather than the ones in the material master, which are usually whatever was typed at go-live and never revisited. A prediction with no action attached is an alarm, and alarms are switched off by the people they wake.

Opened by the planner, the supply chain manager and the procurement lead — what each of them sees first.

Said before you ask

What is not finished.

BETA rather than AVAILABLE: the engine runs against live tenant data — stock, committed sales orders and confirmed purchase orders are all imported already — and no customer has yet run it against their own. Two honest limitations. Cross-plant surplus is not computed, so TRANSFER_FROM_PLANT never fires and the engine falls through to ordering, which is correct but less clever. And Material.leadTimeDays defaults to zero in the schema, so a material nobody has filled in is treated as having no lead time rather than an instant one — which costs a specific action on genuinely same-day materials, and is the right way round: the opposite error recommends ordering today on every material nobody has configured.

Where this sits

One of 16 modules, on one engine.

Shortage Radar reads the same reconciled data as everything else SIAARU runs — connected read-only to your ERP, scored on the way in, measured in SQL. How that engine works is a page of its own. The other 15 modules, each with the state it is really in and the reason where it is not switched on, are on the module list; what this one costs, and what it costs beside the rest, is on the pricing page.

Get started

Bring one month of data. Leave with your own control tower.

A demo runs on your material master, your purchase orders and your stock — not on ours. Thirty minutes, and you see your own exceptions rather than a scripted one.

Ask a question

Book a demo

Thirty minutes, on your own data. Six fields — the rest only helps us prepare.

Not binding. Tell us the size and we will say which one fits.

The demo connects to it, so this shapes the whole session.

Add context, and the demo runs on your problem rather than a scripted one

We reply within one working day.