Ihre Systeme reden miteinander — oder Ihre Mitarbeiter reden für sie.

Was ist das?

Integrations-Projekte hatten lange einen schlechten Ruf: teuer, langsam, fragil. Der Grund waren schwergewichtige Enterprise-Service-Busse, die eigene Experten brauchten und bei jedem System-Update wackelten. Heute ist die Welt anders: Moderne Systeme haben standardisierte APIs, leichtgewichtige Integrations-Plattformen machen die Orchestrierung einfacher, und moderne Ansätze aus der Softwareentwicklung sorgen dafür, dass Integrationen nicht mehr bei jedem Update zusammenbrechen. Ein Integrations-Projekt ist heute ein normales Projekt — keine schwarze Kunst.

Wie sieht das aus?

Ein Unternehmen hatte vor zehn Jahren zwei Monate gebraucht und eine sechsstellige Summe ausgegeben, um CRM und ERP zu verbinden — über einen Enterprise-Service-Bus, der danach regelmäßig Sorgen bereitete. Dasselbe Unternehmen hat heute die Integration komplett neu gebaut: in drei Wochen, ohne Enterprise-Service-Bus, mit klar dokumentierten direkten API-Verbindungen, dauerhaftem Monitoring und einer Codebasis, die jeder Entwickler in zwei Stunden versteht. Die Betriebs-Kosten sind ein Zehntel dessen, was die alte Lösung verbrauchte. Das ist die reale Entwicklung der Integrations-Welt in diesen Jahren.

Warum ist das wichtig?

Viele Unternehmen zögern bei Integrations-Projekten wegen alter Erfahrungen. Das ist wirtschaftlich teuer: Sie akzeptieren die manuellen Brücken, die jede Woche Zeit kosten, obwohl die Alternative heute deutlich leichter und billiger ist als früher. Integration ist 2026 kein Luxus-Projekt mehr — es ist eine Grundleistung, die sich fast immer schnell amortisiert.

Wie wir das bauen

Wir arbeiten mit leichtgewichtigen, modernen Integrations-Ansätzen: klare API-Verträge statt Bus-Infrastrukturen, direkte oder schlanke orchestrierte Verbindungen je nach Komplexität, Überwachung auf jeder Strecke, Fehlerbehandlung als Bauprinzip. Wir investieren nicht in große Infrastruktur, die später teuer wird — wir investieren in saubere, nachvollziehbare Verbindungen, die jedes Entwickler-Team verstehen und anpassen kann.

Typische Anwendungsfälle

• Firmen mit gewachsener Software-Landschaft ohne sauberen Datenaustausch
• Mittelstand nach Systemwechsel oder Zukauf
• Unternehmen mit manuellen Brücken, die Zeit kosten und Fehler produzieren
• Digitalisierungs-Initiativen mit Fokus auf Prozess-Effizienz

Was ist das?

API-first heißt: Wir verbinden Systeme über ihre dokumentierten Schnittstellen (Application Programming Interfaces), nicht über Scripts, die sich durch Benutzeroberflächen klicken. APIs sind strukturierte, stabile, versionierte Zugänge zu den Daten und Funktionen eines Systems. Sie sind gemacht, damit andere Software sie nutzt. Benutzeroberflächen sind gemacht, damit Menschen sie nutzen — und verändern sich mit jedem Design-Update.

Wie sieht das aus?

Ein Industriebetrieb hatte zwei Jahre eine Lösung im Einsatz, die per Bildschirm-Automatisierung Daten zwischen einem Branchensystem und einem Reporting-Tool übertrug. Sie brach alle zwei bis drei Monate, weil das Branchensystem seine Oberfläche änderte — und jede Reparatur kostete einen Tag Stillstand. Wir haben die Lösung durch eine API-basierte Integration ersetzt: Die API des Branchensystems war stabil, dokumentiert und versioniert. Seit der Umstellung gab es drei Updates des Branchensystems — keine einzige Störung der Integration.

Warum ist das wichtig?

Bildschirm-Automatisierung ist ein Notnagel, kein Bauprinzip. Sie ist nur dann gerechtfertigt, wenn ein System wirklich keine API hat — und selbst dann sollte die Entscheidung bewusst gegen die Nachteile getroffen werden. API-basierte Lösungen sind robuster, schneller, günstiger im Betrieb und deutlich weniger pflegeintensiv. Wer heute noch in großem Stil auf Bildschirm-Automatisierung setzt, baut Schulden, die jeden Monat Zinsen kosten.

Wie wir das bauen

