Der IT-Ticket-Prozess als fertiges Rechenmodell

Eingang: 24 000 Tickets im Jahr, also rund 96 an einem Arbeitstag, mit einer Tagesstreuung von 28 % und einem Spitzenfaktor von 1,35 an 8 % der Tage. Montage, Rollouts, Störungen.

Die Spalte „Anteil“ ist der Grund, warum diese Vorlage anders zu lesen ist als die übrigen: Das zweite Level sieht nur ein Drittel der Tickets. Rechnet man seine Auslastung gegen die volle Menge, kommt man auf 155 % und hält einen Schritt für überlastet, der bei 57 % liegt.

Der entscheidende Befund. Die Engpasswahrscheinlichkeit je Schritt aus 20 000 Läufen:

Die Spalte summiert sich auf 100 %: Je Lauf wird genau ein bindender Schritt gezählt, der mit der höchsten Auslastung an diesem Tag.

Das zweite Level, das im Haus als Grund für lange Laufzeiten gilt, ist es in 14 % der Läufe. Der Servicedesk, die Stelle, an der ein Ticket nur aufgenommen wird, fünf bis zehn Minuten lang, ist es in 75 %. Der Prozess verliert die Zeit vor der Arbeit, nicht in ihr.

Und das ist der Punkt, an dem eine Tabelle versagt: Fünf Minuten je Ticket sind unauffällig. 96 mal fünf bis zehn Minuten sind es nicht.

1. Tickets pro Arbeitstag. Tickets des letzten Jahres ÷ Arbeitstage. Steht im Helpdesk-Bericht, und zwar dort, wo auch Doppel- und Sammeltickets gezählt werden. Nehmen Sie dieselbe Definition, die Sie später beim Nachmessen verwenden.
2. Spitzenfaktor. Wie viele Tickets kommen am stärksten Tag gegenüber einem normalen? Montag, der Tag nach einem Rollout, der Tag einer Störung. Faktor 1,3 bis 2 ist üblich. Ohne diesen Wert rechnen Sie einen Servicedesk, der nie unter Last steht, und Last ist bei Tickets der Normalzustand.
3. Personen im Servicedesk und ihre Stunden für Triage. Nicht die Kopfzahl des Teams. Wer nebenbei Anrufe annimmt, hat keine acht Stunden für Erfassung.
4. Bearbeitungsspanne der Triage. Unteres und oberes Ende. Fünf Minuten für ein Passwort, zwanzig für eine Störungsmeldung, die erst rekonstruiert werden muss. Genau diese Spanne treibt die Wartezeit.
5. Anteil, der sofort gelöst wird. In der Vorlage 65 zu 35. Diese Zahl steht in jedem Helpdesk-Bericht als „First Contact Resolution“ und ist die einzige, die Sie wirklich messen können. Sie verschiebt Last zwischen den Zweigen, nicht davor.
6. Vollkostensätze je Rolle. Bruttogehalt × 1,5 bis 1,8, geteilt durch rund 1 500 produktive Stunden im Jahr. Bei 24 000 Vorgängen im Jahr wirkt hier jeder Euro Satzunterschied stark; ein naiver Satz aus Gehalt ÷ 2 080 Stunden macht die Euro-Aussage später angreifbar.

