STRATEGIE6. Sep. 2016

SugarCRM & API: Zentrale Aspekte bei der CRM-Integration speziell bei Banken

Rich Green, Chief Product Officer, SugarCRMSugarCRM
Rich Green, Chief Product Officer, SugarCRMSugarCRM

Der größte Aktivposten, über den Banken bei der Gewinnung und Bindung von Kunden verfügen, ist ihre Reputation für Vertrauens­würdigkeit und Stabilität. Das Vertrauen in neue Finanz­dienst­leistungen bildet sich langsamer aus, als sich die Technologie entwickelt. Laut der Studie „PwC Retail Banking 2020“ ist die Entwicklung eines kundenzentrierten Geschäftsmodells entscheidend. Banken müssen ein umfassenderes, ganzheitliches Verständnis ihrer Kunden entwickeln und dazu verschiedene interne und externe Datenquellen akquirieren, integrieren und analysieren.

von Rich Green, Chief Product Officer, SugarCRM

Banken müssen in der Lage sein, die Bedürfnisse ihrer Kunden zu verstehen und im Bedarfsfall mit einer relevanten Lösung präsent sein.

Banken müssen heute ihr gesamtes Geschäftsmodell unter Berücksichtigung der Kundenperspektive neugestalten.“

Hier kommt das Customer Relationship Management (CRM) ins Spiel. Wird der Kunde und seine Perspektive in den Mittelpunkt des Business gestellt, rücken automatisch Kundeninformationen und deren effiziente Verarbeitung und Bereitstellung ins Zentrum.

Ein großer Flickenteppich aus Daten

Viele Unternehmen setzen ihre CRM-Software nur für einen Zweck ein. Bei diesen einzeln verwendeten Funktionen kann es sich um Opportunity-Management, Pipeline-Auswertung, Lead-Weiterleitung oder die Nachverfolgung von Kundenserviceanfragen handeln. In der Regel wird bei der Nutzung dieser einen Funktion eine beschränkte Informationsmenge im CRM-System gespeichert und bei Gebrauch aktualisiert. Kundeninformationen sind zudem meist über eine Vielzahl von Betriebssystemen (ERP, Buchhaltung/Rechnungswesen, Bürosysteme, Analytik), aber auch über externe Quellen (Daten von Dritten, News-Feeds, soziale Medien) verteilt. Des Weiteren treten Kunden auch mit der Rechts- oder Finanzabteilung, der Verwaltung, Forschung & Entwicklung und anderen Gruppen in Kontakt. Diese Abteilungen nutzen normalerweise ihre eigenen Tools, um relevante Informationen festzuhalten und Aktivitäten zu managen. Hinzu kommt, dass Verbraucher in Kundenportalen, Communities und externen Quellen wie den Seiten sozialer Netzwerke zusätzliche Informationen verbreiten. All dies führt zu einer hochgradigen Streuung von Kundendaten über eine Vielzahl von Anwendungen hinweg.

Die zunehmende Zahl von verfügbaren Cloud-Diensten treibt diese Streuung noch weiter voran. Täglich tauchen neue Nischendienste auf, die zweckdienlich und für eine spezielle Funktion oder Nutzung entworfen wurden.

Aufgrund der einfachen Handhabung und mobilen Verfügbarkeit dieser Lösungen sind viele Daten auch in diesen FinTech-Angeboten gespeichert.“

Daten, auf die eine Bank nur dann zugreifen kann, wenn sie diese in ihre eigenen Bestandssysteme integrieren kann. Ein wirklich informatives und aussagekräftiges CRM muss all diese disparaten Datensilos miteinander verbinden. Die umfassende Integration aller vorhanden Datenquellen und Applikationen ist entscheidend.

Den Knoten knüpfen

Eine effektive CRM-Plattform ist wie ein Netzknotenpunkt konstruiert. Um Informationen zu speichern und aufzurufen, ist eine geeignete Datenstruktur erforderlich, und es muss möglich sein, viele andere Applikationen in der Arbeitsumgebung miteinander zu integrieren, da wertvolle Kundeninformationen oft auch an ganz anderer Stelle gespeichert sind.

Es gibt verschiedene Konstruktionsmodelle zur Web-Service-Integration. Die beiden bekanntesten sind SOAP und REST.“

SOAP – Simple Object Access Protocol: ist dabei von diesen beiden wahrscheinlich das bekanntere Modell. SOAP ermöglicht es Programmen, die nicht auf gleichartigen Betriebssystemen laufen (wie Windows und Linux), miteinander zu kommunizieren, indem sie das Hypertext Transfer Protocol (HTTP) und seine Extensible Markup Language (XML) verwenden.

