Kundenportal mit ERP & CRM verbinden: Integrationsleitfaden

Ein Kundenportal entfaltet seinen Nutzen erst dann vollständig, wenn es mit den bestehenden Unternehmenssystemen verbunden ist. Kunden erwarten keine zweite Datenwelt, sondern aktuelle Informationen zu Aufträgen, Lieferterminen, Preisen, Rechnungen oder Servicefällen – unabhängig davon, in welchem System diese Daten ursprünglich liegen.

Damit wird die Integration von ERP und CRM zu einem der entscheidenden Erfolgsfaktoren eines Kundenportals. Technisch funktioniert vieles.

Die wichtigere Frage lautet jedoch:
Welche Daten müssen in Echtzeit verfügbar sein, welche können zwischengespeichert werden und wie verhindert man, dass das Portal direkt von jedem einzelnen Backend-System abhängig wird?

Eine gute Architektur verbindet deshalb nicht einfach Systeme miteinander. Sie sorgt dafür, dass ERP, CRM und Portal unabhängig voneinander weiterentwickelt werden können und der Kunde auch dann eine zuverlässige Anwendung erhält, wenn ein Backend-System kurzfristig langsam oder nicht erreichbar ist.

Welche Daten aus ERP und CRM gehören ins Kundenportal?

Welche Informationen ein Portal benötigt, hängt vom Geschäftsmodell ab. In Industrie und technischem Großhandel begegnen uns jedoch immer wieder ähnliche Anforderungen.

Typische ERP-Daten sind:

• kundenspezifische Preise und Konditionen
• Produkte und Artikelnummern
• Lagerbestände und Verfügbarkeiten
• offene und abgeschlossene Aufträge
• Bestellhistorie
• Lieferstatus und Liefertermine
• Rechnungen und Gutschriften
• Angebote
• Vertrags- und Rahmenvertragsdaten

Aus dem CRM kommen beispielsweise:

• Kunden- und Ansprechpartnerdaten
• Vertriebszuständigkeiten
• Aktivitäten und Kontaktinformationen
• offene Angebote oder Verkaufschancen
• Serviceanfragen und Tickets
• Kommunikationshistorien

Das Ziel sollte dabei nicht sein, sämtliche Informationen aus ERP und CRM im Portal abzubilden.

Entscheidend ist vielmehr die Frage:

Welche Informationen oder Funktionen vermeiden für Kunde und Mitarbeiter tatsächlich eine manuelle Rückfrage?

Genau hier entsteht der wirtschaftliche Nutzen eines Kunden- und Serviceportals

⁠

Integrations-Architektur: drei grundlegende Ansätze

Für die technische Anbindung eines Kundenportals gibt es drei grundlegende Architekturmodelle. In der Praxis werden sie häufig miteinander kombiniert.

1. Direkte API-Anbindung

Das Kundenportal greift über REST, OData, SOAP oder andere Schnittstellen direkt auf ERP oder CRM zu.

Beispiel: Kundenportal → API → ERP

Der Ansatz ist attraktiv, weil er zunächst einfach erscheint. Das Portal fragt beispielsweise beim ERP den aktuellen Lagerbestand oder Auftragsstatus ab und zeigt die Antwort unmittelbar an.

Vorteile

• direkte Kommunikation
• aktuelle Daten
• geringer zusätzlicher Infrastrukturbedarf
• bei einfachen Szenarien schnell umsetzbar

Nachteile

• Portal und ERP werden eng gekoppelt
• Antwortzeiten des ERP beeinflussen das Portal
• Änderungen der ERP-Schnittstelle können Anpassungen im Portal erfordern
• mehrere Backend-Systeme erhöhen schnell die Komplexität

Direkte API-Aufrufe eignen sich daher besonders für klar abgegrenzte Funktionen und stabile Schnittstellen.

 

2. Middleware oder iPaaS

Zwischen Portal und Backend-Systemen wird eine Integrationsschicht eingesetzt.

Zum Beispiel: Kundenportal → Middleware → ERP / CRM / PIM

Eine solche Middleware kann eine klassische Integrationsplattform, eine iPaaS-Lösung oder eine individuell entwickelte Integrationsschicht sein.

Sie übernimmt unter anderem:

• Transformation von Datenformaten
• Feldmapping
• Authentifizierung
• Routing
• Protokollierung
• Fehlerbehandlung
• Wiederholungsversuche
• Verbindung mehrerer Systeme

Der große Vorteil: Das Kundenportal muss nicht wissen, ob ein bestimmter Datensatz aus SAP, proALPHA, Salesforce oder einem anderen System stammt.

 

3. Datenreplikation und Caching-Layer

Nicht jede Information muss bei jedem Seitenaufruf live aus dem ERP gelesen werden.

