Buzzword or breakthrough?
I have always been exposed to different perspectives on AI, ranging from “AI will steal all jobs” to “AI is just a flash in the pan”. Reality always seemed more complex. As it became a buzzword across industries, it was unclear whether it was truly influential or simply a tool to improve customer perception. Working on the project showed me how AI could fit into a workflow; in our design, a person still made the call. When we let GenAI choose the shift change, it did worse than a simple rule. So, GenAI didn’t do the job; it presented the evidence in a simpler format for the planners.
Narrowing the focus
We began by tracking burnout using available shift data and other physical metrics. Our idea was to create a burnout prediction system that could help roster shifts better and improve the employee environment. When we received feedback on the idea, we were told that burnout detection from those numbers was unreliable, as burnout is more about mental strain. The feedback suggested switching to a strain-based rostering system, but existing software, such as ORTEC, already handles scheduling. So we narrowed it down to re-rostering when someone drops out. This narrowed the problem, and the market with it. But it also gave us a more tangible problem with no ready-made solution. I was concerned that narrowing the scope moved the project into unknown territory. We didn’t know whether such a system or solution existed.
My role: Economics
I was tasked with the economics part of the solution. With GenAI’s help, I gathered a general direction and some ideas for what the numbers might look like. But I couldn’t use that; I needed factual backing. I researched studies on strain and its effects on a roster. There, I found quick returns (returning to work less than 11 hours after a shift) were linked to absence days. One study showed that cutting quick returns by 49% reduced absences in the following roster period. Absences were 44% lower relative to the control wards, but only 17% lower when comparing both groups at the end of the trial. However, in the same study, the control wards saw a spike in absences during the test period. I could see how this could skew the results to look more favourable than reality.
Instead of basing our claims on the 44% figure, I used a 17-44% range, with 44% as the optimistic rate. As a result, at the cautious end, the tool never pays back its setup cost, which is part of why we recommended a test-first approach. The GenAI we suggested as a top layer for the planner to interact with turned out to be the cheapest component of the system, while setup, integration, and compliance costs made up most of the cost.
The question
The main question was whether a system like this already existed. Based on publicly available information, our research found that Erasmus MC (our primary point of reference) used an ORTEC scheduling solution. We researched whether they had something similar to ours or built it into their scheduling software. However, we found no evidence of this, which left us wondering whether this issue matters less for the hospital than we thought. Yet the numbers suggested a real gap: about 700 absence days (our estimate) a year for a 60 FTE unit, based on the 5.33% absence rate reported by Erasmus MC(2024), adding up to € 175- € 385k per unit per year at €250-€550 per day. This is where doubt emerged about whether the system could succeed as a product. Either the gap is unserved as we assume, or hospitals don’t see it as a gap worth buying a solution for, and our research couldn’t say which. We could resolve this uncertainty by asking ORTEC or by reviewing the hospital’s current systems.
In my calculations, the required break-even was 3% to 6% fewer absence days; however, the simulation showed only about 3%, the bottom of that range. This made me doubt whether the gains were significant enough. On paper, the product creates value; what we can’t show is whether the hospital will pay for it.
What the course ideas showed me
Two course ideas shaped how I read my own project: value creation vs value capture and governance. The numbers showed me that, with our solution, the hospital could save money through fewer absences and lower costs of covering them. In course terms, that was value creation, not value capture: as I described above, we couldn’t prove anyone would pay for it. As we moved into planning the solution, I realised the value we offer comes not from the AI, but from the simple underlying rule we proposed. The role of GenAI shrank as we moved forward. By the end, GenAI only explained the rule’s suggestions to the planner in simple terms, but the planner still made the final decision. The governance aspect pushed us in the same direction: we kept GenAI out of the decision-making process, partly so a person remained accountable.
Working as a team
Getting into the groove of working as a team took time. We were still working out who owned what part and how to split the work. Looking back, I could have helped sooner. As the deadline came closer, we set clear expectations as a team. I contributed by tracking internal deadlines and listing open decisions so we could resolve them before the deadline. That showed me how having clear deadlines helped the team move faster than open-ended discussions. On demo day, presenting and seeing the other teams present was reassuring: many had dealt with similar questions about the scope of their ideas, where AI fit in, and had taken similar paths to answer them.
What would I do differently?
What surprised me most was that my question about AI and its real influence is more real than I thought. The actual applicability of AI (in our case) was much lower than I had envisioned; the gains came not from introducing a completely new system, but from refining the existing system. A simple rule plus a GenAI top layer was more effective than a pure GenAI solution. Narrowing our scope made our solution less revolutionary than we had aimed for, but it still gave us a more tangible issue to solve and generate value from. In my next project, I would start by looking at where the burnout came from, then move to the schedule, check the current systems, and spend more effort figuring out why it hadn’t been solved yet. That way, our final recommendation could have moved past a gap check to designing the system. I walked away from the project realising that AI’s influence is neither small nor as big as some companies portray it: it’s earned by using it in the right place.
