Alle Artikel
16 Min. Lesezeit

CRM-ERP-Integration in drei Monaten: Proof of Concept mit Senior-Team in der Schweiz

Eine Drehkartei aus den 1980er-Jahren und ein offenes Buchhaltungsjournal auf einem aufgeräumten Schreibtisch, verbunden durch einen einzelnen orangen Faden von einer Karte zu einer Journalzeile.

Die Integration von CRM und ERP ist der schnellste Weg, um manuelle Übergaben zwischen Vertrieb und Finanzen zu beenden und allen Abteilungen dieselbe Datenbasis zu geben. Fangen Sie klein an: Testen Sie einen Ablauf mit hoher Reibung in einem Proof of Concept, meist Offerte zu Auftrag, bevor Sie irgendetwas anderes anfassen. Klären Sie Authentifizierung, TLS und rollenbasierte Zugriffsrechte, bevor der erste Datensatz synchronisiert wird. Eine überhastete Integration verteilt schlechte Daten sonst über zwei Systeme statt nur über eines, wie in Salesforce Commerce Cloud SEO Automation beschrieben.


Kurz gefasst:

  • Synchronisieren Sie zuerst Kontakt- und Kundendaten, damit saubere, eindeutige Datensätze vorliegen, bevor weitere Datenflüsse dazukommen.

  • Prüfen Sie Datenzuordnung und Leistung in einem Proof of Concept auf einem reibungsintensiven Ablauf wie Offerte zu Auftrag, bevor Sie skalieren.

  • Wählen Sie die Architektur nach Anzahl Endpunkte und Datenvolumen: native Konnektoren für einfache Setups, iPaaS oder eigene APIs für komplexe Anforderungen.

  • Legen Sie von Beginn an klare Datenhoheit, präzises Feld-Mapping und Überwachung fest, um Dubletten und Probleme mit API-Limits zu vermeiden.

  • Synchronisieren Sie kritische, häufig ändernde Daten wie Lagerbestände in Echtzeit und weniger wichtige Daten im Stapelbetrieb, damit die Systeme auch bei wachsendem Volumen schnell bleiben.


Was eine CRM-ERP-Integration für Ihr Unternehmen konkret bedeutet

Eine CRM-ERP-Integration verbindet Ihr Frontoffice-System (wo Vertrieb, Marketing und Support die Kundenbeziehungen verfolgen) mit Ihrem Backoffice-System (wo Lager, Rechnungsstellung und Finanzen liegen). Statt dass eine Verkäuferin bei den Finanzen nach dem Lagerbestand fragt oder ein Sachbearbeiter Auftragsdaten ins CRM abtippt, sprechen die beiden Plattformen direkt miteinander und halten die Datensätze automatisch synchron. Diese Integration verbindet Frontoffice- und Backoffice-Daten zu einer single consistent source of truth für Kunden- und Auftragsdaten, statt zwei halbe Wahrheiten in getrennten Datenbanken zu pflegen.

Der Nutzen zeigt sich im Tagesgeschäft, nicht in einer Präsentation. Wenn Offerten ohne erneute Erfassung direkt zu Aufträgen werden, schliesst der Vertrieb schneller ab und die Finanzabteilung muss keinen fehlenden Bestellnummern mehr nachlaufen. Wenn Lagerbestände nahezu in Echtzeit ins CRM fliessen, versprechen Verkaufsmitarbeitende keine Liefertermine mehr, die das Lager nicht halten kann.

Drei Teams spüren den Unterschied sofort:

  • Vertrieb sieht aktuelle Bestände und Preise direkt im CRM, statt für jede Offerte bei der Logistik nachzufragen.

  • Finanzen erhalten Rechnungs- und Zahlungsstatus automatisch in den Kundendatensätzen, was den Abstimmungsaufwand am Monatsende verkürzt.

  • Operations hat weniger Auftragsfehler, weil einmal erfasste Daten ohne manuelle Neueingabe weiterfliessen.

