Fachartikel

IT-Kosten im Mittelstand: Warum eine Kostenliste noch kein IT-Controlling ist

Wie IT-Leitungen Ausgaben mit Nutzung, Leistung und Entscheidungsverantwortung verbinden, ohne Wirtschaftlichkeit auf pauschale Kürzungen zu reduzieren.

In einem mittelständischen Unternehmen wurden IT-Kosten ordnungsgemäß gebucht. Hardware, Software, Lizenzen und Zubehör erschienen in den Zahlen. Trotzdem konnte niemand belastbar beantworten, ob die IT für dieses Geld besser oder schlechter arbeitete. Es gab keine Kennzahlen, die Kosten und betriebliche Leistung miteinander verbanden.

Nach einem Jahr lagen die betrachteten monatlichen IT-Kosten 30 Prozent unter der vorherigen Vergleichsbasis. Diese Zahl beruht auf einem von mir selbst begleiteten, anonymisierten Fall. Sie ist kein Mittelstandsbenchmark und kein allgemeines Einsparversprechen.

Entscheidend ist ihre Abgrenzung: In der Nachher-Rechnung waren nicht nur die geringeren Rechnungen externer Dienstleister enthalten, sondern auch die vollständigen internen Kosten eines neu eingestellten Administrators einschließlich Arbeitgeber- und Arbeitsplatzkosten. Es wurde also nicht lediglich externer Aufwand unsichtbar in die eigene Organisation verschoben.

Erreicht wurde die Reduktion durch mehrere tatsächlich umgesetzte Maßnahmen: Lizenzen wurden optimiert, nicht benötigte Software abgeschafft, alte Verträge gekündigt und externe Supportleistung durch interne Kompetenz ersetzt. Der Fall zeigt jedoch noch etwas Wichtigeres als eine einzelne Prozentzahl: Eine Kostenliste wird erst dann zu IT-Controlling, wenn sie Entscheidungen über Kosten und Leistung ermöglicht.

Gebuchte Kosten sind noch keine steuerbaren Kosten

Die Finanzbuchhaltung kann zeigen, wie viel Geld an einen Lieferanten geflossen ist und auf welches Konto der Betrag gebucht wurde. Für die Steuerung der IT fehlen damit häufig noch wesentliche Antworten:

  • Welchen betrieblichen Zweck erfüllt die Ausgabe?
  • Wer nutzt die Leistung tatsächlich?
  • Welche Qualität oder Risikoreduktion entsteht dadurch?
  • Wer verantwortet die Position?
  • Wann kann oder muss neu entschieden werden?
  • Was geschieht mit Leistung und Risiko, wenn die Ausgabe sinkt oder entfällt?

Eine Summe ohne diese Zusammenhänge ist transparent, aber noch nicht entscheidbar. Umgekehrt wird aus einer technischen Leistung ohne zugeordnete Kosten kein wirtschaftlich steuerbarer Service.

IT Asset Management verbindet deshalb nicht nur Bestandsführung mit dem Lebenszyklus von IT-Assets. PeopleCert nennt ausdrücklich Wertmaximierung, Kostenkontrolle und Risikosteuerung. Die Norm ISO/IEC 19770-1:2017 beschreibt dafür ein Managementsystem, dessen konkreter Umfang aus dem Kontext der Organisation abgeleitet wird.

Für eine mittelständische IT muss daraus kein vollständiges IT-Asset-Management-System entstehen. Die Grundfrage ist trotzdem dieselbe: Welche Information benötigen wir, um über Anschaffung, Nutzung, Veränderung und Beendigung einer IT-Ausgabe zu entscheiden?

Interne Arbeit gehört in die Rechnung

Eine typische Kostenbetrachtung beginnt bei Rechnungen. Das ist verständlich, weil externe Ausgaben einfach zu finden sind. Es erzeugt aber ein schiefes Bild, sobald eigene Mitarbeitende Aufgaben übernehmen oder manuelle Arbeit durch eine vermeintlich günstige Lösung entsteht.

