The problem
Production planning in a spreadsheet starts clean. One tab for demand, one for work center capacity, one for open work orders. Then someone adds a column for changeover time. Someone else adds a tab for the night shift. Within a month the plan is a set of linked sheets that only two people understand.
The failure is not the math. It is the edit. Two planners open the file, change the same week, and save. One set of changes disappears. A formula gets dragged over a hidden row. A customer order is promised against capacity that a maintenance block already consumed. Nobody can say who moved the press load from week 12 to week 14.
A spreadsheet also hides the real constraint. Production planning is about matching demand to capacity at the bottleneck. In a sheet, the bottleneck is a column that someone has to remember to check. There is no validation that a work order fits the available hours, no link from an order to its routing, and no clean way to publish a frozen plan while the next one is being built. The team spends its time repairing the file instead of deciding what to build.
What a good solution looks like
A good production planning app is narrow. It holds one plan of record, not every manufacturing record. You need items, routings with operation times, work centers with calendars, open work orders with due dates and quantities, and demand from sales orders or forecasts. That is enough to load capacity by week and see the overload.
The app should separate draft planning from the published plan. Planners work in a draft, move orders, split quantities, and resequence operations. When the plan is ready, they publish a snapshot that the shop floor and sales can read. The snapshot does not change when someone edits next week's draft.
Every change should be a record with a user, a time, and a reason. Permissions should follow the job: planners edit, supervisors view their work centers, sales views promise dates, finance exports. The app should flag overloaded work centers in the week bucket, show the orders that cause the load, and let a planner move an order with a keyboard or a drag, not a cut and paste.
Exports matter. A CSV of the published plan, a feed to the shop floor display, and a view your BI tool can read keep the app from becoming another silo. Keep the app small. It is a planning tool, not an ERP.
How to build it
Start with the data model, not the screens. List the fields you actually use in the spreadsheet. For production planning that usually means item, routing, operation, work center, available hours per week, work order, due date, quantity, status, and the planner's note. Add a calendar table for holidays and maintenance blocks. If a field is not used to make a scheduling decision, leave it out of version one.
Load the current data once, then check it. Import the open work orders and the routing times. Compare the app's capacity load for the next four weeks to the spreadsheet's numbers. Differences are usually missing routings, wrong work center calendars, or orders with no due date. Fix those before you let anyone plan in the app.
Build the weekly capacity view first. Each row is a work center, each column is a week, each cell is load hours against available hours. Color the overload. Click a cell to see the work orders behind it. Then add the move action: select an order, pick a new week, and write a change record. Do not build an optimizer in week one. Planners need a clear picture and a fast edit more than an algorithm.
Add publishing and exports. A publish button freezes the plan for a week and writes a snapshot. Exports to CSV and to your finance or BI tool should use that snapshot. Sign in should go through your identity provider, with roles for planner, supervisor, and viewer. Keep an audit trail of every move. Test with one product family and one planner before you roll it out.
Risks and how to manage them
The biggest risk is scope. Production planning touches sales, purchasing, and the shop floor. Every conversation adds a feature: material availability, costing, quality holds. Write the scope in one sentence and put everything else on a list for later. If the app tries to be a full planning system, it will fail slowly and the spreadsheet will win.
The second risk is bad data. A routing time that is wrong by a shift will make the capacity view lie. Pick a small set of items and check the routing times against the last few runs. Ask supervisors to correct the work center calendars. Make missing due dates visible. Do not let the app hide data gaps behind a clean dashboard.
The third risk is adoption. Planners will keep a private spreadsheet if the app is slower for the moves they make every day. Watch them use it. If a move takes more than a few clicks, fix that path. Publish the plan where people already look, and stop updating the old file on a date you announce. Keep it read only for a month, then archive it.
Finally, decide what the app does not decide. It can show load and let a planner sequence orders. It should not promise dates to customers without a human check in the first months. Keep a manual approval step for any change that crosses a week boundary.
How to measure success
Measure the planning process, not the software. Time how long it takes to build next week's plan. Count how many versions of the plan exist at once. Count late releases caused by a capacity miss that the plan could have shown. Ask sales whether promise dates are easier to get.
Check the audit trail. Can you answer who moved a work order and why, without asking three people? Can a supervisor see their work center's load without a meeting? Can finance pull the published plan into a report without copying cells? Those answers are the real test.
Track the number of planners who still keep a private sheet. That number should go to zero. Also track the time to fix a data error, such as a wrong routing time. If a correction takes a week, the app is not trusted. Review these measures monthly for the first quarter, then quarterly. If the app is working, the spreadsheet becomes a read only archive and the planning conversation moves to the plan itself.
If you want a working tool this quarter, the Internal tool sprint from Cloudverg is a fixed price of $16,500 and takes four weeks. It covers one workflow end to end, with sign in, roles, change history and exports. An off the shelf planning module or a build by your own team are the other paths. Pick the one that matches the scope you wrote down.
Frequently asked questions
Can a small web app handle production planning?
Yes, if you keep the scope to one plan of record and the weekly capacity view. A small app can hold work orders, routing times, work center calendars and a published plan. It will not replace a full planning suite, but it can replace the shared spreadsheet.
What data should I import first?
Start with open work orders, item routings, work center calendars and due dates. Add sales orders or forecasts only if they drive the plan. Check the load numbers against the spreadsheet before anyone plans in the app.
Should the app reschedule orders automatically?
No, not in the first version. Planners need a clear capacity view and a fast manual move with an audit trail. Automatic sequencing can come later, after the data and the rules are trusted.