From Proof of Concept to Proof of Value: Building the Business Case for Optimization

Any company exploring an optimization or APS (advanced planning and scheduling) project quickly runs into the same problem: you need an ROI projection to get budget approval, but can you really know the real ROI before the system is actually built? Unfortunately this puts you in a Catch-22.

This is true whether you’re considering an off-the-shelf system that might need customization or a fully tailored solution built from the ground up. In both cases, you might consider reaching out to some potential vendors and asking them to work with you on building a scaled-down proof of concept (POC) to test the waters.

The POC Trap in Optimization – And How to Avoid It

When designing a POC, it’s easy to assume that if most of the application is built or configured, most of the benefit will follow. Unfortunately optimization models don’t work that way. The optimization model is the brain of the system. It is the set of equations and rules that decide how resources, schedules, or routes should be arranged to get the best result. You could have 90% of the mathematical model—its objectives, constraints, and variables—built and still end up with results that cannot be implemented. In some cases that last 10% of missing constraints can swing the ROI from a projected 40% down to 4%.

This non-linearity is built into the mathematics of optimization itself. Value doesn’t accumulate in a straight line as you add more of the model. Very often, it is the last few business rules that make the difference between infeasible recommendations and solutions you can actually use. That’s why ROI extrapolation is risky: projecting savings from a partial model can create phantom numbers that look convincing on paper but disappear in practice.

An Example in Logistics

Suppose your team runs a POC to minimize transportation costs. The model includes routes, loads, vehicle capacity, and delivery windows. On paper, it looks promising. But in this POC, the driver shift rules aren’t included. The routes may look cost-efficient at first glance. But with the missing driver rules, drivers may exceed their legal shift limits. From an evaluator’s perspective, that means the POC does not demonstrate any value, even though 90% of the modeling work is technically there. The true proof of the model’s ROI only comes when the last 10% of critical business rules are added. That’s when the model starts producing feasible, trusted, cost-saving solutions.

It’s also important to realize that adding the final constraint for driver shift rules may make the ROI numbers look worse. For example, the POC model may suggest 20% cost savings. But once the realistic driver shift rules are included, the savings may drop to 18%. This happens because now the routes have to abide by regulations on driver shifts. But do not be alarmed. It’s important to recognize that the original 20% was never actually achievable, it was a phantom result. Without those constraints, the real savings were effectively 0%. The addition of the last 10% of business logic is what transforms infeasible results into an 18% savings that can actually be realized. This is why early POC numbers should be read with caution; partial results can paint an overly optimistic picture that disappears when the model meets reality.

The reverse can also happen if conservative assumptions are made during the POC. For instance, the team might approximate shift rules cautiously, leading to initial savings estimates of only 15%. Once the actual rules are integrated, the model may then uncover opportunities for 18% savings.

In summary, partial POC models can both overstate and understate value, which is why early results should be read as directional, not definitive.

Rethinking the Purpose of the POC

When it comes to optimization POCs, the goal shouldn’t be to generate a final ROI number. That’s a trap. At best, early ROI estimates are directional; at worst, they’re phantom savings that vanish once real-world constraints are added.

A better objective is to use the POC to answer three questions:

1. Feasibility: Can the model realistically capture the constraints and complexities of your business?
2. Usability: Does it produce results that stakeholders can understand, trust, and act on?
3. Trust-building: Does it demonstrate enough fidelity to your world that decision-makers believe a full project will deliver measurable value?

That doesn’t mean ROI should be ignored. Instead, ROI in a POC should be treated as a directional indicator informed by other input. For instance, it’s tremendously helpful to listen to your own experts. Most planners have a surprisingly sharp intuition about how efficient or inefficient their plans really are. They may not always be able to prove it with hard numbers, but if you do like we often do on our calls and ask, ‘Do you think there’s at least 5% improvement possible here?’ you’ll likely to get a quick, confident answer. The people who live and breathe these decisions day in and day out usually know. Once you have that directional sense, it’s often easy to bring someone from finance into the conversation and have them help translate that typically conservative improvement estimate into dollars. In fact, many finance teams love supporting the business this way so you shouldn’t be afraid to engage them.

You can also supplement this with industry benchmarks as well early POC signals. When combined together, these inputs give you a much sturdier foundation for building a business case than trying to extrapolate an exact ROI solely from an incomplete POC model built by an eager vendor who wants your business.

The POC is still an essential step, but not because it can hand you a precise ROI number. Its real purpose is to show that the approach can work in your world and give you confidence in the partner behind it. That’s why, when evaluating vendors through a POC, it helps to look closely at qualities like:

• Technical & Methodological Strength — Do they have depth in optimization, not just generic “AI/ML”? Can they balance heuristics, exact methods, and practical compromises? Have they solved problems with similar complexity before?
• Business & Domain Understanding — Do they understand your industry’s language and constraints? Can they translate technical results into business impacts and spot ROI drivers outsiders might miss?
• Collaboration & Relationship Fit — Will you have direct access to the people doing the work? Are they transparent about trade-offs or prone to overselling? Do they operate in a way that fits your team’s culture?
• Adaptability & Long-Term Support — How fast can they iterate when assumptions change? Do they plan for continuous improvement after go-live, or do they “drop the deck and run”?

If you’re exploring an optimization project and want to talk through how to structure a POC that proves real value, we’d be glad to share what we’ve learned at SimpleRose.