„Niemand hat eine Karte der eigenen Systeme" — was fragmentierte IT den Mittelstand wirklich kostet

Systemintegration im Mittelstand (Fallbeispiel)

Donnerstag, 14:20 Uhr

Ein Kunde ruft an. Er braucht das Drehmoment der AX-240, jetzt, für seine Konstruktionsfreigabe.

Der Vertriebsmitarbeiter weiß, dass es ein Datenblatt gibt. Irgendwo. Er öffnet den Fileserver. Projektordner 2023? Oder 2024? Er findet drei Dateien: Datenblatt_AX-240.pdf, Datenblatt_AX-240_final.pdf, Datenblatt_AX-240_final_v3_NEU.pdf. Welche gilt?

Zwanzig Minuten später hat er eine Antwort. Ob es die richtige war, weiß er nicht sicher.

Zwei Etagen höher erfährt der Geschäftsführer am selben Tag von einem Lieferverzug. Nicht aus dem eigenen System. Vom Kunden, am Telefon.

So sieht der Alltag bei der Brandt Antriebstechnik GmbH aus — 180 Mitarbeiter, Sondermaschinenbau, gesunde Auftragslage. Das Unternehmen ist fiktiv. Die Situation ist es nicht. Ich treffe sie in dieser oder ähnlicher Form in fast jedem mittelständischen Fertigungsbetrieb an.

Die Diagnose: Drei Inseln, keine Brücke

Bei Brandt existieren drei Systeme nebeneinander. Ein ERP, in dem Aufträge, Artikel und Debitoren leben. Ein CRM (HubSpot), in dem der Vertrieb seine Kontakte und Deals pflegt. Und ein Fileserver mit rund 4.000 technischen PDFs — Datenblätter, Prüfprotokolle, Zeichnungen — verteilt über Projektordner, gewachsen über fünfzehn Jahre.

Jedes System für sich funktioniert. Zusammen funktionieren sie nicht.

Der Vertrieb pflegt Kundendaten doppelt. Der Auftragsstatus wandert per Zuruf durchs Haus. Und die Frage nach einem Datenblatt kostet zwanzig Minuten — pro Vorgang.

Das eigentliche Problem: Niemand hat eine Karte der eigenen Systeme. Es gibt keinen Plan, welche Daten wo führend sind, wer wen informiert, was passiert, wenn ein Deal gewonnen wird. Jeder Mitarbeiter trägt ein Stück dieser Karte im Kopf. Das Unternehmen als Ganzes besitzt sie nicht.

Was das kostet — konservativ gerechnet

Studien zeichnen ein drastisches Bild: Nach Erhebungen von McKinsey und Atlassian fließt rund ein Fünftel bis ein Viertel der Arbeitszeit in die Suche nach Informationen. Ich rechne für Brandt bewusst mit einem Bruchteil dieser Werte — die Rechnung soll auch einem skeptischen Controller standhalten.

Sechs Personen im Vertrieb (fünf Vertrieb, eine Innendienststelle), 220 Arbeitstage, Vollkostensatz 45 Euro pro Stunde:

Das sind 0,6 Vollzeitstellen. Bezahlt für Reibung, nicht für Vertrieb.

Zwei Dinge gehören zur Ehrlichkeit dazu. Erstens: Diese Stunden werden nicht zu Cash, wenn man sie einspart — niemand wird entlassen. Sie werden zu Vertriebskapazität: mehr Angebote, schnellere Reaktion, bessere Betreuung. Zweitens: Die Rechnung enthält keine Fehlerkosten. Ein veraltetes Datenblatt, das beim Kunden in eine Konstruktion einfließt, kostet im Maschinenbau schnell einen fünfstelligen Betrag — von der Haftungsfrage ganz zu schweigen. Dieses Risiko lässt sich nicht seriös annualisieren. Es verschwindet aber auch nicht, nur weil es in keiner Tabelle steht.

Das Zielbild: Eine Vermittlungsschicht, die dem Unternehmen gehört

Die Lösung ist keine neue Software. Brandt braucht kein viertes System — Brandt braucht eine Schicht zwischen den dreien, die Ereignisse aus einem System in Aktionen im anderen übersetzt.

Drei Regeln machen aus Inseln eine Landschaft:

Das ERP ist führend für Kundenstammdaten und Aufträge. Das CRM ist führend für alles davor — Leads, Deals, Kommunikation. Die Grenze ist der gewonnene Deal. Und die Vermittlungsschicht läuft auf eigener Infrastruktur, ist dokumentiert und wartbar — sie gehört dem Unternehmen, nicht einem Dienstleister.

Für die Technik-Kollegen (1): Warum eine zustandsbehaftete Integrationsschicht?

Punkt-zu-Punkt-Verbindungen zwischen drei Systemen funktionieren — bis zum vierten System oder zum ersten Sonderfall. Die hier beschriebene Schicht hat deshalb ein Gedächtnis: eine kleine Datenbank (PostgreSQL), die das ID-Mapping hält (Debitorennummer ↔ CRM-Company), Feld-Hashes für die Änderungserkennung speichert und jedes verarbeitete Ereignis protokolliert. Ohne dieses Gedächtnis gibt es keine sauberen Upserts, keine Duplikaterkennung und keine Antwort auf die Frage „warum steht dieser Wert da?". Die Orchestrierung übernimmt n8n (self-hosted); die eigentliche Geschäftslogik — Deal-Positionen auf ERP-Artikel mappen, Konditionen prüfen — liegt in einem schlanken .NET-Service: getestet, versioniert, in Git. Genau an dieser Grenze zwischen Flow und Code scheitern reine Low-Code-Integrationen.

Ein Tag im integrierten Betrieb

Dieselbe Firma, ein Jahr später.

