Case Study: Personalplanung an der Universität Zürich
Das Zentrum für Reisemedizin der Universität Zürich ist die führende reisemedizinische Anlaufstelle der Schweiz. Über 100 Personen arbeiten dort in klinischen und administrativen Rollen. Viele davon studieren, arbeiten Teilzeit oder teilen ihren Tag zwischen Klinik und Forschung auf. Das macht die Personal- und Kapazitätsplanung anspruchsvoll.
Die Personal-planung funktionierte, weil die zuständige Person den Betrieb in- und auswendig kannte. Sie wusste, wer verfügbar war, wer wofür ausgebildet war und wer welche Schichten bevorzugte. Dieses Wissen war über Jahre gewachsen, und es lag grösstenteils bei ihr und nicht in einem System. Als sie über längere Zeit ungeplant ausfiel, übernahmen zwei Personen aus dem Team die Planung und mussten sich das Bild neu zusammensuchen: aus dem bestehenden Planungssystem, einem Teams-Kanal, Post-its, einem Mailpostfach und einer Excel-Liste. Das war der Moment, in dem die Klinik beschloss, etwas zu ändern.
Neben dem Engpass in der Planung gab es ein zweites Thema. Das ZRM stellte zeitweise zusätzliches Personal ein, um Schwankungen in Nachfrage und Pensen abzufedern. An manchen Tagen fehlten in einzelnen Disziplinen die Leute, zum Beispiel krankheitsbedingt. Einen Personalschlüssel, gegen den man hätte planen können, gab es nicht.
Das ist kein Problem, das nur Kliniken haben. Es ist ein Prozessproblem: Das offizielle System hält die formellen Daten, aber die eigentliche Arbeit stützt sich auf Kontext, der ausserhalb davon liegt.
Das System passte nicht zum Arbeitsablauf
Das ZRM arbeitet mit Polypoint PEP, einem etablierten System für Dienst- und Einsatzplanung, das auch an das HR-System der Universität angebunden ist. Was fehlte, war der Blick darauf, wie sich Pensen über längere Zeit entwickeln. Vorausschauend zu planen war damit schwierig. Auch Präferenzen der Mitarbeitenden liessen sich kaum berücksichtigen, wenn die planende Person sie nicht separat und ausserhalb der Plattform festhielt.
Die Tagesplanung war ganz aus dem System herausgewachsen. Wer aus dem Leitungsteam für die Einteilung des Tages zuständig war, las den Plan in PEP ab und tippte ihn in eine Word-Tabelle und einen Teams-Kanal. Der Empfang druckte diese Tabelle jeden Morgen aus, damit Umteilungen von Hand nachgetragen werden konnten.
Das kommt häufig vor, auch in anderen Branchen. Das führende System macht seine Arbeit, aber ein paar Abläufe passen nicht hinein. Und die landen dann in Excel-Tabellen, in E-Mails und in den Köpfen der Beteiligten.
Wir starteten das Projekt im Februar 2026. Nach einem Monat hatte das ZRM einen Prototyp, auf den es reagieren konnte. Seit Juli 2026 arbeitet die Klinik täglich mit der Software, planIQ.
Zentrale Entscheide
Das führende System bleibt
Polypoint PEP, die bestehende Planungsplattform am ZRM, deckt nicht alles ab, was das ZRM brauchte. Aber als führendes System für die Dienstplanung ist es an zentrale HR-Prozesse angebunden und trägt Abläufe rund um die Planung mit. Es zu ersetzen war explizit kein Ziel.
planIQ musste also neben PEP stehen. PEP blieb die Quelle für die offiziellen Dienst- und Anstellungsdaten. planIQ nutzte diese Daten für die Planungsarbeit, die vorher rund um PEP herum passierte: langfristige Personalszenarien, Kompetenzen, Präferenzen und den gedruckten Tagesplan.
Der Prototyp formt das Konzept
Ziel von planIQ war, den planenden Personen eine Oberfläche zu geben, die ihnen tatsächlich hilft. Wer innert Monaten produktiv gehen will, muss die Diskussionen über den Funktionsumfang früh führen. Ein Prototyp machte diese Diskussionen konkret: Man konnte die Abläufe durchspielen, auf die Screens reagieren und entscheiden, was die Anwendung wirklich können muss. Und es zeigte sich früh, welche Informationen wir aus PEP brauchen würden.
Hosting gehört zum Produkt
Eine agentische Coding-Plattform half uns, am Anfang schnell voranzukommen. Sobald das Konzept stand, holten wir die Infrastruktur aber ins Haus. Personalplanungssoftware arbeitet mit Daten von Mitarbeitenden, und die brauchen einen sorgfältigen Umgang. Ein internes Tool wie dieses hat ausserdem keinen Grund, aus dem öffentlichen Internet erreichbar zu sein. Deshalb planten wir die Migration auf die IT-Infrastruktur der Universität früh ein, statt beim Go-live Überraschungen zu erleben.
Wie eine solche Migration abläuft, ist ein Thema für sich. Wie man einen KI-gebauten Prototyp in den produktiven Betrieb bringt, beschreibe ich in einem separaten Beitrag.
Daten nur dort, wo sie gebraucht werden
Vibe-codierte Anwendungen zeigen tendenziell alles, was an Daten da ist. Weil diese Anwendung mit Anstellungsdaten arbeitet, wollten wir bewusst nur das sichtbar machen, was die Arbeit tatsächlich erfordert. Das begann schon in der Entwicklung. Der Prototyp brauchte realistische Daten, aber keine echten Personendaten. Agentische Coding-Tools sind dann nützlich, wenn sie die Struktur des Problems sehen: Rollen, Pensen, Absenzen, Kompetenzen, Präferenzen, Sonderfälle. Konkrete Personen müssen sie dafür nicht sehen.
Entwickelt wurde die Anwendung deshalb auf pseudonymisierten Demodaten: einer Kopie ausgewählter echter Planungsdaten, in der Namen, Kontaktangaben, Personalnummern und weitere direkte Identifikatoren ersetzt waren.
Erst mit dem Umzug auf die Infrastruktur der Universität verbanden wir die Anwendung mit den täglichen Datenlieferungen aus PEP. Auch dann kamen nur Daten in die Anwendung, die für die Abläufe relevant sind: keine Lohnangaben, keine weiteren sensiblen HR-Daten. Dazu kamen Benutzerrollen, die jeweils nur den Teil der Anwendung freigeben, der für die betreffende Person relevant ist. Ein Admin sieht mehr als eine planende Person, und die sieht mehr als ein Mitarbeitender.
Übergabe an die interne IT
Mit dem Go-live war das Projekt nicht zu Ende. Die interne IT musste wissen, wie die Anwendung gebaut ist, auf welcher Infrastruktur sie läuft und vor allem, wie sie sich nach der Übergabe erweitern lässt. Heute nimmt das IT-Team der Abteilung kleinere Anpassungen selbst vor, unterstützt von Coding-Agenten. Das Projekt bringt seinen eigenen Kontext mit: den ursprünglichen Auftrag, die Design-Patterns und ein Entscheidprotokoll, das festhält, warum die Dinge so funktionieren, wie sie funktionieren. Aus einem kleinen Change Request muss nicht mehr ein neues Projekt werden.
Die Lösung
planIQ ist eine interne Webanwendung, die auf der IT-Infrastruktur der Universität läuft. Sie erhält täglich aktualisierte Daten zum Personal, zu Absenzen wie Mutterschaftsurlaub oder Ferien und zu den Anstellungsdetails, die für die Planung nötig sind.
Die Software deckt drei Hauptszenarien ab:
- Langfristige Pensen-Szenarien modellieren: “Haben wir im nächsten November genug von den richtigen Kompetenzen, auch wenn Leute abwesend sind? Oder sind wir bereits überbesetzt?”
- Kompetenzen und Präferenzen verwalten: “Wer kann aufgrund seiner Ausbildung reisemedizinische Beratungen übernehmen?”
- Tagesplanung: “Wer arbeitet heute in welcher Schicht?”
Kompetenzmatrix in planIQ: Die Planung sieht, wer für welche Leistungen qualifiziert ist, auf welchem Niveau, und wie viele qualifizierte Personen pro Bereich zur Verfügung stehen. Screenshot mit pseudonymisierten Demodaten.
Kapazitätsplanung in planIQ: Über- und Unterdeckung pro Leistung über zwölf Monate. Screenshot mit synthetischen Kapazitäts- und Bedarfsdaten.
Ergebnisse
planIQ ist seit Juli 2026 im täglichen Einsatz. Zwei Personen planen wöchentlich damit, wer die Tagesverantwortung hat, öffnet es jeden Morgen, und die Abteilungsleitung nutzt es monatlich für die längere Sicht.
Was mich überrascht hat: Die Tagesplanung war das kleinste der drei Szenarien und nicht der Grund, weshalb es das Projekt überhaupt gab. Heute ist sie das, was jeden Tag genutzt wird. Niemand tippt den Tagesplan mehr in Word ab. planIQ erzeugt auf Knopfdruck ein formatiertes PDF, und genau das druckt der Empfang aus. Diese Verbesserung im Prozess spüren die Mitarbeitenden jeden Tag.
Die Planung geht schneller. Wichtiger ist aber: Sie hängt nicht mehr an einer Person, die alles weiss. Wer die Planung übernimmt, sieht heute, wer verfügbar ist, wer wofür qualifiziert ist und wessen Präferenzen bereits berücksichtigt wurden. Die Pläne entstehen nicht nur schneller, sie sind auch besser. Präferenzen werden konsistenter berücksichtigt, weil sie am selben Ort liegen wie der Plan und nicht in einer Parallelliste.
Und das ZRM kann die Frage nach dem Personalbedarf endlich beantworten. Vor dem Projekt gab es keinen Personalschlüssel. Heute sieht die Klinik, welche Kompetenzen in welchem Monat knapp werden, und stellt gezielt danach ein, statt Unsicherheit mit zusätzlichem Personal abzufedern.
“Aus betrieblicher Sicht hat sich das Projekt nur schon wegen der Timeline-Funktion gelohnt. Sie ist interaktiv und zeigt mir über ein ganzes Kalenderjahr hinweg nicht nur, wie viele FTE wir haben, sondern aufgeschlüsselt nach Profil und auf welchem Kompetenzniveau. Das ist für uns wichtig, weil unsere Teams stark durchmischt sind. Diese Matrix-Organisation war ohne planIQ nicht genügend fassbar.”
— Jenny Crawford, Business Manager, Zentrum für Reisemedizin, Universität Zürich
Wann sich dieser Weg lohnt
Am ZRM waren ein paar Voraussetzungen erfüllt, die dieses Projekt möglich gemacht haben. Wenn Sie etwas Ähnliches vorhaben, lohnt sich der Blick darauf, ob das bei Ihnen auch zutrifft.
Es gab ein führendes System, das wir nicht anfassen mussten. Die Abläufe, die wir gebaut haben, existierten bereits irgendwo: in Word, in Teams oder in einem Kopf. Wir mussten also nicht raten, ob sie jemand nutzen würde. Die Daten waren sensibel, aber überschaubar genug, dass wir streng festlegen konnten, was die Anwendung überhaupt sehen darf. Und es gab eine interne IT, die bereit war, die Anwendung am Schluss zu übernehmen.
Fehlt eine dieser Voraussetzungen, würde ich vermutlich anders beraten. Wenn der zugrundeliegende Prozess nicht funktioniert, repariert ihn auch keine Anwendung. Und wenn niemand in der Organisation die Anwendung danach betreuen kann, läuft das Projekt schon in den ersten Tagen des produktiven Betriebs in Probleme.
Wenn Sie das aus Ihrer eigenen Organisation kennen, einen Ablauf, der aus dem Hauptsystem herausgefallen ist und heute in einem Spreadsheet, einem Word-Dokument oder einem einzelnen Kopf lebt, dann melden Sie sich.
Teilen
Über den Autor
