I would be very interested in a post mortem of the software used called SkySolver. Its supposed to be a Java Application which is said to be developed by Accenture? Anyone have actual technical insights into why it failed?
About a decade ago, I was part of a startup trying to disrupt crew scheduling. It's a non-trivial operations problem when you aim to honor crew preferences, union-negotiated affordances, FAA legalities, etc. We were only involved in the pre-planned schedules. At that time, the airlines we were courting had entirely different human-hravybsystem to resolve real time issues. There was some level of reserve redundancy baked in so the human planners had some wiggle room to work with... but redundancy is expensive to maintain. As a relatively new engineer at the time it was a pretty neat domain with big $$$ at stake. As it turns out, pretty much nobody wanted to take the risk on a new system even if it had provably better schedules for all parties. All it takes is one snafu for the whole thing to turn into a major regret.
We ran a pilot with one carrier for a subset of their crew for maybe a year, but eventually failed to gain further traction. Very tough sales and implementation cycle in spite of the fact that we could convince many individuals (bothe crew and management with their competing concerns) of the benefits of our system.
In what way was it a tough implementation cycle? e.g. resistant to change, or outsourced (e.g. could not get close enough to the fire/ talk to the right people) or was it something else?
Would love to pick your brain because I can relate to what youre saying.
Integrating into the operations on a provisional evaluation basis is a whole lot of work and the stakes are high. As my grandpa used to say, "There's nothing easier than doing nothing." Both parties (our company and the airline) brought the right people to the table, but for the system to really be evaluated we needed an entire crew base to use the system in a "realistic" fashion. There was a fair bit of understandable skepticism about how the system would perform under the stress of real user input, but due to the overall complex nature of the system there was a non-trivial learning curve and lots of crew members didn't see a lot of value in spending their time help us put the thing through its paces. As an example, the system would allow crew members to specify a highly detailed, specific set of flight preferences that were either declared as ranked priorities and/or they could select specific flights. If a crew member was forced to "try" our system, they could put in a generic set of input ("I like the Vegas flight."). However, we suspected that once they were faced with the opportunity to share their real schedule, they would have a lot more incentive to put in a lot more particulars, which would stress our optimization engine differently.
Im actually working at a startup that wants to use an algorithm to plan transport on large scale. ( Different Industry though). Got any tips or insights on biggest challenges?
The biggest challenges we had were more political. Getting buy-in across the airline as well as _support_ from the airline side to integrate their data and system into ours.
Sadly, it was a people problem, not a tech or algo problem.
So, did you manage to "tackle" the people problem in the end? How did you get them to move and integrate with your system in the end? Was it a bottom up (from the end users) or top down (making it part if company strategy) approach?
Sadly, I don't have these answers. I ended up quitting to go on a long sabbatical.
Last I heard, the airline scrapped the entire project to continue doing things the old way because they felt it was too much work on their end. ¯\_(ツ)_/¯
Does the algo work? Is it better than the status quo and under what circumstances is it susceptible to failure? Does it know when the whole system is over-constrained?
If we assume the algo rocks (because you have operations research veterans), what stage of planning does your system address? What is the experience required and cost of manual intervention?
Fun problem. Human factors and edge cases abound. So much is at stake for a system that already works (to any predictable degree).
The algo works. We have two algorithmic experts onboard, of which one is a professor and one is already working with algos each day (e.g. worked on patients/beds capacity challenge when covid began).
The startup focusses on assigning goods to transport. (As in its not part of the commercial sales process.. only execution of the required capacity planning that comes after it) .Something that has been tried 20 times and failed. It currently is done manually.
I'll bet it's just another excuse. The situation was probably so bad that the only solutions SkySolver could offer were beyond their capacity. There were probably partial solutions that were possible, but they rolled the dice on being able to resolve it by overworking people. They decided to double down instead of paying a whole lot of vouchers and refunds they'd rather not have to. Is it the software's fault the bet didn't pay out? As the problem snowballs and becomes more intractable, you get too far off the script and reach a point of no return.
I know nothing about the SkySolver or leadership at Southwest, but that seems like a very likely scenario based on what I've seen of what corporate types expect from software and rank-and-file employees.
SkySolver is a total shit show no doubt, but it’s not the entirety of the problem. Keep in mind when you have disruptions you actually have multiple products. SkySolver only manages the crew. They have another system that manages the aircraft and flight schedule. Believe it or not these systems are mostly decoupled - the schedule is modified first, then the crew, and there may even be a feedback loop back to the schedule if there is no crew solution.