ge0ffrey

We run the Mittelman VRPLib benchmarks at Timefold (and beat other open source solvers like or-tools in 95%+ of the X datasets).

But they are not representive of the real world, at all.

The Mittelman VRPLib benchmarks have only 1-2 constraints. Skills? No need. Working hours? Unlimited. Maps integretion? Cars can fly and the earth is a flat Euclidean space.

Any VRP algorithm optimized for the vrplib datasets is overfitted and not the best one in reality.

Take HGS for instance. Brilliant for CVRPTW. Crumbles to dust in field service routing for telco operations etc.

That being said: I fully agree that the solver industry as a whole has focused for far too long on global optima for academic requirements, instead of real-world use for the actual business requirements, and how to deal with business objective changes each quarter.

I beg to differ. Timefold is used daily in real-world operations.

Neither our clusters in the US or EU can afford to go down for a minute, or business operations in logistics, retail and healthcare are impacted.

> They do not adequately account for traffic, driver preferences, or other factors that require a continuous feedback

- Traffic: supported

- Driver preferences: the APIs support

-- Area affinity (soft) and geo fencing (hard)

-- Fairness and load balancing of work (soft)

-- Overtime (soft and hard)

-- Seniors not doing boring junior tasks (soft)

- Continuous feedback: the APIs support

-- Real-time rescheduling (warm starts) as actual execution data comes in.

-- Recommend assignment: scheduling in survival mode

-- Pinning: user stays in control through overriding assignments

-- Explainability: why a certain decision was made

-- Insights: what are the bottlenecks in my schedule - what type of employees should I hire or upskill.

Our version of a Solver as a Service deals with cases of up to 390'000 shifts in a single dataset for shift scheduling and 30'000 visits for vehicle routing problems.

Some our customers want to go even higher, and we're working on that.

There is an audience for such platforms - Timefold Platform optimizes 1,000,000 visits and 2,000,000 shifts per week - but only if it's more than just orchestration.

If it handles explainabily, what-if scenarios and insights to fulfill business needs.

And that's where supporting many solvers becomes the blocker.

A lowest common denominator design.

Those solvers are a black box. They don't expose what they're running, why they made certain decisions or how they can scale to large datasets or complex business requirements.

We've picked our poison: one solver, which we've built in the open, in the last 20 years, versatile enough to handle any scheduling problem. That delivers.

Sounds similar to Timefold Platform: app.timefold.ai

That's our Solver as a Service for scheduling problems (vehicle routing problem, shift scheduling, job scheduling, etc). It runs scheduling problems implemented with our open source solver: solver.timefold.ai

But this post is such a service for formula problems instead (think master capacity planning, portfolio optimization, etc), due to the choice of MILP solvers underneath. Similar to NextMv, Neos, etc.

Ideally, the solver doesn't just run on the backend, it's also orchestrated to run a pod per solver, with scale to zero.

Nonsense. Timefold Solver and other open source vehicle routing problem solvers deliver better results in less time, with affordable hardware, especially for real-world complexity.

For Job Shop Scheduling like this, Timefold has two implementations:

- Basic: an open source Food Packaging quickstart on solver.timefold.ai

- Advanced: a Job Scheduling REST API on app.timefold.ai

I would argue that inputting a loadBalance(sum(shift.duration)) function per employee is a higher level abstraction than inputting a quadratic math equation to accomplish the same thing.

Think Java/C++/Python vs Assembly.

Ironically, talking about problem reduction... most math equation based solver can't scale quadratic equations, so users "relax" the business constraints (to the point that projects fail in production).

There is truth in this.

Without involving the human planners, the project won't succeed. We're empowering them, with PlanningAI assistance, so they can focus on what they planning must do, for who, instead of how it gets there. So when the plan goes off the rails - 5 people call in sick - they can get it back on the rails in seconds with Real-Time Planning.

The engineering work is only half the work, or less. Fitting the technology into the human processes is another big chunk. Half of my videos on youtube deal with such cases: Continuous Planning, Real-Time Planning, Non-distruptive Replanning, Pinning, ... Not code, not technology, but design patterns.

And even then, this is far from 100% of the solution. Technology and education is still not enough.

That human planner with 30 years of business knowledge in his/her head is still a critical: he/she will always need to tweak, oversee and sometimes overrule the planning solution in production.

A 10% productivity gain is a lot for any company, regardless if they are operating a fleet of 50 or 50 000 vehicles.

However, the cost and risk to achieve that productivity gain is typically huge. Many Operations Research projects fail. And when they do, they are very expensive failures. "Managers getting fired" expensive.

With our technology, we're making OR projects easy and quick to put into production.