The Real Boundaries of Intelligent Scheduling —— Incomplete Constraints, No Matter How Powerful the Algorithm

Scheduling software sells algorithms, but what holds you back are the constraints.

Almost all intelligent scheduling projects fail in the same way: the algorithm generates the "optimal solution," the planner takes one look and says, "This won't work," and then manually adjusts 60% of it. The supplier says, "It's because your data is inaccurate," and the customer says, "It's because the software doesn't understand the business."

Both sides are right, but neither hits the nail on the head. The real reason is: the essence of scheduling is not calculation, but decision-making. And most of the decision-making rules are not written down.

This article clarifies why constraints are the bottleneck, which three types of constraints must be solidified first, and how to use the three-round method to uncover them.

Clarifying "Constraints"

Algorithms need to know what cannot be done. These "cannot be done" fall into two categories:

Explicit Constraints —— those written down. Equipment capacity, process sequence, delivery dates, shift schedules, mold availability. These are usually in the system, though not always accurate.

Implicit Constraints —— those only in the planner's mind. For example:

• "This customer is temperamental; if the delivery is delayed by a day, they will complain. Their orders have priority."
• "Only Old Wang can operate this machine, and he rests on Wednesday."
• "Molds have a lifespan limit. The last time they were pushed to the limit, they almost broke. This batch cannot be scheduled too tightly."
• "This material is often delivered a week late by the supplier, so it should be calculated as a week late."
• "Switching from Product A to Product B requires 4 hours of line clearance, but switching from B to A only takes 1 hour."

All of these are hard constraints, and none of them are written into the system. The system schedules based on "theoretical optimality," while the planner adjusts based on "practical feasibility" — this is the source of the 60% manual adjustments.

Three Types of Constraints That Must Be Solidified First

Key point: Soft constraints must be converted into explicit weights, not left for the "algorithm to learn." The reason is that the weights behind these constraints are business judgments (which customer is more important, which cost is more expensive), which are management decisions, not something the algorithm should guess.

Why "Training with Historical Data" Doesn't Work

Many solutions suggest: feed the scheduling records from the past three years into the model to learn the planner's habits.

This almost never works for scheduling, and the reasons are straightforward:

1. Historical scheduling is a "compromise result," not an "optimal result." Each decision made by the planner in the past was a compromise under the constraints at the time, including material shortages, rush orders, and equipment failures. Learning from this data means learning a bunch of compromises.
2. Lack of Negative Samples. The data only shows what was scheduled, not why other options were not. Constraints are negative knowledge.
3. Constraints Change. If a new piece of equipment is added or a major customer is gained, historical patterns immediately become invalid.

Therefore, the correct approach is not to let the model learn, but to make the rules explicit and write them down, and then let the algorithm optimize within these rules.

The Three-Round Convergence Method: Uncovering Implicit Constraints

This is the most practical part of the article. The method is simple but effective.

First Round: Let the Planner Criticize the System

The system generates an initial schedule (even if it looks bad) and presents it to the planner. Require them to point out "what's wrong and why" for each item. Each "wrong" item reveals a missing constraint.

This round typically uncovers 20 to 40 constraints. Don't rush to encode them; just record them.

Second Round: Encode What Can Be Encoded

Categorize the uncovered constraints into three types:

• Constraints that can be directly set as parameters (e.g., changeover time matrix by product pair) → immediately configure into the system
• Constraints that require management decisions (e.g., customer priority ranking) → report to management for weight determination
• Constraints that cannot be quantified in the short term (e.g., "this machine is unstable") → mark as manual intervention points, allowing the planner to manually adjust these processes

Third Round: Review the Remaining Errors

Re-schedule and let the planner criticize again. This round should have fewer than 10 remaining "wrong" items, and most of them should be the third type (unquantifiable). At this point, the manual adjustment rate usually drops to 20% to 30%.

Criterion: After three rounds, "every plan change can be justified" — if the planner can't clearly explain why they made a change, it's not a constraint but a habit, and it shouldn't be encoded into the system.

Three Scenarios Where the System Can't Generate Good Results (Accept It)

In some scenarios, intelligent scheduling simply can't produce good results, and forcing it will cost money:

① Extreme Multi-Variety Small-Batch Production: Hundreds of work orders per day, each with a few pieces, and different process routes. The scale of constraints explodes, making the algorithm slow and unstable, while human experience is faster.

② Constraint Change Cycle Shorter Than Scheduling Cycle: If customers insert orders dozens of times a day and materials change daily, the generated schedule becomes obsolete in half a day. In this case, what's needed is "rapid rescheduling capability" and "insertion rules," not "optimal scheduling."

③ Key Constraints Cannot Be Quantified: For example, processes that heavily rely on the judgment of experienced workers or priorities driven by customer relationships. In such scenarios, the system can only provide an initial draft, not replace decision-making.

Accepting these three points can make the project more successful — because the expectations are aligned, and it's clear which orders the system covers and which remain manual.

Acceptance Criteria: Focus on Manual Adjustment Rate, Not Algorithm Performance

The most honest metric for a scheduling project is only one:

Metrics like "how fast the algorithm runs" or "how much the objective function is optimized" should not be included in the acceptance criteria. They have no direct relationship with business outcomes. The planner's willingness to use the system-generated schedule is the only standard.

If the manual adjustment rate is still above 50% six months after the system goes live, don't switch the system; go back and add constraints — this is the second round of the same task.

In One Sentence

The upper limit of intelligent scheduling is determined by the completeness of constraints, not by the algorithm. First, use the three-round method to extract the rules in the planner's mind, clarify which can be encoded, which require management decisions, and which must remain manual — after this step, even the most basic scheduling engine will be stronger than the current one; without this step, the most expensive system will still be dictated by Excel.

This article belongs to the "Digitalization and AI Zone · AI Empowering Operations" direction. Prerequisite reading: "Why Do We Still Rely on Excel After Changing Three Scheduling Systems?" (Knowledge code: 16.2.2) discusses three structural prerequisites, while this article focuses on how to uncover constraints.

Knowledge code: 16.3.2 Author: QTank Version: v20261026