Im Praxisfall senkte die Einstellung eines Administrators die externen Supportkosten. Würde man nur die Dienstleisterrechnung vergleichen, erschiene die Einsparung größer, als sie tatsächlich war. Erst durch die Einbeziehung der vollständigen internen Kosten wurde sichtbar, ob die Entscheidung für das Unternehmen insgesamt wirtschaftlich war.

Eine belastbare Betrachtung unterscheidet daher mindestens:

  • externe wiederkehrende Kosten, beispielsweise Lizenzen, Wartung, Cloud und Support,
  • externe einmalige Kosten, beispielsweise Einführung, Migration oder Beschaffung,
  • interne Arbeitskosten für Betrieb, Administration und Support,
  • technische und organisatorische Folgekosten einer Veränderung,
  • sowie den Nutzen und das Risiko, die mit der Ausgabe verbunden sind.

Das UK Cabinet Office nennt bei der Bewertung von Technologieentscheidungen neben Aufbau und laufendem Support auch Wartung, Parallelbetrieb, Migration und Stilllegung. Diese Total-Cost-of-Ownership-Perspektive ist gerade dann wichtig, wenn eine scheinbar günstige Ablösung erhebliche Wechselarbeit oder ein zusätzliches Betriebsrisiko erzeugt.

Eine vollständige TCO-Berechnung für jede Maus und jede kleine Lizenz wäre trotzdem unverhältnismäßig. Der Detaillierungsgrad muss zur möglichen Entscheidung passen. Je größer Kosten, Bindung, Risiko und Wechselaufwand, desto gründlicher sollte die Betrachtung sein.

Eine schlanke IT-Kostenübersicht braucht Entscheidungsfelder

Die konkrete Kostenaufstellung des beschriebenen Falls bleibt vertraulich. Die folgenden Felder rekonstruieren sie nicht. Sie sind meine heutige Empfehlung für eine schlanke IT-Kostenübersicht im Mittelstand.

Feld Zu beantwortende Frage
Kostenposition und Kategorie Wofür zahlen wir: Hardware, Software, Lizenz, Zubehör, Cloud, Support oder interne Arbeit?
Anbieter beziehungsweise interne Leistung Wer stellt die Leistung bereit?
Betrag und Rhythmus Welche einmaligen und wiederkehrenden Kosten entstehen?
Zweck und betrieblicher Nutzen Welche Fähigkeit, welcher Service oder welches Risiko wird damit abgedeckt?
Nutzer und tatsächliche Nutzung Wer benötigt die Leistung und in welchem Umfang wird sie verwendet?
Kosten-Owner Wer steht für die wirtschaftliche Prüfung ein?
Laufzeit und Kündigungsfrist Bis wann ist eine echte Handlungsoption vorhanden?
Auswirkung einer Änderung Welche Folgen hätte Reduzierung, Ersatz oder Beendigung?
Entscheidungstermin Wann wird fortgeführt, angepasst, verhandelt, ersetzt oder beendet?

Nicht jede Position benötigt einen Roman. Bei einer einfachen Standardlizenz können wenige Angaben genügen. Bei einem geschäftskritischen ERP-Vertrag müssen Nutzen, Abhängigkeiten und Wechselkosten wesentlich genauer beschrieben werden.

Die Verbindung zum Configuration Management ist bewusst: Eine Vertrags- oder Kostenposition wird entscheidbarer, wenn bekannt ist, welchen Service und welche kritischen Systeme sie unterstützt. Die CMDB ersetzt keine Kostenübersicht. Sie kann aber erklären, warum eine scheinbar entbehrliche Position betrieblich relevant ist.

Kosten brauchen eine Leistungsseite

Im Praxisfall wurden nach der Umstellung nicht nur monatliche Ausgaben verglichen. Zusätzlich wurden externe Supportkosten und -stunden, Kosten je Nutzer, Lizenznutzung, Ticketmengen sowie mehrere Zeit- und Aufwandskennzahlen betrachtet.

