Unternehmen, die Teile ihrer Geschäftsanwendungen in die Cloud auslagern, setzen oft auf CRM-Systeme wie Salesforce. Diese müssen eng mit den ERP-Systemen verknüpft sein, um die Geschäftsprozesse zu vereinfachen. [...]
Häufig beziehen Unternehmen CRM-Systeme für das Management ihrer Kundenbeziehungen als Software as a Service aus der Cloud. Vorreiter und Marktführer ist hier Salesforce.com. Unternehmen, die eine CRM-Lösung von Salesforce.com einsetzen, müssen diese mit ihrer bestehenden IT-Umgebung und Software-Landschaft verknüpfen. Besonderes Augenmerk gilt hier der Integration mit dem ERP-System, um durchgängige Geschäftsprozesse zu realisieren und das Potenzial des CRM-Systems voll auszuschöpfen. Denn Insellösungen sind mit vielen Nachteilen verbunden. Dazu gehören doppelte Datenhaltung oder Mehraufwand durch die Arbeit mit unterschiedlichen Anwendungen. Zentrale Fragen lauten: Wie gelangen Kundendaten aus Salesforce in das ERP-System und umgekehrt Stammdaten aus dem ERP-System in die Salesforce-Lösung? Wie lassen sich Salesforce und die ERP/SAP-Welt integrieren?
„Technisch ist die Integration zwischen Salesforce CRM und einem lokal installierten ERP-System wie SAP relativ einfach, da es mittlerweile bewährte Tools und Integrations-Plattformen gibt“, erläutert Robert Santner, Managing Partner bei der Nefos GmbH. „Die Herausforderung liegt vor allem in der Konzeptphase, da nur selten ausschließlich Daten zwischen den beiden Welten übertragen werden. Die Integration umfasst meist auch Businesslogik beziehungsweise Geschäftsprozesse. Das macht die Sache komplexer.“ Santner spricht aus Erfahrung, da die Nefos GmbH als Platinum Cloud Alliance Partner von Salesforce.com mittlerweile rund 250 Integrationsprojekte für Kunden umgesetzt hat.
MASTERSYSTEM
Als Grundregel empfiehlt er Unternehmen, das ERP-System als Mastersystem für Bestandskunden, deren Stammdaten sowie natürlich die Aufträge und deren Abwicklung zu verwenden, das CRM-System als Master für neue und potenzielle Kunden. Ein Beispiel: Ein Vertriebsmitarbeiter einer Maschinenbau-Firma spricht auf einer Messe mit Standbesuchern, sprich potenziellen Neukunden. Er trägt deren Daten in das CRM-System ein, ergänzt später den Besuchs-Bericht, weitere Akquise-Aktivitäten oder auch ein Angebotsschreiben. Nimmt der Kunde den Auftrag an und schließt einen Kaufvertrag ab, werden die Daten automatisch in das ERP-System übertragen, der Kunde wird dort als Datensatz angelegt. Damit werden im ERP-System die mit einem Auftrag verbundenen Prozesse (Bestätigung, Rechnung etc.) ausgelöst.
Die Übertragung erfolgt hier meist asynchron. Umgekehrt benötigt der Vertriebsmitarbeiter im CRM-System für die Angebotserstellung beispielsweise Informationen über Verfügbarkeit und Preisfindung. Diese liegen im ERP-System und umfassen Rahmenkonditionen, Mengen-Rabatte etc. Diese Daten sollten inklusive Business-Logik möglichst in Echtzeit (synchron) von der ERP-Lösung nach Salesforce übertragen werden.
Architektonisch kann die Integration zwischen Salesforce und dem ERP-System laut Robert Santner auf drei Ebenen erfolgen: Datenebene, Applikationsebene und Benutzeroberfläche. Auf Datenebene müssen die Unternehmen festlegen, welche Datenobjekte und Felder sie in Salesforce und ERP-System miteinander verbinden wollen. Das können der Account-Name, Adresse, Ansprechpartner, Produkte, Listenpreise oder Auftragsdaten sein. „Durch Integration auf Applikationsebene lässt sich die Business-Logik des Quellsystems über eine Online-Schnittstelle abrufen. Ein Beispiel dafür ist die Preisermittlung für ein Produkt aus dem ERP-System, um ein Angebot in Salesforce zu erstellen“, so Santner. Nach der Integration der Benutzeroberflächen ist es möglich, das User Interface des ERP-Systems direkt in Salesforce aufzurufen oder umgekehrt.
DATENSTRUKTUR
Unternehmen müssen aber darauf achten, dass die Daten korrekt übertragen und transformiert werden. So ist die Datenstruktur der Objekte in Salesforce teilweise anders definiert als im ERP-System. Wird beispielsweise in SAP eine Unterstruktur unter einem Kunden gebildet, kann Salesforce dafür ein eigenes Business-Objekt verlangen. Auch die Salesforce-ID im Schlüsselfeld des Objekts macht die Integration etwas komplexer. Salesforce erstellt im Standard automatisch eine ID für die Identifizierung des Kunden, während dies beispielsweise in ERP-Systemen meist manuell erfolgt. „Bei der Integration muss man daher sehr genau darauf achten, dass hier die Korrelation zwischen Salesforce und der ERP-Lösung stimmt und der Schlüssel korrekt übertragen wird. Nur so kann man den Kunden eindeutig zuordnen“, erläutert Santner.
Darüber hinaus gibt es Felder mit Validierung oder einer Business-Logik dahinter (Alert, Workflow) und Abhängigkeiten zwischen Business-Objekten. Ein typischer Stolperstein: Validierungen können in den Systemen unterschiedlich streng sein. Bei der Integration müssen Unternehmen konzeptionell darauf Rücksicht nehmen, dass Eingaben, die im Quellsystem korrekt sind, aus Sicht des Zielsystems inkorrekt sein können. Je größer die Anzahl der Objekte und Felder wird, umso komplexer wird dieser Teil der Integration. Zu klären ist auch die Frage, wie häufig der Datenaustausch erfolgt: Realtime, mehrmals täglich, einmal wöchentlich oder manuell bei Bedarf?
Für den Datenaustausch bietet Salesforce den Anwendern verschiedene Integrationsmöglichkeiten. Neben dem klassischen manuellen Upload (nur bei geringem Datenaufkommen realistisch) liefert Salesforce mehrere gut definierte Schnittstellen (APIs) für eine automatisierte Integration. „Für die meisten Anwendungsfälle stellt die Web-Service-basierte Integration über die SOAP-API den bevorzugten Lösungsansatz dar. Dies gilt vor allem für die Echtzeitintegration von Daten mit anderen betriebswirtschaftlichen Anwendungen“, weiß Andreas Schmidsberger, Senior Solution Architect beim Beratungsunternehmen Corporate Business Solutions, das sich auf SAP spezialisiert hat. In den letzten Jahren hat er in vielen Unternehmen das SAP-System mit Salesforce verknüpft. Für die Realisierung von mobilen Szenarien bietet die sogenannte REST-API eine schlanke Alternative.
Weitere Optionen wären eine generische Datenübernahme über die Metadaten-API sowie die Massendatenverarbeitung über die Bulk-API. „Der generische Ansatz wäre bei einer Datenmigration sinnvoll, ist aber für die Integration von Geschäftsprozessen wenig geeignet, da er keine definierte Schnittstellenstruktur enthält“, so Schmidberger. Auch die Bulk-API eignet sich nicht für pro-zessorientierte Echtzeitintegration, da die Prozessierung beim Laden von großen Datenmengen entkoppelt und asynchron im Hintergrund abläuft.
SCHNITTSTELLEN
Salesforce stellt bei der Implementierung der Schnittstellen spezifische Anforderungen, die Unternehmen berücksichtigen müssen. Die Salesforce-Authentifizierung basiert auf der Session-Verarbeitung, das heißt es ist ein eigener Login Request notwendig, um die Session-ID zu erhalten, bevor man die eigentlichen Business-Daten erhält. Um die Session-ID für mehrere Salesforce-Aufrufe verwenden zu können, müssen diese Login-Daten im Integration Layer persistiert werden. Salesforce verwendet zudem spezielle Sprachkonstrukte für seine Web-Service-Strukturdefinition (WSDL Web Service Definition Language). Hier sind teilweise – abhängig von der gewählten Integrationsplattform – manuelle Anpassungen notwendig.
Salesforce erlaubt über die SOAP-API die Übertragung von maximal 200 Einträgen (beispielsweise 200 Kunden) in einem Aufruf, um Performance-Probleme und lange Antwortzeiten zu vermeiden. Auch die Zahl der Zugriffe pro Tag ist je nach bezahltem Tarif limitiert. „Daher ist es manchmal sinnvoll, die Daten nicht für jede Transaktion einzeln zu verschicken, sondern in kleinere Pakete zu bündeln. Die Paketierung sollte bevorzugt im ERP-Quellsystem geschehen, lässt sich aber auch über eine Integrationsplattform steuern. Dazu ist aber Programmierarbeit notwendig“, erklärt Schmidsberger.
Für die technische Umsetzung ist es natürlich möglich, Salesforce und ein ERP-System direkt miteinander zu verbinden. Die beiden befragten Experten empfehlen aber derartige Point-to-Point-Verbindungen nur in einfachen Projekten, wenn die Datenmenge nicht zu groß ist, die Daten im genau definierten Format vorliegen und nur selten transferiert werden. „Ab einer gewissen Komplexität raten wir zum Einsatz einer Middleware als Integrationsplattform. Kriterien sind das zu übertragende Datenvolumen, die Häufigkeit der Anfragen und die benötigte Geschwindigkeit“, sagt Robert Santner von Nefos.
MIDDLEWARE
Andreas Schmidsberger bestätigt diese Meinung: „Middleware ermöglicht die Realtime-Übertragung, bildet Integrationslogik sowie die Prozesssteuerung ab und bietet auch BPM-Funktionalität für das Fehler-Management.“ Die Integrationsplattform identifiziert und klassifiziert Fehler bei der Datenübertragung und übergibt die Fehlerkorrektur an eine verantwortliche Person, meist aus der Fachabteilung. Der damit verbundene Geschäftsprozess lässt sich mit der Logik in der Middleware modellieren.
Im Salesforce-AppExchange-Marktplatz sind rund 40 Middleware-Produkte von Herstellern wie Pervasive, IBM oder Magic zu finden. All diese Integrationsplattformen besitzen Konnektoren zu diversen ERP-Systemen und erfüllen damit die spezifischen technischen Voraussetzungen, da sie Daten von beiden Systemen lesen, verarbeiten und in das jeweilig andere System schreiben können. In einer SAP-zentrischen Systemlandschaft ist meist SAP NetWeaver Process Integration (PI) oder dessen Nachfolger SAP NetWeaver Process Orchestration (PO) das Mittel der Wahl.
Bei der Anbieterauswahl sollten Unternehmen darauf achten, dass die Lösung geeignete vorkonfigurierte Bausteine und Templates enthält, die Workflows abbilden und die Kopplung der Systeme beschleunigen. Damit vermeiden sie, für jeden Aspekt einer erfolgreichen Integration von vorne beginnen zu müssen und erneut Lehrgeld bezahlen. So lässt sich auch ein Master-Objekt erstellen, das wiederverwendet und mit wenig Aufwand auf andere Business-Objekte übertragen werden kann. Die beiden befragten Experten empfehlen zudem, im Rahmen des Projektes einen (eventuell auch externen) Integrations-Architekten einzusetzen, der auf Basis der funktionalen Anforderungen das technische Design verantwortet und somit als Schnittstelle zwischen dem Fachbereich und der IT-Abteilung fungiert. (idg)
Be the first to comment