[johnkpaul]

Straight outta Manna, the short story by Marshall Brain. https://marshallbrain.com/manna1

> Manna’s job was to manage the store, and it did this in a most interesting way. Think about a normal fast food restaurant. A group of employees worked at the store, typically 50 people in a normal restaurant, and they rotated in and out on a weekly schedule. The people did everything from making the burgers to taking the orders to cleaning the tables and taking out the trash. All of these employees reported to the store manager and a couple of assistant managers. The managers hired the employees, scheduled them and told them what to do each day. This was a completely normal arrangement. In the early twenty-first century, there were millions of businesses that operated in this way.

> But the fast food industry had a problem, and Burger-G was no different. The problem was the quality of the fast food experience. Some restaurants were run perfectly. They had courteous and thoughtful crew members, clean restrooms, great customer service and high accuracy on the orders. Other restaurants were chaotic and uncomfortable to customers. Since one bad experience could turn a customer off to an entire chain of restaurants, these poorly-managed stores were the Achilles heel of any chain.

> To solve the problem, Burger-G contracted with a software consultant and commissioned a piece of software. The goal of the software was to replace the managers and tell the employees what to do in a more controllable way. Manna version 1.0 was born.

[Buttons840]

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.

[korse]

https://en.wikipedia.org/wiki/Job-shop_scheduling

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.

[Buttons840]

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?

[korse]

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.

[itslennysfault]

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.

[NikolaNovak]

>>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 :-/

[Buttons840]

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.

[sgift]

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."

[NikolaNovak]

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 :-/

[i_don_t_know]

I'm not working in this area.

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.

[wazoox]

Notice than in warehouses it's been at least for the past 10 years that people work with a headset in which a computer order them to go to aisle F, rank 9, take 2 boxes on pallet 3; then say "OK" when the boxes are loaded, and go on this way all day long, like meat robots. The level of soul-sucking exploitation is already way past anything reasonable.

[reactordev]

Where there’s a need for labor, it will be filled. Some of those meat robots are happy for the pay, some are not and wish for a way up (not out). Let’s not assume everyone working in a warehouse is a lazy meat robot.

[smokel]

Let me guess that you are not such a person who is happily working in a warehouse.

[reactordev]

I have in the past

[somewhereoutth]

People tend to become as you treat them - if they weren't meat robots before, they will be soon enough.

[drKarl]

I didn't know about this novel, Manna, it is 21 years old and more relevant today than ever (I'm on chapter 4).

[pstuart]

If we could get to that happy ending it would be nice.

[ericmcer]

It would be a happy ending if it meant the end of useless busy work to impress managers. The machine would understand you need extra employees to deal with spikes in customers and wouldn't require employees to "stay busy" during downtime.

[avidiax]

The day that anyone from corporate sees employees "slacking off", the machine will be programmed to keep employees busy whether it matters or not.

[elaus]

Thank you for mentioning Manna. I did not know about that short story and I very much enjoyed it in the past ~90 minutes. A lot of food for thought and absolutely astonishing that it was apparently published 21 years ago!

[neodypsis]

So a precursor to Amazon's driver scheduler?