CRM neben SAP: Wann es sinnvoll ist und wie es ohne Schnittstellen-Projekt läuft

Was SAP im Vertrieb nicht abbildet

SAP S/4HANA oder SAP Business One sind dafür gebaut, dass ein Auftrag sauber durch das Haus läuft: Kunde, Material, Preis, Lieferung, Rechnung. Das können sie sehr gut, und genau deshalb sind sie in vielen Maschinen- und Anlagenbauern das führende System. Was davor und danach passiert, ist dort nur ein Feld oder gar nichts.

Typische Lücken, die im Vertrieb jeden Tag auffallen:

• Offene Angebote nachfassen. Das Angebot ist im ERP, die Frage „hat sich der Kunde gemeldet?" nicht. Also führt jemand eine Excel-Liste.
• Serviceanfragen. Die Störmeldung kommt per Mail oder Anruf, landet im Postfach eines Kollegen und ist dort für alle anderen unsichtbar.
• Wartungsverträge und Fristen. Welche Anlage ist wann fällig, wer fährt hin, was wurde beim letzten Mal gemacht? Im ERP steht das höchstens als Notiz.
• Die Kundenhistorie. Anrufe, Besuche, Zusagen, Reklamationen: das Gedächtnis des Betriebs liegt in Köpfen und Postfächern, nicht im System.
• Der Außendienst. Wer beim Kunden steht, hat SAP nicht auf dem Handy und will es auch nicht.

Keiner dieser Punkte ist ein Fehler von SAP. Es sind Aufgaben, für die ein ERP nicht gebaut ist. Die Frage ist nur, wo sie stattdessen hingehören.

Die Regel: ein führendes System je Datenart

Der Ärger mit Schnittstellen entsteht fast immer an einer Stelle: Zwei Systeme halten sich für zuständig für dieselben Daten. Der Kunde ändert seine Adresse, der Vertrieb trägt sie im CRM ein, die Buchhaltung in SAP, und ab jetzt streiten sich zwei Wahrheiten. Eine bessere Schnittstelle hilft da nicht. Was hilft, ist eine klare Zuständigkeit:

Sobald diese Tabelle steht, ist die Schnittstelle plötzlich klein: Sie muss nur noch in eine Richtung lesen. Und die IT muss kein Schreibrecht auf SAP vergeben. Für viele SAP-Basis-Teams gibt genau das den Ausschlag.

Was bewusst nicht synchronisiert wird

Eine gute lesende Anbindung erkennt man daran, dass sie das Richtige weglässt. Drei Dinge fließen bei Portario absichtlich nicht:

• Nichts zurück nach SAP. Kein Angebot wird zum Auftrag, keine Adresse wird überschrieben. Was im CRM entsteht, bleibt exportierbar (CSV, offene API), aber SAP bleibt unberührt. So kann dort nichts kaputtgehen.
• Keine Buchungen im CRM. Lieferscheine und Rechnungsbelege werden nicht gespiegelt. Offene Aufträge und offene Posten liest Portario auf Wunsch als Momentaufnahme je Kunde, damit der Außendienst sie vor dem Besuch sieht; ändern lässt sich daran nichts. Eigene Rechnungen und Mahnungen kann Portario trotzdem schreiben; wer in SAP fakturiert, lässt das einfach dort.
• Keine schweren Protokolle. BAPI, RFC und IDoc sind mächtig und erfordern Basis-Wissen auf beiden Seiten. OData über das Gateway ist der Weg, den eine SAP-Basis ohne Projekt freigeben kann.

Das klingt nach Verzicht, ist aber der Grund, warum die Einführung Tage dauert statt Monate: Es gibt keine Konfliktregeln, keine Fehlerwarteschlange und niemanden, der den Connector betreut.

Ohne Gateway: der Einstieg per Excel

Nicht jeder Betrieb hat ein Gateway, das er nach außen öffnen will. Und bei SAP Business One oder älteren Ständen sieht die Schnittstellenlage anders aus. Dann beginnt die Anbindung als Excel- oder CSV-Export aus SAP: Debitoren mit Kundennummer und Adresse exportieren, in Portario importieren, fertig. Importieren Sie die Kundennummer mit. Ein späterer Wechsel auf den OData-Abgleich ordnet die Firmen dann genau darüber zu, und an den Daten ändert sich nichts.

Auch der Umzug aus einem bisherigen CRM läuft so, mit Zuordnung der Spalten und Vorschau vor dem Import. Ein erneuter Import ergänzt neue Kunden, bereits vorhandene Firmen überspringt er. Geänderte Stammdaten bestehender Firmen übernimmt nur der OData-Abgleich.