They have a strong OR team who has been building an excellent open source solver (OR-tools) for more than a decade. It makes sense to start trying to commercialise this work. It's interesting seeing them do it through problem specific APIs though.
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.
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.
I work in a restricted environment where I can't install or-tools. In order to solve our scheduling problem, I wrote a solution in Prolog that runs in a purely web-based "notebook" environment. It works well and has the benefit that non-technical users only have to deal with specifying simple "facts", then running a pre-defined query.
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.
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.
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.