Messbar sind weniger Fehler, ein kürzerer Zyklus von der Offerte bis zum Zahlungseingang und ein Reporting, das über alle Abteilungen hinweg endlich übereinstimmt. Der letzte Punkt wiegt schwerer, als er klingt. Die meisten Finanzverantwortlichen kennen ein Quartal, in dem der Vertrieb eine Umsatzzahl meldete und das ERP eine andere, und die Abstimmung kostete jemanden ein Wochenende.

Welche Datenflüsse sollten Sie zuerst synchronisieren?

Nicht jeder Datensatz braucht ab Tag eins eine Synchronisation in Echtzeit. Praxisleitfäden nennen übereinstimmend eine bestimmte Auswahl von Abläufen, die Priorität verdienen. Denn alles auf einmal synchronisieren zu wollen, ist der häufigste Grund, weshalb integration projects stall. Wählen Sie den Ablauf, der zu Ihrem grössten operativen Schmerzpunkt passt, und bauen Sie von dort aus.

  1. Kontakte und Kunden. Abgeglichene Kunden- und Firmendaten in CRM und ERP verhindern Dubletten und falsche Rechnungsadressen. Das ist fast immer die Grundlage, weil jeder weitere Ablauf auf sauberen Kundendaten aufbaut.

  2. Offerte zu Auftrag. Wandelt eine Verkaufsperson eine Offerte um, sollte daraus ein ERP-Auftrag werden, ohne dass jemand Positionen abtippt. Dieser Ablauf bringt meist den schnellsten sichtbaren Gewinn, weil er einen manuellen Schritt entfernt, den der Vertrieb jede Woche spürt.

  3. Lagerbestand als Verfügbarkeit im CRM. Bestände in Echtzeit oder nahezu in Echtzeit im CRM verhindern, dass der Vertrieb Ware verkauft, die im Lager nicht vorhanden ist.

  4. Rechnungen ins CRM. Rechnungsstatus und Zahlungshistorie zurück ins CRM zu spielen, gibt Kundenbetreuenden vor einem Verlängerungs- oder Upsell-Gespräch den nötigen Kontext.

  5. Preise und Konditionen. Vertragsspezifische Preise, Rabatte und Zahlungskonditionen müssen zwischen den Systemen exakt übereinstimmen, sonst entstehen Streitfälle bei der Rechnungsstellung.

  6. Retouren und Nachvollziehbarkeit im Support. Support-Tickets und Retouren mit dem ursprünglichen Auftrag zu verknüpfen, hilft Service und Finanzen, die ganze Historie ohne Systemwechsel zu sehen.

  7. Warnungen zu offenen Posten. Überfällige Salden im CRM sichtbar zu machen, erlaubt es Vertrieb und Kundenbetreuung, ein Risiko zu melden, bevor die Finanzabteilung eskaliert.

Profitipp: Wählen Sie Ihren ersten Ablauf nicht nach technischer Einfachheit. Wählen Sie den Ablauf, der zur Beschwerde gehört, die Sie in den wöchentlichen Teamsitzungen am häufigsten hören. Dort ist der Nutzen am klarsten.

Ein Handelsunternehmen im Mittelstand profitiert typischerweise am schnellsten von Offerte zu Auftrag und Lagerverfügbarkeit, weil diese beiden Abläufe die meisten Transaktionen pro Tag betreffen. Ein Dienstleistungsunternehmen mit weniger, dafür grösseren Abschlüssen holt oft mehr aus Rechnungen im CRM und Warnungen zu offenen Posten heraus.

Native Konnektoren, Middleware oder eigene APIs: Was passt?

Es gibt drei Architekturwege, und den falschen für Ihre Grössenordnung zu wählen, ist der teuerste Fehler in diesem Prozess. Die drei groben Kategorien sind native Konnektoren, iPaaS- beziehungsweise Middleware-Plattformen und eigene Umsetzungen mit APIs oder Webhooks, jede mit anderen Kompromissen bei Tempo, Flexibilität und langfristigen Kosten.

