Die Ausgangssituation ist in vielen mittelständischen Unternehmen die gleiche: Über die Jahre sind für verschiedene Bereiche die jeweils besten Tools eingeführt worden. HubSpot oder Pipedrive im Vertrieb. lexoffice oder sevdesk für die Buchhaltung. Asana oder Jira in der Projektarbeit. Slack für die Kommunikation. Vielleicht ein spezielles Tool für Marketing-Automation, eins für HR, eins für Zeiterfassung. Jede dieser Entscheidungen war zum Zeitpunkt der Einführung sinnvoll und ist es oft bis heute.
Und trotzdem steht die Geschäftsführung regelmäßig vor derselben Frage: “Wie stehen wir eigentlich gerade da?” Und die Antwort ist nicht in einem System zu finden, sondern setzt sich aus Teilantworten in verschiedenen Systemen zusammen - zuzüglich Excel-Zwischenschritten, zuzüglich manueller Abgleiche.
Dieser Artikel beschreibt, warum gut gewählte Einzeltools trotzdem zu einem Steuerungsproblem werden können - und welche zwei Wege aus dem Tool-Wildwuchs führen: eine leichtgewichtige Klammer als pragmatischer Startpunkt, oder eine individuelle Kernanwendung, die langfristig die Mitte des Geschäfts trägt.
Das Paradox der spezialisierten Tools
Die meisten dieser Tools sind in ihrem jeweiligen Bereich exzellent. HubSpot kann Vertriebspipelines und Marketing-Automation besser, als es eine generische Unternehmenssoftware je könnte. lexoffice ist für den Finanzalltag einer mittelständischen Firma nahezu perfekt. Dass sie so gut sind, ist kein Zufall - es liegt daran, dass sie sich auf einen Ausschnitt konzentrieren.
Genau diese Stärke ist der Grund für das Problem, das dieser Artikel beschreibt: Jedes Tool ist für sich optimiert. Keines ist für die Integration mit Ihrer spezifischen Systemlandschaft optimiert. Daraus entstehen drei typische Muster:
Muster 1
Die Excel-Brücke als Rückgrat
Irgendwo liegt die eine Excel-Tabelle, die den Gesamtüberblick halten soll. Einmal im Monat aus drei, vier, fünf Quellen gefüllt. Informeller Owner, nicht versioniert, nicht auditierbar - und die Qualität hängt an einer Person.
Muster 2
Stammdaten driften auseinander
Ein Kunde in HubSpot ist nicht zwangsläufig derselbe Kunde in lexoffice - zwei Datensätze, abweichende Schreibweise, unterschiedlicher Status. Mit jedem Monat driften die Stammdaten weiter auseinander.
Muster 3
Kein System kennt die ganze Wahrheit
Vertriebstool kennt die Pipeline. Buchhaltung kennt Zahlungen. Projekt-Tool kennt Aufwände. Niemand kennt die Antwort auf “Wie profitabel ist dieser Kunde über die gesamte Beziehung?” - die Antwort liegt zwischen den Systemen.
In der Konsequenz steuert das Unternehmen entweder nach Teilwahrheiten (was einzelne Tools als Zahl ausspucken) oder nach aufbereiteten Gesamtwahrheiten (was die monatliche Excel-Zusammenstellung liefert, mit Verzug). Echtzeit-Steuerung auf Basis verlässlicher Gesamtdaten ist in dieser Konstellation strukturell nicht möglich.
Die typische Folge: Entscheidungen kommen zu spät
Ein O-Ton aus unseren Gesprächen, sinngemäß immer ähnlich: “Wir merken Dinge erst, wenn das Kind schon in den Brunnen gefallen ist.” Cashflow wird knapp, weil niemand die Zahlungsziele über alle Großkunden hinweg in Echtzeit gesehen hat. Ein Kundensegment wird unwirtschaftlich, und es fällt erst im Jahresabschluss auf. Eine Vertriebsregion performt unter Plan, und die Korrektur kommt ein Quartal zu spät.
Das sind keine Einzelfälle. Das ist die systematische Folge einer Landschaft, in der die Daten zwar da sind, aber nicht zusammenkommen. Gesteuert wird, wenn der Schmerz eingetreten ist - nicht, solange noch Spielraum zum Gestalten besteht.
Bauchgefühl allein kann das nicht auffangen. Und es soll es auch nicht müssen: Ein gutes unternehmerisches Gespür ist eine der unterschätztesten Stärken im Mittelstand und wird nie durch ein Dashboard ersetzt. Aber Zahlen leisten etwas, das Bauchgefühl allein nicht schafft - sie machen Entwicklungen sichtbar, bevor man sie spürt. Sie sind das Frühwarnsystem, das dem Gespür Zeit verschafft, richtig zu entscheiden.
Das Ziel ist also nicht, dass die Geschäftsführung jeden Tag alle Zahlen im Kopf hat, sondern eine einzige verlässliche Oberfläche: zusammengesetzt aus allen Quellsystemen, mit einheitlicher Logik, in Echtzeit. Auf die sich Bauchgefühl und Entscheidungen stützen können - bevor das Kind in den Brunnen fällt.
Wo Standard-Suiten an ihre Grenzen kommen
Die naheliegende Antwort auf Tool-Wildwuchs ist historisch, alles in eine große Standard-Suite zu zwingen - die eierlegende Wollmilchsau, die Vertrieb, Buchhaltung, Projekte und HR in einem Atemzug lösen soll. SAP Business One für den Mittelstand. Microsoft Dynamics. Salesforce mit angebundenen Modulen für alles.
Das funktioniert in der Theorie. In der Praxis führt es fast immer zu einem anderen Problem: Die Suite ist in jedem einzelnen Bereich schwächer als das spezialisierte Tool, das sie ersetzt. Der Vertrieb, der vorher HubSpot geliebt hat, bekommt ein CRM-Modul, das schlechter ist. Die Buchhaltung bekommt ein Modul, das gegenüber lexoffice an Komfort verliert. Das Projekt-Team bekommt ein Tool, das ihm die Arbeit schwerer macht.
Das Ergebnis: Die Suite wird eingeführt, aber in der Praxis entstehen trotzdem parallele Tools, weil die Fachabteilungen ihre Arbeitsweise nicht opfern wollen. Am Ende hat das Unternehmen eine teure Suite plus die ursprünglichen Speziallösungen - und das Integrationsproblem ist nicht gelöst, sondern komplizierter geworden.
Zwei Wege, die wirklich tragen
In Projekten sehen wir zwei Ansätze, die den Tool-Wildwuchs auflösen, ohne dabei die Vorteile der guten Einzeltools zu verlieren. Welcher passt, hängt davon ab, wie stark die Kernprozesse das Unternehmen ausmachen - und wie weit Sie in die Zukunft planen.
Weg 1 · Startpunkt
Schlanke Klammer im Hintergrund
Die Fachabteilungen behalten ihre guten Tools. Im Hintergrund entsteht eine schlanke Ebene, die Daten einsammelt, einheitlich strukturiert und verfügbar macht. Nicht die Tools vereinheitlichen - die Daten zusammenführen.
Weg 2 · Zielbild
Individuelle Kernanwendung, Fachtools angedockt
Das operative Herz Ihres Geschäfts - Kunden, Aufträge, Projekte, Produktdaten - läuft in einer individuellen Anwendung, die auf Ihre Logik zugeschnitten ist. Buchhaltung, HR und ähnlich standardisierte Bereiche bleiben in ihren Fachtools und werden sauber angebunden.
Beide Wege haben dieselbe Grundidee: Es gibt einen Ort, an dem die Wahrheit über das Gesamtgeschäft zusammenläuft. Der Unterschied ist, ob dieser Ort nur Daten einsammelt (Weg 1) oder ob er selbst die operative Mitte des Unternehmens ist (Weg 2).
Die Klammer als pragmatischer Einstieg
Wenn Sie heute vor einer gewachsenen Tool-Landschaft stehen, ist die Klammer in den meisten Fällen der richtige erste Schritt. Drei Ebenen bauen sie auf:
01
Zentrales Datenmodell
Eigene Datenbank, in der Kunden, Produkte, Aufträge, Zahlungen und Projekte in einer einheitlichen Struktur liegen - auf Ihr Unternehmen zugeschnitten, nicht generisch.
02
Saubere Datenflüsse
Über die APIs der Einzeltools fließen die relevanten Daten kontinuierlich ins zentrale Modell. Die Tools bleiben Quellsysteme - die Datenbank wird zur Wahrheit über den Gesamtstand.
03
Abgleich und Matching
Driftende Stammdaten werden dort gelöst, wo alles zusammenkommt. Automatisches Matching plus eine Oberfläche für manuelle Klärung - einmal gemacht, danach dauerhaft konsistent.
Aufsatzpunkt für Auswertung und Steuerung ist dann das zentrale Modell. Ob die Auswertung per Metabase-Dashboard, per individuellem Cockpit oder per Excel-Export passiert, ist Geschmackssache - die Datenbasis ist in jedem Fall einheitlich und aktuell.
Ab wann die Suite statt der Klammer Sinn ergibt
Die Klammer ist ein guter Startpunkt. Aber sie hat einen strukturellen Haken: Mit jedem neuen Anwendungsfall - neue Auswertung, neue Validierungsregel, neuer Workflow - wächst sie. Aus einer schlanken Datenebene wird über Jahre eine schwerer werdende Schattenplattform, die immer mehr Geschäftslogik in sich trägt, ohne dafür je gebaut worden zu sein.
An dem Punkt kippt das Verhältnis. Die Klammer war einmal der pragmatische Shortcut - jetzt trägt sie Kernprozesse, für die sie nicht designed ist. Das ist der Zeitpunkt, an dem eine individuelle Kernanwendung der sauberere Weg wird: nicht mehr „Daten aus Tools ableiten”, sondern das Geschäft nativ abbilden und die Fachtools daran andocken, wo sie weiterhin gut sind.
Wenn Ihre Kernprozesse Ihren Wettbewerbsvorteil ausmachen - Ihre spezifische Leistungsverrechnung, Ihr eigenes Margenmodell, Ihre besondere Projektabwicklung - ist die individuelle Kernanwendung am Ende ohnehin die ehrlichste Antwort. Die Klammer ist dann eher der erste Schritt auf diesem Weg als ein dauerhafter Zustand.
Warum das im Mittelstand wirtschaftlich funktioniert
Der naheliegende Einwand ist: Klingt nach teuer. Tatsächlich ist dieser Ansatz oft günstiger als die Alternativen, aus zwei Gründen.
Erstens ersetzt er keine funktionierenden Tools. Lizenzen bleiben, wo sie sind. Einarbeitung der Mitarbeiter bleibt, wo sie ist. Es gibt keine Umstellungsphase, in der das operative Geschäft leidet.
Zweitens ist der Scope überschaubar. Wir sprechen nicht über ein zweijähriges Großprojekt, sondern typischerweise über einen mehrmonatigen Aufbau, der nach Fertigstellung einen sehr niedrigen Betriebsaufwand hat. Das zentrale Modell plus die Integrationen laufen auf einer kleinen Infrastruktur, Weiterentwicklungen erfolgen bedarfsgetrieben.
Die eigentliche Investition liegt nicht in der Technik, sondern im sauberen Nachdenken über das Datenmodell: Welche Entitäten sind wirklich zentral in Ihrem Geschäft? Wie hängen sie zusammen? Welche Stammdaten sind führend, wo? Diese Klärung ist die eigentliche Wertschöpfung des Projekts - und sie bleibt dem Unternehmen erhalten, unabhängig davon, welche Tools Sie in fünf Jahren einsetzen.
Ein ehrlicher Einwand
Nicht jeder Tool-Zoo ist ein Problem.
Kein Handlungsdruck
Wenn Sie mit Ihrer aktuellen Landschaft gut steuern, die monatliche Auswertung in wenigen Stunden steht und Ihre Stammdaten stabil sind - dann gibt es keinen Grund, etwas zu ändern.
Faustregel für den Handlungsbedarf
Wenn Sie regelmäßig mehr Zeit in die Zusammenstellung der Zahlen investieren als in das Arbeiten mit ihnen, ist der Schnitt fällig - mindestens als Klammer, oft als Schritt Richtung individueller Kernanwendung.