The "magic tech" trap
An automated scheduling project, seen from a distance, can look simple: install the tool, plug in time & attendance, and it runs. That is obviously a naive view, and it is often in the gap between that promise and on-the-ground reality that projects fail.
Over 6 years of work alongside healthcare facilities, we have learned one essential thing: technology without support is not adopted. The barriers to adopting AI in scheduling are not technological. They are human, organizational, and sometimes political.
The four main barriers to adoption
- Technology barriers: poor interoperability, inaccessible or unreliable data, complex IT architecture.
- Regulatory barriers: poorly formalized working-time rules, local collective agreements to integrate, GDPR requirements.
- Human barriers: fear of losing control, misunderstanding of what the tool does, distrust of AI in general.
- Organizational barriers: unwritten rules, historical inequities that must be surfaced to be corrected, political balances to preserve.
Each of these barriers can be lifted, provided it is not underestimated from the scoping phase.
The key stages of a successful deployment
1. Scoping & perimeter
Define precisely: which unit, which teams, which objectives, which success indicators. A poorly scoped project is a project that drifts.
2. Needs audit
Formalize the rules, regulatory, team-level, individual. This stage often reveals implicit rules, contradictions, and unwritten practices. It is useful work in itself, regardless of the tool chosen.
3. Configuration
Translate rules into algorithmic constraints. This is where vendor expertise makes the difference: understanding the domain, not just knowing how to code.
4. Review & acceptance
Get validation from key users. Adjust. Iterate.
5. Training & onboarding
Non-negotiable. A tool that is not mastered is a tool that gets abandoned.
6. Change management
Communicate, reassure, address concerns, celebrate early wins. It is ongoing work, not a one-off workshop.
7. Long-term adoption
Monitor, adjust, evolve. Unit rules change, and the tool must keep up.
The key role of deployment teams
At Hopia, project support is not a side service: it is an essential component of the value delivered. Without it, even the best algorithm does not take root in everyday practice. Every project involves:
- A dedicated project lead on the client side.
- An operations engineer at Hopia, specialized in configuration.
- A client lead for long-term support.
- Domain champions on the facility side, trained and equipped.
This mixed team is what makes success possible, more than the raw power of the algorithm, which is a prerequisite but not a sufficient differentiator.
What we have learned not to do
- Don't try to automate everything at once. Start with a well-scoped perimeter, then extend.
- Don't underestimate the time needed to formalize the rules. It is often the longest phase, and the most decisive.
- Don't neglect internal communication. A scheduling project touches everyone.
- Don't sell a "black box". Teams need to understand what the tool does, or they will distrust it for a long time.
Scheduling as a transformation project
Ultimately, a Hopia project is not an IT project. It is an organizational transformation project that uses technology as a lever. That is why we invest as much in human support as in the algorithm, and why, six years after our first deployments, our clients stay with us.