News

Server erreichbar, Datenbank verfügbar, Schnittstellen aktiv: Auf dem Monitoring-Dashboard sieht alles gut aus. Trotzdem kann kein Auftrag verbucht, keine Bestellung abgeschlossen oder keine Rechnung erstellt werden. Das ist kein Widerspruch. Es zeigt vielmehr die Grenzen des Infrastruktur-Monitorings – und warum IT-Verfügbarkeit aus Sicht des Geschäftsprozesses bewertet werden muss.

Es ist eine der unangenehmsten Situationen im IT-Betrieb: Anwender melden eine Störung, doch das Dashboard zeigt fast ausschließlich Grün. Der Webserver antwortet, die Datenbank ist erreichbar, der SAP-Host läuft und der relevante Dienst ist gestartet. Trotzdem steht ein wichtiger digitaler Geschäftsprozess.

In solchen Momenten liegt die erste Vermutung oft nahe: Das Monitoring hat versagt. Häufig ist das jedoch nicht der eigentliche Punkt. Die vorhandenen Prüfungen haben genau das gemessen, wofür sie eingerichtet wurden. Sie haben nur nicht die entscheidende Frage gestellt. Ein grüner Status beweist nicht, dass der Geschäftsprozess funktioniert. Er bestätigt zunächst nur, dass eine konkrete technische Prüfung erfolgreich war.

Aus meiner Sicht beginnt IT-Qualität deshalb nicht beim grünen Hoststatus. Sie beginnt dort, wo sichtbar wird, ob die IT ihren Zweck für das Unternehmen erfüllt. Das bedeutet nicht, dass klassisches Infrastruktur-Monitoring an Bedeutung verliert. Im Gegenteil: Es bleibt die unverzichtbare Basis. Doch bei digitalisierten Prozessketten reicht diese Basis allein nicht aus.

Was ein grüner Status im Monitoring wirklich bedeutet

Jeder Monitoring-Status ist die Antwort auf eine zuvor definierte Prüffrage. Ein Ping beantwortet, ob ein Host über das Netzwerk erreichbar ist. Ein Port-Check zeigt, ob eine Verbindung zu einem bestimmten Port aufgebaut werden kann. Eine Service-Prüfung erkennt, ob ein Prozess läuft. Ein Schwellwert prüft, ob CPU-Auslastung, Speicher oder Antwortzeit innerhalb eines festgelegten Bereichs liegen.

Alle diese Informationen sind wertvoll. Ihre Aussagekraft endet aber an der Grenze der jeweiligen Prüfung. Das zeigen einige typische Beispiele:

• Ein erfolgreicher Ping belegt, dass ein Server über das Netzwerk erreichbar ist. Ob die Anwendung auf diesem Server korrekt reagiert, bleibt offen.

• Der technisch erfolgreiche Aufruf einer Startseite sagt noch nicht, ob Anmeldung, Suche oder Bestellvorgang funktionieren.

• Ein offener Port zeigt, dass eine Verbindung aufgebaut werden kann. Das übertragene Ergebnis kann trotzdem leer, fehlerhaft oder fachlich ungültig sein.

• Ein erfolgreicher Datenbank-Login bestätigt, dass die Datenbank Verbindungen annimmt. Eine wichtige Abfrage kann dennoch blockiert oder zu langsam sein oder veraltete Daten liefern.

• Ein technisch abgeschlossener Hintergrundjob beweist nicht, dass das nachgelagerte System sein Ergebnis übernommen hat.

• Ein laufender Queue-Dienst schließt nicht aus, dass sich Nachrichten stauen oder nicht weiterverarbeitet werden.

Das Problem ist somit nicht die Farbe Grün. Problematisch wird es, wenn ihre Bedeutung zu weit ausgelegt wird.

Warum Komponentenverfügbarkeit keine Prozessverfügbarkeit ist

Ein digitaler Geschäftsprozess besteht selten aus nur einer Anwendung. Selbst ein scheinbar einfacher Bestellvorgang kann Webshop, Identitätsdienst, Zahlungsanbieter, Netzwerk, Datenbank, Middleware, ERP-System, Lagerverwaltung und E-Mail-Versand verbinden. Hinzu kommen externe Cloud-Dienste, Partnerplattformen oder standortübergreifende Verbindungen. In großen und verteilten IT-Umgebungen hilft Distributed Monitoring dabei, die dezentral erfassten Zustände in einer zentralen Sicht zusammenzuführen.

Jede Komponente kann für sich verfügbar sein, während die Übergabe zwischen zwei Systemen scheitert. Genau an diesen Übergängen entstehen häufig die schwer sichtbaren Störungen: Ein Datenformat wurde geändert, ein Zertifikat wird nicht mehr akzeptiert, eine Queue wächst unbemerkt, ein Timeout ist zu knapp gesetzt oder ein fachlich notwendiges Feld bleibt leer.

