Whatthisisaboutinpractice
A roster that has to satisfy too many things at once
Contract hours, rest periods, skills, holidays, and then someone who would rather not work Saturdays. Doing it by hand gets you a roster that works, not the best roster.
Planning runs
Which order goes on which run, in what order, with which vehicle. Driving times, time windows at the customer, and a van that only holds so much.
Ordering what you need
How much to buy in, given lead time, shelf life, volume discounts and the space you have. Too much is money in the warehouse, too little is turning customers away.
Sequence on the shop floor
Which order first, so there is as little changeover as possible and delivery dates still hold. Often the cheapest win, because nothing has to be bought for it.
Whatyousupply:notdatabutrules
The rule of thumb about hundreds of examples does not apply here. What I need is the list of what is allowed and what is required, and that is a completely different conversation. The good news: you do not have to collect anything. The bad news: half of those rules are written down nowhere.
Hard rules and soft rules are not the same, and that distinction is half the work. A hard rule is law or physics: it can never be broken. A soft rule is a preference: rather not two late shifts in a row, rather the same driver for the same customer. Soft rules collide with each other, and then someone has to say which weighs more. That is the question that takes the most time and that nobody can take off your hands.
Beyond that, ten or so plans as you made them by hand recently. Not to learn from, but to measure against: if the model does not come out better than those, it is worth nothing, and you want to know that before you put it to use.
Howyouknowitworks:layingitbesideyourownplan
There is no “accuracy” here. The result is not a prediction that can be right or wrong, but a choice that is better or worse than the one you make now. So it gets compared, on the figures you care about: kilometres driven, overtime, changeover time, how often a preference is broken.
There is a second test that is more often decisive than the first: can a person explain the outcome to the people it affects? A roster that is four percent more efficient but that nobody can justify to the team will not survive. That is why the model works out not only the arrangement but also why it looks that way, in terms of your own rules.
And there is a limit on computing time that you agree up front. A planner has five minutes, not a night. A model that gets close to the optimum in five minutes is usable; one that proves the optimum after eight hours is not.
Wherethiscomesapart
The rules nobody wrote down. This is the classic, and it always arrives at the same moment: the model proposes something and the planner says “obviously that cannot be done”. Ask why, and there turns out to be a rule everyone knows and nobody recorded. That is not a setback but how this work goes, and it is why the project contains several rounds with the planner rather than one intake.
An optimum that is technically right and socially unworkable. The model spreads the unpleasant shifts exactly evenly across the year, but gives one person three weekends in a row because it is compensated later. Arithmetically correct. Humanly the end of it. Things like that only surface when you lay it beside a real plan.
And sometimes the answer is that you do not need it. If there are only two ways to arrange it, there is nothing to optimise; then a clear screen is worth more than a model. You would rather hear that from me in week one than in week six.
Whatitcosts
One question with hard rules only and a manageable number of units: one roster, one set of runs, no trade-offs between objectives.
The soft rules count too, so preferences you weigh against each other. That means more rounds with whoever plans it now, and that is where the work sits.
Several objectives at once, large rosters or routes, or being able to replan the moment something disrupts it: a sick call at seven in the morning.
All amounts exclude VAT.
Whatthisisnot
This is not a planning system. There is no package of screens where you will run your whole planning, with users and permissions and an app for staff. That is a product, not a project, and it costs a multiple. What you get is a model that works out one question, with a way to put something in and get something out.
Nor is there a model that makes your current planner redundant. The outcome is a proposal; whoever does it now judges it and adjusts it. That is not modesty but how it works: the model knows only the rules you wrote down, and they know the rest.
Looking for something else?
Questionsthatcomewiththis
- I have no historical data. Can it still be done?
- Yes, and that is the big difference with the other two models. This learns from rules, not from examples. Historical plans are useful to measure against, but they are not a condition.
- Does the model always find the best solution?
- Usually not, and that is a deliberate choice. Proving that something is the absolute optimum costs disproportionate computing time; getting within a few percent of it takes seconds. For a plan you use tomorrow, the second is the answer.
- What if the rules change?
- Then the model changes with them, and that is usually a matter of adjusting a rule rather than retraining. That is an advantage of this kind of model: there is no learned experience in it that you lose.
- How do I see the result?
- As a file, as an integration with the system you already use, or in a screen built alongside it. You choose that in the configurator; it is the item that varies most per project.