Native Konnektoren sind vorgefertigte Verbindungen zwischen bestimmten CRM- und ERP-Produkten, oft vom Hersteller selbst oder von einem zertifizierten Partner angeboten. Sie sind schnell einsatzbereit und brauchen kaum Eigenentwicklung, was sie für kleinere Teams mit einfachen Anforderungen attraktiv macht. Der Preis dafür ist Flexibilität: Sie sind auf die Felder und Abläufe beschränkt, die der Konnektor unterstützt. Passt Ihr Prozess nicht in die Vorlage, warten Sie auf ein Update des Anbieters.

iPaaS- oder Middleware-Plattformen (Integration Platform as a Service) sitzen als Drehscheibe zwischen CRM und ERP und leiten Daten über vorgefertigte Konnektoren und Transformationsregeln. Dieses Hub-and-Spoke-Muster eignet sich gut für mittelgrosse Unternehmen mit drei oder mehr Systemen, weil ein neuer Endpunkt nur eine weitere Verbindung braucht, statt einer neu gebauten Punkt-zu-Punkt-Kopplung. Grössere Unternehmen wählen aus diesem Grund häufig Plattformen wie Boomi. Boomi’s broad connector library and partner ecosystem machen es zur naheliegenden Wahl, wenn ein Unternehmen viele Systeme gleichzeitig verbinden muss, nicht nur CRM und ERP. Der Preis sind wiederkehrende Abonnementskosten und eine Lernkurve für die Plattform selbst.

Eigene Umsetzungen mit APIs und Webhooks geben Ihnen volle Kontrolle darüber, was wann und wie synchronisiert wird. Dieser Weg lohnt sich, wenn Ihre Datenflüsse ungewöhnlich sind, Ihr Volumen so hoch ist, dass Standardkonnektoren an ihre Grenzen kommen, oder Sie Logik brauchen, die keine Anbietervorlage abbildet. Die Kosten laufen weiter: Wartung, Fehlerbehandlung und jede künftige API-Version auf beiden Seiten liegen bei Ihnen.

Einige Faktoren sollten diese Entscheidung leiten:

  • Anzahl Endpunkte. Zwei Systeme sprechen für einen nativen Konnektor oder eine Punkt-zu-Punkt-API, drei oder mehr für iPaaS.

  • Erwartetes Datenvolumen. Hohe Transaktionsvolumen brauchen unabhängig von der Architektur meist Stapelverarbeitung, kleine Volumen laufen ohne Belastung über Webhooks in Echtzeit.

  • Anforderungen an die Verzögerung. Braucht der Vertrieb Bestandszahlen innerhalb von Sekunden, schlagen ereignisgesteuerte Webhooks jeden Stapellauf.

  • Abhängigkeit vom Anbieter. Native Konnektoren binden Sie an die Roadmap eines bestimmten Anbieters, eigene APIs und iPaaS lassen mehr Spielraum, Komponenten später auszutauschen.

Moderne Integrationen legen zunehmend KI-gestütztes Mapping über jede dieser drei Architekturen, was speeds up field mapping and improves anomaly detection, wenn Datensätze nicht sauber zusammenpassen. Es lohnt sich, jeden Integrationspartner danach zu fragen, denn manuelles Feld-Mapping über Hunderte von Feldern kostet die meisten Projekte Wochen.

Ihre Checkliste vor dem Start für einen sauberen Rollout

Bevor überhaupt Daten produktiv synchronisiert werden, müssen einige Governance-Entscheide feststehen. Wird dieser Schritt übersprungen, läuft die Integration zwei Wochen reibungslos und produziert dann still und leise Dubletten, die niemand bemerkt, bis der Monatsabschluss ansteht.

