Das Problem: Jede Standardsoftware ist eine Insel

Typischer Betrieb: eine Business-Software für Aufträge und Kunden, ein Ticketsystem für Anfragen und Störungen, dazu Buchhaltung, E-Mail, vielleicht ein Lager- oder Zeiterfassungssystem. Jedes Programm macht seinen Job — aber jedes speichert seine Daten für sich.

Das ist kein Einzelfall, sondern die Regel: Erhebungen zur Anwendungslandschaft in Unternehmen — etwa der Connectivity Benchmark von MuleSoft — zeigen Jahr für Jahr, dass nur eine Minderheit der eingesetzten Programme tatsächlich miteinander verbunden ist und dass Datensilos als eine der größten Hürden für Automatisierungs- und KI-Vorhaben gelten. Im Mittelstand sieht es strukturell genauso aus, nur mit weniger Systemen.

Ein Beispiel aus der Praxis: Das Wissen stirbt im geschlossenen Ticket

Fall aus meiner Arbeit (anonymisiert): Ein Betrieb arbeitet mit einer Business-Standardsoftware für Aufträge und Kunden. Support-Anfragen laufen daneben in einem Ticketsystem. Ein Kollege löst ein kniffliges Problem, dokumentiert die Lösung sauber im Ticket — und schließt es. Ab da ist dieses Wissen praktisch tot: Wer ein halbes Jahr später am selben Kunden oder am selben Fehler sitzt, arbeitet in der Business-Software und sieht dort nichts davon. Er löst das Problem noch einmal — oder fragt den Kollegen, der es damals wusste, wenn er noch da ist.

Die Lösung war keine neue Software und kein Wechsel: eine kleine Integrationsschicht, die beide Systeme über ihre Schnittstellen verbindet. Beim Kunden in der Business-Software sind die zugehörigen Tickets samt Lösungen sichtbar; geschlossene Tickets sind kein Grab mehr, sondern ein Nachschlagewerk.

Warum können die Hersteller das nicht einfach selbst?

Drei ehrliche Gründe:

• Fokus: Standardsoftware wird für den Massenmarkt gebaut. Der Hersteller kennt Ihre zweite Software nicht — und baut keine Spezialanbindung für jede Kombination.
• Interesse: Viele Anbieter verkaufen lieber ihr eigenes Zusatzmodul, als das System des Wettbewerbers anzubinden.
• Individualität: Selbst wenn es einen Standard-Connector gibt, passt er selten auf die eigenen Abläufe — welche Felder, welche Richtung, was gilt bei Konflikten?

Was Hersteller aber fast immer liefern: eine Schnittstelle (API) — die Steckdose. Die dritte Softwarelösung ist das Kabel mit dem passenden Stecker auf beiden Seiten.

Was ist diese „dritte Softwarelösung“ konkret?

Formen, vom Kleinen zum Großen:

• Einbahnstraße: System A schiebt Daten regelmäßig nach System B (zum Beispiel neue Aufträge ins Ticketsystem).
• Synchronisation: beide Richtungen, mit klaren Regeln, wer bei Konflikten gewinnt.
• Anreicherung: die Brücke zeigt Daten aus B direkt in A an (das Ticket-Wissen beim Kunden).
• Automatisierung obendrauf: wenn die Daten erst fließen, lassen sich Folgeschritte automatisieren — bis hin zur KI-Wissensdatenbank, die auch die Ticket-Historie durchsuchbar macht.

Wichtig fürs Erwartungsmanagement: Das ist keine dritte „große“ Software mit eigener Oberfläche für alle — im Idealfall sieht kein Mitarbeiter sie je. Sie läuft im Hintergrund.

Verbinden, ersetzen oder neu bauen — was ist wann richtig?

Faustregel aus der Beratungspraxis:

• Verbinden, wenn beide Systeme ihren Job gut machen und nur das Zusammenspiel fehlt. Kleinster Eingriff, schnellster Nutzen, Mitarbeiter behalten ihre gewohnten Programme.
• Ersetzen oder erweitern, wenn eines der Systeme auch für sich genommen nicht mehr passt — dann erst die Make-or-Buy-Frage stellen.
• Neu bauen nur, wenn der Prozess selbst das Alleinstellungsmerkmal ist.

Woran erkenne ich, dass mein Betrieb eine Integrationslösung braucht?

• Dieselben Daten werden in zwei Programme eingetippt (Kunden, Aufträge, Artikel).
• „Schau mal im anderen System nach“ ist ein normaler Satz im Alltag.
• Gelöste Probleme werden mehrfach gelöst, weil niemand die alte Lösung findet.
• Auswertungen entstehen per Copy-and-paste in Excel, weil kein System alles kennt.
• Eine Automatisierungs- oder KI-Idee scheitert daran, dass die Daten verstreut sind.