Die Projektdokumentation eines Automobil-Finanzdienstleisters basierte auf mehr als 100 Ergebnistypen, verteilt über mehr als zehn Projektrollen, mehrere Modellvarianten und unterschiedliche Projektphasen. Die
Manchmal braucht es einen externen Blick, um das Offensichtliche zu sehen. Die IT-Security Unternehmung – ein erfahrener Managed Security Service Provider mit über 30 Jahren Marktpräsenz, ISO 27001/9001/14001-Zertifizierungen und echtem 24x7-Betrieb für Kunden aus Industrie, Behörden und Finanzwesen – beriet ihre Kunden täglich darin, Sicherheitsvorfälle strukturiert zu bewältigen. Intern? Lief alles per E-Mail.
Das war kein böser Wille, sondern gewachsene Realität. Und es war schlicht nicht mehr tragbar.
Ziel des Projekts: Einführung eines zentralen ITSM-Tools als Greenfield-Implementierung – On-Premises, vollständig selbst gehostet, ITIL-konform, ISO 27001-konform und mit einer skalierbaren API-Architektur, die zukünftige Enterprise-Integrationen von Anfang an möglich macht.
Ausgangssituation: Wenn der Schuster die schlechtesten Schuhe trägt
Das Unternehmen berät Kunden in Security Operations, entwickelt Monitoring-Konzepte auf Basis des NIST-Frameworks und betreibt Managed Services rund um die Uhr. Nach außen: strukturiert, zertifiziert, professionell. Nach innen sah es anders aus.
Anfragen kamen per E-Mail, per Telefon – manchmal auch einfach per Zuruf quer durch das Büro. Wer sich darum kümmerte, hing weniger von definierten Zuständigkeiten ab als davon, wer gerade greifbar war. Prioritäten entstanden nicht durch Kriterien, sondern durch den lautesten Absender.
Die Vorabanalyse brachte ein ernüchterndes Bild zutage: Von täglich rund 800 eingehenden Anfragen waren rund 45 Prozent wiederkehrende Standardprobleme und 15 Prozent interne IT-Themen ohne Kundenbezug. Die verbleibenden 40 Prozent – geschäftskritische, SLA-relevante Kunden-Incidents – gingen im allgemeinen Rauschen unter und litten unter unklaren Reaktionszeiten.
Der finale Auslöser kam von außen: Die anstehende ISO 27001-Rezertifizierung machte den Handlungsbedarf unmissverständlich klar. Ein ISMS verlangt dokumentierte Prozesse, nachvollziehbare Vorfälle und messbare Reaktionszeiten. All das ließ sich mit dem bisherigen Ansatz nicht belegen.
Die konkreten Schwachstellen auf einen Blick:
- Keine Priorisierung eingehender Tickets, keine SLA-Klassen, keine Wissensdatenbank
- Keine Trennung zwischen internen IT-Anfragen und kundenbezogenen Vorfällen
- Expertise war personengebunden – fiel jemand aus, fehlte das Wissen
- ISO 27001-Rezertifizierung erforderte erstmals einen dokumentierten Incident-Response-Nachweis
Die Toolentscheidung – Kein Kompromiss bei Datensouveränität
Nach einer strukturierten Marktevaluation – geprüft wurden OTRS-basierte Lösungen sowie verschiedene SaaS-Angebote – war eine Grundbedingung nicht verhandelbar: das System musste On-Premises laufen.
Als MSSP mit hochsensiblen Kundendaten ist Datensouveränität kein optionaler Komfort, sondern ein vertragliches und regulatorisches Muss. Eine Cloud-Lösung schied damit aus. Das gewählte Tool – eine On-Premises-Open-Source-Lösung – läuft vollständig auf einem eigenen Linux-Stack (Debian, MariaDB, Apache) – ohne externe Abhängigkeiten, mit voller Kontrolle über Updates und Security-Patches.
Was in der Demo überzeugte: Der visuelle Workflow-Editor ermöglichte es, Eskalationspfade, Change-Genehmigungen und SLA-Regeln zu konfigurieren, ohne eine einzige Zeile Code zu schreiben. Die Open-Source-Basis sicherte langfristige Unabhängigkeit von Lizenzmodellen und ließ bei Bedarf tiefe Anpassungen auf Codeebene zu. Dass die Entscheidung richtig war, zeigt sich noch heute – das Kunden-Ticketportal läuft bis heute auf dieser Plattform.
Die 6 Phasen der Implementierung
Phase 1 – Erst verstehen, dann konfigurieren (1. Monat)
Bevor auch nur ein einziger Konfigurationsparameter gesetzt wurde, stand eine dreimonatige Analyse. Denn der häufigste Fehler bei ITSM-Projekten ist nicht ein schlechtes Tool – es ist ein gutes Tool, das für den falschen Use Case eingerichtet wird.
Alle Kommunikationskanäle wurden systematisch ausgewertet: Wer schreibt wann mit welchem Anliegen? Das Ergebnis – rund 800 tägliche Anfragen, davon 45 Prozent Standardprobleme, 15 Prozent interne IT-Themen und 40 Prozent echte Kunden-Incidents – war die sachliche Grundlage für alle nachfolgenden Entscheidungen über Queue-Strukturen, SLA-Klassen und Eskalationspfade.
Herleitung der Verteilung: Die Prozentwerte wurden auf Basis einer zweiwöchigen Stichprobenanalyse über alle Eingangskanäle ermittelt. Dafür wurden die Eingänge aus gemeinsamen Postfächern, Telefonprotokollen und manuellen Teamnotizen zusammengeführt und nach Standardproblemen beziehungsweise Service Requests, internen IT-Themen und kundenbezogenen Incidents klassifiziert. Die Verteilung wurde anschließend auf das durchschnittliche tägliche Gesamtvolumen von rund 800 Anfragen normalisiert: etwa 360 Standardprobleme, 120 interne IT-Themen und 320 Kunden-Incidents pro Tag.
Saubere Rechnung bei 800 Tickets pro Tag
- 45 % Standardprobleme und Service Requests: 360 Tickets pro Tag, zum Beispiel Passwort-Resets, Berechtigungen, wiederkehrende Konfigurationen und How-to-Fragen.
- 15 % interne IT- und Organisationsanfragen: 120 Tickets pro Tag, zum Beispiel interne Arbeitsplatz-IT, Hardwarediskussionen und interne Abstimmungen ohne Kundenbezug.
- 40 % Kunden-Incidents und echte Störungen: 320 Tickets pro Tag, zum Beispiel MSSP-Alarmmeldungen, Systemausfälle, Security-Ereignisse und SLA-relevante Vorfälle.
- Summe: 100 % entsprechen 800 Tickets pro Tag.
Deliverable: Dokumentierter Ist-Zustand, Anfragenklassifikation, Bedarfsprofil für die Tool-Konfiguration
Phase 2 – Prozesse vor Tool: ITIL-Alignment (5. Monat)
Vier Kernprozesse wurden für den größten unmittelbaren Mehrwert priorisiert: Incident-Management, Service Request Fulfillment, Change-Management und Maintenance Management.
Die intensivste Diskussion gab es nicht über das Tool – sondern über die Priorisierungsmatrix. Der erste Workshop-Entwurf hatte sieben Stufen. Das klingt präzise, führt in der Praxis aber zu endlosen Einordnungsdiskussionen, wenn gerade ein Kunde anruft.
Die Lösung: vier Prioritäten – Kritisch, Hoch, Mittel und Niedrig – mit eindeutigen, nicht interpretierbaren Kriterien. „Kritisch" bedeutete: Kundenproduktivität beeinträchtigt, SLA-Verstoß droht, Eskalation an die Geschäftsführung in 15 Minuten. Kein Ermessensspielraum.
Dazu passend wurden drei SLA-Klassen entlang der bestehenden Managed-Service-Struktur definiert: Standard (8x5), Extended (12x7) und Premium (24x7).
Deliverable: Prozessdokumentation für alle vier Workflows, Priorisierungsmatrix mit 4 Stufen, 3 SLA-Klassen, Queue-Struktur
Phase 3 – Technische Installation, CMDB und Security-Architektur (5.–7. Monat)
Die Installation erfolgte auf einem dedizierten Debian-Server im eigenen Rechenzentrum. Kein Cloud-Hosting, vollständige Kontrolle.
Bei der CMDB-Konfiguration galt ein klares Prinzip: minimal, aber vollständig und aktuell. Nur eine überschaubare Anzahl an CI-Typen wurde initial definiert. Alles, was nicht aktiv gepflegt werden würde, kam gar nicht erst hinein.
E-Mail-Integration und LDAP-Anbindung an das Active Directory wurden eingerichtet und legten die Basis für ein späteres, vollständiges User-Rollenkonzept mit RBAC.
Security war kein Nachgedanke: Als MSSP mit KRITIS-nahen Kunden ist ISO-27001-Konformität Pflicht. Die Plattform wurde von Anfang an mit verschlüsselter Datenhaltung – AES-256 at Rest und TLS in Transit –, vollständigen Audit-Trails und einem HA-Konzept mit RPO unter 4 Stunden und RTO unter 8 Stunden ausgelegt. Dies bildete die Grundlage für die spätere SIEM-Integration und das Security Monitoring.
Deliverable: Produktionsbereites System, CMDB mit initial definierten CI-Typen, E-Mail- und LDAP/AD-Integration, Security-Basisarchitektur, HA-Konzept
Phase 4 – Workflows, SLA-Logik und API-Architektur für Großkunden (7.–10. Monat)
Das war die technisch anspruchsvollste Phase – und gleichzeitig die, in der der Wert des gewählten Tools am deutlichsten wurde. Eskalationspfade, Change-Genehmigungsworkflows und automatische Zuweisungsregeln basierend auf Tickettyp, Kunde und Tageszeit wurden vollständig konfiguriert, ohne Code zu schreiben.
Ein besonderes Augenmerk lag auf der SLA-Timer-Logik. Für Premium-Kunden mit 24x7-SLA zählt buchstäblich jede Minute. Entsprechend wurden Servicezeiten und bundeslandspezifische Feiertagskalender für Nordrhein-Westfalen und Bayern hinterlegt und intensiv getestet. Ein Fehler dort wäre geschäftskritisch gewesen.
Parallel dazu wurde die API-Architektur für strategische Großkunden von Anfang an mitgedacht. Es war klar, dass High-Value Customers keine manuelle Ticketerfassung akzeptieren würden.
Eine direkte REST-API-Schnittstelle mit Service-Contract-First-Design und Canonical Data Model wurde konzipiert und ermöglichte nach dem Go-Live nahtlose B2B-Integrationen.
Deliverable: Vollständige Workflow-Konfiguration, SLA-Kalenderlogik für 3 Klassen, RFC-Prozess, automatische Eskalationsbenachrichtigungen, REST-API-Architektur für Großkunden
Phase 5 – Die mutigste Entscheidung: Greenfield statt Migration (11.–13. Monat)
Tausende E-Mails, Excel-Listen und informelle Dokumentationen enthielten historische Informationen. Die Versuchung, all das zu importieren, war real. Die Entscheidung dagegen war richtig.
Unstrukturierte, unvollständige und oft veraltete Altdaten ins neue System zu übernehmen hätte bedeutet, die Probleme von gestern in das Tool von morgen einzubauen. Stattdessen: Greenfield.
Nur aktive Kundenkonfigurationen wurden manuell und geprüft in die CMDB übertragen. Historische Tickets blieben im E-Mail-Archiv – zugänglich, aber außerhalb des Systems.
Vor dem Go-Live folgten Smoke-Tests aller Workflow-Pfade, Lasttests der SLA-Timer-Logik und ein simulierter Incident-Test mit dem Operations-Team auf Basis echter vergangener Kundensituationen. Dabei wurden Fehler in der Eskalationslogik gefunden und noch vor dem Go-Live behoben.
Deliverable: Greenfield-Start, aktive CMDB-Daten migriert, vollständige Testdurchläufe, Go-Live-Freigabe
Phase 6 – Go-Live, Training und die Karte an den Monitoren (14.–16. Monat)
Go-Live im 16. Monat – ohne kritische Vorfälle. In der ersten Woche erfolgte ein tägliches Monitoring von Ticket-Volumen, Erstantwortzeit und SLA-Erfüllungsquote.
Beim Training wurde bewusst auf mehrtägige Schulungsmarathons verzichtet. Stattdessen gab es eine zweistündige Einführung und eine laminierte Quick-Reference-Card an jedem Arbeitsplatz – mit Ticket-Typen, Prioritätskriterien und den fünf häufigsten Aktionen im System.
Diese Karte hing auch nach dem Projektabschluss an den meisten Monitoren. Ein kleines Detail, das viel sagt.
Kurz nach dem Go-Live erfolgte die formale Projektabnahme: 100 Prozent der Anfragen wurden strukturiert im System erfasst, die Erstantwortzeit folgte nun einer klaren prioritäts- und SLA-basierten Reaktionslogik statt eines unklaren Ad-hoc-Vorgehens, und die SLA-Erfüllungsquote lag bei über 90 Prozent. Für die ISO-27001-Rezertifizierung konnten die ITSM-Prozesse erstmals als dokumentierter, belastbarer Nachweis für strukturiertes Incident Management vorgelegt werden.
Zeitgleich wurde eine agile Transformation angestoßen: Scrum und Kanban wurden unternehmensübergreifend eingeführt. Das ITSM-Tool wurde damit zum natürlichen Backbone für die neuen Sprint-Prozesse.
Deliverable: Go-Live im 16. Monat, 100 % Ticket-Erfassung, prioritäts- und SLA-basierte Reaktionslogik etabliert, SLA-Quote über 90 %, ISO-27001-Nachweis erbracht
Was danach kam – Die Plattform wächst mit
Ein gutes ITSM-System ist kein abgeschlossenes Projekt. Es ist eine Plattform, die sich mit den Anforderungen des Unternehmens weiterentwickelt. Die Folgeprojekte sprechen für sich:
- Q3/2022 – Abrechnungsschnittstelle: Integration einer Middleware-Schnittstelle für automatisierte Leistungsabrechnung – Ticketdaten werden über eine asynchrone Message-Queue-Architektur (Guaranteed Delivery) an die Abrechnungsabteilung übertragen.
- Q4/2022–Q1/2023 – Großkunden-API-Coupling: Erste produktive B2B-Integration: Incidents eines Großkunden werden vollautomatisch aus dem Kundensystem ins ITSM-Tool übertragen – auf Basis der im Projekt geschaffenen SOA-Architektur.
- Q2–Q3/2023 – ITSM-Redesign: Erweiterung der CMDB für neue Service-Verträge, Überarbeitung der Abrechnungsschnittstelle und Performance-Optimierung.
- Q2–Q4/2023 – Interne ITSM-Variante: Auf Basis der gesammelten Erfahrungen wurde vom gleichen Hersteller eine angepasste Variante für die interne Nutzung eingeführt – mit erweiterter SOA-Integration und Event-Driven Architecture.
- Q1–Q3/2024 – Vollständig überarbeitetes User- und Rollenmanagement: Rollenkonzept für alle internen Tools, Integration ins Active Directory für strukturiertes On- und Offboarding.
Messbarer Projekterfolg
| Kennzahl | Vorher | Nachher |
|---|---|---|
| Erstantwortzeit | Nicht messbar | prioritäts- und SLA-basierte Reaktionslogik |
| SLA-Erfüllungsquote | Nicht existent | > 90 % (94 % im ersten Monat) |
| Ticket-Erfassung | ~0 % strukturiert | 100 % strukturiert im ITSM-Tool erfasst – keine E-Mail-Tickets mehr |
| ISO 27001-Nachweis | Nicht möglich | Erstmals erbracht |
| CMDB | Nicht vorhanden | als gepflegte Single Source of Truth etabliert |
Lessons Learned
Greenfield ist oft mutiger – und besser.
Schlechte Altdaten im neuen System sind teurer als ein sauberer Neustart. Wer alten Ballast mitschleppt, kämpft von Tag eins gegen die eigenen Daten.
Weniger ist mehr – wirklich.
Eine überschaubare Anzahl an CI-Typen statt einer unübersichtlichen Vielzahl, vier Prioritäten statt sieben. Jede Vereinfachung, die auf echtem Verständnis basiert, ist eine Verbesserung.
Das Tool ist das Letzte, worüber man nachdenken sollte.
Das ITSM-System funktioniert, weil die Prozesse und Workflows vor der Konfiguration durchdacht wurden – nicht umgekehrt. Kein Tool rettet schlechte Prozesse.
API-Architektur gehört in die Planung, nicht in den Nachgang.
Wer Großkunden-Integrationen von Anfang an mitdenkt, spart sich später aufwendige Nacharbeiten und kann innerhalb von Monaten produktiv gehen.
Security ist ein Designprinzip, kein Audit-Punkt.
ISO-27001-Konformität, Verschlüsselung, Audit-Trails und HA-Konzept gehören in die Architektur – nicht auf die Liste der Dinge, die man später noch irgendwie einbaut.
Sprechen Sie uns an!
Gerne erzählen wir Ihnen mehr dazu in einem persönlichen Kennenlerngespräch!
War dieser Beitrag hilfreich? Jetzt teilen!