REST – Representational State Transfer: entwickelt sich schnell Richtung bevorzugtes Konstruktionsmodell für öffentliche Programmschnittstellen (APIs). REST verfügt über einen Architekturaufbau, SOAP dagegen ist ein standardisiertes Protokoll. REST nutzt vorhandene und weithin akzeptierte Technologien, insbesondere HTTP, und kreiert keine neuen Standards. Es kann Daten in XML, YAML oder jedes andere maschinenlesbare Format strukturieren, im Normalfall gibt man jedoch JSON – JavaScript Object Notation – den Vorzug. REST ist weitestgehend datengesteuert, SOAP ist im Gegensatz dazu stark funktionsgesteuert.

Nicht-proprietäre API

Viele CRM-Plattformen stellen dahingegen eine nicht-proprietäre API zur Verfügung, was nicht notwendigerweise bedeutet, dass das CRM integrationsfreundlich ist. Oft wurde die API rein als externe Verlängerung zum Produkt gebaut und nicht direkt vom Produkt selbst wirksam eingesetzt. Diese API-Implementationen weisen normalerweise eingeschränkte Applikationsabdeckung auf und erfordern gegebenenfalls eine Art Dosierung zur Minimierung der Skalierbarkeitsherausforderungen. Wichtig ist auch zu wissen, wie oft sich eine API ändert und ob der Dienstleister selbst über eine API-Strategie verfügt.

Wie widerstandsfähig eine API auch sein mag – es gibt immer wieder Situationen, in denen Integrationsentwickler in der Lage sein müssen, die Datenstruktur oder Applikationslogik hinter einer API besser zu verstehen. Dies wird bei vielen SaaS-Lösungen zur großen Herausforderung, da eine ihrer grundlegenden Eigenschaften ihre undurchsichtige Infrastruktur ist.

Abschließend ist es wichtig, dass die IT-Verantwortlichen völlige Flexibilität bei der Auswahl der Bereitstellungsoption haben. Dies ist dort von besonderer Bedeutung, wo eine On-Premise- oder private Cloud-Lösung gefragt ist und die IT für die laufende Instandhaltung und Upgrades verantwortlich ist. Auch bei SaaS-Lösungen ist dies entscheidend, da die IT-Abteilung sonst Bedenken zur Anwendungszuverlässigkeit und den Zugangsanforderungen äußern würde, da sich deren Einsatzstrategie mit der Zeit ändern könnte.

Autor Rich Green
Rich-Green-white-background-516Rich Green (Chief Product Officer bei SugarCRM) leitet das globale Entwicklungs- und Produktmanagement bei SugarCRM und ist sowohl für die Produktweiterentwicklung als auch für die globale Produktstrategie verantwortlich. Seit über 25 Jahren ist Green in der IT-Branche tätig und verhalf in der Zeit sowohl Fortune-500-Unternehmen als auch innovativen Startups zum Erfolg. Er bekleidete hochrangige Führungspositionen unter anderem bei Sun Microsystems, Solaris, Java und Nokia.

Offen, unkompliziert und vielfältig

Die CRM-Plattform der Wahl sollte möglichst offen gestaltet sein und beispielsweise eine Standard-Multi-Tier-Web-Architektur verwenden, die sich auf weit verbreitete Open-Source-Software und -Standards stützt, um schnell robuste Integrationen entwickeln zu können. Dem entsprechend sollten die Anwendungen auch in Programmiersprachen geschrieben sein, die Entwickler kennen und gern benutzen, etwa in Standard-PHP, JavaScript oder CSS.

Um die Integration möglichst unkompliziert und nahtlos vollziehen zu können, sollte das CRM mehrere Betriebssysteme wie Linux und Windows unterstützen und effizient mit Open-Source-Technologien wie Apache Webserver und Elasticsearch zusammenarbeiten. Außerdem sollte darauf geachtet werden, dass verschiedene Datenbanksysteme unterstützt werden, wie beispielsweise MySQL, Oracle und DB2. So eine Architektur sorgt für komplette Transparenz auf allen Anwendungsebenen. Entwickler bekommen vollständige Einsicht in die Datenbankstruktur und jede Anwendungsdatei im Dateisystem.

Sie finden diesen Artikel im Internet auf der Website:
http://www.it-finanzmagazin.de/?p=36049
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (2 Stimmen, Durchschnitt: 5,00 von maximal 5)
Loading...

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

MK-IT_Bruysten_copyright-LxPRESS.JPG-258
Digitalisierung … erst wenn es weh tut: Die Altbau-IT bei Versicherern muss saniert werden!

Legacy-Systeme, Anwendungen in veralteten Programmiersprachen, gesetzliche Rahmen­be­ding­ungen und Kostendruck – die Ver­sicher­ungs-IT ist ein Schlachtfeld. Dazu der Anpassungsdruck auf die IT-Systeme. Wie die Assekuranz mit...

Schließen