IT Service Management im Mittelstand: Leistungen, Verantwortung und Steuerung zusammenbringen

Zuruf-IT ist vor allem unsichtbare IT

Wenn eine Geschäftsführung wissen möchte, was ihre IT eigentlich leistet, erhält sie häufig eine Liste aus Servern, Anwendungen, Projekten und offenen Tickets. Das beschreibt die technische Arbeit. Es beantwortet aber noch nicht die geschäftliche Frage: Welche verlässliche Leistung erhält das Unternehmen dafür?

Genau an dieser Stelle beginnt IT Service Management. Nicht mit einem vollständigen Framework und auch nicht mit dem Kauf eines neuen Tools, sondern mit einem Perspektivwechsel: weg von einzelnen technischen Komponenten, hin zu einem verständlichen Ergebnis für das Geschäft.

Für mittelständische IT-Organisationen halte ich eine breite ITIL-Umsetzung zum Einstieg meist nicht für notwendig. Beliebigkeit ist trotzdem keine Alternative. Es braucht einen belastbaren Kern, in dem Leistungen, Verantwortung, Arbeitsfluss und Wirkung zusammenpassen. Mein Grundsatz dafür lautet: Erst Transparenz schaffen, dann steuern.

Ein IT-Service beschreibt ein Ergebnis für das Geschäft

Ein IT-Service ist kein Server, keine Software und kein Ticket. Er ist eine Leistung, die dem Unternehmen einen konkreten Nutzen liefert: Die E-Mail-Kommunikation funktioniert, das ERP ist verfügbar oder neue Mitarbeitende können am ersten Tag arbeitsfähig starten.

Die Geschäftsführung kauft deshalb nicht einfach eine Firewall. Sie investiert in die Fähigkeit, Daten zu schützen und auch bei einem Sicherheitsvorfall handlungsfähig zu bleiben. Die Firewall ist ein technischer Bestandteil dieser Leistung. Hinzu kommen Menschen, Prozesse, Dienstleister, Betriebswissen und verbindliche Entscheidungen.

Ein sinnvoll beschriebener IT-Service bündelt diese Bestandteile zu einem benennbaren Leistungsversprechen. Er macht deutlich,

• welchen Nutzen das Unternehmen erwartet,
• wer die Leistung benötigt und verantwortet,
• welche Qualität realistisch zugesagt werden kann,
• wovon die Leistung abhängt,
• und welcher Kostenrahmen dafür transparent gemacht werden kann.

Damit ist ein Service mehr als ein freundlicher Name für vorhandene Technik. Er ist die kleinste Einheit, über die IT und Geschäftsführung sinnvoll Leistung, Risiko und Kosten besprechen können.

Das KinOps-Mindestmodell für ITSM im Mittelstand

Das folgende Modell ist meine Empfehlung für einen belastbaren Einstieg. Es ist kein offizieller Mindestumfang von ITIL oder ISO/IEC 20000-1. Die Norm beschreibt ein umfassenderes Service-Management-System, das Services plant, gestaltet, überführt, erbringt, misst und fortlaufend verbessert. Das KinOps-Mindestmodell konzentriert sich bewusst auf sieben Bausteine, mit denen eine mittelständische IT steuerungsfähig werden kann.

1. Ein verständlicher Service-Katalog

Der Service-Katalog beantwortet in der Sprache des Unternehmens, was die IT anbietet. „Arbeitsplatz für neue Mitarbeitende bereitstellen“ ist dafür nützlicher als eine Aufzählung von Konten, Lizenzen und Endgeräten.

Der erste Katalog muss weder vollständig noch perfekt kalkuliert sein. Er muss ehrlich genug sein, um Erwartungen und Verantwortung besprechen zu können. Ein Katalog, den niemand außerhalb der IT versteht, erfüllt diesen Zweck nicht.

2. Ein gemeinsamer Eingang für die Arbeit

Normale Anfragen und Störungen benötigen einen verbindlichen Eingang. In der Regel ist das ein Ticketsystem. Arbeit, die über Flurgespräche, persönliche Postfächer und Zettel verteilt bleibt, lässt sich weder zuverlässig priorisieren noch später auswerten.

