Scheduling Systems Break When Rules Are Alive
Perfect algorithms fail in production because business rules aren't static. I learned this the hard way building ERP scheduling modules.
I built a scheduling system for a logistics company two years ago. The algorithm was solid — mathematically optimal routes, minimal idle time, perfect resource allocation. Looked beautiful in staging.
First week in production, it collapsed.
Not because the math was wrong. Because the real world isn't math.
A driver called in sick. A customer moved their delivery window. A vehicle needed maintenance. The algorithm had no concept of "flexibility" — only constraints. Every change triggered a complete recalculation, and what looked optimal on paper created chaos: drivers reassigned mid-day, customers suddenly unscheduled, delivery promises broken.
I see this pattern constantly in ERPNext and Odoo implementations. Companies implement beautiful planning modules, then reality hits:
The algorithm doesn't know context. It optimizes for metrics, not for keeping the business running. A 10-minute delay to a math formula is nothing. To your customer, it's a broken promise.
Rules change faster than you can hardcode them. A technician gets certified for a new skill. You need to update the model. A customer changes their window. Another update. By month three, you've got 50 edge cases the algorithm never considered.
Humans still need to override it. This is the part vendors don't want to admit. No matter how good your solver is, operations needs an override button. And when operators override the system constantly, your "optimization" is just expensive infrastructure.
What actually works:
Build scheduling as a decision support tool, not an autonomous system. The algorithm suggests, humans decide. It's less sexy than full automation, but it survives first contact with reality.
Make constraints configurable, not hardcoded. If changing a rule requires code deployment, you've already lost.
Track what gets overridden. Those overrides are data. They tell you what your model doesn't understand about the business.
I'm rebuilding the second version right now with this approach. It's slower to deploy, but it won't break production. And honestly, that matters more than being mathematically perfect.