Beginnen Sie mit der Datenhoheit. Für jedes Objekt (Kontakt, Auftrag, Rechnung) muss ein System das führende sein. Wenn CRM und ERP beide dasselbe Adressfeld einer Kundin ändern dürfen, entstehen innert Tagen widersprüchliche Aktualisierungen.

  • Legen Sie fest, welches System welches Objekt führt (Kontakte, Aufträge, Preise, Rechnungen).

  • Ordnen Sie Felder präzise zu, inklusive Datentypen und der nötigen Abgleichsschlüssel (meist E-Mail oder eine eindeutige Kundennummer).

  • Definieren Sie klare Regeln zur Dublettenbereinigung vor der ersten Synchronisation, nicht erst wenn Dubletten auftauchen.

  • Entscheiden Sie den Takt je Ablauf: Echtzeit für Bestände und Offerten, Stapelbetrieb für Finanzreporting oder grosse historische Datenmengen.

  • Richten Sie Überwachung und Alarmierung für fehlgeschlagene Synchronisationen vor dem Livegang ein, nicht im Nachhinein.

  • Budgetieren Sie laufende Wartungsstunden, nicht nur die Kosten der ersten Umsetzung.

Die zentralen Punkte der Checkliste betreffen die Hoheit über die Stammdaten, präzises Feld-Mapping, den Synchronisationstakt, die Überwachung und die Fehlermeldungen.

Auch die Sicherheitsmassnahmen gehören von Anfang an dazu: Authentifizierung über OAuth 2.0, TLS-Verschlüsselung für Daten während der Übertragung, Verschlüsselung ruhender Daten, rollenbasierte Zugriffskontrolle und Audit-Protokolle. Das sind Grundvoraussetzungen, bevor irgendwelche Daten synchronisiert werden.

Warum Dubletten und API-Limits Integrationen zum Entgleisen bringen

Zwei Probleme verursachen die meisten Support-Tickets nach dem Start: Dubletten und API-Ratenlimits. Beide sind vorhersehbar, und für beide gibt es bekannte Lösungen.

Dubletten entstehen meist aus unklarer Hoheit über die Stammdaten. Wenn der Vertrieb im CRM einen neuen Kunden anlegen kann, ohne zu prüfen, ob dieser im ERP bereits existiert, haben Sie am Ende zwei Kundendatensätze, die nie zusammenfinden. Die Lösung ist ein strikter Abgleichsschlüssel (Steuernummer, E-Mail-Domain oder eine gemeinsame Kundennummer), der schon bei der Erfassung durchgesetzt wird, statt im Nachhinein bereinigt zu werden.

API-Ratenlimits sind das zweite wiederkehrende Ärgernis, besonders bei Abläufen mit hohem Volumen wie Bestandsaktualisierungen. Läuft ein Synchronisationsjob in ein Limit, darf die Antwort nie einfach stillschweigend fehlschlagen. In der Entwicklung gilt als gute Praxis, retry logic with exponential backoff and route unrecoverable messages to a dead-letter queue zur manuellen Prüfung vorzusehen, statt fehlgeschlagene Datensätze verschwinden zu lassen.

Einige praktische Gegenmassnahmen, die ab Tag eins eingebaut gehören:

  • Setzen Sie je Objekttyp einen einzigen Abgleichsschlüssel durch, bevor ein Datensatz angelegt wird.

  • Richten Sie für API-Aufrufe mit Ratenlimit eine Wiederholungslogik mit exponentiell steigenden Wartezeiten ein.

  • Leiten Sie fehlgeschlagene oder fehlerhafte Datensätze in eine Dead-Letter-Queue, statt sie zu verwerfen.

  • Planen Sie eine wiederkehrende Wartungsprüfung ein, denn API-Versionen ändern sich auf beiden Seiten ohne grosse Vorwarnung.