Wir prüfen bei jedem Projekt zuerst, welche APIs in Ihrer Landschaft verfügbar sind. Viele Systeme haben mehr davon als ihre Benutzer wissen — moderne Versionen von ERP-, CRM- und Branchen-Lösungen kommen fast immer mit umfangreichen API-Sets. Wo APIs fehlen, arbeiten wir pragmatisch: Datenbank-Zugriff im Lese-Modus, strukturierte Datei-Exports, im äußersten Fall sorgfältig gebaute UI-Brücken mit klaren Wartungs-Plänen. Die Priorität ist immer: sauber vor schnell, dauerhaft vor pfuschig.

Typische Anwendungsfälle

• Moderne Cloud-Systeme (alle gängigen CRMs, ERPs, Marketing-Tools)
• Unternehmens-Software mit veröffentlichten REST- oder GraphQL-APIs
• SaaS-Anbindungen (Zahlungs-Dienste, Versand, Kommunikation)
• Eigenentwickelte Systeme mit dokumentierten Schnittstellen

Was ist das?

In jeder Firma gibt es Daten, die in mehreren Systemen leben: Kundendaten im CRM und im ERP, Produktdaten im ERP und im Shop, Mitarbeiterdaten in HR und in der Zugangskontrolle. Synchronisation beantwortet für jede dieser Daten-Arten drei Fragen: Wer ist die führende Quelle? In welche Richtung fließt eine Änderung? Was passiert bei Konflikten? Ohne klare Antworten entstehen Datenwüsten, in denen niemand mehr weiß, welcher Stand stimmt. Mit klaren Antworten entstehen saubere Landschaften.

Wie sieht das aus?

Ein Dienstleister hatte ein häufiges Szenario: Kontakt-Daten wurden im CRM gepflegt, aber auch im ERP manuell korrigiert, wenn eine Rechnung anstand. Im Ergebnis gab es keinen Datensatz mehr, der stimmte — überall lebte eine eigene Wahrheit. Wir haben für jede Datenart eine führende Quelle definiert (Kontakte: CRM, Rechnungsdaten: ERP, Bank-Infos: ERP), die Synchronisation einseitig aufgesetzt (CRM → ERP für Kontakte, keine Rückrichtung) und eine klare Regel für Konflikte gebaut (ERP-Änderungen an Kontakten werden rückgeschrieben ins CRM und fallen in einen Prüfschritt). Nach drei Monaten waren die Datenbestände konsolidiert, und das bleibt auch so — weil die Regel klar ist und die Maschine sie hält.

Warum ist das wichtig?

Inkonsistente Daten sind nicht nur ein operatives Ärgernis — sie kosten Deals, weil Kunden falsche Informationen bekommen, und sie erzeugen rechtliche Risiken bei Datenschutz und Rechnungswesen. Gleichzeitig sind sie unsichtbar, solange niemand hinschaut: Oberflächlich sieht alles normal aus, die Probleme zeigen sich erst bei Grenzfällen, die dann schmerzhaft sind. Saubere Synchronisation ist unspektakulär, aber wirtschaftlich einer der größten Werte von Integrations-Projekten.

Wie wir das bauen

Wir starten mit einer Daten-Landkarte: Welche Information lebt wo, wer pflegt sie, welches System ist führend. Diese Landkarte wird gemeinsam mit Ihnen gezeichnet und dokumentiert — sie ist oft das erste Mal, dass eine solche Übersicht überhaupt existiert. Auf dieser Basis definieren wir Synchronisations-Regeln pro Datenart und bauen die technische Umsetzung. Konflikte werden nie stillschweigend gelöst, sondern sichtbar gemacht und an einen zuständigen Menschen eskaliert, bis eine Regel greift.

Typische Anwendungsfälle

• Kundendaten zwischen CRM, ERP und Marketing-Tools
• Produktdaten zwischen ERP, Shop und Marktplatz
• Mitarbeiterdaten zwischen HR, IT und Zugangskontrolle
• Finanzdaten zwischen Buchhaltung, Reporting und Banking

Was ist das?

Grundsätzlich gibt es zwei Muster. Echtzeit-Integration: Jede Änderung wird sofort übertragen, oft über Push-Nachrichten zwischen Systemen. Batch-Integration: Änderungen werden in Zeitfenstern (stündlich, täglich, wöchentlich) gebündelt und übertragen. Echtzeit ist teurer in Bau und Betrieb, Batch ist einfacher, aber mit Verzögerung. Die richtige Entscheidung hängt am Anwendungsfall, nicht am Wunschdenken.

Wie sieht das aus?