Ein gemeinsamer Eingang bedeutet nicht, dass ein Produktionsstillstand geduldig auf die Bearbeitung eines Webformulars warten muss. Für kritische Störungen braucht es einen klar definierten Sofortkanal. Der Vorgang wird anschließend trotzdem im gemeinsamen System dokumentiert. Sonst bleibt gerade die wichtigste Arbeit unsichtbar.

Ein Ticketsystem kann diesen Ablauf tragen. Es ersetzt aber nicht die organisatorischen Entscheidungen dahinter. Der Beitrag „Ein Ticketsystem löst keine organisatorischen Probleme“ zeigt, welche Fragen vor einer Toolentscheidung geklärt sein müssen.

3. Die Trennung von Incident und Service Request

Eine Störung ist etwas anderes als eine Anforderung. Wenn das ERP unerwartet nicht verfügbar ist, muss der normale Betrieb möglichst schnell wiederhergestellt werden. Genau darauf richtet sich Incident Management.

Ein Service Request ist dagegen eine vordefinierte, durch Nutzer ausgelöste Anfrage, beispielsweise eine Auskunft, ein Zugriff oder eine Standardleistung. Service Request Management soll solche Anfragen in vereinbarter Qualität wirksam und nutzerfreundlich erfüllen.

Beides im selben System zu bearbeiten ist sinnvoll. Beides nach derselben Dringlichkeit und Bearbeitungslogik zu behandeln ist es nicht. Die Trennung schafft die Voraussetzung für realistische Prioritäten und aussagekräftige Zeiten.

4. Verständliche Leistungserwartungen

Ein mittelständisches IT-Team braucht nicht sofort einen umfangreichen SLA-Katalog. Es braucht zunächst eindeutige Antworten auf einfache Fragen: Wann reagiert die IT? Wann beginnt die Bearbeitung? Was bedeutet Wiederherstellung? Welche Fälle sind wirklich kritisch? Wann läuft eine vereinbarte Zeit nicht weiter?

Erst wenn diese Begriffe und Messpunkte geklärt sind, werden formale Service Level Agreements belastbar. Auch das offizielle Service Level Management richtet Serviceziele am Geschäft und an Kundenerwartungen aus. Eine scheinbar präzise Zahl ohne gemeinsames Verständnis erzeugt dagegen vor allem Streit über die Messung.

5. Leichtes Change Management

Änderungen müssen nicht alle durch dasselbe Gremium. Sie dürfen aber auch nicht davon abhängen, wer gerade Zugang zum System besitzt. Ein leichter Change-Prozess klärt mindestens:

• Wer darf eine Änderung anstoßen?
• Wer bewertet Risiko und betriebliche Auswirkung?
• Wer autorisiert sie?
• Welche Standardänderungen dürfen nach einem vorab vereinbarten Ablauf erfolgen?
• Wann benötigt eine Änderung zusätzliche Planung oder eine Rückfallmöglichkeit?

Change Enablement verbindet deshalb Risikobewertung, Autorisierung und Planung. Für den Mittelstand ist nicht die Zahl der Freigabestufen entscheidend, sondern eine angemessene Entscheidung für das tatsächliche Risiko.

6. Bestandsdaten, die eine Entscheidung unterstützen

Eine gepflegte Inventarliste der wichtigsten Geräte, Anwendungen und Verträge kann für den Einstieg genügen. Sie ist noch keine Configuration Management Database, kurz CMDB.

Service Configuration Management benötigt verlässliche Informationen über relevante Configuration Items und ihre Beziehungen zu Services. Dieser zusätzliche Aufwand ist sinnvoll, wenn die Daten konkrete Entscheidungen unterstützen: Welche Services sind von einem Ausfall betroffen? Welche Abhängigkeiten muss ein Change berücksichtigen? Wer ist für die Pflege verantwortlich?