Die langfristige Wartung wird von den meisten Teams zu knapp budgetiert. Eine Integration, die beim Start perfekt läuft, kann über 18 Monate still verfallen, weil ein Anbieter seine API aktualisiert und niemand das Mapping anpasst. Behandeln Sie Wartung als wiederkehrende Position, nicht als einmalige Projektkosten.

So führen Sie einen Proof of Concept durch, bevor Sie skalieren

Der beste Weg, das Risiko im ganzen Vorhaben zu senken, ist der Nachweis an einem einzigen Ablauf, bevor Sie sich auf den Rest festlegen. Ein fokussierter Proof of Concept auf einem reibungsintensiven Ablauf prüft Ihr Daten-Mapping, Ihre Annahmen zur Leistung und Ihre Überwachung, solange der Schaden bei einem Fehler klein bleibt.

  1. Wählen Sie einen Ablauf. Offerte zu Auftrag ist der häufigste Startpunkt, weil er gut sichtbar und relativ abgegrenzt ist.

  2. Definieren Sie die Erfolgskriterien vorab. Setzen Sie Zielwerte für Datengenauigkeit (Anteil der Datensätze, die ohne manuelle Korrektur synchronisiert werden), Verzögerung (wie lange ein Datensatz braucht, bis er im zweiten System erscheint) und Fehlerquote.

  3. Verteilen Sie klare Rollen. Sie brauchen jemanden für die CRM-Daten, jemanden für die ERP-Daten und eine Entwicklerin oder einen Integrationspartner für die Verbindung selbst.

  4. Begrenzen Sie die Dauer auf drei Monate. Zieht sich ein Proof of Concept über drei Monate hinaus, ist der Umfang meist über den ursprünglich einen Ablauf hinausgewachsen.

  5. Prüfen Sie, bevor Sie skalieren. Vergleichen Sie die Datenintegrität mit den Quelldatensätzen, prüfen Sie, ob die Verzögerung Ihr Ziel erreicht, und holen Sie die Freigabe der tatsächlichen Nutzenden ein, nicht nur der IT.

Profitipp: Führen Sie Ihren Proof of Concept mit echten Produktivdaten in einer Testumgebung durch, nicht mit Beispieldaten. Beispieldaten bringen nie die Sonderfälle zum Vorschein (Sonderzeichen, fehlende Felder, Dubletten), an denen Integrationen in der Praxis scheitern.

Für die Besetzung des Proof of Concept gibt es drei Möglichkeiten: intern umsetzen, wenn Sie bereits Entwickler:innen für Integrationen im Haus haben, einen betreuten Partner beiziehen für eine Umsetzung mit erfahrenen Senior-Leuten ohne Anstellung, oder auf die vorgefertigten Konnektoren einer iPaaS-Plattform setzen, falls Ihre Abläufe standardisiert genug sind. Sobald der Proof of Concept seine Prüfkriterien erfüllt, heisst skalieren: den nächsten priorisierten Ablauf ergänzen, nicht das Funktionierende neu bauen.

Was ein Team aus erfahrenen Senior-Leuten verändert

Die meisten Integrationsprojekte scheitern nicht an der Technik. Sie scheitern am schleichenden Ausufern des Umfangs: Ein Junior-Team ist drei Wochen im Aufbau des Ablaufs von Offerte zu Auftrag, stellt fest, dass das Datenmodell des ERP nicht den Annahmen entspricht, und schreibt die halbe Mapping-Logik neu. Erfahrene Entwickler:innen erkennen diese Abweichung schon in der Analysephase, bevor eine einzige Zeile Integrationscode entsteht, weil sie dieselben ERP-Eigenheiten aus anderen Projekten kennen.

