Overview
ProDex Planning is an Advanced Planning optimizer. Give it demand, on-hand inventory, BOMs, and per-interval resource capacity, and it computes the production plan that best fits — over a horizon you configure (days, weeks, months, whatever your operation runs on). It balances two competing objectives: hitting demand on time (lateness loss) and hitting inventory targets (inventory loss), weighted by a single knob you set. Resource capacity is treated differently: it is a hard constraint, never traded off. If the plan doesn’t fit inside the capacity you give it, the run reports infeasible rather than “close enough” — and tells you which constraint pinched. That is deliberate. A plan that quietly over-commits a bottleneck is worse than a plan that refuses to lie.Planning Model vs. Planning Run
Two concepts do most of the work:- A planning model is the reusable setup: horizon length and interval size, the resources production consumes, the BOMs the optimizer is allowed to see, the order and inventory tags it will honor, and the objective weights. You author it once and reuse it across many plans.
- A planning run is one execution of the optimizer against that model, with a specific start date and its own inputs attached — the demand book, arriving raws, today’s shelf stock, inventory targets, and per-interval capacity. Every run is persistent and re-openable, so you can always look back at what a plan produced and why.
What a Run Takes In
Every run carries five categories of input, covered in Demand and Supply:What a Run Gives Back
A completed run returns a production plan (what to produce, in what quantity, in which interval, using which recipe), a boolean fulfillment flag on every demand order, and solver KPIs — status, objective value, optimality gap, elapsed time — that tell you how much to trust the answer. Planning Runs covers validation and execution; Planning Results covers reading the output.Planning, Simulation, and Scheduling
Planning decides interval-level production quantities. Simulation pressure-tests whether those quantities can actually be executed on the floor under real timing, shift patterns, downtime, and variability. Planning gives you the number to commit to; simulation tells you whether the floor can hit it. Between the two sits job-level scheduling — assigning specific jobs to specific machines in a sequenced, changeover-aware timeline. That capability is on the roadmap and not in the product today; see Job Scheduling for the current status and the practical workflow in the meantime.How You Drive Planning
You author models and runs in the planning UI or by asking Dexter. In chat, the pattern is direct: “Build a weekly model with these resources and these BOMs,” or “Create a run starting next Monday, load demand from the June order book, use yesterday’s on-hand from the ERP export, cap the packaging line at 80 hours per week.”Dexter can pull demand, supply, and on-hand inventory from files you upload or from connected data sources, wiring each input back to its source so the plan stays auditable — and he hands the run back for review before anything goes to the solver.