Gegenprobe, bevor Sie rechnen: Zählen Sie die offenen Tickets im System und teilen Sie durch die Tickets, die Sie an einem Tag schliessen (Little's Law). Kommt Ihre bekannte Laufzeit heraus, ist das Modell brauchbar. Weicht es stark ab, fehlt eine Warteschlange, bei Tickets fast immer der Status „wartet auf Rückmeldung des Anwenders“.

Was die Vorlage nicht enthält. Die Durchlaufzeit ist Bearbeitung plus Warteschlange in Arbeitstagen. Priorisierung ist nicht modelliert: Das Modell arbeitet in der Reihenfolge des Eingangs. Wer eine echte Priorisierung hat, bildet sie als zweiten Zweig mit eigener Kapazität ab; sonst rechnet das Modell für dringende Tickets zu langsam und für den Rest zu schnell. Ebenso wenig enthalten: Ruhezeiten, in denen ein Ticket auf den Anwender wartet.

Hebel 1. Ein Formular am Eingang. Pflichtfelder für Gerät, Anwendung, Fehlerbild und Dringlichkeit. Die Triage fällt von 5–10 auf 3–6 Minuten, weil das Rekonstruieren entfällt. Wirkung: P90 der Durchlaufzeit von 4,9 auf 0,22 Arbeitstage, Auslastung am Spitzentag von 129 % auf 77 %. Der billigste Hebel im Feld, und der einzige, der ohne Personal auskommt.

Hebel 2. Eine dritte Person am Servicedesk. Wirkt ebenfalls deutlich (0,38 Tage), kostet aber eine Stelle. Das Verhältnis zu Hebel 1 ist die eigentliche Aussage dieser Tabelle.

Hebel 3. Wissensdatenbank, die 20 % der Tickets vorher abfängt. Weniger Tickets ist immer besser, aber es löst den Engpass nicht: Die Triage bleibt in 75 % der Läufe der bindende Schritt, ihre Auslastung fällt nur von 129 % auf 103 % am Spitzentag. Ein Fünftel weniger Menge hebt einen Schritt gerade eben über die Linie, mehr nicht.

Hebel 4. Mehr Tickets im ersten Level lösen. Der interessanteste Null-Befund. Die First-Contact-Resolution von 65 auf 75 % zu heben ist die Standardempfehlung im Support, und sie wirkt: Die Arbeitszeit je Ticket fällt von 28,82 € auf 25,34 €, weil teure zweite-Level-Minuten durch billigere erste-Level-Minuten ersetzt werden. Die Durchlaufzeit ändert sich dabei nicht, sie steigt sogar minimal auf 5,0 Tage. Der Hebel spart Geld, keine Zeit. Wer ihn als Laufzeitmassnahme verkauft, verkauft das Falsche an derselben richtigen Massnahme.

Rechnen Sie die vier einzeln und sortieren Sie nach Wirkung je Aufwand. Hebel 1 ist ein Formular, Hebel 2 eine Stelle, und im Modell liegen sie 0,16 Tage auseinander.

Wie aus 20 000 Läufen eine Prozentzahl je Schritt wird, steht im Artikel Monte-Carlo-Simulation für Prozesse; warum schon 85 % Auslastung zu viel sind, in Engpass berechnen.

Nach Ist-Stand sichern, einem geänderten Hebel und einem zweiten Lauf gibt der Vergleich aus:

• Durchlaufzeit vorher/nachher als P50 und P90. Eine Service-Zusage wird gegen das P90 gegeben, nicht gegen den Median. Genau darin unterscheidet sich eine SLA-Aussage von einer Durchschnittsaussage: Der Median sagt 0,08 Tage, und trotzdem reisst die Zusage an jedem zehnten Tag.
• Auslastung je Schritt am Spitzentag und der neue Engpass nach der Massnahme. In diesem Modell wandert er bei zwei von vier Hebeln zum ersten Level.
• Durchsatz als Tickets je Woche gegen die ankommenden: 455 von 480 im Ist-Stand. Die Differenz ist der Rückstau, den der Servicedesk jede Woche neu aufbaut.
• Arbeitszeitkosten je Ticket und im Jahr, aus Mengen, Zeiten und Vollkostensätzen. Bei 24 000 Vorgängen wirkt hier jeder Cent, die Vorlage rechnet mit 28,82 € je Ticket.
• Die Annahmenliste mit jeder geschätzten Eingabe. Der Satz „Priorisierung und Ruhezeiten sind nicht modelliert“ nimmt der schärfsten Rückfrage die Spitze, bevor sie gestellt wird.

Ausgegeben wird das als zwei PDF: Angebot für den Entscheider, Dokumentation für die Nachvollziehbarkeit, mit Ihrem Briefkopf, wenn Sie einen hinterlegt haben.

Dieselbe Vorlage, zwei Fragen. Diese Seite beantwortet die Rechenfrage: woher die 75 % kommen und warum ein Fünftel weniger Tickets den Engpass nicht löst. Die andere Frage (was würde man empfehlen, und was kostet ein Ticket, das liegen bleibt) gehört zur Methode und nicht zum Werkzeug. Sie steht drüben im Analysen-Archiv von Flowrefy, zusammen mit dem Vorgehen, aus dem diese Vorlagen entstanden sind. Ein Datensatz, zwei Fragen, zwei Publika.

• Die Auftragsabwicklung läuft von der Bestellung bis zur Auftragsbestätigung. Der Fall mit einer geteilten Rolle: zwei Schritte, die einzeln bequem aussehen, sind der Nachmittag derselben Person.
• Der Angebotsprozess ist der Fall, in dem Durchlaufzeit auf Umsatz wirkt statt auf Kosten.
• Die Rechnungsfreigabe ist der Volatilitätsfall: im Mittel unter der Kapazität, am Monatsende darüber.
• Bei der Reklamation sitzt der Engpass ausserhalb des Hauses, und die ehrliche Empfehlung lautet deshalb nicht „automatisieren“.
• Das Mitarbeiter-Onboarding hat wenig Volumen und viele Beteiligte, und ein Schritt bindet 86 % der Läufe.
• Das IT-Ticket ist diese Seite.

Jede Vorlage öffnet sich im Willkommensfenster über Vorlagen ansehen. Beim ersten Mal lohnt es sich, eine zu öffnen, bevor Sie ein eigenes Modell beginnen. Man baut sonst zu fein.