Eine umfassende CMDB ohne solchen Nutzungszweck wird schnell zum Dokumentationsprojekt. Datenmenge ersetzt keine Datenverantwortung.

7. Problem Management für wiederkehrende Ursachen

Ein Incident wird behoben, damit der Betrieb weitergeht. Wenn dieselbe Störung wiederkehrt, genügt das auf Dauer nicht. Problem Management richtet den Blick deshalb auf tatsächliche oder mögliche Ursachen von Incidents.

Das muss nicht mit einer eigenen Vollzeitrolle beginnen. Schon eine regelmäßige Entscheidung darüber, welche wiederkehrenden Störungen eine Ursachenanalyse und nachhaltige Maßnahme rechtfertigen, verändert die Arbeit. Die IT behandelt dann nicht mehr nur die nächste Unterbrechung, sondern reduziert vermeidbare Wiederholung.

Drei Verantwortungen müssen unterscheidbar bleiben

Ein kleines IT-Team kann nicht für jeden Service und jeden Prozess eine eigene Stelle schaffen. Es muss aber wissen, welche Verantwortung eine Person gerade wahrnimmt.

Der Service Owner beziehungsweise die IT-Leitung verantwortet das Leistungsversprechen gegenüber dem Business. Dazu gehören Nutzen, zugesagte Qualität, Kostenrahmen und die Abstimmung mit den betroffenen Fachbereichen.

Das Service-Team erbringt die Leistung operativ. Je nach Organisation gehören dazu First und Second Level, Administratoren, Fachverantwortliche und externe Dienstleister.

Der Process Owner verantwortet Ziele, Regeln, Ausnahmen und Weiterentwicklung eines Prozesses. In einem kleinen Haus kann das dieselbe Person wie die IT-Leitung sein. Die Personalunion ist zulässig. Unklarheit über die Rolle ist es nicht.

Wer ein Leistungsversprechen abgibt, wer es täglich erfüllt und wer den Ablauf steuert, sollte deshalb gedanklich sauber getrennt bleiben. Sonst werden operative Engpässe, Qualitätsfragen und Prozessprobleme miteinander vermischt.

Die Vertiefung „Verantwortlichkeiten als Voraussetzung für skalierbaren IT-Betrieb“ übersetzt diese Rollen in konkrete Entscheidungsrechte, Berechtigungen und Eskalationswege.

Bei einer Zuruf-IT zählt die Reihenfolge

Die sieben Bausteine beschreiben das Zielmodell. Sie werden nicht in derselben Reihenfolge eingeführt. Wer heute überwiegend auf Zuruf arbeitet, sollte zuerst die Arbeit sichtbar machen.

Zuerst einen gemeinsamen Eingang schaffen

Alle normalen Vorgänge laufen in ein System. Zulässige Notfallwege und die anschließende Dokumentation werden ausdrücklich vereinbart. Damit entsteht erstmals eine gemeinsame Arbeitsgrundlage für IT und Nutzer.

Danach die tatsächliche Arbeit beobachten

Für einen ersten Überblick halte ich zwei bis drei Wochen für praxistauglich. Dieser Zeitraum ist keine allgemeine Messnorm und kann saisonale Spitzen übersehen. Er reicht aber häufig, um Hypothesen durch sichtbare Vorgänge zu ersetzen: Welche Leistungen werden tatsächlich nachgefragt? Was wiederholt sich? Wo entstehen Rückfragen oder Wartezeiten?

Aus der Arbeit den ersten Service-Katalog ableiten

Der Katalog entsteht nicht am Reißbrett, sondern aus der beobachteten Leistung. Damit bleibt er näher an der betrieblichen Realität. Erst danach werden Incidents und Service Requests getrennt und einfache Prioritäten festgelegt.

Erst dann Zeiten und Prozesse verschärfen

Reaktions- und Wiederherstellungserwartungen folgen, sobald Eingang, Kategorien und Messpunkte verlässlich sind. Leichtes Change Management kommt hinzu, wenn klar ist, welche Änderungen tatsächlich anfallen und welche Risiken sie tragen. Bestandsbeziehungen und Problem Management werden anhand konkreter Entscheidungen ausgebaut.

