Ihr IT-Support hält alle SLAs. Der Vorgang steht trotzdem still?

Die Kernaussage vorweg: Ein Betriebsvertrag verspricht Reaktionszeit auf gemeldete Störungen. Beide Wörter sind das Problem. Ein stehender Vorgang wird nicht gemeldet, weil intern niemand auf ihn wartet, und er ist keine Störung, weil nichts kaputt ist. Das Risiko ist derweil in die Schicht darüber gewandert, in das Zusammenspiel der Systeme — und dorthin reicht kein Verfügbarkeits-SLA. Das ist kein Vorwurf an Ihren Dienstleister: Er erfüllt, was vereinbart wurde. Vereinbart wurde nur etwas anderes, als Sie heute brauchen.

Was ein Verfügbarkeits-SLA tatsächlich zusichert

Lesen Sie Ihren Vertrag einmal mit dieser Frage: Was genau ist der Gegenstand?

In aller Regel steht dort die Erreichbarkeit eines Systems, die Reaktionszeit auf ein Ticket und eine Wiederherstellungszeit nach einem Ausfall. Drei Größen, die sich sauber messen lassen und über die man streiten kann. Alle drei setzen voraus, dass jemand etwas bemerkt und meldet.

Der teuerste Zustand in einem Geschäftsprozess erfüllt keine dieser Voraussetzungen. Der Vorgang steht, das System läuft, das Ticket existiert nicht. Die Uhr, die im Vertrag steht, läuft nie los.

Das Risiko wandert nach oben

Das ist keine Vermutung, es ist in den Zahlen sichtbar. Bei Ausfällen, die auf IT-Systeme und Software zurückgehen, waren die häufigste Ursache über Jahre hinweg Konfigurations- und Änderungsfehler — also Bedienfehler im weitesten Sinn. In der Erhebung 2026 liegen erstmals Firmware- und Softwarefehler vorn, knapp vor den Konfigurationsfehlern.

Der Bericht zieht daraus selbst den Schluss, den wir hier weiterdenken: Das Ausfallrisiko wandere tiefer in den Technologie-Stack, weg von bedienerverursachten Fehlern hin zu Fehlern im Softwareverhalten, in Updates und im Zusammenspiel zwischen Komponenten.

Und ein zweiter Satz aus derselben Passage ist für Geschäftsprozesse noch wichtiger: Probleme, die früher lokal geblieben wären, könnten sich heute über Systeme hinweg ausbreiten, bevor sie entdeckt werden.

Genau dort (im Zusammenspiel zwischen Komponenten, vor der Entdeckung) lebt ein Geschäftsprozess. Er ist nichts anderes als eine Kette von Übergaben zwischen Systemen und Menschen.

Eine Einschränkung gehört dazu, und wir nennen sie gleich selbst: Uptime befragt Rechenzentrumsbetreiber, und die zitierte Detailfrage beruht auf 74 Antworten. Das ist ein Trendsignal aus der Nachbarschicht, keine Messung an Geschäftsprozessen. Eine solche Messung gibt es öffentlich nicht, was ja für sich genommen schon etwas aussagt.

Wer meldet, wenn niemand wartet?

Der entscheidende Unterschied zwischen einem Systemausfall und einem stehenden Vorgang ist nicht technischer Natur. Er liegt darin, wer wartet.

Fällt ein System aus, warten alle gleichzeitig und im Haus. Die Meldung braucht keine Organisation, sie entsteht von selbst. Bleibt dagegen ein einzelner Vorgang stehen, wartet in der Regel genau eine Person und die sitzt draußen. Ein Kunde, ein Lieferant, ein Bewerber. Jemand, der Ihr Ticketsystem nicht kennt und der nicht anruft, sondern erst wartet, dann nachfragt und schlimmstenfalls irgendwann geht.

Die Meldung, auf die Ihr Vertrag wartet, kommt in diesem Fall von der falschen Seite und zu spät, wenn sie überhaupt kommt.

Warum das mit mehr Servicelevel nicht besser wird

Der naheliegende Reflex ist, die Reaktionszeit zu verschärfen. Vier Stunden statt acht, rund um die Uhr statt werktags. Das kostet Geld und ändert nichts, weil die Uhr gar nicht erst startet.