Produktdaten, Dokumente, Ansprechpartner oder Bestellhistorien können beispielsweise regelmäßig synchronisiert und in einer für das Portal optimierten Datenstruktur bereitgestellt werden.

Eine typische Architektur sieht dann so aus: ERP / CRM → Integrationsschicht → Portal-Datenbank oder Cache → Kundenportal

Nur Daten, bei denen Aktualität entscheidend ist, werden weiterhin live abgefragt.

Das reduziert Last und Abhängigkeiten und kann die Geschwindigkeit des Portals erheblich verbessern.

 

API, Middleware oder Replikation?

Es gibt nicht die eine richtige Architektur. Entscheidend sind Datenmenge, Aktualitätsanforderungen und Komplexität der vorhandenen Systemlandschaft.

Unsere Faustregel: Je mehr Systeme beteiligt sind und je geschäftskritischer das Kundenportal wird, desto wichtiger wird eine Integrationsschicht zwischen Frontend und Backend.

 

Echtzeit oder Batch: Nicht jede Information muss live sein

„Wir brauchen alle Daten in Echtzeit“ klingt zunächst nach einer sinnvollen Anforderung.

Technisch und wirtschaftlich ist sie jedoch selten notwendig.

Die entscheidende Frage lautet:
Wie alt darf eine Information sein, bevor sie für den Kunden falsch oder problematisch wird?

 

Typischerweise Echtzeit oder nahezu Echtzeit

• Lagerbestand
• individuelle Preise
• Lieferfähigkeit
• Auftragsstatus
• Bestellfreigaben
• Verfügbarkeitsprüfung

 

Häufig problemlos als Batch oder Synchronisation

• Produktbeschreibungen
• technische Dokumentationen
• Ansprechpartner
• Kategorien
• abgeschlossene Bestellungen
• ältere Rechnungen
• Stammdaten

 

Häufig sinnvoll: Caching mit gezielter Aktualisierung

Zwischen beiden Extremen liegt ein besonders leistungsfähiger Ansatz.

Daten werden zwischengespeichert, bei Änderungen aktualisiert oder nach definierten Zeiträumen erneut abgefragt.

Damit lassen sich Aktualität, Geschwindigkeit und ERP-Belastung gezielt ausbalancieren.

 

SAP, proALPHA, Microsoft Dynamics, Sage und CRM-Systeme anbinden

Die Integrationsarchitektur sollte nicht von einem bestimmten Hersteller abhängig gemacht werden. Trotzdem unterscheiden sich die Möglichkeiten der einzelnen Systeme.

SAP S/4HANA

SAP stellt für S/4HANA unter anderem OData- und SOAP-basierte APIs bereit. OData eignet sich insbesondere für synchrone Szenarien, bei denen eine unmittelbare Antwort benötigt wird.

Typisches Vorgehen:
APIs für klar definierte Geschäftsobjekte verwenden und eine Integrationsschicht zwischen SAP und Portal setzen.

Stolperstein:
Nicht jede im SAP vorhandene Information sollte ungefiltert zur Portal-API werden. Das externe Datenmodell sollte sich am Anwendungsfall des Kundenportals orientieren.

proALPHA

proALPHA bietet für die Integration unter anderem seine Integration Workbench sowie REST-Schnittstellen.

Typisches Vorgehen
 Die Integrationsmöglichkeiten des ERP nutzen und die für das Portal benötigten Geschäftsobjekte klar definieren.

Stolperstein:
Individuell angepasste ERP-Installationen können erheblich von einem Standardsystem abweichen. Deshalb sollte die konkrete Schnittstellenlage frühzeitig geprüft werden.

Microsoft Dynamics

Dynamics 365 beziehungsweise die zugrunde liegenden Microsoft-Plattformen unterstützen Web APIs und OData. Microsoft beschreibt beispielsweise für Finance & Operations OData-V4-Endpunkte für den Zugriff auf freigegebene Datenentitäten.

Typisches Vorgehen:
Standard-Entities nutzen und kundenspezifische Erweiterungen möglichst sauber davon trennen.

Stolperstein:
Die Existenz einer Datenentität bedeutet noch nicht automatisch, dass diese optimal für einen hochfrequenten Portalzugriff geeignet ist.

Sage

Bei Sage hängt der konkrete Integrationsweg stark von Produkt und Version ab.

Typisches Vorgehen:
Zunächst prüfen, welche offiziellen Schnittstellen die eingesetzte Sage-Version bietet und erst anschließend die Portalarchitektur festlegen.

Stolperstein:
„Wir verwenden Sage“ reicht als technische Anforderung nicht. Produkt, Version, Hosting-Modell und vorhandene Erweiterungen müssen bekannt sein.