Der Vertrieb gewinnt einen Deal und setzt ihn im CRM auf „gewonnen". Neunzig Sekunden später existiert der Auftrag im ERP — mit korrektem Debitor, korrekten Positionen, korrekten Konditionen. Niemand hat etwas abgetippt.

Der Auftrag wird in der Fertigung bestätigt, später kommissioniert, geliefert, fakturiert. Jeder Statuswechsel erscheint automatisch am Deal im CRM. Der Vertrieb sieht den Stand, bevor der Kunde fragt. Der Geschäftsführer erfährt Verzögerungen aus dem System — nicht am Telefon.

Und die Frage nach dem Drehmoment der AX-240? Der Vertriebsmitarbeiter tippt sie in den Assistenten direkt im CRM. Die Antwort kommt in Sekunden, mit Link auf das gültige Datenblatt in der aktuellen Version. Aus zwanzig Minuten Suche werden zwanzig Sekunden.

Für die Technik-Kollegen (2): Der Ereignisfluss unter der Haube

Vier Muster entscheiden darüber, ob so eine Integration zwei Wochen oder zehn Jahre hält. Idempotenz: Webhooks kommen gelegentlich doppelt an; jede Event-ID wird geprüft, bevor sie verarbeitet wird — sonst entstehen doppelte Aufträge. Echo-Unterdrückung: Schreibt die Integration ein Feld ins CRM, löst das selbst wieder einen Webhook aus; der Abgleich gegen den gespeicherten Feld-Hash verhindert das Ping-Pong. Retry mit Dead-Letter-Queue: Schlägt ein Aufruf fehl, wird mit wachsendem Abstand wiederholt; was dreimal scheitert, landet in einer Warteschlange mit Alarm an die IT — kein Ereignis geht stillschweigend verloren. Reconciliation: Ein nächtlicher Vollabgleich findet die Drift, die trotz allem entsteht. Ereignisgetriebene Systeme ohne dieses Sicherheitsnetz sind Schönwetter-Architekturen.

Für die Technik-Kollegen (3): Wie aus 4.000 PDFs eine Wissensbasis wird

Ein Watcher prüft den Fileserver zyklisch und erkennt neue oder geänderte Dateien am Hash. Azure Document Intelligence extrahiert Layout, Text und — entscheidend im Maschinenbau — Tabellen; auch aus gescannten Dokumenten. Ein Klassifikationsschritt ordnet Dokumenttyp, Artikelnummer und Version zu: erst per Regelwerk gegen das Artikelnummern-Schema, bei Mehrdeutigkeit per Sprachmodell. Und wo beides scheitert, entscheidet ein Mensch — über eine schlichte Review-Queue. Die KI löst neunzig Prozent; wer die restlichen zehn verschweigt, baut keine verlässlichen Systeme. Indexiert wird in Azure AI Search mit Filtern auf Artikelnummer, Typ und Version — der Assistent zitiert ausschließlich aus der jeweils gültigen Dokumentversion. Im Maschinenbau ist das kein Komfortmerkmal, sondern eine Haftungsfrage.

Werkzeuge: keine Glaubensfrage

Für so ein Vorhaben braucht es keine Enterprise-Plattform. Die Orchestrierung übernimmt ein Open-Source-Werkzeug auf einem Server für unter 50 Euro im Monat. Die KI-Dienste für die Dokumente kommen aus der Azure-Cloud und kosten nutzungsabhängig zwischen 50 und 150 Euro monatlich — wohlgemerkt: In die Cloud wandern nur Produktdokumente, der unkritischste Datentyp im Haus. Der Kundendaten-Sync läuft vollständig auf eigener Infrastruktur.

Die Kosten liegen nicht in der Technik. Sie liegen im Entwurf — in der Karte, die vorher niemand hatte.

Kein Big Bang

Der größte Fehler bei Integrationsprojekten ist der Versuch, alles auf einmal zu lösen. Der Weg bei Brandt sieht anders aus.

Phase eins: der Stammdaten-Sync. Zwei bis drei Wochen, sichtbarer Nutzen ab dem ersten Tag — und allein durch die wegfallende Doppelpflege amortisiert sich dieser Schritt in unter einem Jahr. Phase zwei: der Auftrags-Lifecycle. Phase drei: die Dokumenten-Intelligenz. Jede Phase steht für sich, jede liefert eigenen Nutzen, keine setzt einen Umbau der bestehenden Systeme voraus.

Setzt man die konservativ gerechneten 47.000 Euro Reibungskosten pro Jahr gegen den Gesamtaufwand, liegt die Amortisation des kompletten Vorhabens bei rund zwölf Monaten. Alles danach ist Rendite — in Form von Vertriebszeit, Reaktionsgeschwindigkeit und Fehlern, die nicht passieren.

Zwei Fragen zum Schluss

An die Geschäftsführung: Könnten Sie heute aufzeichnen, welche Ihrer Systeme welche Daten führen — und was passiert, wenn ein Auftrag gewonnen wird? Wenn nicht, ist das kein IT-Problem. Es ist der Anfang jedes Gesprächs, das ich führe: Wir zeichnen zuerst die Karte.

An die IT-Leitung: Wenn Sie bei Idempotenz, Echo-Unterdrückung oder der Review-Queue anderer Meinung sind — schreiben Sie mir. Ich diskutiere Architektur am liebsten mit Leuten, die selbst schon Systeme betrieben haben. Widerspruch ausdrücklich erwünscht.

Guido Altmann ist Software-Architekt (CPSA-F) und technischer Berater in Berlin. Er hilft mittelständischen Unternehmen, gewachsene Systemlandschaften zu kartieren, zu integrieren und zu modernisieren. → guido-altmann.de