Zwei Integrationen aus demselben Unternehmen. Erste: Neue Kunden aus dem Shop sollen im CRM erscheinen, damit der Vertrieb sie sofort ansprechen kann. Echtzeit ist sinnvoll, weil jede Minute Verzögerung direkt Conversion kostet. Zweite: Produkt-Verkaufszahlen sollen täglich in das Reporting-Tool. Echtzeit wäre übertrieben — das Reporting-Tool wird sowieso morgens um 8 Uhr geöffnet, nicht nachts um 2. Ein nächtlicher Batch-Job ist robuster, einfacher zu betreiben und günstiger. Die Entscheidung war bewusst unterschiedlich pro Integration, nicht einheitlich "immer Echtzeit".

Warum ist das wichtig?

Teams überschätzen fast immer den Bedarf an Echtzeit. Das führt zu überdimensionierten Lösungen, die im Betrieb teuer sind und in Ausnahmefällen kompliziert zu debuggen. Batch-Integrationen sind lange unterschätzt worden — dabei decken sie einen Großteil realistischer Anwendungsfälle besser ab: einfacher, robuster, kostengünstiger, wartbarer. Die Faustregel: Echtzeit nur dort, wo Echtzeit nachweislich Geschäftswert bringt. Überall sonst: Batch.

Wie wir das bauen

Wir entscheiden pro Integration: Was passiert, wenn diese Information eine Stunde später ankommt? Wenn die Antwort "nichts" ist, ist Batch der richtige Weg. Wenn die Antwort "direkter Umsatzverlust" oder "ärgerliche Kundenerfahrung" ist, sprechen wir über Echtzeit. Zwischen den Extremen gibt es viele Mittelwege — Mini-Batches alle fünf oder fünfzehn Minuten sind oft der perfekte Kompromiss.

Typische Anwendungsfälle

• Lead-Übernahme (oft Echtzeit)
• Rechnungs-Synchronisation (oft nächtlicher Batch)
• Lagerbestände (oft Mini-Batch alle paar Minuten)
• Reporting und Analytik (meist täglicher Batch)
• Zahlungsbestätigungen (Echtzeit, aus Kundenerwartung)

Was ist das?

In einem einzelnen System sind Fehler meist klar lokalisierbar: Ein Knopf klappt nicht, eine Funktion wirft einen Fehler. In verteilten Systemen entsteht eine neue Fehler-Klasse: Netzwerk-Probleme, Zeitüberschreitungen, zwei Systeme mit unterschiedlichen Ständen, Nachrichten, die versandt, aber nicht empfangen wurden, Aktionen, die halb durchgeführt wurden. Ohne bewusste Fehlerbehandlung wird jede Integration eine Zeitbombe.

Wie sieht das aus?

Ein Szenario, das wir oft treffen: Eine Integration überträgt nachts Bestellungen an einen Dienstleister. Eines Nachts ist der Dienstleister für zehn Minuten nicht erreichbar. Eine schlecht gebaute Integration würde die 200 betroffenen Bestellungen als verloren markieren — und am Morgen gäbe es einen Support-Alarm. Unsere Integration erkennt das Problem, probiert dreimal mit wachsenden Abständen, landet beim dritten Versuch erfolgreich, und es gibt keine verlorene Bestellung. Bei dauerhaftem Problem: präzise Meldung an das zuständige Team mit genau den Vorgängen, die manuell geprüft werden müssen — nicht pauschal "alles kaputt".

Warum ist das wichtig?

Schlechte Fehlerbehandlung ist der Hauptgrund, warum Integrationen den Ruf haben, fragil zu sein. Gute Fehlerbehandlung macht Integrationen langweilig im Positiven: Sie laufen, was passiert, ist nachvollziehbar, und die wirklich seltenen Fälle, die menschliche Aufmerksamkeit brauchen, werden präzise gemeldet. Wir sprechen bei Kunden oft davon, dass "langweilig" das Kompliment ist, das wir uns wünschen — es bedeutet, dass niemand mehr über die Integration reden muss.

Wie wir das bauen

Unsere Fehler-Architektur hat mehrere Schichten. Automatische Wiederholungen bei temporären Problemen (Netzwerk, kurze Ausfälle), mit wachsenden Zeitabständen. Sichere Pausen bei dauerhaften Problemen, damit kein Datenschaden entsteht. Präzise Eskalations-Meldungen mit vollem Kontext statt generischen Alarmen. Wiederaufnahme-Fähigkeit, damit nach Unterbrechungen genau dort weitergemacht wird, wo der Fehler war — nicht noch einmal von vorn. Alles geloggt, alles nachvollziehbar, für jede Integration individuell ausgelegt.