Der Zusammenhang ist wichtig: Eine sinkende Rechnung beweist keine verbesserte Wirtschaftlichkeit. Vielleicht wurden Leistungen abgebaut, Tickets nicht mehr erfasst, Bearbeitungszeiten verlängert oder Risiken in die Zukunft verschoben. Erst die parallele Leistungssicht macht diese Entwicklung sichtbar.

Steuerungsfrage Mögliche Kennzahl Wichtige Grenze
Wie stark sind wir von externem Support abhängig? externe Supportstunden und -kosten Niedrige Kosten können auch fehlende Unterstützung bedeuten
Passt der Lizenzbestand zur Nutzung? aktive beziehungsweise berechtigte Nutzer im Verhältnis zu bezahlten Lizenzen Seltene Nutzung kann trotzdem geschäftskritisch sein
Wie verändert sich der Unterstützungsbedarf? Anzahl der Tickets, sinnvoll nach Art und Priorität getrennt Weniger Tickets sind nicht automatisch besser
Wie schnell beginnt die Bearbeitung? Zeit bis zur ersten qualifizierten Reaktion Eine automatische Eingangsbestätigung ist noch keine Bearbeitung
Wie lange wartet der Nutzer auf eine Lösung? Zeit bis zur Lösung oder zu einem tragfähigen Workaround Komplexität und Priorität müssen berücksichtigt werden
Wie viel aktive Arbeit bindet ein Ticket? durchschnittliche aktive Bearbeitungsdauer Liege- und Wartezeiten werden damit nicht sichtbar
Welche direkten internen Kosten verursacht die Bearbeitung? aktive Bearbeitungsdauer × interner Stundensatz Das Ergebnis sind keine vollständigen Ticket- oder Ausfallkosten

Das National Cyber Security Centre unterscheidet bei Dienstleistervereinbarungen ebenfalls zwischen der Zeit bis zum Beginn der Untersuchung und der Zeit bis zur Lösung beziehungsweise einem Workaround. Im beschriebenen Fall hießen diese Größen intern TTR für „Time to Respond“ und TTS für „Time to Solve“.

Diese Kürzel sind außerhalb des Falls nicht eindeutig genug. TTR wird in unterschiedlichen Organisationen für verschiedene Zeitbegriffe verwendet. Ein Bericht sollte deshalb nicht nur eine Abkürzung zeigen, sondern Startpunkt, Endpunkt, Betriebszeit, Pausenregeln und Prioritätsklassen definieren.

PeopleCert ordnet Kennzahlen als Mittel ein, um Wirksamkeit und zeitnahe Wiederherstellung zu bewerten. Daraus folgt kein universelles KPI-Set. Die richtigen Kennzahlen hängen von der Entscheidung ab, die eine Organisation treffen möchte.

Durchschnittliche Ticketkosten sind ein Näherungswert

Im Praxisfall wurden durchschnittliche direkte Ticketkosten aus der aktiven Bearbeitungsdauer und einem internen Stundensatz abgeleitet:

direkte interne Ticketkosten =
aktive Bearbeitungsdauer × interner Stundensatz

Das ist für Vergleiche nützlich. Es zeigt beispielsweise, ob eine Ticketart regelmäßig viel interne Kapazität bindet und ob Standardisierung oder Automatisierung wirtschaftlich prüfenswert ist.

Die Zahl ist trotzdem keine vollständige Prozesskostenrechnung. Sie enthält je nach Abgrenzung nicht:

  • Warte- und Liegezeiten,
  • Koordination und Eskalation außerhalb des Tickets,
  • anteilige Tool-, Infrastruktur- und Führungskosten,
  • externe Pauschalverträge,
  • Produktivitätsverluste betroffener Nutzer,
  • Ausfallkosten des Unternehmens,
  • oder die Kosten späterer Folgeprobleme.

