Kurzprofil
Über zehn Jahre IT-Betrieb und IT Service Management (ITSM), durchgehend bei einem Managed Service Provider. Der Weg führte vom System Engineer über die Geschäftsleitung zurück in die fachliche Tiefe: das war eine bewusste Entscheidung für Prozess- und Automatisierungsarbeit statt für Personalführung. Was seither entstanden ist, steht unten.
Ich arbeite nah am Betrieb. Die drei Beispiele auf dieser Seite sind nicht aus Projektbudgets entstanden, sondern aus Reibung im Tagesgeschäft: etwas dauerte zu lange, blieb liegen oder ging an die falschen Leute. Ich baue die Automatisierung, dokumentiere sie und übergebe sie so, dass sie ohne mich weiterläuft. Was ich baue, läuft auf Servern im Betrieb und nicht auf meinem Laptop: als Docker-Container, mit Login über Keycloak und AD-Gruppen, der Code in GitLab.
Ich messe, bevor ich baue. Für einen Dispatch-Assistenten zeigte die Messung an 1'684 Tickets, dass die verlangten 95 Prozent Treffsicherheit für die Ticketart nicht erreichbar sind. Der Assistent übernimmt deshalb nur die Zuweisung.
Ich entwickle täglich mit KI-Agenten (Claude Code) und prüfe jedes Ergebnis selbst, bevor es produktiv geht.
Management-Reports schreibt niemand mehr von Hand
Kontext: Service Desk eines Schweizer IT-Dienstleisters. Rund 950 Tickets pro Monat, rund 50 Agents, rund 270 Kundenorganisationen im Ticketsystem (Zammad).
Das Problem: Der wöchentliche Management-Report entstand von Hand. Rohdatenaufbereitung rund 15 Minuten, danach baute ein Kundenberater den fertigen Report daraus, 30 bis 60 Minuten. Pro Report also 45 bis 75 Minuten, verteilt auf zwei Rollen. Der Kundenreport für die Bilanzgespräche kostete zusätzlich 30 bis 45 Minuten pro Kunde. Reports entstanden spät, und die Frage, warum bestimmte Themen lange offen bleiben, kam erst in der Besprechung auf den Tisch.
Was ich gebaut habe: Eine Report-Suite auf der Zammad-API, die Management-, Kunden- und Agent-Reports als fertige Word-Dokumente erzeugt. Der Management-Report läuft wöchentlich, der Kundenreport ein- bis zweimal pro Monat.
Das Ergebnis:
- Management-Report: rund 6 Sekunden Laufzeit statt 45 bis 75 Minuten Handarbeit, rund 4,3 Mal pro Monat
- Kundenreport: rund 60 Sekunden Laufzeit statt 30 bis 45 Minuten pro Kunde
- Zusammen rund 3,75 bis 6,9 Stunden pro Monat, die nicht mehr in die Erstellung fliessen
- Der Report ist heute die Grundlage der Team-Besprechung, nicht mehr deren Nachbereitung
Womit: Zammad-API, JavaScript, automatisierte Word-Generierung.
Die Eskalation erreicht die Person mit Bereitschaft, nicht alle
Kontext: Incidents hoher Priorität im selben Service Desk. Wer gerade Bereitschaft hat, steht im Einsatzplan.
Das Problem: Jede Eskalationsmeldung ging an alle Bereitschaftsrollen gleichzeitig, in der Regel elf Personen. Auch jede Aktualisierung zum selben Incident löste eine neue Rundmeldung aus. Wer nicht zuständig war, wurde trotzdem gestört, und wer zuständig war, musste die eigene Meldung aus dem Rauschen fischen. Herabstufung, Entwarnung und Abschluss eines Incidents wurden gar nicht gemeldet.
Was ich gebaut habe: n8n-Workflows, die beim Incident die diensthabende Person aus dem Einsatzplan lesen und nur sie erwähnen, je nach Priorität eine oder zwei Personen. Aktualisierungen laufen als Antwort im selben Thread, ohne neue Erwähnung. Neu gemeldet werden auch Herabstufung, Entwarnung und Abschluss.
Das Ergebnis:
- In den 18 Tagen vor der Umstellung gab es 411 Personenbenachrichtigungen. Mit dem neuen Ablauf wären es für dieselben Meldungen unter 40 gewesen, ein Rückgang um mindestens 90 Prozent
- Die Meldung ist gezielter und zugleich vollständiger: Der ganze Verlauf eines Incidents steht in einem Thread
- Nach demselben Muster laufen die 2nd- und 3rd-Level-Eskalationen: rund 58 pro Monat, im Schnitt unter 4 Sekunden vom Tag im Ticket bis zur Meldung im Team-Chat
Ehrlich dazu: Die 411 sind gemessen. Die Zahl danach ist eine Obergrenze aus dem Aufbau, gerechnet so, als wäre jede Meldung ein eigener Incident. Gemessen werden Benachrichtigungen, nicht eingesparte Arbeitszeit.
Womit: n8n, Zammad-Trigger, Einsatzplan, Mattermost.
Wartungsüberwachung auf einen Blick statt Job für Job
Kontext: Wartungszyklen auf Server-Umgebungen von Kunden, ausgeführt über bestehende AWX-Jobs (Ansible). Die Update- und Wartungs-Playbooks selbst stammen nicht von mir, was ich gebaut habe, liegt darüber.
Das Problem: Ob eine Wartung sauber durchgelaufen war, liess sich nur Schritt für Schritt prüfen: Übersicht öffnen, pro Kunde die fehlgeschlagene Software suchen, dann im AWX-Job die genaue Fehlermeldung nachlesen. Das kostete rund 5 bis 10 Minuten pro Kunde. Welche Umgebungen überhaupt einen Wartungszyklus haben, stand in einer handgepflegten Liste.
Was ich gebaut habe: Ein Dashboard über den bestehenden AWX-Jobs. Es findet die Wartungszyklen selbst über die AWX-API, statt sie aus einer Liste zu lesen. Pro Kunde zeigt es fehlgeschlagene Updates mit Grund, verlinkt direkt in den Job und erzeugt per Klick ein Ticket für den Techniker. Ist zum selben Fehler schon ein Ticket offen, entsteht kein zweites.
Das Ergebnis:
- Die Prüfung, die vorher 5 bis 10 Minuten pro Kunde kostete, ist eine Übersicht auf einen Blick
- Neue Wartungszyklen erscheinen automatisch, die handgepflegte Liste entfällt
- Die Fehlschläge liessen sich auf vier eingegrenzte Ursachen zurückführen, ein grosser Teil davon auf zwei einzelne Vorlagen
- Das Dashboard läuft zentral auf einem Server im Betrieb und geht mit Dokumentation an die nächste zuständige Person
Womit: AWX-API, JavaScript (Node.js), Docker, Mattermost- und Ticketsystem-Anbindung.