Typische Anwendungsfälle

• Finanz-Integrationen mit Zero-Tolerance für Datenverlust
• Produktions-nahe Anbindungen mit Echtzeit-Anforderung
• Kommunikations-Integrationen mit garantierten Antwortzeiten
• Mehrstufige Workflows mit Abhängigkeiten zwischen Systemen

Was ist das?

Legacy-Systeme — also ältere Software, die seit Jahren produktiv läuft — sind oft Rückgrat der Firma und gleichzeitig der größte Integrations-Schmerz. Sie haben wenig oder keine modernen APIs, ihre Dokumentation ist lückenhaft, ihre Betreiber sind vorsichtig. Diese Systeme abzulösen ist meist keine realistische Option — zu teuer, zu riskant. Sie zu umarmen und in moderne Landschaften einzubetten ist der pragmatische Weg, den wir fast immer empfehlen.

Wie sieht das aus?

Ein Unternehmen nutzt seit über zwanzig Jahren ein Fachsystem, das auf einer eigenen Datenbank läuft und keine modernen APIs hat. Ablösen stand immer wieder im Raum — und wurde immer wieder verschoben, weil die Kosten unkalkulierbar wären. Wir haben eine Integrations-Brücke gebaut: Eine schlanke Zwischen-Schicht liest im Lese-Modus direkt aus der Datenbank des Fachsystems, bereitet die Daten strukturiert auf, und stellt sie als moderne API für alle anderen Systeme zur Verfügung. Schreibender Zugriff läuft kontrolliert über bestehende Import-Mechanismen. Ergebnis: Das Fachsystem bleibt unverändert und stabil, alles andere in der Firma kann mit modernen Mitteln darauf zugreifen. Die Ablösung wurde damit nicht mehr dringend — und das ist okay.

Warum ist das wichtig?

Viele Firmen sind zwischen zwei Extremen gefangen: dem Druck, Legacy-Systeme abzulösen (teuer, riskant, langsam), und der Unzufriedenheit, dass sie nicht mit moderner Software verbunden werden können (teuer, bremsend). Der dritte Weg — Legacy-Systeme respektieren und mit intelligenten Integrations-Brücken einbetten — wird oft übersehen, ist aber in den meisten Fällen wirtschaftlich überlegen. Wir haben Kunden, deren dreißig Jahre altes System heute besser integriert ist als manches Cloud-Tool.

Wie wir das bauen

Wir arbeiten mit allen verfügbaren Zugangswegen: offiziellen APIs (wenn vorhanden), Datenbank-Zugriff im Lese-Modus (bei stabilen Datenmodellen und klarer Freigabe), strukturierten Datei-Exports, Protokoll-basierten Schnittstellen bei älteren Industrie-Systemen, und im äußersten Fall sorgfältig gebauten UI-Automatisierungen mit dokumentierter Wartungs-Strategie. Alles mit dem Grundsatz: Das Legacy-System wird nicht verändert, nur befragt oder kontrolliert gefüttert.

Typische Anwendungsfälle

• Mittelstand mit historisch gewachsenen Fachsystemen
• Industrie mit alten Maschinensteuerungen
• Gesundheitswesen und öffentlicher Sektor mit lang laufenden Systemen
• Firmen nach Zukauf mit heterogener Software-Landschaft

Was ist das?

Jede Integration bedeutet, dass ein System einem anderen Zugriff gibt — auf Daten, auf Funktionen, oft auf sensible Informationen. Sicherheit an diesen Stellen beantwortet drei Fragen: Wer darf was (Authentifizierung und Rollen), welche Daten fließen tatsächlich (Minimierung, Verschlüsselung, Protokollierung), was passiert bei Missbrauch oder Ausfall (Erkennung, Eindämmung, Wiederherstellung). Das klingt technisch, ist aber im Kern genau das, was auch Ihre IT-Abteilung und Ihr Datenschutzbeauftragter Ihnen raten werden.

Wie sieht das aus?

Eine Integration zwischen Shop und ERP überträgt Kundendaten und Bestellpositionen. Wir prüfen: Braucht der Shop tatsächlich Zugriff auf die vollständigen Kundendaten im ERP (Geburtsdatum, interne Kunden-Notizen)? Nein — es reicht eine reduzierte Sicht ohne diese Felder. Wir bauen entsprechend einen eigenen, minimalen API-Zugang für den Shop, mit nur den Daten, die er wirklich braucht. Dieser Zugang läuft über eine separate Authentifizierung, wird protokolliert und würde bei Auffälligkeiten sofort gesperrt. Datenminimierung als Sicherheits-Prinzip spart Diskussionen mit Datenschutz und reduziert Angriffsfläche gleichzeitig.

