SLA-Kalender entwerfen, die Schichtwechsel und Feiertage überstehen

Jede ITSM-Einführung hat einen Moment — meist etwa sechs Wochen nach Go-Live —, in dem der Service-Desk-Manager dem CIO den ersten quartalsweisen SLA-Report schickt und dabei still bemerkt, dass die Zahlen nicht stimmen. Nicht dramatisch — ein Prozentpunkt hier, eine widersprüchliche Verletzung dort — aber falsch. Das Muster ist immer dasselbe: Ein Vorfall, der am Freitag vor Kurban Bayramı um 16:55 Uhr eröffnet wurde, wird am Montagmorgen als verletzt markiert, obwohl in Wirklichkeit nie ein Techniker im Dienst war. Die SLA-Richtlinie lautete „9 bis 17 Uhr, Montag bis Freitag", der Kalender sagte, Ramazan Bayramı sei ein Mittwoch, und irgendwo zwischen diesen beiden Tatsachen fiel ein Ticket durchs Raster.

Der naive SLA-Kalender — der, mit dem jedes ITSM standardmäßig ausgeliefert wird — verursacht das. Er ist die häufigste Ursache für unzuverlässiges SLA-Reporting, und er lässt sich beheben. Dieser Beitrag geht das Kalendermodell durch, das wir verwenden und empfehlen, sowie die vier Kategorien von Komplikationen, die jeder produktive Kalender bewältigen muss.

Der naive Standard: „9 bis 17 Uhr, Montag bis Freitag"

Die meisten ITSM-Tools bieten von Haus aus einen Geschäftszeit-SLA-Kalender, der so aussieht:

• Montag bis Freitag, 09:00 bis 17:00 Uhr.
• Wochenenden ausgeschlossen.
• Eine kurze Liste „gesetzlicher Feiertage", die jemand jedes Jahr im Dezember aktualisieren muss.

Das funktioniert gut für ein kleines Unternehmen, dessen IT-Team komplett in derselben Stadt lebt, dieselben Stunden arbeitet und dieselben Feiertage hat. Überall sonst funktioniert es nicht. In der Praxis brechen mindestens vier Kategorien von Komplikationen dieses Modell innerhalb des ersten Jahres auf:

1. Bewegliche Feiertage — die meisten türkischen religiösen Feiertage folgen dem Mondkalender und verschieben sich jedes Jahr um 10–11 Tage nach vorn.
2. Schichtmodelle — ein 24/7-NOC kennt überhaupt keine „Geschäftszeiten".
3. Techniker-Abwesenheiten — die SLA-Uhr läuft weiter, unabhängig davon, ob der zugewiesene Techniker am Schreibtisch sitzt.
4. Standortübergreifender Betrieb — Istanbul öffnet um 09:00 Uhr Europe/Istanbul; London öffnet um 09:00 Uhr Europe/London; das P1-Ticket interessiert das nicht.

Wir gehen jede Kategorie einzeln durch.

1. Türkische Feiertage sind keine festen Daten

Der offizielle türkische Feiertagskalender kennt zwei Arten von Tagen:

• Feste weltliche Feiertage. Neujahr (1. Jan.), Tag der Nationalen Souveränität und des Kindes (23. Apr.), Tag der Arbeit und Solidarität (1. Mai), Gedenktag an Atatürk, Jugend- und Sporttag (19. Mai), Tag der Demokratie und nationalen Einheit (15. Jul.), Siegestag (30. Aug.), Tag der Republik (29. Okt.). Das sind einfache Datumsregeln.
• Bewegliche religiöse Feiertage. Ramazan Bayramı (3,5 Tage) und Kurban Bayramı (4,5 Tage) richten sich nach dem islamischen Mondkalender und verschieben sich jedes gregorianische Jahr. 2026 dauert Ramazan Bayramı vom 20. März (Halbtag) bis 23. März; 2027 beginnt er um den 10. März. Kurban Bayramı läuft 2026 vom 27. Mai (Halbtag) bis 31. Mai; 2027 um den 17. Mai.

