KI in der Dienstplanung: Besetzung, Ruhezeiten und Fairness verständlich erklärt

Ein ernstzunehmendes KI-Planungssystem besteht aus zwei klar getrennten Teilen. Der erste ist ein Konversationsassistent: Er liest Anweisungen, interpretiert vorhandene Tabellen oder PDFs und übersetzt lose Anforderungen wie „freitagabends brauchen wir mehr Leute“ in strukturierte Einstellungen. Der zweite ist ein Solver — eine deterministische Engine, die aus diesen Einstellungen berechnet, wer wann arbeitet, und dabei jede Regel für jede mögliche Zuweisung prüft.

Die Trennung ist entscheidend, weil Sprachmodelle konstruktionsbedingt probabilistisch sind. Sie verstehen Kontext hervorragend und taugen nicht als letzte Instanz dafür, ob eine Zuweisung eine Ruhezeit verletzt. Der Solver ist das Gegenteil: Er kann nicht plaudern, liefert aber bei gleichen Eingaben stets dasselbe überprüfbare Ergebnis — und kann belegen, dass keine harte Regel verletzt wurde.

In der Praxis sieht der Ablauf so aus: Sie beschreiben Ihren Betrieb in normaler Sprache, der Assistent strukturiert ihn in Rollen, Besetzung und Regeln, der Solver erzeugt einen Planentwurf, und eine Führungskraft prüft ihn, bevor irgendetwas veröffentlicht wird. ShiftCal ist genau um diese Trennung herum gebaut: ein Chat-Assistent für Einrichtung und Fragen, ein deterministischer Auto-Planer für die Zuweisungen selbst.

Der größte Fortschritt gegenüber dem Denken „alle von 9 bis 17 Uhr“ ist, den Bedarf pro Zeitfenster statt pro Tag zu definieren. Ein Besetzungsziel sagt: Zwischen diesen Uhrzeiten, an diesem Wochentag, an diesem Standort brauche ich so viele Personen in dieser Rolle. Der Tag ist kein Block mehr, sondern ein Bedarfsprofil, das steigt und fällt.

Nehmen wir ein Café als durchgerechnetes Beispiel. Der Montag braucht vielleicht zwei Baristas und eine Schichtleitung von 08:00 bis 12:00, drei Baristas im Mittagsgeschäft von 12:00 bis 15:00 und wieder zwei von 15:00 bis 18:00. Diese drei Zeitfenster beschreiben den echten Betrieb weit besser als „fünf Leute am Montag“.

Der Solver baut daraus Schichten, die Zeitfenster überspannen, und besetzt jede geforderte Position mit einer Person für das gesamte Fenster. Eine gute Engine meldet beide Fehlerrichtungen: Unterbesetzung, wenn ein Fenster das Ziel verfehlt, und Überbesetzung, wenn Sie mehr Präsenz bezahlen, als das Fenster verlangt. Beide Zahlen gehören vor die Veröffentlichung — nicht erst auf die Fläche.

Harte Regeln sind Bedingungen, die ein Dienstplan erfüllen muss — nicht nur bevorzugen sollte. Der übliche Satz: genehmigter Urlaub und gemeldete Verfügbarkeit, tägliche und wöchentliche Stundenobergrenzen aus dem Vertrag, Mindestruhezeit zwischen Schichten, geforderte Qualifikationen oder Nachweise für eine Position — und die offensichtlichste: Niemand arbeitet in zwei überlappenden Schichten.

Technisch wirken harte Regeln als Filter, nicht als Punktwerte. Bevor die Engine Kandidaten für eine Schicht bewertet, wird jede Person, die eine harte Regel verletzen würde, komplett aus dem Pool entfernt. Das unterscheidet sich grundlegend von Strafpunkt-Ansätzen, bei denen ein Verstoß nur „teuer“ ist: Teure Regeln brechen in vollen Wochen — Filter nicht.

Qualifikationen zeigen, warum diese Strenge zählt. Verlangt eine Position einen zertifizierten Staplerfahrer oder eine Person mit Schließberechtigung, dürfen nur entsprechend Qualifizierte überhaupt in Frage kommen. Und wenn niemand in Frage kommt, ist das ehrliche Verhalten, die Schicht offen zu lassen und den Grund zu nennen — „keine verfügbare Person mit dieser Qualifikation unter Einhaltung der Ruhezeiten“ — statt still jemanden Unqualifizierten einzuteilen.

Die meisten Länder verlangen eine tägliche Mindestruhezeit zwischen Schichten und eine Form wöchentlicher Ruhe; die genauen Werte variieren je nach Land und teils nach Branche oder Tarifvertrag. Eine gut gebaute Engine behandelt sie als konfigurierbare Parameter pro Arbeitsbereich — nie als fest einprogrammierte Annahmen — und wendet sie als harte Regeln im obigen Sinn an.

Der klassische Fehler, den das verhindert, ist die Kombination Spätschluss plus Frühöffnung. Angenommen, Dana schließt dienstags um 23:00, und die Öffnungsschicht am Mittwoch beginnt um 07:00. Die Lücke beträgt acht Stunden. Liegt die konfigurierte Mindestruhe höher — etwa bei elf oder zwölf Stunden — sieht die Engine Dana für diese Öffnung schlicht nie als Kandidatin; vielleicht bekommt sie stattdessen die Mittagsschicht. Kein Gefallen, keine Müdigkeit, keine Verhandlung: Die Zuweisung ist per Regel unmöglich.

Ruhelogik muss außerdem über den ganzen Planungshorizont funktionieren, nicht Tag für Tag. Wochenstunden summieren sich, lange Schichten brauchen unter Umständen geplante Pausen innerhalb der Schicht, und ein Ruhefenster kann die Grenze zwischen einer veröffentlichten Woche und der nächsten überspannen. Engines, die jeden Tag isoliert bewerten, erzeugen Pläne, die montags gut aussehen und donnerstags unzulässig sind.