Ob ein Geschäftsprozess verfügbar ist, lässt sich deshalb nicht pauschal aus den Statuswerten seiner Komponenten ableiten. Entscheidend ist, wie die einzelnen Systeme und Dienste zusammenwirken: Welche Abhängigkeit ist zwingend erforderlich? Wo gibt es Redundanzen oder alternative Wege? Welches Ergebnis muss am Ende tatsächlich entstehen? Erst diese Prozesslogik zeigt, ob ein technischer Fehler den Ablauf beeinträchtigt oder ohne spürbare Auswirkung bleibt.

Fällt beispielsweise einer von zwei redundant ausgelegten Servern aus, kann der Geschäftsprozess weiterhin funktionieren. Ist dagegen ein einziger nicht redundant vorhandener Identitätsdienst gestört, kann die gesamte Prozesskette stehen. Ein Dashboard, das beide Ereignisse gleich gewichtet, zeigt technische Zustände – aber noch keine belastbare Geschäftsauswirkung. Die Blickrichtung sollte deshalb immer beim Geschäftsprozess beginnen. Er bestimmt, welche technische Leistung in welcher Qualität benötigt wird.

Fünf typische Ursachen für Prozessstörungen trotz grüner Systemstatus

1. Es werden Komponenten geprüft, aber nicht ihre Übergaben

In gewachsenen IT-Landschaften liegen Monitoring-Verantwortlichkeiten oft bei unterschiedlichen Teams. Das Netzwerkteam überwacht Verbindungen, die Servergruppe Hosts und Ressourcen, das Applikationsteam einzelne Anwendungen und ein externer Anbieter seinen Cloud-Service. Innerhalb der jeweiligen Zuständigkeit kann alles funktionieren. Die Lücke liegt zwischen den Bereichen.

Für den Geschäftsprozess ist jedoch nicht entscheidend, ob jedes Team einen grünen Teilstatus sieht. Entscheidend ist, ob die notwendige Information vollständig und rechtzeitig von einem Prozessschritt zum nächsten gelangt.

2. Technische Erreichbarkeit wird mit fachlicher Funktionsfähigkeit verwechselt

Ein HTTP-Status 200 bedeutet, dass eine Anfrage technisch erfolgreich beantwortet wurde. Er sagt nicht automatisch, dass ein Nutzer die erwartete Aktion durchführen konnte. Eine Webseite kann erreichbar sein, während das Anmeldeformular fehlschlägt. Ein ERP-System kann laufen, obwohl ein wichtiger Buchungsprozess keine Belege verarbeitet.

Die fachliche Prüffrage muss daher lauten, ob das erwartete Ergebnis tatsächlich erreicht wurde. Bei einem Bestellprozess könnte das ein korrekt angelegter Auftrag sein, bei einem Registrierungsprozess ein aktiviertes Benutzerkonto und bei einer Datenübertragung ein vollständig verarbeiteter Datensatz im Zielsystem.

3. Datenqualität bleibt außerhalb der Prüfung

Viele Prozessstörungen sind keine klassischen Ausfälle. Systeme übertragen Daten, doch diese sind unvollständig, doppelt, verspätet oder fachlich nicht plausibel. Technisch betrachtet funktioniert die Verbindung. Aus Sicht des Unternehmens ist das Ergebnis dennoch unbrauchbar.

Ein aussagekräftiges Geschäftsprozess-Monitoring muss deshalb – soweit technisch und datenschutzrechtlich sinnvoll – nicht nur Transport und Antwortzeit, sondern auch erwartete Ergebnisse oder definierte Plausibilitätsmerkmale berücksichtigen.

4. Externe Abhängigkeiten fehlen im Gesamtbild

Zahlungsdienste, Identitätsprovider, Cloud-Anwendungen, Logistikpartner oder öffentliche Schnittstellen sind Teil vieler digitaler Prozesse. Sie liegen jedoch nicht vollständig unter der Kontrolle der internen IT. Bleiben diese Abhängigkeiten im Prozessmodell unsichtbar, zeigt das interne Dashboard Grün, während der Anwender am externen Prozessschritt nicht weiterkommt.

Das Monitoring muss nicht jedes Fremdsystem intern durchleuchten können. Es sollte aber prüfen, ob die vom eigenen Geschäftsprozess benötigte externe Leistung verfügbar ist und die erwartete Antwort liefert.

5. Zeit und Reihenfolge werden nicht ausreichend berücksichtigt

Einzelprüfungen sind Momentaufnahmen. Geschäftsprozesse sind Abläufe. Eine Transaktion kann nur dann erfolgreich sein, wenn mehrere Schritte in der richtigen Reihenfolge und innerhalb einer akzeptablen Zeit stattfinden. Werden Daten zwar verarbeitet, erreichen ihr Ziel aber erst Stunden später, sind alle beteiligten Systeme möglicherweise verfügbar – der Prozess erfüllt seine Aufgabe dennoch nicht rechtzeitig.

