Ein Kunde bezahlt.
Das Geld ist gebucht.
Das Ticket wird trotzdem nicht erstellt.
Oder:
Die Nutzerzahlen in GA4 brechen innerhalb eines Tages massiv ein.
Oder:
Eine Webseite wird plötzlich langsam, obwohl am Frontend scheinbar nichts geändert wurde.
In solchen Situationen passiert fast immer dasselbe.
Man schaut zuerst dorthin, wo der Fehler sichtbar wird.
Der Shop funktioniert nicht? Dann wird die Webagentur gefragt.
Die Zahlung ist auffällig? Dann ist vermutlich der Payment-Anbieter zuständig.
Die Zahlen stimmen nicht? Dann wird das Tracking geprüft.
Das ist verständlich.
Aber es führt häufig zu einer falschen Schlussfolgerung:
Ein sichtbarer Fehler gehört nicht automatisch dem System, in dem er sichtbar wird.
Ein Symptom ist noch keine Ursache
Digitale Produkte bestehen heute selten aus einem einzigen System.
Ein Webshop kann zum Beispiel gleichzeitig von folgenden Komponenten abhängen:
- Frontend
- CMS
- Shoplogik
- Warenkorb
- Payment
- Backend
- Schnittstellen
- Kundendaten
- E-Mail-Versand
- Consent
- Tracking
- Hosting
- externen APIs
Der Nutzer sieht davon nichts.
Er klickt auf „Kaufen“.
Für ihn ist das ein Vorgang.
Technisch können dahinter jedoch zehn oder mehr Systeme miteinander kommunizieren.
Wenn an einer Stelle etwas schiefläuft, zeigt sich der Fehler deshalb häufig an einer anderen Stelle.
Der Checkout bricht ab.
Die Ursache liegt aber vielleicht in einem Timeout des Backends.
Das Ticket fehlt.
Die Zahlung war trotzdem erfolgreich.
GA4 meldet weniger Nutzer.
Das tatsächliche Nutzerverhalten hat sich aber gar nicht verändert – nur das Consent-Setup blockiert die Messung.
Wer nur auf das sichtbare Symptom schaut, beginnt schnell an der falschen Stelle zu optimieren.
Jeder Spezialist sieht einen plausiblen Ausschnitt
Das Schwierige daran ist:
Die einzelnen Beteiligten liegen oft nicht einmal falsch.
Die Webagentur kann sagen:
„Der Request wurde korrekt gesendet.“
Der Backend-Anbieter kann sagen:
„Bei uns ist keine vollständige Anfrage angekommen.“
Der Payment-Dienstleister kann sagen:
„Die Zahlung war erfolgreich.“
Und das Monitoring kann gleichzeitig zeigen:
„Der Prozess ist fehlgeschlagen.“
Vier Aussagen.
Alle können technisch korrekt sein.
Und trotzdem funktioniert das Gesamtsystem nicht.
Genau hier entsteht in digitalen Projekten schnell ein gefährliches Pingpong.
Jeder prüft seinen Verantwortungsbereich.
Jeder liefert eine plausible Antwort.
Und der Auftraggeber bleibt mit der eigentlichen Frage zurück:
Warum hat der Gesamtprozess nicht funktioniert?
Das ist ein gutes Beispiel dafür, warum Agentursteuerung mehr sein muss als Tickets weiterzuleiten.
Systemgrenzen sind oft die eigentliche Fehlerquelle
Viele technische Probleme entstehen nicht innerhalb eines Systems.
Sie entstehen an Übergängen.
Dort, wo ein System Daten an ein anderes übergibt.
Dort, wo unterschiedliche Timeouts gelten.
Dort, wo Statuswerte nicht gleich interpretiert werden.
Dort, wo ein System davon ausgeht, dass ein anderer Prozess bereits abgeschlossen ist.
Dort, wo Fehler zwar technisch korrekt behandelt werden, aber fachlich trotzdem zu einem falschen Ergebnis führen.
Diese Übergänge sind besonders kritisch, weil sich Verantwortung dort oft schlecht zuordnen lässt.
System A funktioniert.
System B funktioniert.
Die Verbindung zwischen beiden aber nicht zuverlässig.
Aus technischer Sicht kann deshalb jeder Beteiligte gute Argumente haben.
Aus Nutzersicht bleibt das Ergebnis trotzdem falsch.
Symptom, Ursache und Verantwortung sind drei verschiedene Dinge
Gerade bei komplexeren Problemen hilft es, diese drei Ebenen bewusst voneinander zu trennen.
Das Symptom
Was ist konkret passiert?
Zum Beispiel:
Zahlung erfolgreich, aber kein Ticket erstellt.
Das beschreibt nur das sichtbare Ergebnis.
Die Ursache
Warum ist es passiert?
Vielleicht:
- ein Timeout
- ein fehlender Identifier
- eine doppelte Anfrage
- eine nicht behandelte Antwort
- ein Race Condition
- ein Consent-Blocker
- eine fehlerhafte Konfiguration
- ein veralteter Client
- eine nicht synchronisierte Datenquelle
Das ist die technische oder organisatorische Ursache.
Die Verantwortung
Wer muss jetzt was tun?
Das ist noch einmal eine andere Frage.
Derjenige, in dessen System die Ursache liegt, ist nicht automatisch derjenige, der den Gesamtprozess koordinieren kann.
Und derjenige, der den Fehler zuerst sieht, ist nicht automatisch für seine Behebung verantwortlich.
Genau deshalb scheitert Problemlösung häufig nicht an fehlendem Fachwissen.
Sondern daran, dass diese drei Ebenen miteinander vermischt werden.
Gute Problemanalyse beginnt mit dem Prozess, nicht mit dem Schuldigen
Wenn ein digitaler Prozess fehlschlägt, ist eine der schlechtesten ersten Fragen:
„Wer ist schuld?“
Eine bessere Frage lautet:
„Was ist entlang des gesamten Prozesses passiert?“
Ich versuche solche Situationen deshalb zuerst als Kette zu rekonstruieren.
Was war der Auslöser?
Welche Systeme waren beteiligt?
Welche Anfrage wurde wann gesendet?
Welche Antwort kam zurück?
Welche Daten wurden übernommen?
Wo gab es Zeitüberschreitungen?
Welche Statuswerte wurden gespeichert?
Was sah der Nutzer?
Was sah das Monitoring?
Erst danach wird sichtbar, an welcher Stelle die Kette wirklich gebrochen ist.
Das ist übrigens sehr ähnlich zu einer guten Anforderungsanalyse.
Auch dort hilft es wenig, direkt mit einer Lösung zu starten. Zuerst muss das eigentliche Problem verstanden werden. Eine Anforderung ist eben noch keine Lösung.
Ein Beispiel: Die Zahlen brechen ein
Nicht jedes Problem zeigt sich als technischer Fehler.
Manchmal zeigt es sich als Zahl.
Angenommen, die Nutzerzahlen in einem Analytics-System fallen plötzlich um 70 oder 80 Prozent.
Die naheliegende Reaktion wäre:
„Wir haben massiv Reichweite verloren.“
Vielleicht stimmt das.
Vielleicht aber auch nicht.
Mögliche Ursachen könnten ebenso sein:
- Consent blockiert Analytics
- ein Tag feuert nicht mehr
- der Container wurde falsch veröffentlicht
- ein Script wird durch eine neue Konfiguration verhindert
- Events werden anders benannt
- ein technischer Fehler betrifft nur die Messung
- ein Bot- oder Filtermechanismus wurde verändert
Die entscheidende Frage lautet deshalb nicht sofort:
„Warum kommen weniger Nutzer?“
Sondern zunächst:
„Ist das Nutzerverhalten wirklich eingebrochen – oder nur unsere Sicht darauf?“
Auch hier liegt das Problem vielleicht nicht dort, wo es sichtbar wird.
Die Zahl ist das Symptom.
Die Ursache kann in einer völlig anderen technischen Schicht liegen.
Auftraggeber müssen nicht jedes System im Detail verstehen
Das bedeutet nicht, dass Unternehmen jede Schnittstelle selbst debuggen oder jeden Logfile lesen müssen.
Das wäre weder realistisch noch sinnvoll.
Aber auf Auftraggeberseite sollte jemand in der Lage sein,
- die beteiligten Systeme zu identifizieren,
- Aussagen verschiedener Spezialisten zusammenzuführen,
- Widersprüche zu erkennen,
- die richtigen Rückfragen zu stellen,
- Verantwortung für die Klärung zu organisieren
- und zu prüfen, ob die Maßnahme tatsächlich das Problem löst.
Das ist ein wichtiger Unterschied.
Technische Tiefe ist nicht dasselbe wie technische Gesamtverantwortung.
Ich muss nicht besser programmieren können als ein Entwickler.
Ich muss aber verstehen können, ob seine Antwort die eigentliche Frage beantwortet.
Ich muss nicht mehr über Payment wissen als der Payment-Anbieter.
Ich muss aber erkennen können, ob dessen erfolgreiche Transaktion wirklich bedeutet, dass der gesamte Kaufprozess erfolgreich war.
Genau diese Perspektive fehlt in vielen Projekten.
Mein Vorgehen: erst Gesamtbild, dann Maßnahme
Bei komplexen digitalen Problemen versuche ich deshalb möglichst früh fünf Dinge zu klären.
1. Den Prozess rekonstruieren
Nicht nur das System betrachten, in dem der Fehler sichtbar wurde.
Sondern den vollständigen Ablauf.
2. Systemgrenzen sichtbar machen
Wo werden Daten übergeben?
Welche Abhängigkeiten existieren?
Welche Annahmen treffen die beteiligten Systeme übereinander?
3. Aussagen zusammenführen
Nicht nur einzelne technische Antworten sammeln.
Sondern prüfen, ob sie gemeinsam ein konsistentes Bild ergeben.
4. Hypothesen priorisieren
Nicht zehn mögliche Ursachen gleichzeitig bearbeiten.
Sondern zuerst diejenigen prüfen, die das beobachtete Verhalten am besten erklären.
5. Wirkung absichern
Ein Fix ist erst dann belastbar, wenn klar ist, dass der Gesamtprozess wieder funktioniert.
Nicht nur das einzelne System.
Gute Steuerung beginnt dort, wo Zuständigkeiten enden
Die anspruchsvollsten digitalen Probleme sind oft keine reinen Technikprobleme.
Sie sind Schnittstellenprobleme.
Zwischen Systemen.
Zwischen Teams.
Zwischen Dienstleistern.
Zwischen fachlicher Erwartung und technischer Realität.
Deshalb ist es auch gefährlich, Verantwortung ausschließlich entlang von Zuständigkeitsgrenzen zu organisieren.
Denn für den Nutzer gibt es diese Grenzen nicht.
Er sieht keinen Payment-Provider.
Keine API.
Kein CMS.
Keine interne IT.
Er sieht nur:
Es funktioniert. Oder es funktioniert nicht.
Genau diese Perspektive muss auf Auftraggeberseite erhalten bleiben.
Nicht jedes Problem braucht mehr Technik
Manchmal ist die richtige Lösung ein technischer Fix.
Manchmal eine bessere Schnittstelle.
Manchmal ein anderes Monitoring.
Manchmal eine klarere Verantwortlichkeit.
Und manchmal schlicht die Erkenntnis, dass bislang alle Beteiligten das richtige Detail betrachtet haben – aber niemand den gesamten Prozess.
Deshalb ist eine meiner wichtigsten Fragen bei digitalen Problemen:
Wo wird der Fehler sichtbar – und wo könnte er tatsächlich entstehen?
Diese Unterscheidung spart oft mehr Zeit als die nächste schnelle Lösung.
Wenn du ein digitales Produkt oder Projekt nicht nur an einer einzelnen Stelle, sondern als Gesamtbild betrachten möchtest, ist der Digital Product Health Check genau für solche Situationen gedacht.
Und wenn du Beispiele dafür sehen möchtest, wie solche Probleme in der Praxis aussehen, findest du unter Cases typische Konstellationen aus Relaunch, Commerce und Daten.