Module

Production Planner

Which plant makes what, against capacity somebody actually stated.

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

What it produces

  • Demand placed across the plants that can make it, week by week
  • The objective, the capacity basis and the tie-break that decided every row
  • What could not be placed, and at which plant the capacity ran out
  • Plants skipped because the run would be under their minimum lot
  • Material-weeks that could not be planned at all, named with what is missing

A worked example

RM-4410 — week of 14 Sep — 1,050 demanded, 50 short
PL-01 takes 1,000 at ₹90/unit — cheapest capable plant, 1,000 units free
PL-02 skipped — 50 offered against a 500 minimum lot
→ 50 units have nowhere to go this week
3 material-weeks could not be planned — listed, not hidden

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

Why it is hard

The part that is not a report.

Allocating work across plants is arithmetic right up until somebody's capacity figure turns out to be aspirational. A beautiful schedule built on capacity nobody stated is why production plans are ignored on the shop floor — the people doing the work know the number is wrong, so they treat the whole plan as decoration. Capacity here is a figure a person entered and can be held to, and every allocation is shown with the constraint that bound it, which is the difference between a plan and a proposal.

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

Said before you ask

What is not finished.

The engine is built and tested — 31 tests and 19 mutants, all killed — and it fills the cheapest capable plant first, nets off the work already scheduled into each week, drops a plant offered less than it will run, and reconciles the shares exactly against the demand it started from. Two limitations are worth stating rather than discovering. It needs two tables most ERPs do not export on their own: plant capacity and material routings. Both have import templates, and until they carry rows every material reports NO_ROUTING by name rather than planning against a capacity nobody stated. And the finest grain it can plan at is a week — a production order here records a planned start and a planned end and nothing else, no work centre, no operation, no duration, no sequence, so nothing on file can order two jobs within a day and a daily schedule would be inventing the precision. Where two materials want the same machine it applies a priority rule rather than finding an optimum: the larger demand is placed first, the screen counts how often that happened, and the output is never described as optimal.

Where this sits

One of 16 modules, on one engine.

Production Planner 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.