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 fand faktisch nicht statt. Ich baue die Automatisierung, dokumentiere sie und übergebe sie so, dass sie ohne mich weiterläuft.
Zum Arbeiten selbst nutze ich ein eigenes, dateibasiertes Wissens- und Automatisierungssystem mit Obsidian und Claude Code.
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.
Eskalationen in Sekunden statt über Zuruf
Kontext: 2nd- und 3rd-Level-Eskalationen im selben Service Desk. Eskaliert wird über einen Tag im Ticket, informiert werden muss das zuständige Team.
Das Problem: Ein gesetzter Tag ist nur dann eine Eskalation, wenn ihn jemand sieht. Die Weitergabe hing an Aufmerksamkeit und Zuruf. Wer gerade nicht ins Ticketsystem schaute, erfuhr von der Eskalation später oder gar nicht.
Was ich gebaut habe: Zwei n8n-Workflows, je einer für 2nd und 3rd Level. Sie reagieren auf den Tag im Ticket und melden die Eskalation automatisch in den Team-Chat (Mattermost), mit Link direkt ins Ticket.
Das Ergebnis:
- Rund 58 Eskalationen pro Monat laufen über die beiden Workflows
- Vom Tag im Ticket bis zur Meldung im Team-Chat vergehen im Schnitt unter 4 Sekunden
- Die Eskalation ist damit nicht mehr davon abhängig, dass jemand zur richtigen Zeit hinschaut
Womit: n8n, Zammad-Trigger, Mattermost-Webhooks.
Die Meldung, die den Fehler anzeigen sollte, war selbst defekt
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 ein Wartungszyklus hinterlegt war und ob er fehlerfrei durchlief, stand nur verstreut in AWX-Job-Logs und wurde über eine handgepflegte Liste nachgehalten. Genau die Meldung, die einen Fehlschlag hätte anzeigen sollen, war selbst unzuverlässig. Dadurch blieb der tatsächliche Zustand über Jahre unsichtbar, unabhängig davon, wie viel Zeit jemand in die manuelle Prüfung gesteckt hätte.
Was ich gebaut habe: Das Dashboard von der handgepflegten Liste auf Auto-Discovery aus der AWX-API umgestellt. Die Zahlen sind damit nicht mehr geschätzt, sondern direkt aus dem System abgeleitet: pro Umgebung sichtbar, ob ein Wartungszyklus hinterlegt ist und ob er fehlerfrei durchläuft, mit Direktlink in den jeweiligen AWX-Job und einer Funktion, die daraus per Klick ein Ticket für den Techniker erzeugt.
Das Ergebnis:
- Rund drei Viertel der Produktions-Server-Umgebungen haben einen Wartungszyklus hinterlegt (41 von 54)
- Von den eingerichteten Wartungen laufen nur 17 von 64 tatsächlich fehlerfrei durch, ein Zustand, der vorher niemand sichtbar war
- Die Fehlschläge liessen sich auf vier eingegrenzte Ursachen zurückführen, ein grosser Teil davon auf zwei einzelne Vorlagen
- Werkzeug und Befund gehen als dokumentierte Übergabe mit eingegrenzter Ursachenliste an die nächste zuständige Person
Ehrlich dazu: Die Quote gilt für das Aufbewahrungsfenster von AWX, nicht für die gesamte Historie. Und eine fehlende Wartung ist nicht automatisch ein Versäumnis, weil Zyklen erst von Hand eingetragen werden, sobald sie mit dem Kunden vereinbart sind.
Womit: AWX-API, JavaScript, Mattermost- und Ticketsystem-Anbindung.