Im Bericht sollte sie deshalb „direkte interne Bearbeitungskosten“ heißen. Wer sie als vollständige Ticketkosten ausgibt, erzeugt eine Genauigkeit, die das Modell nicht besitzt.

Auch der Durchschnitt kann täuschen. Wenige sehr aufwendige Störungen und viele einfache Requests können sich zu einem unauffälligen Mittelwert verrechnen. Für Entscheidungen sollten Ticketart, Priorität und gegebenenfalls Verteilung betrachtet werden. Eine einzelne Zahl ersetzt keine Ursachenanalyse.

Kostenverantwortung braucht Entscheidungsrecht

Lieferanten und Vertragspartner liefern Rechnungen, Preis- und Vertragsinformationen. Damit stellen sie einen wichtigen Teil der Datengrundlage bereit. Sie können jedoch nicht entscheiden, welchen betrieblichen Wert eine Leistung für das Unternehmen besitzt oder ob ihre Nutzung angemessen ist.

Im Praxisfall verantwortete die IT-Leitung die Kosten. Sie traf auch die Entscheidungen über Vertragskündigungen, Softwareabschaffungen und die Einstellung des Administrators. Grundlage war ein dokumentierter Entscheidungsrahmen, der im Unternehmen als Letter of Authority, kurz LoA, bezeichnet wurde.

Der LoA ist hier eine Beschreibung des konkreten Organisationsmodells, keine allgemeine IT-Controlling-Vorgabe. Seine konkreten Inhalte und Wertgrenzen werden nicht veröffentlicht. Entscheidend ist das Prinzip: Wer eine Kostenposition verantwortet, benötigt einen bekannten Rahmen, in dem er tatsächlich entscheiden darf. Außerhalb dieses Rahmens muss der Eskalations- und Freigabeweg klar sein.

Ohne Entscheidungsrecht wird Kostenverantwortung zur Berichtspflicht. Die IT-Leitung sammelt Zahlen, kann aber weder einen Altvertrag beenden noch interne Kompetenz aufbauen. Der Beitrag „Verantwortlichkeiten als Voraussetzung für skalierbaren IT-Betrieb“ zeigt, warum Verantwortung, Befugnis und technische Umsetzung zusammenpassen müssen.

Nicht jede Lizenzreduktion ist eine Einsparung

Eine häufige Reaktion auf hohe Softwarekosten lautet: pauschal Lizenzen reduzieren. Das kann sinnvoll sein, wenn ungenutzte oder doppelte Positionen nachweisbar sind. Es ist riskant, wenn allein der sichtbare Nutzungszähler entscheidet.

Eine selten verwendete Software kann einen hohen Wert besitzen, weil sie bei Monatsabschluss, Störung, Audit oder einem spezialisierten Fachprozess benötigt wird. Umgekehrt kann ein häufig genutztes Werkzeug durch Doppelarbeit oder schlechte Integration unverhältnismäßige Folgekosten verursachen.

Vor einer Reduktion sollten deshalb mindestens vier Fragen beantwortet werden:

  1. Welcher Prozess oder Service benötigt die Lizenz?
  2. Wie häufig und wie kritisch ist die Nutzung?
  3. Welche Alternative besteht einschließlich Umstellung und Schulung?
  4. Welche Betriebs-, Sicherheits- oder Vertragsfolge entsteht beim Entfall?

Wirtschaftlichkeit bedeutet nicht, jede seltene Nutzung zu erhalten. Sie bedeutet, eine bewusste Entscheidung über Kosten, Nutzen und Risiko zu treffen.

Der Fall zeigt Wirkung, aber keinen Benchmark

Die 30-Prozent-Reduktion ist für den beschriebenen Fall belastbar abgegrenzt: monatliche Kosten vorher und nachher, ein Jahr Betrachtungszeitraum, vollständige interne Kosten der neuen Admin-Stelle eingeschlossen. Die Maßnahmen sind benannt.

