Ein CRM kann sauber laufen. Ein Newsletter-Tool kann zuverlässig versenden. Ein Shop kann Bestellungen korrekt verarbeiten. Ein Reporting kann technisch funktionieren.
Und trotzdem entsteht im Alltag Reibung.
Das Problem liegt dann oft nicht in einem einzelnen System.
Es liegt zwischen den Systemen.
Viele Unternehmen bauen ihre Systemlandschaft Schritt für Schritt auf.
Zuerst kommt ein CRM. Dann ein Newsletter-Tool. Später vielleicht eine Fachsoftware, ein Shop, ein ERP, eine Buchhaltungslösung oder ein Reporting-Tool. Jedes System wurde zu einem bestimmten Zeitpunkt für einen konkreten Zweck eingeführt. Das ist grundsätzlich sinnvoll.
Schwierig wird es, wenn die Systeme zwar einzeln funktionieren, aber nicht als zusammenhängende Architektur gedacht wurden. Dann entstehen Übergaben, die niemand bewusst geplant hat.
Ein Lead kommt über die Website. Die Daten landen im CRM. Ein Teil davon wird an ein Marketing-Tool übergeben. Eine andere Information wird zusätzlich in einer Tabelle gepflegt. Der Vertriebsstatus verändert sich, aber das Newsletter-System weiß nichts davon. Für das Reporting werden Daten aus mehreren Quellen zusammengeführt.
Jeder einzelne Schritt funktioniert irgendwie.
Nur das Ganze nicht.
Systemprobleme zeigen sich oft nicht dort, wo sie entstehen.
Wenn ein Report falsche Zahlen zeigt, liegt das Problem nicht zwangsläufig im Reporting. Vielleicht werden Daten im CRM unterschiedlich gepflegt.
Wenn Kontakte die falsche Kommunikation erhalten, liegt es nicht unbedingt am Newsletter-Tool. Vielleicht fehlt eine klare Segmentierungslogik oder ein sauberer Trigger.
Wenn Mitarbeitende Daten manuell übertragen, fehlt nicht automatisch eine neue Automatisierung. Vielleicht ist ungeklärt, welches System für welche Information zuständig ist.
Genau deshalb reicht es selten, nur auf ein einzelnes Tool zu schauen. Entscheidend sind die Übergänge:
Erst wenn diese Fragen beantwortet sind, lässt sich beurteilen, wo die Ursache liegt und ob sie überhaupt technisch gelöst werden muss.
Ein typisches Zeichen für eine nicht verbundene Systemlandschaft ist nicht unbedingt ein technischer Fehler. Oft ist es eine Excel-Datei. Oder eine zusätzliche Liste. Oder ein manuell gepflegtes Feld, weil die Information „sonst irgendwo verloren geht".
Solche Workarounds entstehen meist aus einem guten Grund. Das Team braucht eine Information, die im bestehenden System nicht zuverlässig verfügbar ist. Also wird eine zusätzliche Lösung gebaut. Kurzfristig funktioniert das. Langfristig entstehen mehrere Datenstände.
Das CRM sagt etwas anderes als die Tabelle. Das Marketing-Tool kennt einen anderen Status als der Vertrieb. Im Reporting taucht eine dritte Zahl auf. Ab diesem Punkt ist Datenqualität nicht mehr nur ein technisches Thema. Sie wird zu einem Steuerungsproblem.
Denn Entscheidungen sind nur so belastbar wie die Daten, auf denen sie basieren.
Wenn Prozesse manuell werden, ist der nächste Gedanke oft: Das müssen wir automatisieren. Das kann richtig sein. Aber eine Automatisierung löst nicht automatisch das zugrunde liegende Problem.
Wenn Daten falsch strukturiert sind, verteilt eine Automatisierung die Fehler schneller. Wenn Zuständigkeiten unklar sind, automatisiert ein Workflow die Unklarheit.
Automation skaliert nicht nur gute Prozesse – sie skaliert auch ihre Schwächen.
Deshalb sollte vor jeder Automatisierung geklärt werden: Was soll eigentlich passieren und warum?
Erst danach stellt sich die Frage, wie es technisch umgesetzt wird.
Auch das Gegenteil kann zum Problem werden. Nicht jedes System muss mit jedem anderen System verbunden sein. Mehr Schnittstellen bedeuten nicht automatisch eine bessere Architektur.
Jede Integration schafft neue Abhängigkeiten. Wenn sich Datenfelder ändern, kann eine Schnittstelle brechen. Wenn Prozesse angepasst werden, müssen Automatisierungen überprüft werden. Wenn mehrere Systeme dieselbe Information verändern dürfen, wird schnell unklar, welcher Stand gültig ist.
Eine gute Systemarchitektur verbindet deshalb nicht möglichst viel.
Sie verbindet das Richtige.
Welches System ist für welche Information führend – und welches System übernimmt welche Aufgabe?
Diese Entscheidung ist oft wichtiger als die technische Schnittstelle selbst.
Einzelne Symptome wirken zunächst harmlos. In Kombination zeigen sie aber oft ein strukturelles Problem:
| Daten werden zwischen Systemen manuell übertragen. | |
| Teams führen zusätzliche Listen. | |
| Reports müssen vor Meetings erst geprüft oder korrigiert werden. | |
| Kontakte befinden sich in mehreren Systemen in unterschiedlichen Status. | |
| Automatisierungen funktionieren nur, solange bestimmte Personen wissen, wie sie aufgebaut sind. | |
| Neue Tools erzeugen zusätzliche Arbeit statt weniger. | |
| Niemand kann klar sagen, welches System für welche Information führend ist. | |
| Änderungen in einem System haben unerwartete Auswirkungen auf andere Prozesse. |
Keiner dieser Punkte bedeutet automatisch, dass die gesamte Systemlandschaft neu aufgebaut werden muss. Aber sie sind ein Hinweis darauf, dass sich ein Blick auf die Zusammenhänge lohnt.
Wenn Systeme nicht sauber zusammenspielen, liegt ein Systemwechsel schnell nahe. Manchmal ist er richtig. Häufig würden die bestehenden Probleme jedoch mit umziehen: unklare Datenstrukturen, schlecht definierte Übergaben, historisch gewachsene Workflows oder fehlende Verantwortlichkeiten.
Ein neues System löst keine Architekturprobleme, die außerhalb des Systems liegen.
Deshalb sollte ein Toolwechsel nicht der Ausgangspunkt der Analyse sein, sondern eine mögliche Konsequenz daraus.
Eine gute Systemlandschaft fühlt sich im Alltag nicht besonders technisch an.
Informationen sind dort verfügbar, wo sie gebraucht werden. Daten müssen nicht mehrfach gepflegt werden. Teams arbeiten mit demselben Stand. Automatisierungen übernehmen wiederkehrende Arbeit, ohne neue Unsicherheit zu erzeugen. Reports müssen nicht vor jeder Entscheidung hinterfragt werden. Und wenn sich das Unternehmen verändert, lässt sich die Architektur weiterentwickeln, ohne jedes Mal von vorne zu beginnen.
Das Ziel ist nicht, möglichst viele Systeme miteinander zu verbinden.
Das Ziel ist eine Struktur, in der Systeme, Daten und Prozesse gemeinsam funktionieren.