So–Do-Team, Mo–Fr-Lieferanten: SLA-Ziele festlegen

Wenn Ihr Service Desk in Riad, Doha, Kuwait-Stadt, Maskat oder Manama sitzt, läuft Ihre Woche von Sonntag bis Donnerstag. Ihr Cloud-Anbieter, Ihr ERP-Partner und Ihr Hardware-Wartungsdienstleister arbeiten mit ziemlicher Sicherheit von Montag bis Freitag.

Auf dem Papier arbeiten beide Seiten fünf Tage pro Woche. In der Praxis teilen Sie sich vier Tage, und an jedem davon weniger Stunden, als Sie denken. Die meisten SLA-Dokumente in der Region sind so geschrieben, als gäbe es diese Lücke nicht. Dann verletzt ein lieferantenabhängiger Incident, der an einem Donnerstagnachmittag erfasst wurde, am Montag sein Ziel, und niemand kann erklären, warum.

Das ist keine Kuriosität der Terminplanung. Es entscheidet darüber, ob die Ziele, die Sie dem Fachbereich zusagen, überhaupt erreichbar sind.

Die Woche, die Sie tatsächlich haben

Legen Sie die beiden Kalender nebeneinander, und es gibt vier Arten von Tagen:

Das sind zwei Tage pro Woche, an denen nur eine Seite arbeitet. Und die Stunden schrumpfen weiter, sobald Zeitzonen ins Spiel kommen.

Ein Rechenbeispiel (zur Veranschaulichung, kein Benchmark). Ihr Service Desk arbeitet 08:00–17:00 Ortszeit Riad (UTC+3). Ein britischer Lieferant arbeitet 09:00–17:30 Londoner Zeit, im Winter also 12:00–20:30 in Riad. Die Überschneidung liegt bei 12:00–17:00: fünf Stunden pro Tag, vier Tage pro Woche. Das sind 20 Stunden echte gemeinsame Zeit in einer Woche, in der Ihr Service Desk 45 Stunden geöffnet ist. In der britischen Sommerzeit wächst die Überschneidung um eine Stunde. Bei einem Lieferanten in Indien (UTC+5:30) verschiebt sich die Überschneidung stattdessen auf Ihren Vormittag.

Spielen Sie nun einen Incident vom Donnerstag durch. Ein P3, für den der Lieferant gebraucht wird, wird am Donnerstag um 15:00 erfasst. Ihrem Service Desk bleiben zwei Stunden bis zum Wochenende. Der Lieferant arbeitet am Freitag, aber auf Ihrer Seite ist niemand da, um einen Fix zu testen oder eine Frage zu beantworten. Am Sonntag hat der Lieferant frei. Gemeinsame Zeit gibt es erst wieder am Montag ab 12:00. Bis dahin ist Ihre Geschäftszeiten-Uhr 15 Stunden gelaufen (zwei am Donnerstag, neun am Sonntag und vier am Montagvormittag), und die beiden Seiten haben davon gerade einmal zwei Stunden zusammengearbeitet.

Wenn Ihr P3-Lösungsziel zwei Geschäftstage beträgt (18 Stunden in diesem Kalender), wird es am Montag um 15:00 verletzt, drei Stunden nachdem beide Seiten wieder gemeinsam arbeiten. Realistisch war das Ziel schon am Donnerstag um 17:00 verloren.

Warum die üblichen Lösungen es schlimmer machen

Das SLA im Kalender des Lieferanten messen. Manche Teams stellen die Service-Desk-Uhr stillschweigend auf Montag–Freitag um, passend zum Lieferanten. Jetzt zählt Ihr Sonntag nicht mehr, und Ihre Anwender, die sonntags arbeiten, bekommen ein Ziel, das einen ihrer Arbeitstage ignoriert. Das SLA existiert für den Kunden, also läuft es im Kalender des Kunden.

Die Uhr für „Warten auf Lieferant“ anhalten. Die meisten ITSM-Tools erlauben es, ein SLA zu pausieren, während ein Incident auf einen Dritten wartet. Als Standard eingesetzt, lässt das Ihre Erfüllungsquote gut aussehen, während der Anwender vier Tage wartet. Eine Pause ist fair, wenn Sie auf den Anwender warten, denn er kontrolliert diese Zeit. Das Warten auf Ihren eigenen Lieferanten ist Ihr Problem, nicht seines. Wenn Sie für Lieferanten doch pausieren, weisen Sie die pausierten Stunden neben der Erfüllungsquote aus, sonst ist die Quote Fiktion.

„Nächster Geschäftstag“ in den Underpinning Contract übernehmen. Für einen Lieferanten ist der nächste Geschäftstag nach Donnerstag der Freitag, an dem Ihr Service Desk geschlossen ist. Der Vertrag ist erfüllt, und für den Fachbereich ist nichts passiert.

Regeln, die halten

Aus meiner Erfahrung in der Leitung von IT-Betrieben im Nahen Osten und in Afrika, bei der ich die SLA-Erfüllung in fünf regulierten Branchen bei 98–99% gehalten habe: Dies sind die Regeln, die ich in jedes Set aus SLAs und OLAs schreiben würde, wenn die Arbeitswochen nicht zusammenpassen.

1. Eine Kundenuhr, in Ihrem Kalender. Messen Sie jedes Service-Desk-SLA in Ihrer eigenen Arbeitswoche, mit Ihren Feiertagen und Ramadan-Zeiten. Biegen Sie es nicht für den Lieferanten zurecht.