Der psychologische Unterschied ist erheblich: Wer mit SLAs und Prozessdisziplin startet, bevor das Team den Nutzen der Sichtbarkeit erlebt, erzeugt leicht Widerstand. Die neuen Regeln wirken dann wie Kontrolle. Wer zuerst Transparenz schafft, kann dieselben Regeln als Lösung eines gemeinsam sichtbaren Problems begründen.

Ein Praxisfall: Erst die Daten veränderten die Diskussion

Bei einem Maschinenbauer mit rund 180 Mitarbeitenden und einer dreiköpfigen IT kamen Anliegen per Anruf, Flurgespräch und Zettel. Niemand konnte belastbar sagen, wie viele Vorgänge anfielen oder welche Themen den größten Anteil ausmachten.

Nach Einführung eines gemeinsamen Ticketsystems zeigte eine damalige Auswertung, dass rund 60 Prozent der erfassten Tickets auf fünf Themen entfielen: Passwort-Resets, VPN, Druckerprobleme, Onboarding und Berechtigungen. Der genaue Auswertungszeitraum ist im heute vorliegenden Rohmaterial nicht dokumentiert. Die Zahl ist deshalb nur eine begrenzte Beobachtung aus diesem konkreten, anonymisierten Fall und keine Kennzahl für andere mittelständische Unternehmen.

Die Auswertung machte wiederkehrende Arbeit und mögliche Standardisierungen sichtbar. Ein monatlicher Einseiter zeigte der Geschäftsführung erstmals nachvollziehbar, was die IT bearbeitete. Nach meiner Beobachtung veränderte das die Budgetdiskussion: Die IT wurde nicht mehr ausschließlich als pauschaler Kostenblock betrachtet, sondern zunehmend als beschreibbare und steuerbare Leistung.

Ob und welche der fünf Themen anschließend konkret automatisiert oder delegiert wurden, ist nicht belastbar dokumentiert. Ich ergänze diese Lücke deshalb nicht nachträglich. Passwort-Self-Service und ein standardisierter Rollen- und Berechtigungsprozess für das Onboarding wären typische Prüfkandidaten. Das ist eine fachliche Empfehlung, keine berichtete Maßnahme aus diesem Fall.

Gerade diese Trennung ist wichtig. Ein Praxisfall soll zeigen, was tatsächlich beobachtet wurde. Mögliche nächste Schritte müssen als Empfehlung erkennbar bleiben.

Die Geschäftsführung braucht Wirkung statt Toolstatistik

Ein eingeführtes Ticketsystem und eine veröffentlichte Prozessbeschreibung sind noch kein Nutzen. Wirkung wird dort sichtbar, wo sich die Leistungsfähigkeit des Unternehmens verändert.

Beobachtung	Geschäftsnahe Frage
Wiederherstellungszeit bei Störungen	Wie lange bleibt eine wichtige Geschäftsfähigkeit eingeschränkt?
Reaktionszeit	Wie schnell erhält der Nutzer eine qualifizierte Rückmeldung?
Onboarding-Durchlaufzeit	Wann kann eine neue Mitarbeiterin oder ein neuer Mitarbeiter tatsächlich arbeiten?
Vergessene Vorgänge und Eskalationen	Wie verlässlich hält die IT vereinbarte Abläufe ein?
Verhältnis von ungeplanter Betriebsarbeit zu Projektarbeit	Bleibt Kapazität für Weiterentwicklung oder dominiert die Feuerwehrarbeit?
Planbarkeit von Leistungen und Kosten	Kann die Geschäftsführung Aufwand, Risiko und Investitionen belastbarer entscheiden?

Auch Personenabhängigkeit gehört in diese Betrachtung. Wenn Wissen nur im Kopf eines Administrators steckt, bleibt ein Service trotz guter Technik verletzlich. Dokumentierte Abläufe, klare Verantwortung und gepflegte Informationen erhöhen deshalb nicht nur Effizienz, sondern auch Ausfallsicherheit.