Warum ist das wichtig?

Integrationen sind lange Zeit die Schwachstelle in Sicherheits-Architekturen gewesen. Zu breite Zugriffe, zu grosszügig vergebene Schlüssel, unverschlüsselte Übertragungen — lauter Klassiker, die vermeidbar sind. Im DACH-Raum kommt hinzu: DSGVO verlangt explizit eine Prüfung, welche Daten tatsächlich fließen. Wer das nicht dokumentieren kann, hat bei der nächsten Prüfung Erklärungsbedarf. Sicherheit an Integrations-Grenzen ist damit sowohl technische Pflicht als auch regulatorische Voraussetzung.

Wie wir das bauen

Wir arbeiten standardmässig mit dedizierten Zugangs-Accounts pro Integration (keine geteilten "Admin-Logins"), minimalen Rechten (nur das, was die Integration wirklich braucht), verschlüsselter Übertragung zwischen allen Systemen, zentraler Verwaltung von API-Schlüsseln mit regelmässigem Rotations-Plan, Protokollierung jeder Zugriffs-Aktion und automatischer Überwachung auf Anomalien. Für regulierte Branchen ergänzen wir spezielle Compliance-Kontrollen.

Typische Anwendungsfälle

• Integrationen mit personenbezogenen Daten (DSGVO-Pflicht)
• Finanz-Integrationen mit Zugriff auf Zahlungsinformationen
• Gesundheits-Integrationen mit besonders geschützten Daten
• Integrationen mit externen Partnern (Lieferanten, Dienstleister)

Was ist das?

Integrationen altern anders als normale Software. Jedes der verbundenen Systeme entwickelt sich weiter: neue Versionen, geänderte APIs, neue Sicherheitsanforderungen. Wenn die Integration nicht mitwächst, wird sie irgendwann brechen. Pflegbarkeit ist damit kein Luxus, sondern wirtschaftliche Pflicht. Eine perfekt gebaute Integration, die nach zwei Jahren niemand mehr versteht, ist schlimmer als eine einfache Lösung, die jeder lesen kann.

Wie sieht das aus?

Wir haben mehrere Kunden, die Integrationen seit über fünf Jahren betreiben, die wir ursprünglich gebaut haben. Alle laufen stabil, alle wurden in der Zeit einige Male angepasst (neue System-Versionen, neue Felder, neue Compliance-Anforderungen). Die Anpassungen waren jedes Mal im Rahmen weniger Tage erledigt — weil die Lösungen dokumentiert, strukturiert und nach modernen Softwareentwicklungs-Prinzipien gebaut wurden. Firmen, die Integrationen als "einmal bauen, nie anfassen" sehen, bauen unbeabsichtigt Altlasten, die später teuer werden.

Warum ist das wichtig?

Viele Anbieter bauen Integrationen, die beim ersten Live-Gang wunderbar aussehen, aber in drei Jahren eine komplette Neu-Entwicklung erfordern, weil niemand den Code mehr versteht und niemand die Änderungen sicher anfassen kann. Das ist verschwendetes Geld. Gute Integrations-Architekturen altern würdig: Sie lassen sich anpassen, sie lassen sich prüfen, sie lassen sich durch andere Entwickler übernehmen. Der Unterschied zeigt sich erst über Jahre — aber dann sehr deutlich.

Wie wir das bauen

Wir bauen Integrationen mit den gleichen Standards, die wir auch für Produkt-Software anlegen: versionierter Code in Git, automatische Tests pro Integration, klare Dokumentation was wohin fließt und warum, leichte Änderbarkeit bei Feld- oder Format-Änderungen, Protokollierung mit Auswerte-Möglichkeiten, Rollback-Fähigkeit bei Problemen. Und wir investieren in eine Übergabe-Dokumentation, die jedes halbwegs erfahrene Entwickler-Team in kurzer Zeit verstehen und übernehmen kann. Vendor-Lock-in liegt uns fern — Sie sollen die Freiheit haben, mit wem Sie arbeiten möchten.

Typische Anwendungsfälle

• Langfristige Integrationen im produktiven Einsatz
• Kritische Integrationen, bei denen Ausfälle teuer sind
• Firmen mit wachsendem internen Entwickler-Team
• Projekte mit Compliance-Anforderung an Nachvollziehbarkeit