Yes, that is what we synthetically did as our, Team 26, entry for the Information Stategy’s AI Strategy Lab. We picked the Erasmus Medical Centre and asked whether AI could make nurse rosters less harsh on the same few people. Our answer was a rule that ranks the cover options ORTEC, the roster software the hospital already uses, offers when a nurse calls in sick, GenAI that explains the ranking, and a scheduler who still decides.
At first we were looking if we could spot burnout early from operational data? We were building on burnout without any evidence that rosters really caused it, as correlation is not causation ofcourse. This also meant that we were running ahead of ourselves. The feedback on our proposal reached the same weak spot from another side. Predicting burnout needs a ground truth we didn’t have, but it also brings privacy, surveillance and false-positive risks. It pointed us to a roster-strain tool built on observable things, such as rest between shifts, consecutive shifts, and overtime, compared with how rosters are made today. Narrowing to one organisation was the easy part. The harder part was accepting that burnout stays our motivation and not something we predict. The data that was enticing to me came while I was orienting, namely the EMC’s absence rate, a 60-FTE unit loses around 700 days a year, which translates to roughly 3.2 FTE that is simply not there.
I took the Problem & Opportunity and the Competitive & Ecosystem analysis components, made slides, and helped with the prototype where needed. Beyond that, I believe I was the glue of the team. This means being a sparring partner, critic, and the one fine-tuning copy and layout of the slides. Being the critic meant asking whether sources were valid, whether a sentence claimed more than we could show, and whether everything followed logically, from the slide structure, which I argued for, to the prototype. There was one worry thought that I could not let go.
As we worked through the steps of the assignment, ORTEC kept turning up in three roles at once. It hosted our decision, as our tool sits inside its workflow, it is the probable owner of the data we needed, and it is a plausible rival, since its 2026 material points to AI-supported rescheduling. It felt like a pitfall for every component. If they’re already doing what we want to do, how do we create intrinsical value? Is this real disruption, or digitisation that older technology could handle? I did not get a clean answer at that point. What we did was build the uncertainty into the plan. The ecosystem slide has a decision for each situation we might find at the Erasmus MC, and the first test in our recommendation is a two-week gap check. If ORTEC already does this, we stop or redefine. If the function exists but sits unused, we configure it instead of building. Our assumption register still lists “ORTEC does not already do this” as not tested. That is the nearest thing to a failure we have, and i would rather say so.
The prototype was fun, but its results also complicated our own story. We had framed the problem around the repair moment (a nurse calls in sick, who covers?). Yet, the simulated repairs created only 12 of the 182 quick returns in the baseline. Most of the strain was already in the base roster, so the pilot now compares repair-time ranking with a strain-aware base roster. Break-even is the other result I had my thoughts on. The tool needs roughly a 3-6% cut in absence days to repay three years of costs, and our simulation points to about 3%. That is the bottom of the range, which is why our recommendation is “test next, not scale”. It was good to see other teams ask the same break-even questions at Demo Day.
Looking back, everyone had their own style, and putting four people’s work together was harder than splitting it. Next time I would meet more often, and before dividing anything I would make sure everyone shares the same “bird’s-eye view” of the project. Also, the course hands out its lenses one session at a time (e.g. platforms and ecosystems only arrive in Session 5) while a project needs them all at once. By then we had already picked a direction. If you start from the end, you can backwards-engineer an idea that avoids pitfalls like ORTEC hosting our decision. I’m curious how far I could have pushed all the sessions into a different idea if that was possible.
Furthermore, I did not realise how ubiquitous AI already is in the market. The vendor we sit on top of already markets AI-supported rescheduling. What I liked most is where that leaves the value creation. It is not AI taking over people. The decision is the important part, and our prototype supports exactly that. The AI Canvas calls it judgment: which errors matter most and who decides the trade-off. Count short-notice changes more heavily and you get fewer of them, but more cases of nurses with three plus quick returns. No model can say which is right. A manager has to. And when we let GenAI choose instead of the rule, it did worse (10.0 nurses with three or more quick returns vs 6.2). So GenAI writes and people decide. I also learned what a platform actually is and how it creates value, partly because our case isn’t one. We could have gone deeper there. The surprise of the project was how much of it was about who is already in the room and who gets to decide, not about what we actually built.
