Im Vertrieb gilt das Angebot als gewonnen, in der Buchhaltung existiert der Auftrag noch nicht. Der Kunde hat seine Lieferadresse im CRM geändert, aber das ERP verwendet weiterhin den alten Datensatz. Der Aussendienst verspricht eine Lieferzeit, die niemand anhand des aktuellen Lagerstands geprüft hat. Danach beginnt die Suche in E-Mails, Excel-Dateien und zwei Systemen, die eigentlich zusammenarbeiten sollten.
Genau dort zeigt sich, ob eine CRM-ERP-Integration operativ trägt oder nur Daten kopiert. Eine belastbare Verbindung synchronisiert nicht einfach Tabellen. Sie legt fest, welches System für welches Feld führend ist, wer Änderungen auslösen darf, wie Konflikte behandelt werden und wie Finanz- und Serviceprozesse nachvollziehbar bleiben. Mit sauberer Automatisierung können KI-Agenten später Angebote prüfen, Aufträge anlegen, Abweichungen erklären oder Serviceteams mit belastbaren Kundendaten versorgen. Ohne klare Datenhoheit automatisieren sie dagegen nur bestehende Fehler.
Inhaltsverzeichnis
- Warum CRM ERP Integration jetzt über Effizienz entscheidet
- Architektur und Connector Strategie richtig wählen
- Datenmodell abgleichen und Datenhoheit je Feld definieren
- Sicherheit Governance und Compliance sauber aufsetzen
- Testen ausrollen und in den Betrieb übergeben
- Fazit und nächste Schritte für deine Integration
Warum CRM ERP Integration jetzt über Effizienz entscheidet
Ein typisches österreichisches Mittelstandsunternehmen arbeitet mit einem CRM für Leads, Kontakte und Angebote sowie einem ERP für Aufträge, Lager, Einkauf und Buchhaltung. Ein Vertriebsmitarbeiter erfasst einen Kunden im CRM. Wird das Konto gewonnen, überträgt jemand die Daten manuell ins ERP. Die Buchhaltung ergänzt Zahlungsbedingungen, der Innendienst prüft Preise, und der Aussendienst wartet auf Informationen, die längst verfügbar sein sollten.
Der Fehler liegt nicht bei einzelnen Mitarbeitern. Das Unternehmen hat einen Prozess gebaut, in dem Menschen als Schnittstelle zwischen Systemen arbeiten. Jede zusätzliche Übergabe erzeugt eine neue Möglichkeit für doppelte Kunden, veraltete Preise, fehlende Pflichtfelder oder einen Auftrag, der zwar verkauft, aber nicht erfüllbar ist. Ein praxisnaher Überblick zur Effizienzsteigerung in Unternehmen hilft bei der Einordnung, aber die technische Ursache bleibt meist dieselbe: Verantwortlichkeiten sind nicht im Datenmodell verankert.
Österreichische Unternehmen stehen dabei auf unterschiedlichen Ausgangsniveaus. Statistik Austria berichtet für 2023, dass 59 % der Unternehmen zumindest auf Basisniveau digitalisiert waren, während 40 % dieses Niveau nicht erreichten. Das Basisniveau umfasst mindestens vier von zwölf Technologien, darunter ERP, CRM, Data Analytics und Cloud-Services. Statistik Austria beschreibt diese Digitalisierungsbasis im IKT-Bericht 2023.
Der operative Nutzen entsteht an den Übergaben
Eine Integration wird dann wertvoll, wenn sie einen konkreten Handgriff entfernt oder eine Entscheidung verbessert. Nach der Freigabe eines Angebots kann das CRM einen Auftrag im ERP anstossen. Das ERP liefert den bestätigten Status zurück. Vertrieb und Service sehen dadurch nicht nur, was versprochen wurde, sondern auch, ob Auftrag, Lieferung und Rechnung tatsächlich weiterlaufen.
Für mobile Teams ist die Latenz entscheidend. Eine österreichische Referenz beschreibt einen Beleuchtungshersteller mit 450 Mitarbeitenden in Österreich, Deutschland, Italien und der Schweiz, der den Aussendienst live mit ERP, CRM und WMS verband. Der relevante Punkt ist nicht die Unternehmensgrösse, sondern der Prozess: Der Aussendienst arbeitet mit aktuellen Informationen, während zentrale Stammdaten und operative Vorgänge verbunden bleiben. Die Referenz zur CRM-ERP-WMS-Integration beschreibt diesen Live-Ansatz.
KI kann auf dieser Grundlage mehr als Text erzeugen. Ein Agent kann prüfen, ob ein Kunde im ERP gesperrt ist, ob der gewünschte Artikel verfügbar ist und ob ein Rabatt innerhalb der definierten Regeln liegt. Er kann einen Auftrag vorbereiten, aber die Freigabe an eine Rolle oder einen Schwellenwert binden. KI ersetzt dabei keine Governance. Sie macht gute Governance nutzbar.
Vor der Architektur kommen drei Entscheidungen
Klären Sie zuerst, welche Prozesse wirklich synchron laufen müssen. Kundenstammdaten und Aufträge brauchen oft eine andere Aktualität als historische Verkaufsdaten. Danach definieren Sie die führenden Systeme je Objekt und Feld. Erst dann entscheiden Sie, ob eine direkte API-Verbindung, Middleware oder ein zentraler Integrations-Layer passt.
Österreichische CRM-Nutzung ist nicht flächendeckend. Die OECD nennt für Österreich rund 45 % CRM-Nutzung, im europäischen Durchschnitt 33 %. Bei grossen Unternehmen liegt die Nutzung bei 70 %, bei kleinen Unternehmen bei 40 %. Die OECD ordnet diese Unterschiede in Österreichs digitalem Übergang ein. Das erklärt, warum Standardannahmen aus reinen SaaS-Landschaften im österreichischen Mittelstand oft nicht funktionieren.
Architektur und Connector Strategie richtig wählen
Die Architekturentscheidung sollte nicht mit der Frage beginnen, welcher Connector gerade verfügbar ist. Sie beginnt mit der Landschaft: Cloud-CRM, On-premise-ERP, proprietäre Datenbank, lokale Buchhaltung, mobile Endgeräte und möglicherweise mehrere Gesellschaften. Eine direkte Verbindung kann für einen kleinen, stabilen Prozess sinnvoll sein. Sie wird problematisch, sobald weitere Systeme, unterschiedliche Schreibrechte oder komplexe Fehlerpfade dazukommen.
Drei Muster im direkten Vergleich
Punkt zu Punkt verbindet CRM und ERP unmittelbar. Das ist überschaubar, wenn wenige Objekte fliessen und beide Systeme stabile APIs besitzen. Die Logik sitzt jedoch oft direkt in der Verbindung. Ändert sich ein Endpunkt, müssen Mapping, Fehlerbehandlung und Tests meist gemeinsam angepasst werden.
Middleware oder iPaaS trennt die Systeme durch eine Vermittlungsschicht. Dort lassen sich Transformationen, Routing, Wiederholungen und Protokollierung zentral verwalten. Der Preis ist zusätzliche Plattform-Governance. Teams müssen Datenflüsse, Zugangsdaten und Betriebsverantwortung sauber organisieren.
Ein Enterprise-MCP-Layer ergänzt die klassische Integration um kontrollierten Zugriff für KI-Agenten. Ein Agent erhält nicht pauschal Zugriff auf eine Datenbank, sondern auf definierte Werkzeuge mit Rollen, Protokollierung und erlaubten Aktionen. Das ist besonders relevant, wenn ein Agent CRM-Daten lesen, im ERP einen Auftrag vorbereiten und eine Freigabe anfordern soll.
| Option | Stärken | Grenzen | Ideal für |
|---|---|---|---|
| Punkt zu Punkt | Schneller Start, wenig Infrastruktur | Brüchig bei Änderungen, verteilte Logik | Wenige stabile Cloud-Systeme |
| Middleware oder iPaaS | Zentrale Transformation, Routing und Monitoring | Zusätzliche Plattform und Governance | Mehrere Systeme und laufende Prozesse |
| MCP-Layer | Kontrollierter KI-Zugriff, Tool-Grenzen und Auditierbarkeit | Benötigt klare Agenten- und Berechtigungsmodelle | Automatisierung mit internen Agenten |
| Custom Connector | Passt an BMD, DATEV, Navision, Exact, weclapp oder proprietäre Systeme | Höherer Pflegeaufwand | On-premise und Legacy-Landschaften |
Für ältere Systeme ist eine API nicht immer vorhanden. Dann kann ein Connector über Datenbankzugriff, gesicherte Exporte oder einen lokalen Dienst arbeiten. Direkter Datenbankzugriff ist kein Freibrief zum Schreiben. Finanzrelevante Tabellen sollten nur über kontrollierte Geschäftslogik oder freigegebene Transaktionen verändert werden.
Bei ereignisgetriebenen Prozessen entscheidet die Semantik über die Stabilität. Ein Auftrag sollte nicht mehrfach angelegt werden, nur weil ein Ereignis erneut zugestellt wurde. Eine Einführung in eventgetriebene Architektur liefert dafür wichtige Denkmodelle zu Ereignissen, Zuständen und Wiederholungen.
Auch kleine Eingabekanäle gehören ins Architekturdiagramm. Wenn Mitarbeiter Informationen per Sprache erfassen, muss geklärt sein, ob daraus ein CRM-Aktivitätseintrag, eine Aufgabe oder ein ERP-relevanter Datensatz entsteht. Die Dokumentation der Schnellstart Diktier-App ist dafür ein nützlicher Referenzpunkt, wenn Spracheingaben in bestehende Arbeitsabläufe eingebettet werden sollen.
Ein MCP-Layer wie Supercenter kann den Zugriff auf verschiedene Systeme zentral kontrollieren, statt jeden KI-Agenten direkt mit CRM, ERP und Legacy zu verbinden. Das reduziert Lock-in nicht automatisch. Es schafft aber einen sinnvolleren Ort für Richtlinien, Werkzeuge, Protokolle und Freigaben, sofern die Schnittstellen und Datenmodelle dem Unternehmen gehören.
Datenmodell abgleichen und Datenhoheit je Feld definieren
Die wichtigste Integrationsfrage lautet nicht: „Welche Felder können wir synchronisieren?“ Sie lautet: Wer darf dieses Feld ändern, und welches System setzt den verbindlichen Wert? Ein CRM kann eine Telefonnummer gut verwalten. Ein ERP sollte typischerweise über Auftragsstatus, Rechnungen und Finanzdaten bestimmen. Bei Preisen, Rabatten oder Lieferadressen hängt die Antwort vom Prozess ab.
Statistik Austria weist für 2021 darauf hin, dass 65 % der Unternehmen ERP-Software und ebenfalls 65 % CRM-Software zur Verwaltung von Kundendaten einsetzten. Im selben Datensatz nutzten hochgerechnet rund 12.200 Unternehmen elektronische Verkaufskanäle, was 30 % aller Unternehmen entsprach. Der IKT-Bericht von Statistik Austria dokumentiert diese Ausgangslage. Viele Unternehmen besitzen damit die Systeme, aber nicht zwingend ein gemeinsames Datenmodell.
Vom Objekt zur einzelnen Eigenschaft
Beginnen Sie mit einem begrenzten Prozess, etwa „Opportunity zu Auftrag“. Listen Sie nicht nur Objekte auf, sondern deren Felder:
- Kunde: Das CRM kann Interessenten verwalten. Das ERP vergibt die verbindliche Kundennummer, sobald ein Geschäftspartner angelegt wurde.
- Kontakt: Das CRM führt Kommunikationsdaten. Das ERP erhält nur jene Kontaktdaten, die für Lieferung, Rechnung oder rechtliche Dokumente benötigt werden.
- Produkt: Das ERP führt Artikelnummer, Verkaufspreis, Steuerlogik und Verfügbarkeit. Das CRM darf diese Werte anzeigen, aber nicht frei überschreiben.
- Auftrag: Das ERP führt Auftragsnummer, Status, Positionen und Rechnungsbezug. Das CRM zeigt den Status für Vertrieb und Service.
- Notizen: Das CRM führt Gesprächsnotizen. Sie gehören nicht ungeprüft in Finanz- oder Auftragsfelder.
Diese Matrix muss auch Ausnahmen abbilden. Ein Key Account kann individuelle Preise haben. Eine Adresse kann im CRM vorerfasst, aber erst nach einer Prüfung im ERP freigegeben werden. Ein Feld kann in einem System führend sein, während das andere nur eine lesende Kopie erhält.
Konflikte sind Teil des Designs
Bidirektionale Synchronisation ohne Konfliktregeln ist keine stabile Integration. Definieren Sie für jedes gemeinsam genutzte Feld Priorität, Zeitstempel, Validierung und Eskalation. Bei einem abweichenden Zahlungsziel darf der Prozess nicht stillschweigend den zuletzt geschriebenen Wert übernehmen. Er sollte den Konflikt markieren und an die zuständige Rolle geben.
Die österreichische Praxis zeigt, warum reines Tool-Deployment nicht genügt. Eine österreichische Masterarbeit beschreibt CRM-ERP-Systeme als nicht standardisiert und mit hohem Konfigurationsaufwand verbunden. Effizienzgewinne entstehen deshalb nicht automatisch. Die Arbeit von Andreas Walk behandelt diese Integrationskomplexität im österreichischen KMU-Kontext.
Praktische Regel: Wenn niemand den führenden Wert eines Feldes benennen kann, ist das Feld noch nicht integrationsreif.
Fehlerbehandlung gehört in dieselbe Governance. Ein ungültiger Steuerwert, eine fehlende Kundennummer oder ein nicht verfügbares Produkt darf nicht als unverständlicher API-Fehler im Hintergrund verschwinden. Der Prozess braucht eine verständliche Fehlermeldung, eine Wiederholungslogik, eine verantwortliche Person und eine nachvollziehbare Historie.
Sicherheit Governance und Compliance sauber aufsetzen
Eine funktionierende Verbindung kann trotzdem ein Kontrollproblem sein. Das passiert, wenn das CRM Finanzfelder schreiben darf, ein KI-Agent mit einem technischen Vollzugang arbeitet oder Änderungen an Kundendaten nicht nachvollziehbar bleiben. In einer hybriden österreichischen Landschaft müssen technische Berechtigungen, fachliche Freigaben und lokale Prozesse zusammenpassen.
Schreibrechte nicht pauschal vergeben
Legen Sie Rollen nicht nur auf Systemebene fest. Ein Vertriebsmitarbeiter darf einen Gesprächsstatus ändern, aber nicht zwingend Zahlungsbedingungen. Die Buchhaltung darf Rechnungsdaten bearbeiten, während der Service den Rechnungsstatus lesen kann. Ein Agent sollte dieselben Grenzen einhalten und zusätzlich nur jene Aktionen ausführen, die sein konkretes Werkzeug erlaubt.
Für bidirektionale Prozesse bewährt sich eine Trennung zwischen Vorschlag, Prüfung und Verbuchung. Ein Agent kann einen Auftrag aus einer freigegebenen Opportunity vorbereiten. Die eigentliche Buchung erfolgt über einen kontrollierten ERP-Service und wird protokolliert. Dadurch bleibt die Finanztransaktion im dafür vorgesehenen System.
Audit und lokale Anschlussfähigkeit
Revisionssicherheit bedeutet mehr als ein Logfile mit technischen Fehlermeldungen. Protokollieren Sie ursprünglichen Wert, neuen Wert, Identität des Auslösers, Zeitpunkt, Quelle, Freigabe und Ergebnis. Bei automatisierten Aktionen muss erkennbar sein, welcher Agent welches Werkzeug mit welchem Kontext verwendet hat.
Österreichische Unternehmen müssen ausserdem ihre lokale Systemrealität berücksichtigen. Marktangebote adressieren Migrationen aus On-premise-Umgebungen in SaaS, etwa bei BMD Cloud oder Dynamics 365 in europäischen Azure-Regionen. Gleichzeitig bleiben BMD, Sage, Microsoft Dynamics und proprietäre Lösungen wichtige Bestandteile heterogener Landschaften. Eine österreichische Marktübersicht beschreibt diese Kombination aus Legacy, Cloud und lokalen Anforderungen.
FinanzOnline-Änderungen, Datenschutz, EU-Datenresidenz und branchenspezifische Vorgaben gehören deshalb in die Betriebsplanung. Prüfen Sie vor der Umsetzung, welche Portale, Zertifikate und Exportformate betroffen sind. Ein zentraler MCP-Layer kann Zugriffe bündeln und Systeme weniger direkt exponieren, aber er nimmt dem Unternehmen die Verantwortung für Berechtigungen, Aufbewahrung und fachliche Freigaben nicht ab.
Der Security-Governance-Framework-Ansatz kann helfen, Rollen, Kontrollen und Nachweise als dauerhaftes Betriebsmodell statt als einmalige Projektaufgabe zu behandeln.
Testen ausrollen und in den Betrieb übergeben
Eine Integration ist nicht fertig, wenn der erste Datensatz erfolgreich übertragen wurde. Im produktiven Betrieb zählen Sonderfälle: ein bereits vorhandener Kunde, eine geänderte Adresse, ein abgelehnter Rabatt, ein ERP-Ausfall, eine doppelte Nachricht oder ein Auftrag, der im ERP angenommen, aber im CRM nicht aktualisiert wurde.
Beginnen Sie mit einem Prozessvertrag. Darin stehen die beteiligten Systeme, die führenden Felder, erlaubte Zustände, erwartete Reaktionszeiten, Fehlerwege und Abnahmekriterien. Für einen Auftrag kann das bedeuten: Eine Opportunity darf nur bei definiertem Status übertragen werden, Pflichtfelder müssen validiert sein, die ERP-Auftragsnummer muss zurückkommen und ein Fehler muss einer benannten Rolle zugewiesen werden.
Testdaten müssen reale Ausnahmen enthalten
Ein sauberer Testkatalog umfasst nicht nur den Idealpfad. Verwenden Sie anonymisierte oder eigens erzeugte Datensätze für doppelte Firmen, mehrere Lieferadressen, Sonderpreise, fehlende Steuerinformationen, gesperrte Kunden und abweichende Produktnummern. Prüfen Sie danach nicht nur den Inhalt, sondern auch Nebenwirkungen in Buchhaltung, Lager, Service und Reporting.
Technische Tests decken Mapping und API-Verträge ab. Prozess- und Rechte-Tests zeigen, ob ein Benutzer oder Agent tatsächlich nur erlaubte Aktionen ausführen kann. Last- und Wiederholungstests prüfen, ob Nachrichten sicher erneut verarbeitet werden. Ein manuell ausgelöster Wiederholungsversuch darf keinen zweiten Auftrag erzeugen.
Pilotbetrieb mit dem Aussendienst
Die Live-Anbindung mobiler Teams ist ein guter Belastungstest, weil sie Aktualität, Netzqualität und Bedienbarkeit zusammenbringt. Die österreichische Referenz mit dem Beleuchtungshersteller zeigt einen verbundenen Prozess zwischen Aussendienst, CRM, ERP und WMS. Für einen Pilotbetrieb sollte das Team bewusst mit echten Varianten arbeiten: Produktalternativen, Liefertermine, Kundenänderungen und nachträgliche Korrekturen.
Führen Sie den Rollout schrittweise durch. Starten Sie mit einer klar abgegrenzten Einheit oder einem Prozess, beobachten Sie Fehlerbilder und erweitern Sie erst nach stabiler Abnahme. Parallel braucht der Betrieb ein Monitoring mit verständlichen Alarmen:
- Datenfluss: Welche Nachrichten stehen aus, wurden abgewiesen oder mehrfach zugestellt?
- Feldqualität: Welche Pflichtfelder fehlen, welche Werte verletzen Regeln?
- Geschäftsprozess: Wie viele Aufträge warten auf Prüfung oder bleiben in einem Zwischenstatus?
- Berechtigungen: Welche Schreibversuche wurden blockiert?
- Agentenaktionen: Welche Vorschläge wurden angenommen, geändert oder abgelehnt?
In der Übergabe müssen Runbooks, Mapping-Dokumentation, Zugangspflichten, Eskalationswege und Testfälle vorhanden sein. Definieren Sie ausserdem, wer API-Änderungen bewertet und wer ein Modell oder Agentenwerkzeug freigibt. Die FMA berichtet, dass österreichische Finanzdienstleister bereits mehr als 3.000 kritische IT-Anwendungen für geschäftskritische Prozesse einsetzen und RPA in Banken bei rund 60 % verbreitet ist. Der IKT-Bericht 2025 von Statistik Austria mit FMA-Bezug verdeutlicht den Governance-Aufwand komplexer Finanzlandschaften. Mehr Automatisierung senkt diesen Aufwand nur, wenn Zustände, Daten und Verantwortlichkeiten sauber verbunden sind.
Fazit und nächste Schritte für deine Integration
Eine belastbare CRM-ERP-Integration beginnt nicht mit einem Mapping-Workshop und auch nicht mit einem KI-Pilot. Sie beginnt mit einer Entscheidung über Datenhoheit. Danach folgen Prozessgrenzen, Architektur, Connectoren, Sicherheitsmodell, Tests und ein kontrollierter Rollout.
Die Reihenfolge ist entscheidend:
- Governance festlegen: Bestimme für jedes relevante Feld das führende System, erlaubte Schreibrollen, Ausnahmen und Konfliktweg.
- Prozess priorisieren: Starte mit einem klaren Ablauf wie Opportunity zu Auftrag, Kundenanlage oder Serviceauskunft. Vermeide den Versuch, sofort alle Datenobjekte zu verbinden.
- Landschaft bewerten: Trenne Cloud-APIs, On-premise-Systeme, proprietäre Datenbanken und lokale Finanzprozesse. Wähle Punkt-zu-Punkt nur dort, wo die Abhängigkeit vertretbar bleibt.
- Connectoren schützen: Kapsle Legacy-Zugriffe, validiere Eingaben und halte die Integrationslogik ausserhalb unkontrollierter Datenbankänderungen.
- KI begrenzen: Gib Agenten definierte Werkzeuge für Lesen, Vorschlagen und Ausführen. Finanzielle oder irreversible Aktionen brauchen Freigaben und Audit-Trails.
- Betrieb vorbereiten: Vereinbare Monitoring, Wiederholungen, Support, API-Änderungsmanagement und regelmässige Datenqualitätsprüfungen vor dem Go-live.
Was nicht funktioniert, ist eine bidirektionale Vollsynchronisation ohne Feldverantwortung. Ebenso riskant ist ein Agent mit Zugang zu allen Tabellen, der Geschäftslogik selbst erraten soll. Und ein einmaliger Migrationstag löst keine laufende Datenqualität, wenn danach weiterhin unklare Regeln gelten.
Eine gute Integration macht den nächsten Schritt möglich. Sie schafft die verlässliche Grundlage für Agenten, die Kundeninformationen zusammenfassen, Aufträge vorbereiten, Lieferprobleme erkennen oder Buchhaltungsfragen an die richtige Stelle routen. Specialty Tokens kann dabei als eingebettetes Senior-Engineering-Team Architektur, Custom Connectoren für ERP-, CRM- und Legacy-Systeme sowie einen kontrollierten MCP-Layer mit Supercenter bis in den produktiven Betrieb begleiten.
Die zentrale Entscheidung lautet nicht, wie schnell Daten fliessen. Sie lautet, wer für jeden Wert verantwortlich ist, bevor Daten automatisch fliessen.
Wenn du deine CRM-ERP-Landschaft in Österreich bewerten willst, starte mit einem Feld- und Prozessaudit statt mit einer Tool-Auswahl. Besprich mit Specialty Tokens deine Legacy-Anbindungen, Governance-Regeln und den sicheren Einsatz von Agenten in ERP, CRM und Backoffice.