Bei Ampersand Labs liegt genau darin der praktische Unterschied: Dieselben erfahrenen Leute, die die Integration abstecken, bauen sie auch und übergeben sie, sodass zwischen Verkaufsgespräch und Umsetzungsteam nichts verloren geht. Für CRM-ERP-Projekte relevant sind:

  • API-Entwicklung und Systemintegration, die CRM-Plattformen mit ERP- und Buchhaltungssystemen verbinden.

  • Ein Proof of Concept, abgesteckt auf einen einzigen Ablauf, mit vorab definierten Erfolgskriterien.

  • Laufende Überwachung und Wartung nach dem Livegang, damit fehlgeschlagene Synchronisationen auffallen, bevor sie sich häufen.

Ein Beispiel für diese technische Kontinuität in der Praxis ist die Arbeit von Ampersand für Die Mitte, eine Schweizer Partei, für die das Studio eine Infrastruktur mit über 600 einzelnen Websites aus einem einzigen System aufgebaut hat und heute betreibt, statt jede Website als eigenes Projekt zu behandeln. So viele verbundene Instanzen gleichzeitig zu betreuen, verlangt dieselbe Disziplin wie das Synchronisieren von CRM- und ERP-Abläufen über Abteilungen hinweg: klare Hoheit je Objekt, überwachte Fehlerbehandlung und ein System, das beim Wachsen nicht still abbaut.

Die Wahl zwischen einem betreuten Partner und einer internen Umsetzung hängt meist an einer Frage: Haben Sie Entwickler:innen für Integrationen, die in achtzehn Monaten noch da sind, um das Ganze zu warten? Wenn ja, ist die interne Umsetzung sinnvoll. Wenn nein, vermeidet ein betreutes Mandat das Risiko einer Integration, die niemand im Haus gut genug versteht, um sie zu reparieren.

Wie eine Integration Ihre Datenqualität mit der Zeit verändert

CRM und ERP zu verbinden, bewegt nicht nur Daten schneller. Es verändert, was «saubere Daten» für Ihre Organisation überhaupt bedeutet. Vor der Integration blieben die Qualitätsprobleme jedes Systems eingegrenzt: Ein unsauberes CRM schadete nur dem Vertrieb, ein unsauberes ERP nur den Finanzen. Sobald synchronisiert wird, pflanzen sich Fehler fort. Ein doppelter Kundendatensatz im CRM erzeugt nun eine doppelte Auftragshistorie im ERP.

Der Vorteil wirkt in die gleiche Richtung. Ein einziger geprüfter Abgleichsschlüssel über beide Systeme bedeutet, dass eine einmal im ERP korrigierte Adresse überall korrekt erscheint, wo sie referenziert wird, statt monatelang als veralteter Wert im CRM zu bleiben. Teams, die Feld-Mapping und Dublettenregeln von Anfang an richtig setzen, sehen in den folgenden zwei bis drei Monaten meist einen stetigen Rückgang der Tickets für manuelle Datenkorrekturen, weil schlechte Datensätze bereits bei der Erfassung auffallen und nicht erst später in einem Report.

Auch die Häufigkeit der Synchronisation spielt hier eine Rolle. Echtzeit für Daten mit hoher Änderungsrate wie Lagerbestände hält beide Systeme ehrlich, während Stapelbetrieb für weniger wichtige Daten (etwa historische Auftragsarchive) die Last senkt, ohne dort an Genauigkeit einzubüssen, wo sie zählt. Der zu vermeidende Fehler ist, jedes Feld so zu behandeln, als bräuchte es Echtzeit. Das ist nicht so, und wer es erzwingt, belastet meist nur die API-Limits ohne betrieblichen Nutzen.

Integrierte Systeme schnell halten, wenn das Volumen wächst

Leistungsprobleme in CRM-ERP-Integrationen zeigen sich selten am ersten Tag. Sie zeigen sich sechs Monate später, wenn sich das Transaktionsvolumen verdoppelt hat und Synchronisationsjobs, die früher Minuten brauchten, plötzlich Stunden dauern.