Neben dem Status gehören deshalb Dauer, Durchsatz, Rückstau und zeitliche Abweichungen zu einer belastbaren Prozesssicht.

Von der Infrastruktur zum Geschäftsprozess: fünf Monitoring-Ebenen

Die Grenzen des Infrastruktur-Monitorings lassen sich nicht durch einen einzigen zusätzlichen Check überwinden. Notwendig ist ein abgestuftes Modell, in dem jede Ebene eine eigene Frage beantwortet.

Ebene 1: Infrastruktur-Monitoring

Sind Server, Netzwerkgeräte, Speicher, Betriebssysteme und Ressourcen grundsätzlich verfügbar? Diese Ebene erkennt technische Ausfälle und Engpässe und bildet das Fundament jeder weiterführenden Überwachung.

Ebene 2: Service- und Applikations-Monitoring

Funktionieren die benötigten Dienste und Anwendungen? Beim Applikations-Monitoring werden nicht nur Hosts, sondern beispielsweise Datenbanken, Webservices, Prozesse, Schnittstellen oder SAP-nahe Funktionen geprüft.

Ebene 3: Abhängigkeits- und Service-Sicht

Welche Komponenten tragen gemeinsam einen IT-Service oder Geschäftsprozess? Prozessmodellierung beziehungsweise Service Mapping macht sichtbar, welche Systeme kritisch, redundant oder nur unterstützend sind. Dadurch kann ein technischer Fehler nach seiner tatsächlichen Auswirkung bewertet werden.

Ebene 4: End-to-End-Monitoring

Kann ein definierter Vorgang aus Sicht eines virtuellen oder realen Anwenders vollständig durchgeführt werden? Ein End-to-End-Test bildet nicht jede denkbare Nutzung ab. Er prüft aber einen repräsentativen Kernpfad – etwa Anmeldung, Suche, Bestellung und Bestätigung – vom Anfang bis zum erwarteten Ergebnis.

Ebene 5: Geschäfts- und Qualitätskennzahlen

Erfüllt der Prozess seine Aufgabe in der benötigten Qualität? Dazu können Prozessverfügbarkeit, Durchführungsdauer, Fehlerrate, Anzahl erfolgreich abgeschlossener Vorgänge oder Abweichungen vom üblichen Verlauf gehören. Die passenden Kennzahlen hängen vom konkreten Geschäftsprozess ab und sollten für IT, Service Desk und Management unterschiedlich aufbereitet werden.

Erst das Zusammenspiel dieser Ebenen schafft ein realistisches Lagebild. Die WOTAN-Plattform verbindet dafür Infrastruktur-, Applikations- und Prozess-Monitoring. Im WOTAN Prozess-Monitoring können technische Abhängigkeiten modelliert und Geschäftsprozesse sowohl auf Basis dieser Beziehungen als auch mittels End-to-End-Prüfungen überwacht werden.

So schließen IT-Teams die Lücke in der Praxis

Der Aufbau einer Prozesssicht muss nicht mit der vollständigen Modellierung der gesamten IT-Landschaft beginnen. Sinnvoller ist ein klar abgegrenzter, geschäftskritischer Vorgang.

1. Mit dem erwarteten Ergebnis beginnen

Definieren Sie den Prozess aus Anwender- oder Geschäftssicht: Was muss am Ende erfolgreich passiert sein? Die Erreichbarkeit des Webservers ist noch kein Prozessergebnis. Eine angenommene und im ERP-System angelegte Bestellung ist dagegen ein konkretes Ergebnis.

2. Den relevanten Kernpfad beschreiben

Welche Schritte durchläuft der Vorgang? Welche Anwendungen, Schnittstellen, Dienste und externen Partner werden benötigt? Nicht jede technische Komponente ist für jeden Prozess gleich wichtig. Konzentrieren Sie sich zunächst auf den sogenannten Golden Path, also den regulären, geschäftlich wichtigsten Ablauf.

3. Abhängigkeiten logisch bewerten

Kennzeichnen Sie kritische Einzelabhängigkeiten, Redundanzen und alternative Wege. Bei einer UND-Verknüpfung müssen mehrere Bedingungen erfüllt sein. Bei redundanten Ressourcen genügt möglicherweise eine verfügbare Instanz. Diese Logik entscheidet darüber, ob ein Komponentenfehler den Geschäftsprozess tatsächlich beeinträchtigt.

4. Technische und fachliche Prüfungen kombinieren

