Many people don't like it when their shifts change dramatically. Sure, you can cover the night when half the staff takes off to see Taylor Swift, but calling all those people in means they in turn need their next shift covered, and so forth, and you end up with an entirely different schedule of people who have never worked together, etc. This is all fixable adding more constraints, but even just writing it all down and prioritizing them isn't trivial. They're not Legos.

Think about this

Go players: Go is so difficult. So many options and constrain blah blah blah

AlphaGo: Oh yah?

The optimization space for Go is very large, but the rules are relatively simple.

Think about this: People are not Go stones

(ok, maybe managers of low margin business are, but I digress)

The same Operations Research group has scheduling examples for restaurants: https://developers.google.com/optimization/service/schedulin...

And a API for shift scheduling: https://developers.google.com/optimization/service/reference...

This is actually the exact problem I want to solve. I hear the same thing from almost everyone I've met who makes schedules. Having an OR background, I always find it insane, their problems sound straightforward to model and solve with normal solvers and no fancy techniques - and they also always sound high value. I think the problem is that OR broadly just isn't accessible.

Most well supported solvers use a mathematical paradigm to define your problems, which "normal" people would look at and immediately get overwhelmed. There are nice off-the-shelf solutions for common scheduling problems, but unless you used it from the start, every business has some unique wrinkles which make fully adopting one of those solutions too hard. Either your wrinkle is not supported, or you cannot figure out how to wedge it into the tools provided. If you're really inclined to try to solve your scheduling problems better, the courses you'll find usually assume significant prior programming and/or mathematical knowledge.

I think it should be possible to lean on no-code paradigms to build a modelling environment for scheduling problems that is accessible for "normal" people who need more than Excel but can't hire an OR specialist.

I think it will be very difficult to come up with a simple and visual way to model all the constraints that a real world scheduling problem might have.

Honestly, I think the problem is people, not tools. Any time a company wants to create an exception-based vs a rules-based process, it screws things up royally from an efficiency POV.

To give a stupid example, I was once responsible for all the enterprise apps at an F500 used by Finance, HR, and Supply Chain/Procurement. This included our internal travel request tool, which had embedded approval hierarchies based on HR hierarchies & levels -- as one would expect. In the 2008 recession, part of the belt tightening was a new policy that the CFO had to personally approve any international travel requests, no matter who submitted them. Theoretically it was a very easy change, but can you imagine how unpleasant it was to build that logic into the system in a non-destructive way ... but a way that also had exception-handling to deal with times the CFO wasn't personally available.

Travel software is hilarious one of "You think this should be simple." until you run into people.

If their title is X, they must get approval. EXCEPT This one really good sales person. Their title is X but they can fly first class if they want and doesn't need preapproval unless it's 10k where everyone else is 2k.

Everyone flies except that one Software Developer who has Doctor provided note about their flying phobia so they can take the train (Amtrak). If train schedule doesn't line up, they get to show up a day early or stay extra day to accommodate train schedule.

Anything dealing with People quickly becomes madness.

Working in vehicle routing optimization for MSB, I would like to share a couple of insights/observations.

1. People can be very creative in solving their problems with your features (and bugs!), even completely unrelated at first thought. They just have to be (a) observable, (b) speaking the language your users understand, which mathematically oriented or generic packages do not.

2. On the other hand, the quite plausible (to me) approach of "obtain an initial solution — adjust for ad-hoc constraints — reoptimize the rest" constantly fails as "too complex" with users reverting to Excel instead.

However, I still stubbornly believe that mathematical optimization cannot do everything, and we should aim for domain-specific decision-support systems that are primarily manual where optimization is only a part of solution building, and UX really matters in that process.

This is a really important problem, and a lot of software attacks it. Pretty much every big HR/workforce management system includes options for it, e.g. https://www.workday.com/en-us/products/workforce-management/... and https://www.oracle.com/human-capital-management/workforce-ma..., plus a lot of dedicated providers.

As some other comment mentioned, these systems have been controversial, because some of them are used in ways that don't take into account normal human needs. E.g. some schedule back-to-back shifts, change with little notice, and can't take into account sorts of real life things (like child care) that a human manager might be able to.

I have some background is combinatorial optimization. I did consider writing some software in this area or something similar, like school time table planning. But I think the problem is that each business will have different constraints (have to have at least 1 first aider on a shift, Alice doesn't get on with Bob, you can't work 2 saturday in a row, shifts change every 2 weeks, you have to have at least 12 hours between shifts etc). Anything flexible enough to be used by a sizeable percentage of organizations will be too complex for them to use.