Dynamics CRM mit SAP – Teil 2: Grundüberlegungen
Eine enge und verlässliche Integration des Dynamics CRM mit dem vorhandenen SAP wirft eine Menge an technischen, inhaltlichen und nicht zuletzt auch kostenbezogenen Fragen auf. Diese Fragen wollen sorgfältig beantwortet sein, damit das Projekt gute Chancen auf Erfolg hat und Überraschungen im Projektverlauf weitestgehend ausgeschlossen werden können. Auch bei sorgfältigster Planung bleibt gerade bei Spezialentwicklungen wegen der vielen beweglichen Teile immer eine gewisse Unschärfe bestehen. Das beschriebene Lösungsszenario kann viele der Fragen im Vorfeld beantworten.
Dies gilt umso mehr, je größer die geplante Integrationstiefe ist. Wenn also im CRM neben Debitorenstammdaten auch dazugehörige Vertriebsbereiche, SAP-Ansprechpartner, Partnerrollen, Produktdaten, Vertriebsbelege, Finanzdaten usw. benötigt werden. Je tiefer die Integration sein soll, desto vorteilhafter ist es, wenn inhaltliche Zusammenhänge, Technik und Darstellungsform mit Erfahrungshintergrund bereits durchdacht sind.
Zumindest Stammdaten werden in allen CRM-Systemen in irgendeiner Weise lokal im System benötigt. Sie sind dort der Dreh- und Angelpunkt für alle weiteren kundenbezogenen Informationen und Aktivitäten. Hier stellt sich die (grundsätzlich berechtigte) Frage normalerweise nicht, ob SAP-Daten wirklich in das CRM repliziert und dort redundant vorgehalten werden müssen. Ohne geht es einfach nicht. Spätestens gilt das – und zwar für jede CRM-Lösung – bei geforderter Offline-Verfügbarkeit der Informationen.
Typischer Umfang einer Integrationslösung mit SAP
Besonderes Augenmerk verdienen bei der Betrachtung der Datenintegration die Bewegungsdaten. Häufig ist gefordert, dass der Vertriebsmitarbeiter Aufträge (mit Informationen zu Rechnungen, Lieferungen usw.) zu seinen Kunden im CRM im Zugriff hat. Die Datenmenge kann schnell ausufern und so das CRM aufblähen und unübersichtlich werden lassen. Bei der Übertragung in das CRM-System erfordert die schiere Anzahl an Vertriebsbelegen häufig besondere logische Vorkehrungen zur Sicherstellung der Bedienbarkeit. Ein Beispiel wäre die Einschränkung der aktiven Datenmenge im CRM. Eine zeitliche Rollierung bietet sich dafür an.
Etwas komplizierter wird es, wenn die Rollierung z.B. nur für bestimmte Kombinationen von Verkaufsorganisationen und Belegtypen greifen soll (z.B. Normalauftrag), aber für einige Belegtypen (langfristige Kontrakte, Lieferpläne, Wartungsverträge o.ä.) Ausnahmen gelten. Derartige Regeln sollten in der Integrationsschicht grundsätzlich konfigurierbar sein. Ein CRM ist auf die Effizienz Office-naher Vertriebsprozesse, das komfortable Arbeiten mit weichen Daten und für die Offline-Nutzung optimiert. Übersichtlichkeit und Agilität fördern die Akzeptanz. Bei Massendaten sollten daher Alternativen in Betracht gezogen werden. Dies können direkte Realtime-Anfragen an das SAP sein oder auch Aufrufe von Berichten z.B. für eine Umsatz- oder Auftragsübersicht. Bei Verfügbarkeits- oder Preisabfragen bietet sich der erstgenannte Weg in jedem Fall an. Neben der Einsparung der ansonsten anfallenden Datenbewegungen müssen auch die betreffenden Geschäftsregeln nicht doppelt abgebildet werden. In einer serviceorientierten Umgebung ist das in der Regel auch nicht nötig. Wichtig ist, dass es keinen Bruch im Arbeitsprozess gibt und die übergreifenden Funktionen gut in das CRM integriert sind. Das Microsoft CRM basiert vollständig auf einer serviceorientierten Architektur. In Verbindung mit den Integrationsdiensten des SQL-Servers und dessen Reporting Services hat das CRM alle Voraussetzungen für eine nahtlose Eingliederung in die SAP-Umgebung auf Daten- und Prozessebene sowie bei Analyse und Reporting.