Go players: Go is so difficult. So many options and constrain blah blah blah
AlphaGo: Oh yah?
(ok, maybe managers of low margin business are, but I digress)
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 also have access to Google's OR API as a trusted tester and have been toying with the solveShiftScheduling endpoint. Out of the box, I don't think I'll be able to easily represent some of our constraints to work with the API. Also, our management frequently want to change the scheduling behavior, so while I can reformulate the problem to make it work with the API now, I never know what's coming down the pipe.
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.
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.
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.
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.