Building a Scheduling System
Safe and effective flight operations, both commercial and military, rely on inherently complex systems and swift, efficient decision-making. Schedulers across both operational environments must make high-impact decisions quickly and repeatedly on a sustained basis. However, time scarcity forces schedulers to make short-sighted choices, often opting for the first feasible, reasonable solution to their immediate scheduling challenge or requirement. Hitting this “easy button” too quickly only exacerbates their problems – high costs, low pilot availability, and network effects of myopic decisions causing chronic inefficiencies.
The challenge posed by time scarcity – the reality that schedulers face – necessitates technology solutions that automate most of these complex decisions to make them as quickly as possible while maintaining operational quality.
That’s precisely why OpsLab built our SkySchedule platform. SkySchedule takes the guesswork out of squadron scheduling; It enables squadron operation managers to make the best possible scheduling decisions.
But building a system like SkySchedule is no small task – doing so requires advanced techniques from Operations Research (OR). To create an effective system, you need a deep understanding of your customer’s challenges and the decisions they face. And it would be best to comprehensively understand the many OR tools at your disposal, including exact large-scale algorithms, metaheuristics, and knowing how to build hybrid solution frameworks. In the following, we outline the main concepts and principles that must drive the development of such systems.
1. Build for trust
Typically, the process of building a scheduling system follows these steps:
An OR scientist talks to users to understand what they look for when creating a schedule, i.e., what are the nuanced inputs these schedulers execute against and what are the challenges they regularly encounter.
Then, these scientists translate their understanding into an objective function that takes a candidate schedule and maps it to a number that ascribes value to the schedule – for example, the number can be large for good and small for bad schedules.
Once schedules have been ascribed values based on their merit, the scientists write an algorithm that uses a mix of heuristics and optimization models to create a schedule and show it to the users for validation.
A typical result here is that the schedule looks entirely alien to users, and almost immediately, the scientist has lost the user's trust. To be successful in this scenario, the customer must be highly motivated and patient as they work through many iterations of the system with the scientist.
At OpsLab, we’ve chosen to build our systems for trust and with the end user in mind. Instead of creating a system that spits out schedules that look utterly foreign to the end user but might be “optimal” according to fancy OR algorithms, we build systems with a focus on strategies that create schedules that users are accustomed to. It doesn’t matter if your schedule is optimal if it isn’t helpful for the end user.
We believe this is a simpler, more elegant way to build an effective system for a few reasons. First, it’s hard to capture all the needs of the end user in an objective function. For instance, measuring the trade-off between instructor quality of life and students graduating on time. Do you want to burn out your base of instructors to maximize student graduation rates?
Bottomline: building schedules that users can relate to, instead of forcing them to accept alien-looking schedules that are optimal in a scientist’s interpretation of an objective function, leads to far better outcomes and far more effective systems.
2. Be mindful of the cost
Even if the budget allows it, don’t reach for a commercial solver yet. It is easy to clutter your scheduling approach with models. However, any new model creates tribal knowledge. This also intimidates future developers of the scheduling system to the point where they are too scared to touch the models. No matter what gets built, always keep the cost of development and maintenance of your scheduling system in mind.
3. Give users control
OpsLab’s philosophy is that the customer should be able to validate the output generated by the system immediately. Any scheduling system where users look at a schedule and must accept or reject the whole thing in one shot is dead on arrival. Any such platform severely limits users on how they can use the product. Therefore, engineering resources must be dedicated to create functionality that allows users to modify any automatically generated solution and observe the impact of their changes. For instance, squadron schedulers must be able to change the assignment of pilots to missions and immediately receive feedback on whether their changes are possible based on asset availability and other requirements.
4. Measure everything and show it
Maintain a scorecard that highlights crucial metrics that users care about. This scorecard should be populated for any schedule created by the platform and updated whenever users edit a schedule manually. This scorecard allows users to see the impact of their changes and further builds trust between the user and the platform.
Conclusion
When I tell people outside the industry about our work, they’re often surprised to learn how primitive most scheduling systems are. Our pilots need and deserve better scheduling solutions than what they have today.
Since our founding, we’ve followed exactly this playbook to build SkySchedule. OpsLab conducted 6 months of user interviews and surveys to understand the pain points felt by pilots and schedulers – all before writing a single line of code.
From day one of the development of our product, we have maintained biweekly meetings with all of our customers to keep the end-user feedback loop as fast and effective as possible. When we built our product, we started with the rule engine, not the optimizer, to dictate what was right and wrong about any given schedule. The first version of our software used simple, greedy heuristics to develop schedules that customers could immediately iterate on. After this round of refinement, we then introduced advanced OR techniques to accommodate more complex decision strategies. We also built a scorecard that provides a snapshot of the squadron’s operational health. These steps have helped us accelerate product launches and increased adoption across various fighter squadrons.