Einige praktische Hebel halten integrierte Systeme auch bei Wachstum reaktionsschnell:

  • Führen Sie schwere, nicht dringende Abläufe im Stapel aus. Warnungen zu offenen Posten oder historische Auswertungen brauchen keine Echtzeit. Nachts gebündelt, senken sie die API-Last während der Geschäftszeiten.

  • Reservieren Sie ereignisgesteuerte Webhooks für wirklich zeitkritische Abläufe, etwa Lagerverfügbarkeit oder Auftragsstatus, wo eine Verzögerung tatsächlich einen Verkauf oder ein Support-Ticket kostet.

  • Überwachen Sie den Verbrauch der API-Ratenlimits, nicht nur Erfolg oder Misserfolg der Synchronisation, damit Sie drohende Limits erkennen, bevor Datensätze verloren gehen.

  • Archivieren oder paginieren Sie grosse historische Synchronisationen, statt bei jedem Lauf den ganzen Datenbestand zu ziehen.

Die Teams, die Leistungseinbussen vermeiden, prüfen ihre Synchronisationsarchitektur in geplanten Abständen und nicht erst, wenn etwas kaputtgeht. Eine quartalsweise Prüfung des Synchronisationsvolumens gegen die ursprünglichen Annahmen erkennt das langsame Kriechen, bevor daraus ein Ausfall wird.

Wohin sich die CRM-ERP-Integration entwickelt

Die sichtbarste Veränderung im Moment ist, dass KI vom netten Zusatz zur Schicht wird, die das Mapping tatsächlich erledigt. Statt dass eine Entwicklerin Hunderte Felder zwischen zwei Schemas von Hand zuordnet, schlagen KI-gestützte Werkzeuge zunehmend Zuordnungen vor und melden Auffälligkeiten, wenn ein Datensatz nicht ins erwartete Muster passt. Eine Aufgabe, die früher Wochen dauerte, schrumpft so auf ein paar Tage Prüfarbeit.

Rechnen Sie damit, dass sich mehr Integrationen auch für die laufende Erkennung von Auffälligkeiten darauf stützen, nicht nur für die Ersteinrichtung. Ein Synchronisationsjob, der ungewöhnliche Muster erzeugt (etwa ein plötzlicher Anstieg doppelter Kontakte), kann automatisch gemeldet werden, statt drei Wochen später in einem Finanzbericht aufzutauchen. Diese Verschiebung macht die Fehlerbehandlung vorausschauend statt reaktiv, und genau daran sind Integrationsteams bisher meist gescheitert.

Der übergeordnete Trend dahinter: Immer weniger Unternehmen versuchen riesige Integrationen auf einen Schlag, immer mehr wählen den schrittweisen Weg mit einem Proof of Concept zuerst, wie ihn dieser Artikel beschreibt. Das ist weniger ein technischer Trend als eine hart erkaufte Lektion aus genügend gescheiterten Grossumstellungen, bis sich die Branche auf kleinere, überwachte Schritte geeinigt hat.

Ampersand Labs für Ihr Integrationsprojekt

Wenn Sie abwägen, ob Sie intern umsetzen, eine Generalistenagentur beauftragen oder Spezialist:innen beiziehen, ist das Risiko bei den ersten beiden Optionen meist dasselbe: ausufernder Umfang durch Personalwechsel bei Junior-Leuten oder eine Übergabe mitten im Projekt, bei der Kontext verloren geht. Ampersand Labs führt Integrationsprojekte mit denselben erfahrenen Entwickler:innen vom ersten Gespräch bis zur Übergabe. Das nimmt das Risiko, dass die halbe Arbeit neu geschrieben werden muss, weil ein Team die Eigenheiten Ihres ERP erst mitten im Aufbau kennenlernt.

Zu den passenden Leistungen von Ampersand gehören hier Systemintegration und API-Entwicklung zur Anbindung von CRM-, ERP- und Buchhaltungsplattformen, dazu ein Proof of Concept, abgesteckt auf einen einzigen Ablauf, und laufende Überwachung im Betrieb. Für Teams, die zusätzlich KI-gestütztes Mapping oder das Erkennen von Auffälligkeiten prüfen, decken die Dienstleistungen für KI-Automatisierung des Studios auch diese Ebene ab.

