Production planning in Excel — why the master sheet always breaks

The real competitor is a spreadsheet

Ask a mid-sized Indian manufacturer how they plan production and the honest answer is usually the same: one planner, one enormous Excel workbook, and a great deal of care. That sheet is not a joke — it encodes years of hard-won knowledge, and it works well enough to keep the plant running. The problem is not that Excel is bad; it is that a spreadsheet has no model of a BOM, of stock, or of capacity, so past a certain complexity the master sheet always breaks in the same handful of ways. Naming those failure modes is more useful than any feature list. For the model a real system uses instead, see the production planning pillar.

It can’t explode a multi-level BOM

A finished good is a tree — assemblies of sub-assemblies of components of raw material. To plan it, you must multiply demand down every level of that tree. Excel has no concept of a BOM, so the planner flattens the structure by hand: a lookup here, a helper column there, a manual multiply for each level. It works for a shallow product and a handful of finished goods. Add a level, or a shared component that appears in five assemblies, and the manual explosion becomes error-prone and slow. A missed level means missed material; a wrong multiply means either a shortage or waste. Multi-level explosion is exactly what an MRP engine does automatically — see what is MRP.

It nets against stale stock

Netting only works if the stock figure is current. In a spreadsheet, stock is a column pasted from an export taken at some point — this morning, yesterday, last Friday. The moment the export is taken it starts ageing, and the plan nets against a number that no longer matches the store. The planner ends up ordering material that has since arrived, or missing a draw-down that already happened. A planning system nets against live stock and the open purchase orders and work orders in the same database, so the netting reflects the store as it is now, not as it was when someone last exported it.

It has no reservation, so plans collide

This is the failure that hurts most and is hardest to see. A spreadsheet nets Plan A against, say, 250 gears in stock. Next week the same planner (or another) nets Plan B against the same 250 gears — because nothing in the sheet knows that Plan A already committed them. Two plans spend the same inventory, and the collision only surfaces on the floor when the second job comes up short. Stock reservation — committing inventory to a specific plan so the next run treats it as gone — is structurally impossible in a flat spreadsheet and native to a planning system.

• Excel has no memory of what a previous plan committed, so inventory is silently double-counted.
• A planning system reserves stock per plan and reports exactly what is committed to which plan.
• Open work orders and open POs are netted automatically, not remembered by a person.
• The result is fewer phantom-availability shortages that appear only at the machine.

It depends on one person

The master sheet is usually understood by exactly one person. Its formulas, its helper tabs, its unwritten rules — all live in a single planner’s head. When that planner is on leave, the plant plans nervously; when they leave the company, a chunk of institutional knowledge walks out with them. A system encodes the planning logic in software that anyone with the right role can run, so the plan does not hinge on one person’s presence or memory.

It can’t load finite capacity

Even a perfect spreadsheet plan says nothing about whether the machines can do the work. Excel has no model of a machine, its available hours, or the operations routed to it, so capacity is checked — if at all — by a supervisor’s judgement. That is how a plan that looks fine on paper misses a due date: the bottleneck machine was overloaded and nothing flagged it. Finite machine loading and Gantt scheduling are simply outside what a spreadsheet can do — see planning versus scheduling.

Excel versus a planning system

When Excel is still fine — and when to move

Honesty helps here. If you make a handful of shallow-BOM products, hold little stock, and run one plan at a time, a spreadsheet may genuinely be enough — and a system would be over-engineering. The signals that the master sheet has outgrown itself are concrete: multi-level or shared-component BOMs that take real effort to explode by hand; recurring shortages that trace back to stale stock or two plans spending the same inventory; a bottleneck machine that keeps surprising you; and a plan only one person can run. When two or three of those are true, the spreadsheet has stopped saving time and started hiding risk.

Moving from the master sheet to Fast Planning

Fast Planning Software, built by Improsys in Pune under the Fast Technology brand, replaces the master sheet with the mechanisms it structurally lacks: automatic multi-level BOM explosion and netting against live stock, stock reservation so plans never collide, purchase requisitions from netted demand, finite machine loading with Gantt scheduling, and barcode-booked plan-vs-actual — all on one shared platform with production, inventory and purchase. It runs on-premise for a single-plant MSME or in the cloud, with indicative INR pricing (confirm current tiers with the team). The migration usually starts where the sheet is weakest — disciplined BOM and live stock — because that is the foundation MRP needs. To weigh it against a wider suite, read MRP vs ERP; for the payoff, the benefits.

Frequently asked questions