Ebenso wenig hilft ein weiteres Werkzeug allein. Eine Auswertung, die im Nachhinein aus Protokollen liest, sagt Ihnen, was passiert ist. Sie bringt den Vorgang nicht weiter. Zwischen „hier ist eine Abweichung“ und „der Vorgang läuft wieder“ liegt eine Entscheidung, und die ist fachlich: Darf der Schritt wiederholt werden? Sind die Daten inzwischen veraltet? Was macht das angebundene System mit einem zweiten Datensatz? Ein Werkzeug meldet. Es entscheidet nicht.

Damit ist die eigentliche Frage nicht, wie schnell jemand reagiert, sondern wem der Fehler gehört. Ein Hersteller beantwortet, ob die Engine läuft. Er beantwortet nicht, warum Vorgang 4711 in Schritt drei steht und ob man ihn wiederholen darf.

Die vier Größen, die stattdessen im Vertrag stehen müssten

Wenn Verfügbarkeit der falsche Gegenstand ist, braucht es einen anderen. Vier Größen reichen, und sie sind alle messbar:

1. Durchlaufzeit je Vorgangsart, gegen die eigene Verteilung geprüft, nicht gegen einen Wunschwert.
2. Bestandsalter, also wie alt ist der älteste offene Vorgang je Schritt.
3. Mengengerüst, das klärt: kommen heute so viele Vorgänge an wie üblich.
4. Korrekturquote, die angibt wie oft ein Ergebnis nachgearbeitet werden musste, erfasst als eigener Vorgang, nicht geschätzt.

Ein Hinweis aus der Praxis dazu, weil hier die meisten Versuche scheitern: Grenzwerte gehören an den einzelnen Schritt und an die Vorgangsart, nicht an den Prozess als Ganzes. Ein globaler Schwellwert erzeugt Fehlalarme, und ein Alarm, den zweimal niemand ernst genommen hat, wird nie wieder ernst genommen. Der Schwellwert muss aus der tatsächlichen Verteilung kommen, und er muss nachjustiert werden, wenn sich das Geschäft ändert.

Diese vier Größen sind Prozesskennzahlen, keine IT-Kennzahlen. Ein Vertrag, dessen Gegenstand ein System ist, kann sie nicht tragen — wer sie zusagen soll, muss den Ablauf kennen. Das ist der eigentliche Unterschied zwischen Systembetrieb und Prozessbetrieb, und er ist kein Qualitätsunterschied, sondern ein Gegenstandsunterschied.

Wie sich solche Abweichungen im Alltag zeigen, haben wir an zwei Beispielen aus Lager und e-Commerce ausführlicher beschrieben: warum klassischer IT-Support für digitale Prozesse nicht ausreicht.

KI-Agenten machen die Lücke größer, nicht kleiner

Bis hierher ging es um Prozesse, in denen Menschen und Systeme sich abwechseln. Der Zuschnitt ändert sich gerade. 11 % der Unternehmen setzen KI-Agenten bereits ein, 29 % planen es, 31 % diskutieren es.

Ein Agent ist definitionsgemäß etwas, das selbstständig handelt. Damit verschwindet die letzte Instanz, die bisher unauffällige Fehler gefunden hat: der Mensch, dem etwas komisch vorkam.

Die Zahlen dazu sind eindeutig. Nur 21 % der Unternehmen haben nach eigener Einschätzung ein ausgereiftes Governance-Modell für agentische KI. Rund 80 % fehlen die Fähigkeiten, die man dafür bräuchte — und es sind genau die drei, um die es in diesem Beitrag geht: klare Grenzen, welche Entscheidungen ein Agent allein treffen darf und welche eine menschliche Freigabe brauchen; eine Überwachung in Echtzeit, die das Verhalten verfolgt und Abweichungen meldet; und eine lückenlose Aufzeichnung der Handlungskette.

Deloitte formuliert die Folge in drei Worten: Agenten können „unbemerkte Fehler“ machen.