Ticketmengen allein sind dagegen kein Erfolgsmaß. Eine sinkende Zahl kann auf weniger Störungen hinweisen. Sie kann ebenso bedeuten, dass Nutzer den vereinbarten Kanal nicht mehr verwenden. Eine steigende Zahl kann mehr Probleme zeigen oder lediglich eine vollständigere Erfassung. Aussagekräftig werden solche Werte erst mit vergleichbaren Kategorien, Zeiträumen und einem stabilen Erfassungsgrad.

Ein gutes Reifezeichen ist für mich der Moment, in dem die IT-Leitung eine Frage der Geschäftsführung mit nachvollziehbaren Zahlen statt mit Bauchgefühl beantworten kann.

Wann das leichte Modell nicht mehr genügt

Das KinOps-Mindestmodell ist ein Einstieg, kein Endzustand für jede Organisation. Ein gezielter Ausbau wird notwendig, wenn das Geschäft mehr Koordination, Nachweis oder Risikosteuerung verlangt. Typische Signale sind:

• mehrere Standorte oder Landesgesellschaften mit unterschiedlichen Anforderungen,
• mehr Dienstleister und technische Schnittstellen,
• häufige oder riskante Changes,
• vertraglich zugesicherte Service Levels,
• Audit- und Kundennachweise,
• regulatorische Pflichten,
• starkes Wachstum und zunehmende organisatorische Komplexität.

Aus meiner Erfahrung liegt zwischen etwa 250 und 500 Beschäftigten häufig ein Bereich, in dem informelle Absprachen sichtbar an Grenzen geraten. Das ist keine harte Schwelle. Ein regulierter Betrieb mit 120 Beschäftigten kann deutlich mehr formale Steuerung benötigen als ein wenig komplexes Unternehmen mit 600 Beschäftigten.

Auch Standards und Gesetze lassen sich nicht auf diese Faustregel reduzieren. ISO/IEC 27001:2022 beschreibt ein Informationssicherheits-Managementsystem für Organisationen jeder Größe. Ob ein Unternehmen unter NIS-2 fällt, hängt vom gesetzlichen Anwendungsbereich ab und sollte mit den aktuellen Informationen und Prüfungshilfen des Bundesamts für Sicherheit in der Informationstechnik geprüft werden. Das deutsche Umsetzungsgesetz ist am 6. Dezember 2025 in Kraft getreten.

Wenn diese Ausbausignale vorliegen, werden formelles Service Level Management, ein belastbareres Change- und Release-Management, verlässliche Konfigurationsbeziehungen, strukturiertes Reporting und gegebenenfalls dedizierte Rollen sinnvoll. Der Reifegrad folgt dabei dem geschäftlichen Risiko und dem Steuerungsbedarf, nicht dem Wunsch nach einem möglichst vollständigen Framework.

Der erste Schritt ist kleiner als eine ITIL-Einführung

IT Service Management beginnt im Mittelstand nicht mit der Entscheidung, welche Praktiken vollständig umgesetzt werden. Es beginnt mit einer einfacheren und zugleich unbequemeren Aufgabe: Die IT muss verständlich benennen, welche Leistungen sie für das Geschäft erbringt, welche Arbeit dafür anfällt und wer welche Verantwortung trägt.

Schaffen Sie zuerst einen gemeinsamen Eingang und machen Sie die tatsächliche Arbeit sichtbar. Leiten Sie daraus einen ehrlichen Service-Katalog ab. Trennen Sie Störungen von Anforderungen. Vereinbaren Sie erst dann Zeiten, Regeln und weiterführende Prozesse.

Ein leichtes Modell ist nicht daran zu erkennen, dass es wenig dokumentiert. Es ist daran zu erkennen, dass jeder Baustein einen klaren Zweck besitzt. Wenn die Geschäftsführung Nutzen, Risiko und Kosten nachvollziehen kann und die IT ihre Arbeit mit Daten statt Bauchgefühl steuert, ist aus reaktiver Technikarbeit ein steuerbarer Service geworden.