Salesforce und HubSpot

Bei CRM-Systemen wie Salesforce oder HubSpot erfolgt die Integration üblicherweise über REST APIs mit tokenbasierter Authentifizierung beziehungsweise OAuth. Salesforce verlangt für REST-Zugriffe eine entsprechende Autorisierung; HubSpot entwickelt seine OAuth-Schnittstellen ebenfalls kontinuierlich weiter.

Typischer Einsatz:
Ansprechpartner, Vertriebszuständigkeiten, Aktivitäten oder Serviceinformationen zwischen Portal und CRM synchronisieren.

Stolperstein:
CRM und ERP enthalten häufig ähnliche Kundendaten. Vor der Integration muss deshalb eindeutig definiert werden, welches System für welches Datenobjekt führend ist.

 

Sicherheit an der Schnittstelle

Ein Kundenportal stellt interne Geschäftsdaten extern zur Verfügung. Sicherheit muss deshalb Bestandteil der Architektur sein und darf nicht erst am Ende des Projekts ergänzt werden.

Wichtige Maßnahmen sind unter anderem:

• OAuth 2.0 oder vergleichbare sichere Authentifizierungsverfahren
• möglichst keine dauerhaft im Frontend hinterlegten API-Schlüssel
• rollenbasierte Zugriffsrechte
• Rate Limiting
• Protokollierung sicherheitsrelevanter Zugriffe
• verschlüsselte Übertragung
• Datenminimierung
• eindeutige Mandanten- und Kundenzuordnung
• DSGVO-konforme Verarbeitung personenbezogener Daten

Besonders wichtig: Das Portal darf nicht lediglich prüfen, ob ein Benutzer angemeldet ist, sondern muss für jeden Geschäftsvorgang prüfen, auf welche Daten dieser Benutzer tatsächlich zugreifen darf.

 

Die häufigsten Integrationsfehler

Aus unserer Sicht entstehen Integrationsprobleme selten deshalb, weil keine technische Schnittstelle vorhanden ist. Häufiger liegt das Problem in der Architektur.

Anti-Pattern 1: Das Portal greift überall direkt auf das Produktiv-ERP zu

Damit bestimmt das ERP die Geschwindigkeit und Verfügbarkeit des Kundenportals.

Besser:
Live-Zugriffe nur dort verwenden, wo sie wirklich erforderlich sind.

 

Anti-Pattern 2: Keine Retry- und Fehlerlogik

Eine Schnittstelle wird irgendwann nicht erreichbar sein.

Wenn dieser Fall nicht vorgesehen wurde, werden aus kleinen technischen Unterbrechungen sichtbare Kundenprobleme.

Besser:
Fehler protokollieren, Wiederholungsmechanismen vorsehen und klar definieren, wie das Portal bei fehlender Backend-Verfügbarkeit reagiert.

 

Anti-Pattern 3: Niemand dokumentiert das Datenmapping

Was bedeutet customer_id? Welches System führt die Adresse? Woher kommt der kundenspezifische Preis?

Ohne dokumentiertes Mapping wird jede spätere Änderung teuer.

 

Anti-Pattern 4: Datenhoheit ist ungeklärt

ERP, CRM und Portal enthalten beispielsweise unterschiedliche Ansprechpartner oder Adressen.

Besser:
Für jedes relevante Datenobjekt ein führendes System definieren.

 

Anti-Pattern 5: Big Bang statt schrittweiser Integration

Zuerst ERP, CRM, PIM, DMS und Ticketsystem vollständig integrieren und anschließend das Portal starten zu wollen, erhöht Projektrisiken erheblich.

Besser:
Mit wenigen wertschöpfenden Prozessen beginnen und die Integration iterativ erweitern.

 

Wie hoch ist der Aufwand einer ERP- oder CRM-Integration?

Die technische Integration ist häufig einer der größten Aufwandsblöcke eines Kundenportal-Projekts.

Als Planungsgröße rechnen wir bei Integrationsprojekten häufig damit, dass rund 30 bis 40 Prozent des Portalaufwands auf Schnittstellen, Datenmapping, Synchronisation, Tests und Fehlerbehandlung entfallen können.

Der konkrete Aufwand hängt jedoch stark davon ab:

• wie viele Systeme angebunden werden,
• welche Schnittstellen bereits existieren,
• wie stark ERP oder CRM individualisiert wurden,
• welche Daten in Echtzeit benötigt werden,
• wie viele Geschäftsprozesse zurückgeschrieben werden müssen,
• welche Datenqualität vorliegt.

Ein Portal, das lediglich Rechnungen anzeigt, ist integrationsseitig eine völlig andere Aufgabe als ein Portal, über das Kunden Preise prüfen, verfügbare Mengen abrufen, Bestellungen auslösen und anschließend den Lieferstatus verfolgen.

