When I worked at Home Depot during the 2000's there was a "schedule person" who would mostly wonder around talking to friends who worked there while messing up my schedule every other week. When I applied I told them I wouldn't work on certain days because of school, they hired me under those conditions. The schedule person couldn't go 2 weeks without messing it up. I have to conclude this person was paid more than me to just randomly throw people onto a schedule every week, giving thought only to their friends (which I was not). I do hope this person's job was replaced by computers years ago.
One of the most challenging problems I've every been faced with is machine-scheduling a set of manufacturing facilities. I understand that Home-Depot is a simple case, but I would caution you against trivializing the problem. The amount of compute (and accurate data collection) necessary to beat a (semi-competent) human is astounding.
On side note, I'm mentally preparing myself for a wave of AI powered plant scheduling hucksterism where those selling the systems bill AI as a tool that can magically fix the persistent problem of poor data collection.
It doesn't help that this is such a fun problem every programmer wants to try solving it.
What do you think the hardest part of solving this with computers is? Surely if we can get all the constraints (some of which would be soft-constraints) into the computer it can come up with an better solution than a person can. Right?
Is it a problem because the real world is messy and not all the data can go into the computer? Or is it that we just don't know how to define a "score function" that accounts for everything?
The real world version of the problem looks similar to the 'flexible job shop' but with a few tweaks that increase the problem complexity significantly.
Real time, accurate data collection is a non-trivial problem in a high-mix environment and if you've got a handle on the first two, compute infrastructure to crunch all of it and then push it back to the facility being scheduled is expensive.
Finally, systems that are this optimized can be slow to react to sources of error.
The alternative is to pay a couple of guys to spend most of their time walking or golf-carting around a few hundred thousand square feet of facility. Their job is to intimately know the various processes and employees involved, run a very basic scheduling protocol and modify it on the fly as the situation demands. In most instances, it is very hard to prove that the technologically complex version is a true improvement over the good ol' boy approach.
As such, the computational solutions usually end up implemented to boost the companies valuation to potential buyers.
edit: job shop scheduling can work wonders, but it generally fails hard in 'high-mix' environments.
True. That is a job that could easily be done better by a computer. On the other hand, if you mostly eliminate human workers in general that job becomes much easier.
>>I do hope this person's job was replaced by computer years ago.
It was not (source: family & friends did that job at several Home Depots recently:)
It takes about 16 - 24 hours of work on a weekly basis to manually update schedule after it has been automatically generated based on policies, requirements, and all known constraints.
Reasons, if you care - I got to hear about them weekly:
1. Department Supervisors are supposed to manage the schedules for their teams, but they did not at most stores, for various reasons from lack of training to lack of will/bother. So the job effectively gets "internally and unofficially outsourced" from a dozen leaders who know their teams, to a single HR / schedule person who now has 150-200 people they know less well (and other work to do as well). This was NOT well understood by corporate/HQ, so entire process is based on flawed assumptions from the get-go.
2. As part of that, nobody's preferences and working hours are correctly in the system. Again, should've been entered upon hire and maintained by DS, instead a single person needs to figure out and manage for 150-200 people.
3. As part of that, people made changes all the time - wedding, funeral, birth, movie, party, picnic, vacation, illness, whatever. Should: Be entered directly in the system by the DS. Actually: people leave voicemail, post it notes, yell in passing, or try to telepathically message, yes, the single person who's job it is strictly speaking not to maintain such information.
4. Software isn't great; training and documentation are worse; processes are not reflective of reality; and nobody does what they're supposed to do, from associates to DSs to ASMs. People TRY their best, mind you. But people are people, so see next point:
5. Basically, the problem there, as I see it: just like economists assume perfectly rational economic actors and physicists assume frictioneless spheres, programmers assume "well defined requirements understood by all and a process that is documented and accurately followed" when they say "this can definitely be easily automated" :->. Don't even get me STARTED on bright eager university graduates who come to companies to do robotic process automation of business processes in a quick agile way with fast ROI.... and the even quicker and painful lesson in real life they soon obtain :O
This is NOT to say I don't feel your pain - I very much do! Not sure if a little bit of background will help or make it worse :-/
Why is the generated schedule so bad that it requires a couple dozen hours to fix? Does the schedule produced fail to meet the defined constraints? Or is it because some of the constraints have not been entered into the computer?
Scheduling is NP complete, but the problems are small enough that I think computers can trivially find near optimal solutions, given some scoring function, better than a human can. Why doesn't this happen? Is defining the scoring function too hard? Am I wrong about computer's solving abilities?
Language models have proven themselves reliable with natural speech and highly technical speech (like code), they could help make entering the constraints more approachable. Also, as my example demonstrates, if such a system fails occasionally, it's not worse than the status quo.
Not GP, but usually things are missing or not up to date. Also, people are really bad at defining what exactly is a "good" result. When we introduce scheduling at customers it can take twenty to thirty iterations until we have a good scoring function with all constraints. And then the data needs to be kept up to date or it gets slowly worse over time (requirements change, data rot). This often leads to people saying "the system is bad, I'll just do it by hand" instead of investing the time to find the underlying issue. Especially if it happens gradually. First you rework one schedule, then two and so on. Or if they are not able to enact a change of the system. In many companies the people who do the schedule don't know who to tell that the system is getting worse or get ignored. And they have a job to do after all ..
Stereotypical discussion with customers after a "bad" scheduling result: "Hey, why did your system not schedule Dave to do any of these jobs? All others are at 100% already, but he has nothing to do." "The job all need a Fubar cert, Dave doesn't have one." "Of course he has a Fubar cert." "Not according to the system." "Oh, we probably forgot it, because all schedulers know it anyway."
I tried to provide detailed, bullet-point answers to that question, in the initial post, and the general comment on difficulty of automating seemingly discrete and simple business processes.
I don't have much additional information, but perhaps to summarize:
* Initial iteration of system is (by definition) imperfect
* People who are supposed to maintain constraints and parameters, don't
* Person who typically does end up maintaining the system is not aware of all constraints and parameters, and doesn't have power or channel to change system
* Process for noting and updating constraints is poorly communicated and not enforced
* Through entropy, system, which was not perfect in the first place, gets worse over time, which feedback loops because people keep overriding it and updating it less and less.
My friends'/family experience has been that when a new HR Manager joins a store, they tend to "clean up" everything as much as they can; but then entropy sinks in again - people don't update constraints and requirements, system deteriorates, and provides more reason/excuses for people to not use it properly.
------------
On aside, in my own daily life, I've been working on ERP systems all my life, and as a techie it's a fascinating place to be. I assumed that numbers are numbers, business processes are well structured, defined and documented, and that people who's job it is to use a specific system will be at least somewhat proficient in that system. None of those things are necessarily broadly true :).
On aside-aside, similar thing can be observed in MS Project btw. MS Project has an incredibly powerful scheduling engine. It's amazing! But! 99% of MS Project users don't know how to use MS Project. They try to use it as Excel. They type in some tasks, the dates aren't what they want them to be, then they override automatic scheduling by putting manual dates rather than putting constraints into the system... and the negative feedback loop commences. I've rarely seen a MS Project Plan file which properly uses the scheduling engine :-/
As others have mentioned, you don't always have a complete and accurate set of constraints. So you generate a schedule based on what you have. You hand it out to your employees. And they point out conflicts that they forgot to tell you about or that come up on short notice. So you have to rework the schedule to take them into account manually.
You could regenerate the schedule with the additional constraints. But the new schedule is likely quite different from what you originally handed out. People will have assumed the original schedule is final and they will have made plans. You cannot simply replace the schedule.
You might also already be halfway into the schedule period and the new schedule might only be fair if you had applied it from the beginning of the period.
You might be able to account for all of that in your constraints but it's going to get really hairy.
