Two templates for RFI and RFP on supply chain software
Most organizations don’t buy supply chain software every year; when they do, the process is often ritualized as an RFI followed by an RFP. In my book Introduction to Supply Chain, I argue that these rituals are not the best way to choose software. A short, adversarial market‑research exercise—grounded in your own data and focused on measurable outcomes—tends to be faster, cheaper and more reliable. Yet many teams still face procurement mandates that require an RFI/RFP path. This article offers two ready‑to‑use templates—first an RFI, then an RFP—that preserve the spirit of evidence and outcomes even inside a formal process.
If you are new to the acronyms: an RFI (request for information) is typically used to explore the landscape broadly; an RFP (request for proposal) is used to select among a short‑list for a concrete scope. Neither document, by itself, guarantees good decisions; what matters is the questions you ask and the answers you will accept.
How to use these templates
- Treat the RFI as a filter: eliminate solutions that cannot express outcomes in money, cannot handle uncertainty explicitly, or cannot run safely without constant human babysitting.
- Treat the RFP as a proof: demand clear problem framing, explicit decision logic, parallel‑run evidence, and a commercial model aligned with outcomes—not screen time.
RFI — a short, sharp filter (12 items)
1) Economic objective in plain money
Question. What financial objective does your product optimize in production? Please express it in money terms (e.g., margin after write‑offs and working‑capital charges), not percentages.
Why this matters. Percent KPIs (service level, forecast error) are not an outcome; profit and cash are. If a vendor cannot talk money, they cannot arbitrate trade‑offs.
Good answer. “Per SKU‑location‑day we compute expected gross margin minus carrying costs, obsolescence risk, penalties, and a capital charge; we pick actions that improve expected net profit over the horizon.”
2) Decisions, not dashboards
Question. Which operational decisions does your software produce automatically in steady state (e.g., purchase lines, transfers, production orders, price changes), and at what granularity and cadence? Provide typical unattended‑decision percentages from live deployments.
Why this matters. Reports are useful; decisions move stock, capacity and cash.
Good answer. “Replenishment: ~99.95% of lines emitted unattended at SKU‑location granularity; ~0.05% flagged for review based on explicit rules. Price moves proposed daily at article level with dollarized justification.”
3) Uncertainty handled explicitly
Question. How do you represent uncertainty for demand, lead times and supply reliability? Do you carry ranges/probabilities to the decision, or collapse everything to point values + safety factors?
Why this matters. Supply chain economics happen at the tails; decisions made on single‑point guesses are brittle.
Good answer. “We maintain empirical distributions for demand and lead time, refresh daily, and optimize against the full distribution (not just means).”
4) Parallel‑run before cut‑over
Question. Describe your standard parallel‑run (“dual‑run”) practice prior to go‑live. What daily artifacts are captured? What qualifies as a “nonsensical” recommendation, and how is it eliminated before cut‑over?
Why this matters. Parallel‑run is the fastest way to surface model/semantics issues safely.
Good answer. “We run on full scope daily, log emissions and per‑decision explanations, classify anomalies, fix causes, and require zero nonsensical lines for 10 consecutive business days before switching.”
5) Programmable decision logic
Question. How is the decision logic authored and maintained (language/DSL)? Who can change it, and how quickly?
Why this matters. Real supply chains are idiosyncratic; checkboxes won’t cover them.
Good answer. “A compact, readable script (few hundred lines) maintained by a supply‑chain engineer; typical small change: <1 day from request to deployment with version control.”
6) Clean data feed & reproducibility
Question. Do you operate from immutable daily snapshots (with timestamps and checksums), or from mutable live databases/‘cleansed’ marts? Can you replay any past run bit‑for‑bit?
Why this matters. Reproducibility is the difference between debugging and guessing.
Good answer. “Daily snapshot at a fixed ‘closing bell’; schema‑faithful CSV/Parquet; every run pinned to data + code versions for exact replay.”
7) Per‑decision explanation
Question. What explanation accompanies each emitted decision? List the financial drivers you surface and an example of the format.
Why this matters. You won’t trust what you can’t explain to operations and finance.
Good answer. “Each line shows top drivers with sign/magnitude: expected margin, stock‑out cost, carrying cost, and the constraint that bound the choice.”
8) Safety stop conditions
Question. Under which conditions does your engine stop emitting decisions and fall back to manual operations?
Why this matters. Safety is not a dashboard banner; it is an automatic stop.
Good answer. “Stops on missing/stale key tables, abnormal distribution shifts, or contradictions (e.g., negative available capacity). Alerts the owner with root‑cause clues.”
9) Boundary with systems of records
Question. Are you the same vendor as our ERP/WMS? If yes, how do you ensure a clean boundary between transaction processing and heavy decision‑making?
Why this matters. Blended systems often inherit the constraints of the transaction layer. It’s also critical to be able to “unplug” either the system of records or the system of intelligence; the two solutions must not be bundled.
Good answer. “Independent runtime; read snapshots, write back orders/prices via a narrow interface. Strict independent databases to segregate transactional from analytical workloads.”
10) Uplift measurement in money
Question. How do you measure impact versus the baseline once live? Please describe the financial metrics and the comparison design.
Why this matters. If you can’t measure uplift, you can’t manage it.
Good answer. “Monthly pack with net profit uplift broken down into margin gains, reduced write‑offs and capital freed; baseline from dual‑run months and control sites.”
11) Commercial alignment with outcomes
Question. What pricing options tie fees to the volume/quality of automated decisions and/or measured uplift?
Why this matters. Paying for seats incentivizes manual work; paying for outcomes incentivizes automation quality.
Good answer. The vendor charges little for the setup. Most fees are postponed until the solution demonstrates its capacity to generate profitable unattended decisions.
12) Roles and ownership
Question. Which client roles are needed to own the logic, the data feed and the financial parameters?
Why this matters. One small, accountable team beats diffuse committees.
Good answer. “A named owner for decision logic, a data steward for the daily snapshot, and a finance partner to maintain monetary parameters.”
RFP — a concrete, testable proof (20 items)
1) Problem statement in your own words
Question. Write two pages that restate our challenge without pitching your product. Emphasize stakes (money and risk), uncertainties, decisions to be automated, and constraints.
Why this matters. You can’t solve what you haven’t stated clearly.
Good answer. “A crisp narrative with numbers, constraints and uncertainties, not marketing.”
2) Economic model
Question. Describe the money model you will use: unit of analysis, horizons, how you treat carrying costs, write‑offs, penalties, and shared costs.
Why this matters. Decisions reflect how you price trade‑offs.
Good answer. “SKU‑location‑day with monthly capital charge; explicit write‑off curve by age; late‑delivery penalties priced per lane; shared costs allocated by activity drivers.”
3) Objective and constraints (formal)
Question. Provide the objective in math/pseudocode and list hard vs soft constraints. Explain how uncertainty enters the objective.
Why this matters. Precision here prevents months of misaligned tuning later.
Good answer. “Maximize expected net profit over T days subject to capacity/credit limits; soft constraints (MOQs, presentation minimums) priced with explicit penalties.”
4) Demand & lead‑time modeling
Question. Detail your approach for intermittent demand, promotions, cannibalization, and lead‑time variability. How often are models refreshed?
Why this matters. Long tails and regime changes are the norm. Time-series models are guaranteed to be insufficient.
Good answer. “General high-dimensional probabilistic models refreshed daily without outlier clipping.”
5) Admissible actions and levers
Question. List what the engine may do (buy/move/produce/price), at what granularity and cadence, and the levers available (batch sizes, lanes, substitutions, price steps).
Why this matters. Optimization quality is bounded by the option set.
Good answer. “Daily reorder at SKU‑location; weekly inter‑DC transfers; make‑to‑order batches ≥ X; price ladder with Δ=Y.”
6) Knowing when to wait
Question. How do you decide between acting now versus deferring a decision?
Why this matters. Waiting can be the most profitable action.
Good answer. “Act only when the expected financial gain exceeds carrying cost + risk premium + value of information from waiting one day.”
7) Algorithmic approach and scalability
Question. Describe your optimizer (heuristics, mathematical programming, policy search) and how you avoid combinatorial blow‑ups while respecting coupled constraints.
Why this matters. Elegant toy models often crumble at scale. Deterministic solvers (ex: MILP) also crumble under uncertainty.
Good answer. “Greedy selection on marginal profit under constraints, with targeted stochastic solver for constrained sub‑problems; proven to run on N=50M item‑days/night.”
8) Sample decision logic
Question. Provide a redacted snippet or flow (inputs → transformations → selection → outputs) from a similar client.
Why this matters. Readable logic is maintainable logic.
Good answer. “One‑page flow with field names, intermediate metrics, and the write‑back schema.”
9) Per‑decision explanation (example)
Question. Attach a sample ‘explain’ for one order line and one price change. Show top drivers with sign and magnitude.
Why this matters. Without this, you will end up debating opinions, not drivers.
Good answer. “A compact table: +$12 expected margin, −$5 carrying cost, −$7 stock‑out penalty avoided; binding constraint: inbound dock capacity.”
10) Parallel‑run plan and exit criteria
Question. Propose a daily parallel‑run plan with artifacts, triage workflow, and a quantitative exit criterion.
Why this matters. You want a scientific, not ceremonial, go‑live.
Good answer. “30 business days of daily runs; triage by severity; exit when 0 nonsensical lines for 10 consecutive days.”
11) Safety stops and alerts
Question. List the conditions that stop emissions, how alerts are routed, and how fallbacks are selected.
Why this matters. Reliability beats blind uptime.
Good answer. “Stop on missing mandatory table, failed sanity checks, or extreme parameter drift; route to named owner; resume only after green checks.”
12) Detecting semantic drift
Question. How do you detect when a field’s meaning changed upstream (e.g., unit switches, new codes)?
Why this matters. Silent semantic shifts generate the worst errors.
Good answer. “Schema versioning; distribution monitoring; canary recomputations; automatic quarantine of suspect entities.”
13) Data feed (“snapshot”) contract
Question. Specify the daily files/tables, cut‑off time, formats, and validation you require. Include checksums and failure handling.
Why this matters. Clear seams prevent fragile integrations.
Good answer. “Daily 6am UTC drop; row‑level counts, hash manifest; reject‑with‑report on mismatch.”
14) Governance of overrides
Question. How are human overrides logged, audited and converted into improvements of the logic?
Why this matters. Overrides should shrink over time.
Good answer. “Every override is a ticket with reason codes; weekly review; accepted patterns become logic changes in the next release.”
15) Impact measurement plan
Question. Define the financial KPIs and the comparison design for measuring impact six and twelve months after go‑live.
Why this matters. You cannot argue with a metric you agreed up front.
Good answer. “Net profit uplift with decomposition (margin, disposals, capital); control vs treated sites; seasonality‑aware.”
16) Security and data minimization
Question. Describe least‑privilege access, data retention, and isolation between environments.
Why this matters. Security failures erase all gains.
Good answer. “Read‑only to snapshots; no PII unless justified; 90‑day retention. No interns ever touching the production.”
17) Performance at scale
Question. Provide expected run times and hardware assumptions for our order of magnitude (SKUs, sites, transactions).
Why this matters. Overnight must mean overnight.
Good answer. “For <100M item‑days: 50 minutes guaranteed; elastic allocation of cloud resources.”
18) Extensibility beyond the first scope
Question. How will you add new categories, channels or countries without rewriting from scratch?
Why this matters. Today’s pilot becomes tomorrow’s platform.
Good answer. “Shared core logic + local modules for constraints and parameters; new scope typically adds small, isolated files.”
19) Commercial terms aligned with outcomes
Question. Offer at least one option where fees align with automated decision volume and/or audited financial uplift. Explain the audit process.
Why this matters. Incentives shape behavior.
Good answer. “Fixed fee + success component calculated from agreed, auditable uplift formula; transparent spreadsheets and replayable runs.”
20) What you will not do
Question. List a few popular activities you intentionally exclude (with reasons).
Why this matters. Saying “no” is a sign of engineering discipline.
Good answer. “No vanity twins; no ‘accuracy’ contests detached from financial outcomes; no one‑off demo on toy data.”
Closing note
If you can avoid a heavyweight RFI/RFP, do so: a focused, adversarial market‑research sprint—on your data—will get you to evidence faster. If you cannot, the two templates above will still tilt the process toward decisions and money, which is the whole point of supply chain software.