Die Zahl lässt sich trotzdem nicht auf andere Unternehmen übertragen. Ausgangsverträge, Lizenzbestand, Supportmodell, interne Kompetenz und technische Landschaft unterscheiden sich. Ein Unternehmen mit bereits optimierten Verträgen wird denselben Hebel nicht besitzen. Ein anderes muss möglicherweise zunächst mehr investieren, um Sicherheits- oder Betriebsrisiken zu reduzieren.

Ebenso wenig belegt die Kostenreduktion allein, dass jede Leistungskennzahl besser wurde. Die KPI wurden eingerichtet, um Kosten und Performance gemeinsam steuern zu können. Konkrete Verbesserungswerte für Reaktions- oder Lösungszeiten werden hier nicht behauptet.

Der wirtschaftliche Fortschritt liegt daher auf zwei Ebenen:

  • Die betrachteten Gesamtkosten sanken unter ehrlicher Einbeziehung interner Arbeit.
  • Die IT-Leitung konnte Kosten anschließend mit Nutzung, Supportaufwand und betrieblicher Leistung verbinden.

Der zweite Punkt ist langfristig wichtiger. Eine einmalige Vertragsbereinigung spart Geld. Ein Steuerungsmodell verhindert, dass dieselbe Unklarheit erneut entsteht.

Wann eine einfache Übersicht nicht mehr reicht

Für eine kleine oder mittlere IT kann eine gepflegte Übersicht mit klarer Kostenverantwortung genügen. Ein formelleres IT-Controlling wird erforderlich, wenn Entscheidungen eine genauere Zuordnung verlangen, beispielsweise bei:

  • mehreren Gesellschaften, Standorten oder Kostenstellen,
  • gemeinsam genutzten Plattformen mit strittiger Kostenverteilung,
  • komplexen Cloud- und nutzungsabhängigen Kosten,
  • internen Leistungsverrechnungen oder Servicepreisen,
  • Investitionen mit mehrjähriger Abschreibung und umfangreichen Migrationskosten,
  • regulatorischen, steuerlichen oder prüfungsbezogenen Nachweisen,
  • oder Portfolios, in denen Alternativen anhand konsistenter Business Cases verglichen werden müssen.

Dann reicht eine Tabellenliste fachlich und technisch möglicherweise nicht mehr. Kostenmodell, Buchhaltung, Asset- und Vertragsdaten sowie Serviceinformationen müssen sauber zusammenspielen. Das ist ein Ausbaugrund, aber kein Argument, bereits den Einstieg unnötig schwer zu machen.

Beginnen Sie mit einer Entscheidung, nicht mit einer Kostensenkung

Nehmen Sie nicht zuerst das gesamte IT-Budget auseinander. Wählen Sie eine wiederkehrende Kostenposition, deren Zweck, Nutzung oder Verantwortlichkeit heute unklar ist.

Klären Sie:

  1. Was kostet sie intern und extern?
  2. Welche Leistung und welches Risiko sind damit verbunden?
  3. Welche Nutzungs- und Leistungskennzahl hilft bei der Entscheidung?
  4. Wer darf innerhalb welchen Rahmens entscheiden?
  5. Bis wann muss entschieden werden?

Das Ergebnis muss nicht „kündigen“ lauten. Fortführen, neu verhandeln, konsolidieren, ersetzen oder bewusst ausbauen können ebenso wirtschaftliche Entscheidungen sein.

Eine gute IT-Kostenübersicht zeigt deshalb nicht nur, wo Geld ausgegeben wird. Sie zeigt, welche Entscheidung als Nächstes getroffen werden muss und woran ihre Wirkung erkennbar wird.

Quellen

  1. ITIL 4 Practitioner: IT Asset Management – PeopleCert
  2. ISO/IEC 19770-1:2017 Information technology — IT asset management — Part 1: IT asset management systems — Requirements – International Organization for Standardization
  3. Cabinet Office Architecture Principles – UK Cabinet Office
  4. Choosing a managed service provider (MSP) – UK National Cyber Security Centre
  5. ITIL 4 Practitioner: Incident Management – PeopleCert