Die Halbtagsregel ist wichtig. Der Ministerrat erklärt den Arbeitstag vor einem Bayram routinemäßig zum offiziellen Halbtag (arefe), an dem öffentliche Ämter um 13:00 Uhr schließen. In der Privatwirtschaft variiert das — manche folgen dem behördlichen Halbtag, manche arbeiten einen vollen Tag, manche schließen ganz. Welche Regelung Ihre Organisation auch verfolgt, der SLA-Kalender muss sie explizit abbilden. Ein Halbtag ist nicht „halbe Geschäftszeiten"; es ist ein bestimmtes Fenster, das zur üblichen Öffnungszeit beginnt und um 13:00 Uhr endet.

Darüber hinaus erklärt das türkische Präsidialamt gelegentlich ad hoc einen Feiertag — den Tag nach einem nationalen Fußballsieg, einen außerordentlichen Trauertag oder einen Brückentag zwischen einem festen Feiertag und einem Wochenende. Diese lassen sich in keinen Kalender vorab einpflegen. Das SLA-Kalendermodell muss es erlauben, mit 24 Stunden Vorlauf einen einmaligen Feiertag einzufügen, ohne die Historie neu zu berechnen.

Jeder SLA-Kalender, der einen erneuten Code-Deploy erfordert, um einen Feiertag hinzuzufügen, wird in seinem ersten Betriebsjahr scheitern. Der Kalender muss Daten sein, keine Konfiguration.

2. Schichtmodelle sind keine „Geschäftszeiten"

Ein 24/7-Network-Operations-Center kennt keine Geschäftszeiten. Es hat Schichten. Der SLA-Kalender für einen 24/7-Desk sollte sich vollständig von dem für einen Montag-bis-Freitag-Desk unterscheiden. Und in den meisten realen Organisationen existieren beide nebeneinander — der 24/7-NOC bearbeitet P1-Infrastrukturvorfälle, während ein 09-bis-18-Uhr-Desk L1-Anfragen bearbeitet. Für beide lässt sich nicht derselbe Kalender verwenden.

Die drei Schichtmuster, die wir am häufigsten modellieren:

• Standard-Tagschicht. Mo–Fr, 09:00 bis 18:00 Uhr, mit einem einstündigen Mittagsfenster, das die SLA-Uhr nicht pausiert (Techniker überschneiden sich beim Mittagessen absichtlich).
• Erweiterte Tagschicht. So–Do (für Desks im Finanzsektor, deren Geschäftswoche Sonntag bis Donnerstag läuft), 07:00 bis 21:00 Uhr.
• Rund-um-die-Uhr-Rotation. Drei-Schicht-24/7-Betrieb mit Übergaben um 08:00, 16:00 und 00:00 Uhr. Die SLA-Uhr läuft durchgehend; die Übergabe bleibt für den Kunden unsichtbar.

Das richtige Kalendermodell hängt an der SLA-Richtlinie, nicht am Servicedesk als Ganzes. Ein P1-Infrastrukturvorfall wird gegen den 24/7-Kalender gemessen; eine P4-Anfrage „bitte fügen Sie mich der Gruppenmailbox hinzu" wird gegen den 09-bis-18-Uhr-Kalender gemessen. Dieselbe Organisation, zwei Kalender, ticketweises Routing.

3. Techniker-Abwesenheit — die Diskussion, die niemand führen möchte

Hier die Frage, die früher oder später in einem SLA-Review-Meeting auftaucht: Ein P2-Ticket wurde am Freitagnachmittag Ayşe zugewiesen. Ayşe nahm den folgenden Montag als Jahresurlaub. Die SLA-Uhr lief weiter. Sie löste es am Dienstagmorgen, vier Geschäftsstunden nach ihrer Rückkehr, und der Report zeigt eine Verletzung. Ist das fair?

Zwei Denkschulen:

1. Die Perspektive des Kunden. Der Kunde weiß nicht und interessiert sich nicht dafür, dass Ayşe im Urlaub war. Die SLA verspricht eine Reaktion innerhalb von X Geschäftsstunden; die Reaktion kam zu spät; die SLA wurde verletzt. Grundursache: Das Routing hätte das Ticket bei Urlaubsantritt von Ayşe wegverlagern sollen.
2. Die Perspektive des Teams. Pausiert die Techniker-Abwesenheit die SLA nicht, sehen Servicedesks mit hoher Urlaubsnutzung künstlich schlechter aus als Desks, die Urlaub entmutigen. Das ist ein perverser Anreiz.

Unsere Empfehlung, und das Modell, das wir standardmäßig implementieren:

• Techniker-Abwesenheit pausiert die SLA auf dem zugewiesenen Ticket nicht.
• Stattdessen löst das Kalendersystem eine Neuzuweisung aus, sobald der Urlaub eines Technikers mit aktiven Tickets in seiner Warteschlange beginnt.
• Das neu zugewiesene Ticket behält seine ursprüngliche SLA und seine ursprüngliche Uhr.
• Der Manager erhält zum Zeitpunkt der Urlaubsanfrage eine Warnung, falls der Techniker Tickets hat, deren SLA-Ziel in den Urlaubszeitraum fällt.

Das erzwingt das richtige Verhalten: Urlaubsplanung ist eine Führungsverantwortung, und der SLA-Report spiegelt die Erfahrung des Kunden wider, nicht die interne Personaldisposition. Der Anreiz für das Team bleibt erhalten, weil die Tickets verschoben werden, nicht weil die Uhr pausiert wird.

4. Ruhezeiten pro Benutzer

Ein separates, aber verwandtes Konzept: Manche Organisationen möchten einem Kunden versprechen „Ihr Ticket erhält innerhalb von vier Geschäftsstunden eine Antwort" und gleichzeitig dem Techniker versprechen „Sie erhalten zwischen 22:00 und 07:00 Uhr keine Push-Benachrichtigungen, selbst wenn der SLA-Kalender läuft." Modernes ITSM muss diese Konzepte getrennt modellieren.

Die Unterscheidung:

• SLA-Kalender = das Versprechen des Unternehmens gegenüber dem Kunden. Bestimmt, wann die Uhr läuft.
• Benachrichtigungskalender pro Benutzer = die persönliche Push-/E-Mail-Präferenz des Technikers. Bestimmt, ob das Telefon summt.

Diese werden kollidieren. Ein um 03:00 Uhr eröffneter P1-Vorfall auf einem 24/7-Kalender ist eine echte Verletzung, wenn ihn niemand aufnimmt. Sind bei allen Bereitschaftstechnikern die Benachrichtigungen stummgeschaltet, bleibt das Ticket bis 07:00 Uhr liegen, und die Vier-Stunden-Uhr des Kunden läuft ab. Die Antwort besteht nicht darin, beide Konzepte zusammenzulegen; sie besteht darin, die Bereitschaftsrotation als eigenständigen Kalender zu modellieren, der persönliche Ruhezeiten während des Bereitschaftsfensters außer Kraft setzt.

5. Standortübergreifender Betrieb und Zeitzonen

Eine Organisation mit Standorten in Istanbul, Ankara und London hat keinen einzigen Geschäftstag — sie hat drei einander überlappende. Wird der SLA-Kalender in der lokalen Zeit des Servers gespeichert, brechen Sommerzeitumstellungen das Reporting zweimal im Jahr still und heimlich. Wird er in UTC gespeichert, scheinen sich die Geschäftszeiten für Benutzer in anderen Zeitzonen zu verschieben, sofern die Oberfläche nicht sorgfältig gestaltet ist.

Unsere Regel: Alle Kalendereinträge werden in UTC gespeichert, und jeder Kalender trägt seine eigene Anzeigezeitzone. Die SLA-Berechnung läuft gegen UTC; die Oberfläche rendert gegen die Zeitzone des Kalenders. Benutzer in einer anderen Zeitzone sehen weiterhin die korrekte Öffnungszeit für den Kalender, den sie betrachten.

Ein P1, das um 08:55 Uhr Europe/Istanbul gegen einen Istanbul-Kalender gemeldet wird, liegt innerhalb der Geschäftszeiten. Dasselbe Ticket, um 08:55 Uhr Europe/London gegen den London-Kalender gemeldet, liegt noch nicht innerhalb der Geschäftszeiten (London öffnet um 09:00 Uhr GMT = 11:00 Uhr Europe/Istanbul im Winter, 12:00 Uhr im Sommer). Das Routing entscheidet, welcher Kalender gilt.

6. Notfall-Änderungsfenster

Das Change Management fügt eine weitere Komplikation hinzu. Eine Notfalländerung an einem Produktivsystem kann erfordern, dass der Servicedesk die SLA für jedes Ticket pausiert, dessen Lösung von diesem System abhängt. Dies ist der einzige legitime Fall für eine von einem Manager initiierte SLA-Aussetzung.

Die Regel, die wir implementieren:

• Eine Notfalländerung ist ein eigenständiges Objekt mit einem Start- und Endfenster.
• Jedes Ticket, das als abhängig von CI X markiert ist, wobei CI X von der Änderung betroffen ist, hat seine SLA-Uhr für die Dauer des Änderungsfensters pausiert.
• Die Pause wird mit der Change-ID protokolliert, sodass der Audit-Trail genau zeigt, welches Ticket für welche Änderung pausiert wurde.
• Wenn die Änderung geschlossen wird, werden alle pausierten Tickets automatisch fortgesetzt.

Dies dient nicht dazu, Verletzungen zu verschleiern. Es bildet ab, dass eine Lösung während eines kontrollierten Ausfalls tatsächlich unmöglich war.

Alles zusammenfügen

Das vollständige Kalendermodell sieht auf Entitätsebene so aus:

Das sind getrennte Belange, die auf vorhersehbare Weise interagieren. Die SLA-Berechnung liest WorkCalendar plus WorkCalendarHoliday plus WorkCalendarOverride plus SlaPauseWindow. Die Benachrichtigungsschicht liest OnCallRotation plus UserSilentHours. Das Reporting kann nach Kalender, nach Pausengrund oder nach Verletzungsursache aufschlüsseln — weil jede Information gespeichert wird, nicht abgeleitet.

Warum das für das Reporting wichtig ist

Ein gut entworfener Kalender beantwortet die Frage, die in der zweiten oder dritten Quartalsprüfung immer wieder auftaucht: Warum wurde Ticket #4728 verletzt? Die Antwort muss mehr sein als „es war eben so." Idealerweise zeigt das Öffnen des Tickets das SLA-Panel, und dieses Panel zeigt genau, welcher Kalender angewendet wurde, welche Fenster offen waren, welche Pausen aufgetreten sind und wie viele Geschäftsminuten bis zur Reaktion vergangen sind. Wenn die Pause änderungsbedingt war, ist die Change-ID verlinkt. War der Techniker im Urlaub und das Ticket wurde neu zugewiesen, zeigt sich die Neuzuweisung in der Timeline.

Der Sinn dieser korrekten Modellierung ist kein Perfektionismus. Es geht darum, dass SLA-Reports genau geprüft werden. Fragt der CIO, warum die P2-Compliance-Zahl gesunken ist, hat das Operations-Team entweder eine belastbare Antwort samt den konkreten Tickets, Kalendern und Pausen, die die Veränderung verursacht haben — oder es hat sie nicht, und der SLA-Report wird zum Objekt des Zweifels statt zum Werkzeug.

Die LinaDesk-Implementierung, kurz erklärt

LinaDesk modelliert jede der Entitäten aus obiger Tabelle als eigenständiges Domain-Aggregat. WorkCalendar ist der Ankerpunkt; WorkCalendarHoliday und WorkCalendarOverride sind untergeordnete Datensätze; SlaPolicy referenziert eine WorkCalendarId. Die SLA-Berechnung ist eine reine Funktion der Statusübergänge eines Tickets und der zu jedem Übergang sichtbaren Kalenderentitäten. Da Pausen als explizite Datensätze gespeichert werden, liefert das erneute Durchrechnen der SLA-Berechnung für ein beliebiges historisches Ticket heute dieselbe Antwort wie am Tag seiner Schließung — genau das, was Audit-Teams erwarten, und das trifft auf ITSM-Systeme, die gegen den aktuellen Kalender neu berechnen, nicht zu.

Das Ramazan-Bayramı-Ticket vom Anfang dieses Beitrags ist in diesem Modell keine Verletzung. Das Ticket wird am letzten Geschäftstag vor Bayram um 16:55 Uhr eröffnet. Der WorkCalendarHoliday für die vier Bayram-Tage setzt den Kalender auf geschlossen. Die SLA-Uhr tickt an diesem Freitag nur die verbleibenden fünf Geschäftsminuten bis 17:00 Uhr und setzt sich dann um 09:00 Uhr am ersten Geschäftstag nach Bayram fort. Das Reaktionsfenster bleibt erhalten.

Weiterführende Artikel

• Warum On-Premise-ITSM 2026 wieder im Aufwind ist
• Migration von ManageEngine Service Desk Plus — ein Praxisleitfaden
• LinaDesk vs. ServiceNow, ManageEngine, Freshservice — Vergleichstabelle
• LinaDesk Sicherheit & Compliance