2. Ziele nach Abhängigkeit aufteilen, nicht nur nach Priorität. Ein Incident, den Ihr Team allein lösen kann, und einer, für den ein Lieferant nötig ist, sind unterschiedliche Versprechen. Geben Sie lieferantenabhängigen P3- und P4-Incidents ein eigenes Lösungsziel, und leiten Sie es aus den gemeinsamen Stunden Ihrer Woche ab, nicht aus den Kalenderstunden.

3. Die Pflichten des Lieferanten in Ihrer Zeit festschreiben. Jeder Underpinning Contract nennt Reaktions- und Lösungsziele in Ihren Arbeitszeiten und Ihrer Zeitzone oder sagt klar, welche Ihrer Tage er nicht abdeckt. Wenn Ihnen der Sonntag wichtig ist, bezahlen Sie für eine Sonntagsabdeckung, oder akzeptieren Sie, dass der Sonntag für lieferantenabhängige Arbeit ein toter Tag ist, und setzen Sie Ihre Ziele entsprechend.

4. Den Freitag nutzbar machen. Alles Lieferantenabhängige, das am Donnerstagmittag noch offen ist, geht an den Lieferanten, bevor Ihr Service Desk schließt, mit allem, was er braucht, um allein zu arbeiten: Logs, Screenshots, Schritte zur Reproduktion, ein namentlich benannter Ansprechpartner und was er ohne Rückfrage tun darf. Ein Lieferant mit einem vollständigen Übergabepaket kann den Freitag nutzen. Ein Lieferant, der auf eine Antwort wartet, kann es nicht.

5. P1 läuft auf beiden Seiten 24 × 7, und prüfen Sie, dass das wirklich so ist. Vergewissern Sie sich, dass der kritische Support des Lieferanten dessen Wochenende abdeckt und dass Ihr Rufbereitschaftsplan Freitag und Samstag abdeckt. Ein P1 in dem Zeitfenster, in dem eine Seite schläft, ist genau der Punkt, an dem Major Incidents das Vertrauen des Fachbereichs verspielen (siehe warum ein P1 ein Vertrauensereignis ist).

6. Beide Feiertagskalender hinterlegen. Eid al-Fitr, Eid al-Adha und der Nationalfeiertag fallen nicht mit Weihnachten, Ostern oder Diwali zusammen. Jeder davon ist ein Tag, an dem eine Seite fehlt. Laden Sie Ihre Feiertage in Ihren SLA-Zeitplan und die des Lieferanten in Ihren OLA-Review, und planen Sie die Abdeckung für beide an derselben Stelle.

7. Die Überschneidung in jedem Service Review prüfen. Weisen Sie lieferantenabhängige Incidents getrennt aus: wie viele es sind, wie lange sie gewartet haben und wie viele an einem Donnerstag erfasst wurden. Wenn Donnerstags-Incidents ihr Ziel weit häufiger verletzen als der Rest, muss Ihr Übergabepaket oder Ihr Vertrag nachgebessert werden, nicht Ihre Techniker.

Ein Hinweis zu den VAE: Die meisten Teams im Privatsektor arbeiten dort inzwischen Montag–Freitag und sind damit im Takt mit europäischen Lieferanten. Die Lücke verlagert sich stattdessen ins Unternehmen hinein. Ein Hub in Dubai, der Anwender in Saudi-Arabien oder Katar unterstützt, hat dieselbe viertägige Überschneidung mit seinen eigenen Kunden.

Bevor Sie das SLA unterzeichnen: eine Checkliste

• Die SLA-Uhr läuft in der Arbeitswoche des Kunden, mit seinen Feiertagen und Ramadan-Zeiten.
• Lieferantenabhängige Incidents haben ein eigenes Lösungsziel, abgeleitet aus den gemeinsamen Stunden.
• Jeder Underpinning Contract nennt seine Ziele in Ihrer Zeitzone und Arbeitswoche.
• Die Sonntagsabdeckung steht entweder im Vertrag oder ist bewusst von Ihren Zielen ausgenommen.
• Es gibt ein Übergabepaket für Donnerstag, und mit dem Lieferanten ist vereinbart, was er ohne Sie tun darf.
• Der P1-Support des Lieferanten deckt dessen Wochenende ab. Ihre Rufbereitschaft deckt Freitag und Samstag ab.
• Die Feiertage beider Seiten stehen im Kalender und werden jedes Jahr überprüft.
• Pausen für „Warten auf Lieferant“ werden, falls Sie sie nutzen, zusammen mit der Erfüllungsquote ausgewiesen.
• Service Reviews weisen lieferantenabhängige und donnerstags erfasste Incidents getrennt aus.

Prüfen Sie Ihre eigenen Zahlen

Richten Sie die Arbeitswoche Ihres Teams im kostenlosen GCC-Geschäftszeitenkalender ein. Die Vorlagen für Saudi-Arabien, Katar, Kuwait, Oman und Bahrain sind bereits auf Sonntag–Donnerstag eingestellt. Legen Sie dann die Woche des Lieferanten als benutzerdefinierten Kalender an, mit seinen Zeiten in Ihre Zeitzone umgerechnet, und exportieren Sie beide. Vergleichen Sie sie Tag für Tag, um Ihre gemeinsamen Stunden zu zählen.

Nehmen Sie dann einen lieferantenabhängigen Incident, der sein Ziel verletzt hat, und spielen Sie ihn in der SLA-Uhr nach. Suchen Sie den Moment, in dem er wirklich verloren war. Bei nicht zusammenpassenden Wochen ist das oft ein Donnerstagnachmittag, der bis Montag niemandem aufgefallen ist. Beide Tools laufen in Ihrem Browser. Nichts, was Sie eingeben, verlässt Ihren Rechner.