Du betreibst einen Onlineshop. Gerade jetzt will jemand bezahlen. Der Checkout ist kaputt. Der Kunde bekommt einen Fehler. Der Kunde geht. Du hast gerade einen Verkauf verloren.
Ohne operatives Dashboard würdest du den Fehler erst morgen bemerken, wenn du den Tagesbericht prüfst.
Mit operativem Dashboard entdeckt das Betriebsteam den Fehler innerhalb von Sekunden. Es behebt ihn sofort. Der Kunde versucht es erneut. Der Verkauf geht durch.
Kosten langsamer Erkennung: hunderte Dollar pro Stunde und Fehler.
Operative Dashboards erkennen Probleme in Echtzeit, nicht Stunden oder Tage später.
Die Aufgabe operativer Dashboards
Operative Dashboards überwachen die Gesundheit des Systems und laufende Vorgänge.
Ist die Website erreichbar? Funktionieren die Abläufe im Checkout? Antworten die Zahlungsdienste? Werden E-Mails versendet? Laufen die API-Aufrufe durch?
Ein operatives Dashboard dreht sich nicht um Umsatz oder Geschäftskennzahlen. Es geht um die Gesundheit des Systems.
Anforderung an Echtzeit-Daten
Ein operatives Dashboard muss in Echtzeit oder nahezu in Echtzeit aktualisiert werden (innerhalb einer Minute).
Verzögerte Daten sind nutzlos. Wenn sich das Dashboard stündlich aktualisiert, verpasst du Ausfälle, die zwischen den Aktualisierungen passieren.
Die Echtzeit-Anforderung bedeutet: Ein operatives Dashboard ist aufwendig zu bauen und zu pflegen. Nutze es nur für kritische Systeme.
Was du auf einem operativen Dashboard überwachst
Verfügbarkeit des Systems
Antwortet die Website? Grün, wenn sie läuft, rot, wenn sie ausgefallen ist.
Antwortzeit
Wie schnell ist die Website? Grün unter 2 Sekunden, gelb bei 2 bis 5 Sekunden, rot über 5 Sekunden.
Fehlerrate
Welcher Anteil der Anfragen liefert Fehler? Grün unter 0,1 %, gelb bei 0,1 % bis 0,5 %, rot über 0,5 %.
Laufende Transaktionen
Wie viele Transaktionen laufen gerade? Zur Orientierung. Nicht von sich aus gut oder schlecht.
Conversion-Trichter in Bewegung
Wie viele Besucher befinden sich gerade in welchem Schritt des Checkouts? Ein Abbruch in einem Schritt löst eine Untersuchung aus.
Leistung der APIs
Antwortzeiten externer Anbindungen. Zahlungsdienst, E-Mail-Dienst, Versand-API.
Leistung der Datenbank
Antwortzeiten von Abfragen, Zustand des Verbindungspools.
Echtes Beispiel: operatives Dashboard für einen Onlineshop
Oberer Bereich (Systemzustand)
Status der Website: ONLINE (grün). Antwortzeit: 1,2 Sekunden (grün). Fehlerrate: 0,08 % (grün). Aktive Nutzer: 423. Laufende Transaktionen: 17.
Mittlerer Bereich (Checkout-Trichter)
Warenkorb angesehen: 127 Nutzer. Checkout gestartet: 89 Nutzer (70 % Conversion vom Warenkorb). Versandangaben: 72 Nutzer (81 % Conversion). Zahlungsangaben: 68 Nutzer (94 % Conversion). Bestellbestätigung: 64 Nutzer (94 % Conversion). Abbruch bei den Versandangaben: 17 Nutzer (Moment, das ist höher als normal, untersuchen).
Unterer Bereich (Anbindungen)
Zahlungsdienst: antwortet in 800 ms (grün). E-Mail-Dienst: 99,8 % Zustellung (grün). Versandrechner: antwortet in 1200 ms (gelb, etwas langsam).
Sofortige Handlung
Der Abbruch bei den Versandangaben ist höher als normal. Untersuche, ob die Langsamkeit des Versandrechners die Abbrüche verursacht.
Alarmsystem
Ein operatives Dashboard sollte Alarme auslösen, wenn Kennzahlen rot werden.
Alarmiere das Betriebsteam sofort. Nicht per E-Mail, die übersehen werden kann. Per SMS, Chat oder Pager, die unterbrechen.
Die Schwellenwerte sollten streng sein. Du willst keine Fehlalarme. Aber lieber ein Fehlalarm und ein echtes Problem erkannt, als Probleme zu verpassen.
Beispiele für Schwellenwerte: Website 30 Sekunden nicht erreichbar = Alarm. Fehlerrate über 1 % für 5 Minuten = Alarm. Antwortzeit über 5 Sekunden für 10 Minuten = Alarm. Zahlungsdienst antwortet nicht = sofort Alarm.
Der Bereitschaftsdienst
Bei Systemen, die kritisch genug für ein operatives Dashboard sind, brauchst du einen Bereitschaftsdienst im Wechsel.
Jemand ist rund um die Uhr für die Überwachung zuständig. Wenn um 3 Uhr nachts ein Alarm auslöst, wacht die Person im Bereitschaftsdienst auf und behebt das Problem.
Bereitschaft ist teuer. Aber Ausfallzeit ist teurer.
Nimm nur kritische Systeme mit Bereitschaftsdienst in das operative Dashboard auf.
Was du NICHT überwachst
Überwache keine Geschäftskennzahlen auf dem operativen Dashboard. Umsatz, Conversions und Traffic-Trends gehören in Geschäfts-Dashboards, nicht in operative Dashboards.
Wer Geschäft und Betrieb mischt, verwischt den Zweck. Operativ geht es um die Gesundheit des Systems. Beim Geschäft geht es um die Gesundheit des Geschäfts.
Getrennte Dashboards für getrennte Zwecke.
Dashboard oder Alarme
Das operative Dashboard lässt dich vorausschauend überwachen. Du prüfst das Dashboard, bevor ein Problem kritisch wird.
Alarme lassen dich reagieren. Ein Problem tritt auf, der Alarm löst aus, du behebst es.
Du brauchst beides. Das Dashboard für die vorausschauende Überwachung. Alarme für die Reaktion, wenn niemand auf das Dashboard schaut.
Ablaufpläne für Vorfälle
Was passiert, wenn ein Alarm auslöst? Das Betriebsteam sollte für jede Art von Alarm einen Ablaufplan haben.
Alarm Website ausgefallen: den Webserver neu starten. Wenn sie weiter ausgefallen ist, auf das Backup umschalten. Wenn sie weiter ausgefallen ist, an einen erfahrenen Entwickler eskalieren. Alarm Zahlungsdienst ausgefallen: auf einen Ersatzdienst umschalten. Kunden über mögliche Verzögerungen informieren. Beobachten, bis der Hauptdienst wieder läuft. Alarm Datenbank langsam: den Verbindungspool prüfen. Wenn er voll ist, vergrößern. Das Abfrageprotokoll prüfen. Langsame Abfragen beenden. Beobachten.
Ablaufpläne verhindern Panik. Klare Schritte verhindern Fehler.
Häufige Fragen
Wie oft sollten wir das operative Dashboard prüfen?
Während der Arbeitszeit durchgehend. Eine Person schaut jederzeit hin. Außerhalb der Arbeitszeit schaut die Person im Bereitschaftsdienst hin. Bei nicht kritischen Systemen prüfst du stündlich. Bei kritischen Systemen (Zahlungsabwicklung, Checkout) überwachst du durchgehend. Lege fest, welche Systeme kritisch sind: Systeme, bei denen eine Stunde Ausfall viel Umsatz kostet. Alles andere kannst du stündlich prüfen. Mit dem Website-Builder von WEMASY richtest du das direkt auf deiner Website ein.
Welche Antwortzeit ist akzeptabel?
Für den Checkout im Onlineshop: unter 2 Sekunden. Für eine Marketing-Website: unter 3 Sekunden. Für interne Admin-Tools: unter 5 Sekunden. Bei längeren Zeiten leidet die Conversion oder das Nutzererlebnis. Miss aus Sicht des Nutzers, nicht aus Sicht des Servers. Wenn der Nutzer eine Verzögerung spürt, ist es zu langsam.
Wie vermeiden wir Alarmmüdigkeit?
Strenge Schwellenwerte. Alarmiere nur bei einem echten Problem. Wenn du 10 Alarme am Tag bekommst und 9 davon Fehlalarme sind, hören die Leute auf, darauf zu achten. Besser sind 2 Alarme am Tag, die alle echt sind. Stelle die Schwellenwerte konsequent nach. Wenn ein Alarm auslöst und nicht dringend ist, erhöhe den Schwellenwert. Alarmmüdigkeit tötet die Reaktionsfähigkeit.
Sollte das operative Dashboard mobil erreichbar sein?
Ja. Die Person im Bereitschaftsdienst muss von überall nachsehen können. Achte darauf, dass es auf dem Smartphone funktioniert. Die Person im Bereitschaftsdienst ist womöglich nicht am Schreibtisch. Optimiere für Mobilgeräte. Große Bedienflächen. Einfaches Layout. Schnelles Laden, auch über 4G.
Wie verfolgen wir die Betriebsgesundheit über die Zeit?
Protokolliere alle Kennzahlen. Auch wenn das operative Dashboard in Echtzeit läuft, bewahre den Verlauf auf. Prüfe wöchentlich: Wie oft waren wir ausgefallen, wie langsam waren wir, welche Fehler waren am häufigsten. Nutze den Verlauf, um systematische Probleme zu erkennen. Beispiel: Wenn du pro Woche 3 Zeitüberschreitungen beim Zahlungsdienst hast, untersuche den Zahlungsdienst. Passe nicht einfach den Schwellenwert für Alarme an.
Was, wenn die Person im Bereitschaftsdienst nicht weiß, wie sie das Problem behebt?
Lege einen Eskalationsweg fest. Die Person im Bereitschaftsdienst ist die erste Anlaufstelle. Wenn sie es nicht in 5 Minuten behebt, eskaliert sie an einen erfahrenen Entwickler. Der erfahrene Entwickler ist die zweite Stufe. Wenn beide es nicht beheben können, eskaliere an den Support des Anbieters oder die Geschäftsführung. Die Ablaufpläne sollten den Eskalationsweg für jede Art von Alarm beschreiben.