Die Preise für eine einzelne Verbindung oder ein vollständiges Integrationspaket finden Sie auf der Preisseite von Ampersand Labs, und laufende Unterstützung nach dem Start gibt es mit dem Plan «Run & monitor» für CHF 750 pro Monat. Falls Ihr Team parallel zur Integration eine grössere Ablösung von Altsystemen erwägt, ist das ein eigenes, aber verwandtes Thema, das man früh besprechen sollte. Der sinnvollste nächste Schritt ist ein kurzes Erstgespräch, um einen einzelnen Ablauf abzustecken, also genau der Weg mit dem Proof of Concept zuerst, den dieser Leitfaden empfiehlt. So sehen Sie, wie ein Zeitrahmen von drei Monaten für Ihre konkreten Systeme aussieht.

Quellen

Dieser Leitfaden stützt sich auf Untersuchungen zur Integrationsarchitektur von NetSuite, IBM Think und auf Praxisleitfäden für Entwickler:innen. Schweizer Teams sollten bei jedem Integrationsanbieter den Datenstandort und die Einhaltung des revidierten DSG prüfen.

Häufige Fragen

Was sind ein CRM und ein ERP?

Ein CRM (System für das Kundenbeziehungsmanagement) verwaltet die Interaktionen mit Kundinnen und Kunden in Vertrieb, Marketing und Support. Ein ERP (System zur Unternehmensressourcenplanung) verwaltet Backoffice-Funktionen wie Lager, Buchhaltung und Auftragsabwicklung. Die Integration verbindet beide, damit Kunden- und Auftragsdaten in beiden Systemen konsistent bleiben.

Was umfasst eine CRM-Integration konkret?

CRM-Integration bedeutet, Ihr CRM mit anderen Geschäftssystemen zu verbinden, meist mit einem ERP, damit Datensätze wie Kontakte, Aufträge und Rechnungen automatisch synchronisiert werden, statt von Hand neu erfasst zu werden. Das läuft je nach Volumen und Komplexität typischerweise über einen nativen Konnektor, eine iPaaS-Plattform oder eine eigene API.

Ist SAP ein CRM oder ein ERP?

SAP ist vor allem als ERP-Plattform bekannt und deckt Finanzen, Lager und Betrieb ab, bietet aber auch CRM-Module und -Produkte an. Die meisten Unternehmen, die SAP als ERP nutzen, binden es trotzdem an ein separates, spezialisiertes CRM an, um den vollen Funktionsumfang im Frontoffice zu erhalten.

Ist ein ERP besser als ein CRM?

Keines ist «besser». Sie lösen unterschiedliche Probleme: Das ERP steuert den Backoffice-Betrieb wie Lager und Finanzen, das CRM die Kundenbeziehungen und die Verkaufspipeline. Die meisten wachsenden Unternehmen brauchen irgendwann beides, verbunden über eine CRM-ERP-Integration, statt sich für das eine oder andere zu entscheiden.

Wie lange dauert es, bis eine CRM-ERP-Integration live geht?

Ein fokussierter Proof of Concept auf einem einzelnen Ablauf, etwa Offerte zu Auftrag, läuft typischerweise über drei Monate von der Abgrenzung bis zur Prüfung. Der vollständige Rollout über mehrere priorisierte Abläufe dauert länger und hängt davon ab, wie viele Systeme und Datenflüsse Sie verbinden.

Aktualisiert

Sprechen Sie mit uns

Haben Sie ein Projekt, das dieses Thema berührt?

Ein kostenloses 10-Minuten-Gespräch ist der schnellste Weg, um herauszufinden, ob wir das richtige Studio dafür sind.

Kostenloses 10-Min-Gespräch buchen