Eine einzelne Woche auszubalancieren ist leicht; Unmut entsteht aus wiederholten Mustern. Wenn dieselbe Person drei Wochenenden in Folge den Samstagsschluss übernimmt, heilt eine perfekt ausgewogene aktuelle Woche dieses Gefühl nicht. Fairness braucht deshalb Gedächtnis: Die Engine sollte beim Bewerten neuer Zuweisungen auf ein rollierendes Fenster bereits veröffentlichter Wochen zurückblicken.

Konkret: Angenommen, Marta hat in den letzten vier Wochen drei Wochenendschlüsse übernommen, Alex einen. Ist der Samstagsschluss dieser Woche zu besetzen und sind beide nach allen harten Regeln geeignet, sollte die Engine Alex bevorzugen — nicht, weil Marta nicht verfügbar wäre, sondern weil ihre angesammelte Last höher ist. Nächte, frühe Öffnungen, Wochenenden und Feiertage können jeweils einen eigenen Zähler führen.

Die Zähler sind zugleich ein Kommunikationswerkzeug. Fragt jemand „warum schon wieder ich?“, hat eine Führungskraft, die die Rotation der letzten sechs Wochen zeigen kann, eine Antwort, die ein Bauchgefühl-Plan nie liefert. Ein Plan fühlt sich fair an, wenn die Rotation sichtbar ist — nicht nur, wenn sie mathematisch stimmt.

Kosten kommen erst ins Spiel, wenn alle harten Regeln erfüllt sind — sie sind ein Optimierungsziel, nie ein Vorwand, Ruhezeiten oder Qualifikationen zu opfern. Die Engine kann Stundensätze, Zuschläge für Nächte, Wochenenden oder Feiertage und die Position jeder Person relativ zu ihren Überstundenschwellen gewichten, wenn sie unter gültigen Kandidaten wählt.

Ein konkreter Fall: Zwei Beschäftigte sind für eine Donnerstagabend-Schicht gleichermaßen geeignet. Bei der einen bleibt die Zuweisung innerhalb der Vertragsstunden; beim anderen kippt sie über die Wochenschwelle in den Zuschlagsbereich. Bei sonst gleichen Bedingungen wählt die Engine die erste — und über Dutzende Schichten pro Woche summieren sich diese kleinen Entscheidungen zu einem spürbaren Unterschied in der Lohnsumme.

Ebenso wichtig ist, die Summe vor der Freigabe zu sehen. Ein Planentwurf sollte mit den projizierten Personalkosten kommen, idealerweise aufgeschlüsselt nach Tag und Standort, damit die Führungskraft sie mit dem erwarteten Bedarf vergleichen und entscheiden kann, ob das Besetzungsniveau die Ausgabe wert ist — solange noch Zeit zum Anpassen bleibt.

Das Ergebnis der Engine ist ein Vorschlag, kein veröffentlichter Plan. Zwischen Erzeugung und Veröffentlichung liegt ein Prüfschritt, in dem die Führungskraft alles sieht, was der Solver weiß: offene Schichten mit dem Grund, warum sie nicht besetzt werden konnten, Warnungen zu Engstellen, projizierte Kosten und die Verteilung der unbeliebten Schichten.

Diesen Schritt gibt es, weil kein Modell des Betriebs vollständig ist. Die Engine weiß nicht, dass donnerstags im Morgengrauen eine Lieferung kommt, dass zwei Kollegen getrennt besser arbeiten oder dass sich die Prognose fürs Wochenende gerade geändert hat. Die Führungskraft legt dieses Urteil über einen Entwurf, der bereits alle formalen Regeln einhält — deutlich schneller, als bei null anzufangen.

Hier liegt auch die Verantwortung. Einen Dienstplan zu veröffentlichen ist ein betrieblicher und rechtlicher Akt des Unternehmens, für den eine Person einsteht. Gute KI-Planung verkürzt den Weg von „leerer Woche“ zu „prüfbarem Entwurf“; die menschliche Unterschrift am Ende ersetzt sie nicht. Und Teams vertrauen einem Plan mehr, wenn sie wissen, dass eine Führungskraft ihn freigegeben hat.

Die minimale Ausgangsbasis ist kleiner, als die meisten erwarten: Ihre Leute mit Rollen und Vertragsstunden, ihre Verfügbarkeit und genehmigten Abwesenheiten, eine Besetzungsvorlage je Wochentag und die Schichtvorlagen, die Sie tatsächlich nutzen — Öffnung, Mitte, Schluss und was Ihr Betrieb sonst an Mustern kennt. Ruhe- und Stundenregeln vervollständigen das Bild.

Fangen Sie klein an. Erzeugen Sie ein bis zwei Wochen für einen einzelnen Standort, vergleichen Sie den Entwurf ehrlich mit dem, was Sie von Hand gebaut hätten, und justieren Sie, was die Abweichungen offenlegen — meist eine fehlende Verfügbarkeit, eine nie erfasste Pflichtqualifikation oder ein Besetzungsziel, das bisher nur in einem Kopf existierte. Jede Korrektur verbessert den nächsten Entwurf, weil die Eingaben besser werden.

Wenn Sie diese Arbeitsweise ausprobieren möchten: ShiftCal bietet sie von Anfang bis Ende — beschreiben Sie Ihren Betrieb dem Assistenten im Chat, lassen Sie den Auto-Planer den Entwurf erzeugen und prüfen Sie Besetzung, Warnungen und Kosten vor der Veröffentlichung. Für Teams bis fünf Beschäftigte ist es kostenlos — genug, um den Ansatz an einer echten Woche mit eigenen Daten zu testen.