Eine ausführliche Einordnung finden Sie unter Kosten eines Kundenportals und Integrationskosten⁠

Auch die Entscheidung zwischen Standardsoftware und Eigenentwicklung⁠ beeinflusst Architektur und Integrationsaufwand.

 

Praxis: Ersatzteilportal mit ERP-Live-Daten

Gerade im Ersatzteilgeschäft zeigt sich, warum eine saubere Integration entscheidend ist.

Ein Kunde kennt beispielsweise die Artikelnummer eines Ersatzteils, sucht dieses im Portal und möchte unmittelbar wissen:

• Ist das Ersatzteil verfügbar?
• Was kostet es für mich?
• Wann kann es geliefert werden?
• Gibt es einen Nachfolgeartikel?
• Welche bisherigen Bestellungen gab es?
• Kann ich direkt nachbestellen?

Produktsuche und Content können dabei hochperformant aus spezialisierten Systemen kommen, während Preis, Bestand oder Auftragsstatus gezielt aus dem ERP abgefragt werden.

So entsteht kein zweites ERP im Web, sondern eine für den Kunden optimierte Sicht auf die relevanten Geschäftsprozesse.

Mehr dazu zeigen wir am Beispiel eines Ersatzteilportals mit ERP-Live-Daten⁠.

 

Kundenportal-Integration richtig planen

Eine erfolgreiche Integration beginnt deshalb nicht mit der Auswahl einer API.

Sie beginnt mit vier Fragen:

1. Welche Informationen und Prozesse benötigt der Kunde tatsächlich?
2. Welches System ist für diese Informationen führend?
3. Wie aktuell müssen die Daten wirklich sein?
4. Was passiert, wenn ein beteiligtes System nicht erreichbar ist?

Sind diese Fragen beantwortet, lässt sich meist relativ klar entscheiden, welche Daten direkt abgefragt, über Middleware orchestriert oder für das Portal repliziert werden sollten.

Das Ergebnis ist ein Kundenportal, das nicht nur technisch funktioniert, sondern schnell, wartbar und langfristig erweiterbar bleibt.

FAQ: Kundenportal mit ERP und CRM verbinden

Kann ein Kundenportal direkt an das ERP angebunden werden?

Ja. Über REST-, OData-, SOAP- oder andere APIs kann ein Kundenportal Daten direkt aus einem ERP abrufen. Bei komplexeren Portalen empfiehlt sich jedoch häufig eine zusätzliche Integrationsschicht, damit Portal und ERP nicht zu eng miteinander gekoppelt werden.

Müssen alle Daten im Kundenportal in Echtzeit bereitgestellt werden?

Nein. Echtzeit ist vor allem für zeitkritische Daten wie Verfügbarkeit, kundenspezifische Preise oder Auftragsstatus wichtig. Produktdaten, Dokumentationen oder historische Informationen können häufig synchronisiert oder zwischengespeichert werden.

Sollte ERP oder CRM das führende System für Kundendaten sein?

Das lässt sich nicht generell beantworten. Entscheidend ist, für jedes Datenobjekt eindeutig festzulegen, welches System führend ist. Beispielsweise kann das ERP für Rechnungsadressen und Konditionen zuständig sein, während Ansprechpartner und Vertriebsaktivitäten im CRM gepflegt werden.

Wann lohnt sich eine Middleware?

Eine Middleware wird besonders sinnvoll, wenn mehrere Backend-Systeme angebunden werden, Daten transformiert werden müssen oder Portal und ERP unabhängig voneinander weiterentwickelt werden sollen.

Kann SAP an ein Kundenportal angebunden werden?

Ja. SAP S/4HANA stellt verschiedene Schnittstellentechnologien zur Verfügung, darunter OData- und SOAP-APIs. Welche davon geeignet ist, hängt vom jeweiligen Geschäftsprozess und der vorhandenen SAP-Landschaft ab.

Wie hoch sind die Integrationskosten bei einem Kundenportal?

Sie hängen insbesondere von Anzahl und Qualität der vorhandenen Schnittstellen, Echtzeitanforderungen und der Individualisierung der Backend-Systeme ab. Als Planungswert können Schnittstellen, Datenmapping und Integration bei anspruchsvollen Projekten einen erheblichen Teil des Gesamtaufwands ausmachen.

Was passiert, wenn das ERP zeitweise nicht erreichbar ist?

Das sollte bereits bei der Architektur berücksichtigt werden. Caching, Datenreplikation, Retry-Mechanismen und definierte Fallbacks können verhindern, dass eine kurzfristige ERP-Störung automatisch das gesamte Kundenportal unbenutzbar macht.