Ein End-to-End-Test zeigt, dass der Gesamtvorgang scheitert. Komponenten- und Service-Prüfungen helfen anschließend dabei, die Ursache einzugrenzen. Nur die Gesamtprüfung ohne technische Tiefe führt zu einer unspezifischen Fehlermeldung. Nur technische Tiefe ohne Gesamtprüfung lässt die Geschäftsauswirkung offen. Beide Perspektiven gehören zusammen.

5. Erfolgskriterien und Warnstufen festlegen

Unterscheiden Sie nicht nur zwischen verfügbar und nicht verfügbar. Legen Sie fest, welche Antwortzeit akzeptabel ist, wie lange Daten maximal in einer Queue liegen dürfen oder welche Fehlerrate eine Warnung auslöst. Schwellenwerte sollten die erwartete Servicequalität des Prozesses abbilden – nicht lediglich technisch leicht messbare Werte.

6. Dashboards nach Rollen ausrichten

Systemadministration, Service Desk, IT-Management und Geschäftsführung benötigen unterschiedliche Detailstufen. Administratoren brauchen technische Ursachenhinweise. Der Service Desk muss Auswirkungen und Bearbeitungsstatus kennen. Das Management benötigt verdichtete Kennzahlen zur Prozessqualität. Rollenbezogene KPI-Dashboards verhindern, dass wichtige Informationen in einer universellen, aber für niemanden wirklich passenden Ansicht untergehen.

7. Alarmierung an Handlungsfähigkeit koppeln

Ein erkannter Prozessfehler schafft noch keine Lösung. Es muss klar sein, wer bei welcher Auswirkung handeln kann, wie Vertretungen geregelt sind und wann die nächste Eskalationsstufe greift. Eine strukturierte IT-Eskalation verbindet den technischen Status mit Zuständigkeit, Reaktion und Nachvollziehbarkeit.

8. Die Prozesssicht nach Changes aktualisieren

Neue Releases, geänderte Schnittstellen, Cloud-Migrationen oder organisatorische Zuständigkeiten verändern Prozessketten. Ein Prozessmodell, das nach der Einführung nicht gepflegt wird, verliert schnell an Aussagekraft. Änderungen an kritischen Services sollten deshalb immer auch die Frage auslösen: Welche Abhängigkeiten, Prüfungen und Eskalationswege müssen angepasst werden?

Ein sinnvoller Startpunkt: ein Prozess, eine klare Frage

Für den Einstieg empfehle ich, nicht das gesamte Unternehmen auf einmal abzubilden. Wählen Sie einen Prozess, dessen Störung spürbare Auswirkungen hat und dessen Ablauf den beteiligten Teams grundsätzlich bekannt ist. Das kann ein Bestell-, Buchungs-, Registrierungs-, Produktions- oder Abrechnungsprozess sein.

Beantworten Sie dafür gemeinsam fünf Fragen:

1. Welches konkrete Ergebnis erwartet der Anwender oder das Unternehmen?

2. Welche Systeme und Übergaben sind dafür zwingend erforderlich?

3. Welche Ausfälle können durch Redundanzen kompensiert werden?

4. Welche technische Prüfung belegt jeden kritischen Schritt?

5. Wie wird eindeutig erkannt, dass der Gesamtvorgang erfolgreich abgeschlossen wurde?

Bereits diese Fragen verändern die Perspektive. Das Monitoring wird nicht länger nur entlang vorhandener Geräte und Zuständigkeiten aufgebaut, sondern entlang der Leistung, die die IT für das Unternehmen erbringen soll.

Fazit: Ein grünes Dashboard ist der Anfang, nicht das Ziel

Infrastruktur-Monitoring bleibt unverzichtbar. Ohne verlässliche Informationen zu Servern, Netzwerken, Ressourcen und Diensten fehlt jede technische Grundlage. Die Grenzen des Infrastruktur-Monitorings werden jedoch dort sichtbar, wo aus vielen einzeln verfügbaren Komponenten ein geschäftlich relevantes Ergebnis entstehen muss.

Geschäftsprozess-Monitoring schließt diese Lücke, indem es technische Abhängigkeiten, Servicequalität und End-to-End-Funktionsfähigkeit zusammenführt. Dadurch erhalten IT-Teams nicht nur mehr Daten, sondern mehr Kontext: Welcher Prozess ist betroffen? Welche Komponente ist tatsächlich kritisch? Kann der Anwender sein Ziel erreichen? Wer muss handeln?

Für mich ist genau das der Unterschied zwischen einer IT, die lediglich betrieben wird, und einer IT, die zur Stärke des Unternehmens wird: Ihre Qualität ist messbar, ihre Wirkung transparent und ihre Reaktion verlässlich.

Sie möchten wissen, wie sich kritische Geschäftsprozesse und ihre technischen Abhängigkeiten mit WOTAN sichtbar machen lassen? Lernen Sie das WOTAN Prozess-Monitoring kennen oder vereinbaren Sie ein unverbindliches Gespräch.