Prescriptive Optimization Recipe Collection

Concise, runnable recipes for common prescriptive analytics tasks (scheduling, routing, inventory, allocation). Each recipe offers problem framing, required inputs, minimal model or heuristic, evaluation checks, deployment notes, a quick test case, and a short checklist to move from prototype to reliable operation.

Prescriptive Optimization Recipe Collection

Short, practical recipes analysts and operational teams can adapt to turn forecasts and constraints into feasible, actionable recommendations. Each recipe is intentionally minimal — enough math and structure to run a first prototype, paired with pragmatic evaluation and deployment notes so solutions survive real-world operations.

How to use this toolbox

  • Pick a recipe that matches your operational problem (scheduling, routing, inventory, allocation).
  • Gather the required inputs and a small test dataset described in the recipe.
  • Implement the minimal model or heuristic (pseudocode + solver guidance included).
  • Run the evaluation checks and sensitivity tests suggested below.
  • Follow the deployment checklist and human-override patterns before releasing recommendations to users.

Standard recipe structure (applies to every entry)

  1. Problem framing — concise description of the decision to make, stakeholders, and acceptable action types.
  2. When to use — typical contexts and scale where the recipe fits.
  3. Data inputs — exact fields, formats, and reasonable validation checks.
  4. Minimal model or heuristic — objective, decision variables, constraints, and a runnable formulation (LP/MILP/heuristic pseudocode).
  5. Evaluation metrics — operational KPIs to measure improvement and regression tests.
  6. Common pitfalls — data, modeling and operational traps to watch for.
  7. Deployment notes — latency, integration points, human override patterns, monitoring and rollback criteria.
  8. Quick test case — small dataset and expected result to validate implementation.

Example recipes (concise templates)

1. Single-item Inventory Reorder with Service-Level (Reorder + Safety Stock)

When to use: periodic review for single SKU with stochastic demand and lead time.

Data inputs: daily demand history, lead time distribution, holding cost per unit, stockout cost or target service level.

Model / Heuristic: choose reorder point R = expected demand during lead time + z * sigma_{dlt} (z from desired service level). Order-up-to S = R + EOQ batch size or economic order quantity if fixed costs exist.

Evaluation metrics: fill rate, average on-hand, inventory turns, total cost.

Quick test case: synthetic demand with known mean/variance and lead time; verify service level roughly meets target.

Deployment notes: run daily, alert when suggested order differs from manager input; monitor realized service level and data drift.

2. Simple Production Scheduling (Single machine, minimize weighted tardiness)

When to use: short job queues on a bottleneck machine where due dates and weights matter.

Data inputs: job processing times, due dates, priority weights, ready times.

Model / Heuristic: for small n use MILP sequencing. For larger n use dispatch heuristics: Smith's rule (process by ratio p_i/w_i) or minimize (due date - processing) slack-based priority, with local improvement swaps.

Evaluation metrics: average tardiness, weighted tardiness, throughput.

Deployment notes: provide human-adjustable windows, allow freeze period near release, and show sensitivity if a job is delayed.

3. Vehicle Routing (Capacitated VRP) — Simple Savings Heuristic

When to use: last-mile small fleet routing where exact VRP is too slow.

Data inputs: customer locations, demands, vehicle capacities, travel times/costs.

Heuristic: start with separate routes per customer, compute pairwise savings s_{ij} = c_{i0}+c_{0j}-c_{ij}, sort by savings, merge feasible routes until no more merges possible. Optionally run 2-opt for route improvement.

Evaluation metrics: total distance/time, capacity violations, percent of customers served within promised window.

Deployment notes: recompute nightly, expose manual resequencing for drivers, track on-route deviations to update future estimates.

Evaluation & Testing guidance

  • Unit test every recipe with the provided quick test case.
  • Run sensitivity analysis on key parameters (demand variance, lead time, cost weights). If actions change for small parameter changes, add safeguards.
  • Simulate historical replay (backtest) with a holdout period and compare to baseline policy.
  • Calculate value-of-information for major input parameters — is additional data collection worth the cost?

Deployment checklist (minimal)

  1. Data validation and ingest pipeline in place.
  2. Clear human-in-loop override and explanation: show what changed and why.
  3. Latency and cadence defined (real-time, hourly, nightly).
  4. Monitoring KPIs and alert thresholds (performance degradation, model drift).
  5. Rollback plan and a conservative safe default policy.

Common pitfalls & mitigations

  • Overfitting to noise — always validate with holdout and simple baselines.
  • Poor data quality — add simple validation checks and fallbacks.
  • Ignoring implementation cost — include human time, integration and exception handling in evaluation.
  • Opaque recommendations — always provide concise explanation and key sensitivities for operators.

Next steps and extensibility

Once a recipe proves valuable, consider adding:

  • rigorous stochastic optimization or rolling-horizon simulation;
  • value-of-information experiments to guide data collection;
  • automated A/B experiments and online learning for policies that adapt over time;
  • integration with task-management or scheduling systems to close the loop.

This toolbox is intentionally practical: start with a lightweight, testable model, prove value, and then iterate toward greater fidelity while preserving operator control and explainability.


Discussion

Comments and conversation will live here.