Die Situation
Es ist nicht das erste Mal, dass dieses Gespräch so verläuft. Und es ist nicht das erste Mal, dass niemand im Raum erklären kann, was genau passiert ist, warum es passiert ist und was getan wurde, um es zu beheben. Irgendjemand hat irgendetwas gemacht. Die Seite läuft wieder. Mehr weiß niemand.
In einem anderen Unternehmen, wenige Wochen zuvor, ein ähnliches Bild. Ein Geschäftsführer starrt auf eine Fehlermeldung in seinem Browser. Die WordPress-Seite zeigt einen weißen Bildschirm. Er weiß, dass das System seit Jahren läuft, dass verschiedene Agenturen und Freelancer daran gearbeitet haben, dass es irgendwann intern „übergeben“ wurde. Aber er kann nicht benennen, wer jetzt dafür zuständig ist. Nicht im Sinne von „wer hat Zugang zum Server“, sondern im Sinne von: Wer trifft die Entscheidungen? Wer kennt das System gut genug, um einschätzen zu können, was gerade passiert?
Das Team weiß, dass „jemand das gebaut hat“. Es gibt vielleicht einen Slack-Kanal, in dem technische Fragen gestellt werden. Es gibt vielleicht einen Freelancer, der vor einem Jahr das letzte Mal geantwortet hat. Es gibt vielleicht eine Agentur, deren Vertrag ausgelaufen ist, die aber „im Notfall noch ansprechbar“ sein soll. Was es nicht gibt, ist eine Person, die die Verantwortung trägt. Nicht die Schuld, wenn etwas schiefgeht, sondern die Fähigkeit und das Mandat, Entscheidungen zu treffen, bevor etwas schiefgeht.
Wenn niemand diese Entscheidungen trägt, werden Updates aufgeschoben. Nicht weil das Team fahrlässig wäre, sondern weil niemand autorisiert ist, das Risiko eines Updates zu bewerten und zu tragen. Und so bleibt das System in einem Zustand, den niemand aktiv gewählt hat, der aber mit jedem Monat schwieriger zu verändern wird.
Der Mechanismus
Ownership-Lücken entstehen selten plötzlich. Sie entwickeln sich in einem Prozess, der fast immer demselben Muster folgt.
Am Anfang steht eine Website als Projekt. Eine Agentur oder ein Freelancer baut sie. Es gibt einen Projektleiter auf Kundenseite, der Feedback gibt, Inhalte liefert, Freigaben erteilt. Die Rollen sind klar: Die Agentur baut, der Kunde nimmt ab. Nach dem Launch gibt es vielleicht noch einen Wartungsvertrag für ein paar Monate. Dann endet die Zusammenarbeit, oder sie läuft aus, weil niemand sie aktiv verlängert.
Was zurückbleibt, ist ein laufendes System ohne definierten Verantwortlichen. Der ursprüngliche Projektleiter hat längst andere Aufgaben. Die Agentur hat die Dokumentation übergeben, falls es eine gab. Die Zugangsdaten liegen in einem Passwort-Manager, auf den drei Leute Zugriff haben, von denen einer das Unternehmen verlassen hat.
In dieser Phase beginnt etwas, das sich am besten als schleichende Fragmentierung beschreiben lässt. Der Marketing-Lead bekommt Zugang zum WordPress-Backend, um Blogbeiträge zu veröffentlichen. Ein Praktikant aktualisiert ein Plugin, weil WordPress eine Warnung anzeigt. Ein externer SEO-Berater installiert ein Tracking-Plugin. Ein neuer Entwickler wird für ein Feature engagiert und fragt: „Warum ist dieses Plugin hier?“ Niemand weiß es. Also bleibt es.
Jede dieser Handlungen ist für sich genommen harmlos. In der Summe entsteht ein System, das mehrere Personen verändern können, aber niemand überblickt. Es gibt keinen Ort, an dem festgehalten wird, warum etwas so ist, wie es ist. Kein Entscheidungsprotokoll. Keine Architekturübersicht. Keine Person, die sagen kann: „Das Plugin ist da, weil wir 2023 die Versandkostenberechnung umgestellt haben, und es wird von der Schnittstelle zum Fulfillment-Dienstleister benötigt.“
Technische Schulden häufen sich in dieser Situation nicht durch bewusste Entscheidungen an, sondern durch das Fehlen von Entscheidungen. Niemand entscheidet, ob ein Plugin bleiben oder entfernt werden soll. Niemand entscheidet, ob die PHP-Version aktualisiert wird. Niemand entscheidet, ob der Hosting-Vertrag noch zum aktuellen Traffic passt. Die Dinge bleiben einfach, wie sie sind, bis sie nicht mehr funktionieren.
Die Konsequenzen
Die unmittelbarste Folge ist, dass Updates sich riskant anfühlen, obwohl sie technisch oft unkompliziert wären. Der Grund ist nicht die Komplexität des Updates selbst, sondern die fehlende Kenntnis des Systems. Wenn niemand weiß, welche Plugins miteinander interagieren, welche Custom-Code-Anpassungen existieren und welche Datenbankstrukturen von welchem Plugin angelegt wurden, dann ist jedes Update eine Gleichung mit zu vielen Unbekannten. Die rationale Reaktion darauf ist Vermeidung. Und genau das passiert.
Die zweite Folge ist subtiler, aber teurer: Chancen werden verpasst, weil niemand weiß, wer „Ja“ sagen darf. Der Marketing-Lead möchte eine neue Landingpage für eine Kampagne. Dafür müsste ein Plugin installiert oder ein Template angepasst werden. Aber wer entscheidet das? Der Marketing-Lead fühlt sich nicht zuständig für technische Veränderungen. Die Geschäftsführung hat keine Zeit, sich mit Plugin-Entscheidungen zu befassen. Der Freelancer, der das letzte Mal etwas am System gemacht hat, antwortet nicht sofort. Also wartet die Kampagne. Nicht Tage, manchmal Wochen.
Die dritte Folge zeigt sich bei Notfällen. Wenn die Seite ausfällt und jemand unter Zeitdruck eingreift, ohne das System zu kennen, werden Probleme oft nicht gelöst, sondern verschoben. Ein Plugin wird deaktiviert, das die Fehlermeldung verursacht hat, aber auch eine Funktion bereitstellte, deren Fehlen erst Tage später auffällt. Eine Datenbanktabelle wird repariert, aber die Ursache der Beschädigung bleibt. Die Seite läuft wieder, aber das System ist instabiler als vorher.
Der eigentliche Kostenfaktor ist nicht der einzelne Ausfall. Es ist die Unsicherheit, die jede Entscheidung verlangsamt. Teams, die nicht wissen, wer für ihr wichtigstes digitales System verantwortlich ist, treffen weniger Entscheidungen. Sie setzen weniger um. Sie reagieren statt zu gestalten. Und mit der Zeit wird die Website von einem Geschäftsinstrument zu einem Risikofaktor, den man lieber nicht anfasst.
Was es verändert
Klare Ownership bedeutet nicht, dass eine einzelne Person alles macht. Sie bedeutet, dass eine Person die Entscheidungen trägt. Das ist ein wesentlicher Unterschied.
In der Praxis sieht das so aus: Es gibt eine klar benannte Person, intern oder extern, die den Zustand des Systems kennt, die weiß, welche Abhängigkeiten existieren, und die autorisiert ist, Entscheidungen über Updates, Änderungen und Priorisierungen zu treffen. Diese Person muss nicht jedes Plugin selbst aktualisieren. Aber sie muss wissen, was passiert, wenn es aktualisiert wird. Und sie muss entscheiden können, wann es passiert.
Der zweite Baustein ist die Dokumentation von Entscheidungen, nicht nur von Code. Die meisten technischen Dokumentationen beschreiben, wie etwas funktioniert. Was fehlt, ist das Warum. Warum wurde dieses Plugin gewählt? Warum ist die Seitenstruktur so aufgebaut? Warum gibt es diese Custom-Funktion? Wenn das Warum dokumentiert ist, kann jede neue Person, die am System arbeitet, Entscheidungen im richtigen Kontext treffen, statt im Blindflug.
Der dritte Baustein sind regelmäßige Check-ins statt Notfall-Kontakt. Die meisten Unternehmen sprechen mit ihrem technischen Dienstleister nur, wenn etwas nicht funktioniert. Das bedeutet, dass jedes Gespräch unter Druck stattfindet, dass Entscheidungen reaktiv sind und dass präventive Maßnahmen systematisch zu kurz kommen. Ein monatlicher oder quartalsweiser Austausch, kurz, strukturiert, ohne akuten Anlass, verändert die Dynamik grundlegend. Probleme werden erkannt, bevor sie eskalieren. Entscheidungen werden getroffen, wenn noch Zeit zum Nachdenken ist.
Wie es weitergeht
Wenn Sie beim Lesen an Ihr eigenes System gedacht haben, an die Frage, wer eigentlich die Entscheidungen trifft, wer das System wirklich kennt und ob es eine klare Verantwortlichkeit gibt, dann ist das ein guter Ausgangspunkt für ein Gespräch.
Schreiben Sie uns über unser Kontaktformular. Kein Commitment, keine Verkaufspräsentation. Wir hören zu, stellen ein paar Fragen und geben Ihnen eine ehrliche Einschätzung, ob und wo eine Ownership-Lücke besteht, und was ein realistischer nächster Schritt wäre.