Wer einen Agenten in einen Ablauf setzt, braucht dieselben drei Dinge wie bei jedem nicht deterministischen Schritt: ein maschinell prüfbares Abnahmekriterium, einen Rückfallpfad an einen Menschen, und die Korrektur als erfassten Vorgang. Wir haben das an anderer Stelle vertieft, unter der Frage, warum KI-Agenten am Prozess scheitern und nicht am Modell.

Fünf Fragen an Ihren Betriebsvertrag

Diese Liste taugt auch für das Angebot eines fremden Anbieters.

1. Was ist der Gegenstand — ein System oder ein Ablauf? Steht im Vertrag die Verfügbarkeit einer Anwendung, ist der Gegenstand das System. Dann ist alles Weitere Auslegung, und Sie werden sie im Ernstfall verlieren.
2. Was passiert, wenn niemand meldet? Wenn die Antwort lautet „dann liegt keine Störung vor“, kennen Sie Ihre Lücke. Fragen Sie nach, welche Abweichung ohne menschliche Meldung ein Ticket erzeugt — und lassen Sie sich das zeigen, nicht zusichern.
3. Wer entscheidet, ob ein Schritt wiederholt werden darf? Die Antwort muss ein Name oder eine Rolle sein, nicht ein Prozess. Lautet sie „das klären wir mit dem Fachbereich“, dauert jeder Zwischenfall mindestens einen Tag länger.
4. Welche vier Zahlen bekomme ich monatlich? Durchlaufzeit, Bestandsalter, Mengengerüst, Korrekturquote. Wer sie nicht liefern kann, betreibt Ihr System, nicht Ihren Prozess.
5. Was kostet ein Vorgang, den Ihr Kunde entdeckt? Diese Zahl steht in keiner Studie, und wer Ihnen einen Faktor nennt, hat ihn geschätzt. Sie müssen sie selbst rechnen: Nacharbeit, Kommunikation, Wiederherstellung, und was ein verlorener Kunde wert war. Ohne diese Rechnung ist jede Investition in Überwachung Geschmackssache.

Wo dieser Gedanke nicht trägt

Zwei Einschränkungen, die wir lieber selbst nennen.

Der Systembetrieb wird dadurch nicht überflüssig. Jemand muss weiterhin sichern, aktualisieren und dafür sorgen, dass die Maschine läuft. Prozessbetrieb kommt dazu, er ersetzt nichts — und wer ihn als Ersatz verkauft, hat entweder nie ein Rechenzentrum betrieben oder verschweigt etwas.

Und es lohnt sich nicht überall. Ein Ablauf mit zwölf Vorgängen im Jahr braucht keine Überwachung mit Schwellwerten, sondern einen Kalendereintrag. Der Aufwand trägt sich erst, wenn die Fallzahl hoch genug ist, dass ein stehender Vorgang untergeht — und das ist eine Rechnung, keine Überzeugung.

Was wir dazu anbieten

Wir haben die Technik dafür im Haus: Prozess- und Regel-Engines auf offenen Standards, die Anbindung an Ihre Bestandssysteme, Betrieb in der Cloud oder in Ihrem Rechenzentrum, vollständige Protokollierung auf Prozessebene — und den fachlichen Support, der einen Ablauf über Jahre stabil hält. Gemessen wird dabei der Schritt, nicht die Person: Uns interessiert die Zahl der Vorgänge, nicht wer sie bearbeitet hat.

Der Unterschied liegt nicht in der Überwachung. Den Teil kann inzwischen jede ernsthafte Engine. Er liegt darin, wer im dritten Betriebsjahr noch hinsieht und wer entscheidet, wenn ein Vorgang nicht weiterläuft.

Der Einstieg ist wie immer ein einzelner Ablauf: ein Prozess-Schnitt zum Festpreis. Am Ende wissen Sie, wie lange er heute dauert, wo die Zeit liegen bleibt und welche vier Zahlen Sie künftig monatlich sehen sollten. Ein mögliches Ergebnis ist, dass sich der Aufwand bei Ihrer Fallzahl nicht lohnt — dann sagen wir Ihnen das.

Den Vorgang, der bei Ihnen regelmäßig liegen bleibt, kennen Sie vermutlich längst.