In vielen mittleren KMU ist die IT längst geschäftskritisch. Ein kleines internes Team hält den Betrieb am Laufen, meist kompetent und mit hohem Einsatz. Was fehlt, sind selten Fachkenntnisse. Es fehlen Prozesse. Und es braucht davon weniger, als die meisten Geschäftsleitungen annehmen.
Ein Muster, das sich wiederholt
Ein Unternehmen mit rund 150 Mitarbeitenden, ein bis zwei Personen in der IT. ERP, Dateiablage, Kommunikation, Remote-Zugriff, alles im eigenen Haus betreut. Die IT funktioniert im Alltag. Aber oft sehe ich ähnliche Situationen vor Ort.
Ein neuer Mitarbeiter tritt ein. HR meldet das per E‑Mail oder mit einem Papier-Formular. Hardware muss bestellt, Konten müssen eröffnet, Berechtigungen vergeben, Lizenzen zugewiesen, Telefonie eingerichtet werden. Wo der Auftrag gerade steht, weiss niemand verlässlich. Beim Austritt läuft dasselbe rückwärts, mit dem Unterschied, dass ein vergessener Zugang kein Ärgernis, sondern ein Sicherheitsproblem ist.
Und Störungen? Die Benutzer rufen an, schreiben eine E‑Mail an eine persönliche Adresse oder stehen direkt im Büro der IT. Wer den kürzesten Weg zur IT hat, wird zuerst bedient.
Was dabei unsichtbar bleibt
Das eigentliche Problem ist nicht der fehlende Komfort, sondern die fehlende Grundlage für Entscheidungen.
Die Reihenfolge entsteht zufällig. Die Störungen werden in der Reihenfolge des Eintreffens oder nach Goodwill behandelt. Es besteht keine Priorisierung nach definierten Kriterien. Meist ist es so, dass wer lauter ist, auch zuerst bedient wird.
Die Dauer ist nicht messbar. Niemand kann sagen, wie lange die Behebung einer Störung im Schnitt dauert. Damit lässt sich weder gegenüber den Fachbereichen etwas zusagen noch gegenüber einem externen Dienstleister etwas einfordern.
Häufungen fallen nicht auf. Dieselbe Störung tritt im Quartal dreissig Mal auf, wird dreissig Mal behoben und nie gezählt. Es wird die Störung behoben, nicht die Ursache beseitigt.
Das Wissen hängt an Personen. Der Verlauf einer Störung liegt im Kopf und im Postfach einer einzelnen Person. Ferien, Krankheit oder ein Austritt machen daraus ein Betriebsrisiko.
Warum ITIL für die meisten KMU die falsche Antwort ist
Wer sich mit dem Thema Service Management in der IT befasst, landet schnell bei ITIL. Das aktuelle Rahmenwerk umfasst 34 Praktiken, dazu ein eigenes Vokabular, Rollenmodelle und Zertifizierungspfade. Für einen Konzern mit einer IT-Organisation von mehreren hundert Personen ist das sinnvoll. Für ein Team von zwei Personen bedeutet eine flächendeckende Einführung monatelange Arbeit an Dokumenten, die im Alltag niemand liest.
Solche Projekte enden auf zwei Arten. Entweder werden sie nach der Hälfte abgebrochen, oder es entsteht ein Regelwerk, das im Ordner steht, während im Betrieb weiter zugerufen wird.
Das heisst nicht, dass die Inhalte falsch wären. Die Trennung von Störung und Anfrage, eine nachvollziehbare Priorisierung, eine definierte Eskalation: das ist unabhängig von der Unternehmensgrösse richtig. Falsch ist der Umfang, in dem es üblicherweise eingeführt wird.
Vier Prozesse und eine Liste
Für den Einstieg genügen fünf Elemente. Sie sind in wenigen Wochen umsetzbar.
- Ein einziger Eingangskanal. Jede Meldung wird erfasst, auch die, die mündlich hereinkommt. Der Zuruf im Gang wird nicht verschwinden und muss es auch nicht. Er muss nur im System landen. Ohne Erfassung gibt es nichts zu steuern. In der Fachsprache ist das der Einstieg ins Incident Management, die strukturierte Behandlung von Störungen.
- Eine einfache Priorisierung. Zwei Dimensionen, Auswirkung und Dringlichkeit, mit je drei Stufen reichen aus. Entscheidend ist, dass die Kriterien von der Geschäftsleitung mitgetragen und den Fachbereichen bekannt sind. Sonst bleibt die Priorisierung eine Meinung der IT und wird bei jeder Gelegenheit übersteuert.
- Wiederkehrende Aufträge als definierter Ablauf. Ein- und Austritt sind keine Störungen, sondern planbare Standardaufträge. Als Checkliste hinterlegt, ausgelöst durch HR, mit Termin und klaren Verantwortlichkeiten. Damit wird der Eintritt pünktlich und der Austritt vollständig. Gemeint ist damit das Service Request Management, die Bearbeitung von Serviceanfragen.
- Eine monatliche Auswertung. Anzahl Meldungen, Kategorien, durchschnittliche Bearbeitungsdauer, Wiederholungsfälle. Das ist eine Auswertung von zwanzig Minuten. Erst ab hier lässt sich an Ursachen arbeiten, was unter dem Begriff Problem Management läuft, und erst ab hier ist eine sachliche Diskussion über Ressourcen möglich.
- Ein schlanker Servicekatalog. Eine Liste der IT-Services, die tatsächlich betrieben werden, mit je zwei Sätzen: was der Service leistet, wer ihn fachlich verantwortet, wer ihn technisch betreibt. Für ein KMU passt das auf wenige Seiten. Der Nutzen zeigt sich sofort: Erst wenn sichtbar ist, was betrieben wird, lässt sich beurteilen, was ein Ausfall bedeutet, was der Betrieb kostet und wo Doppelspurigkeiten oder verwaiste Anwendungen existieren. Nebenbei liefert der Katalog die Kategorien für das Ticketsystem und damit die Struktur für die Auswertung.
Mehr braucht es zu Beginn nicht. Kein Change Advisory Board, kein Katalog über vierzig Seiten mit Service-Level-Zusagen für jede Anwendung, keine Kennzahlensammlung, die niemand liest.
FitSM und YaSM als Orientierung
Zwischen «gar nichts» und ITIL liegen leichtgewichtige Rahmenwerke, die genau für diese Situation gemacht sind.
FitSM stammt aus dem europäischen Forschungsumfeld, ist unter einer offenen Lizenz frei verfügbar und formuliert seine Anforderungen bewusst knapp und überprüfbar. Die Struktur orientiert sich an ISO 20000, ohne deren Aufwand zu verlangen. Störungen und Serviceanfragen sind dort in einem einzigen Prozess zusammengefasst, was der Realität eines kleinen Teams näher kommt als eine saubere Trennung auf dem Papier. Die oben beschriebenen fünf Elemente finden sich hier wieder, verteilt auf vier der insgesamt vierzehn Prozesse.
YaSM ist ein vereinfachtes Prozessmodell aus dem Umfeld der bekannten ITIL-Prozesslandkarten. Es beschreibt in rund zwanzig Prozessen, wie ein Dienstleistungserbringer arbeitet, deutlich schlanker und ohne die Terminologielast des grossen Vorbilds.
Die Werkzeugfrage kommt übrigens zuletzt. Brauchbare Ticketsysteme kosten wenige Franken pro Benutzer und Monat. Die Hürde ist nie die Lizenz, sondern die Frage, wer wofür zuständig ist.
Zwei Fragen vor der Einführung
Bevor investiert wird, lohnen sich zwei Abklärungen.
Erstens: Ist das fehlende Service-Management tatsächlich das Problem, oder macht es nur ein anderes sichtbar? Sehr häufig zeigt sich, dass die Zuständigkeiten zwischen Fachbereichen und IT nie geklärt wurden. Ein Ticketsystem legt das offen, löst es aber nicht.
Zweitens: Welchen Nutzen erwartet die Geschäftsleitung konkret? Kürzere Ausfallzeiten, planbare Eintritte, eine belastbare Grundlage für Ressourcenentscheide oder eine saubere Auslagerung von Teilen des Betriebs. Je nach Antwort sehen die ersten Schritte anders aus.
Genau diese Einordnung ist Gegenstand einer IT-Standortbestimmung. Sie betrachtet neben den Prozessen auch Strategie, Kosten, Sicherheit, Infrastruktur und Organisation und zeigt, wo der Handlungsbedarf am grössten ist. Manchmal lautet das Ergebnis, dass ein einfaches Ticketsystem die günstigste Massnahme mit der grössten Wirkung ist. Manchmal lautet es, dass zuerst die Verantwortlichkeiten geklärt werden müssen. Beides ist ein brauchbares Ergebnis, solange es vor der Investition vorliegt und nicht danach.
