Von einem deutschen Finanzdienstleister haben wir den Auftrag bekommen, ihn bei der Einführung eines CRM Systems zu unterstützen.
In dieser zweiteiligen Artikelserie gebe ich unsere Erfahrungen in diesem Projekt weiter.
Vor dem Entwicklungsstart wurde in einem Workshop eine Liste der groben Anforderungen zusammengestellt, bei dem alle beteiligten Systeme und die Datenflüsse und vielfältigen Synchronisationsprozesse einbezogen wurden.
Die Herausforderung bei unserem Kunden besteht darin, dass eine Vielzahl von Kundendaten (Verträge, Versicherungsleistungen, Prämien, Versicherungssummen, Schadensbeträge u.s.w. im CRM System abgebildet werden müssen. Aber: Die Pflege dieser Daten wird künftig nicht komplett im CRM System erledigt werden - nur die Kontakt-relevanten Daten (Kundennamen, -Adressen und natürlich die verkaufsrelevanten Potentiale) werden im CRM System verwaltet; die übrigen Daten werden weiterhin in anderen Systemen bearbeitet und ins CRM System synchronisiert.
Somit ergibt sich ein durchaus komplexes Datenflussmodell, denn auch die Daten, die künftig im CRM System gepflegt werden, müssen synchronisiert werden - sie müssen in die IT zurückgespielt werden.
Im Falle unseres Kunden müssen folgende IT-Lösungen berücksichtigt werden:
Kundendaten-Verwaltungssystem (IBM iSeries mit proprietärer Software)
Telefonie-Anwendung (Bereitstellung der Kundendaten für die CLIP-Funktion, Direktwahl aus dem Browser)
DMS System (Zugriff auf Vertragsdokumente)
Webauftritt/TYPO3 (Anbindung von Online-Workflows)
Bildunterschrift: Das CRM System muss zu einer Vielzahl von proprietären Bestandsystemen Schnittstellen bilden; Synchronisationsprozesse sind für jede Entität gezielt zu enwickeln.
Wie modelliert man eigentlich ein CRM System?
Sehr vereinfacht gesagt ist ein CRM System eine relationale Datenbank mit automatischen Prozessen, welche bei Datenänderungen ausgelöst werden (Worklflows). Es gibt eine Reihe von Entities (Datensätzen), die eine Vielzahl von Feldern haben. Zwischen Entities bestehen eine Vielzahl von Relationen: Personen gehören zu Organisationen, Verkaufspotetntiale haben Aufgaben, Aufgaben sind Personen oder Organisationene zugeordnet … Details finden sich in der Grafik weiter unten.
Ab Werk wird ein Standard-Umfang von Entities bereitgestellt, die über die Web-GUI modelliert werden können. Diese Modellierung ermöglicht das Hinzufügen von Datenfeldern mit unterschiedlichen Typen (konfigurierbare Auswahllisten, Textfelder, ..).
Rechtesystem
Ebenfalls erforderlich ist die Konfiguration des umfangreichen Rechtesystems, über das man einen einen eigenen Artikel schreiben kann und sollte. Hier ein kurzer Überblick über die zu Grunde liegenden Strukturen:
Profile regeln den allgemeinen Zugriff auf Module
Rollen sind hierarchisch; jede Rolle enhält 1-n Profile
User haben exakt eine Rolle
Gruppen werden für Ownership von Entities benötigt. Gruppenmitglieder ergeben sich aus zugeordneten Rollen (1-n), können auch einzeln hinzugefügt werden.
vTiger ER Modell
Die grundsätzlichen Ziele und Arbeitsweisen mit einem CRM System sind sicherlich an andrer Stelle besser aufgehoben als in diesem Artikel; deswegen beschränke ich mich hier auf die wesentlichen Entities und Zusammenhänge 1):
Personen und
Organisationen sind die wichtigsten Entities; fast alle anderen Entities werden einer Person oder Organisation zugeordnet.
2)
Leads sind die Vorstufe zu Personen; sie werden zu Personen durch eine Umwandlung (Conversion)
Verkaufspotentiale sind das Herzstück einer CRM Anwendung. Bei einem sauber gepflegten CRM System lassen sich an Hand der Verkaufspotentiale valide Umsatzprognosen bestimmen. Verkaufspotentiale können mit Verkaufsbestellungen detailliert strukturiert werden. Verkaufsbestellungen wiederum bestehen aus Produkten und Dienstleistungen
Serviceverträge werden direkt Personen oder Organisationen zugeordnet und können Trouble Tickets enthalten.
Assets sind physische Objekte, die Produkten zugeordnet sind.
Dokumente können unterschiedlichen Entities zugewiesen werden; diese beinhalten entweder selber das Dokument (als Attachment) oder einen Verweis auf ein externes Objekt.
Aufgaben dienen zur Arbeitsplanung im CRM. Fast alle Entities können mit Aufgaben versehen werden, die dann in der Kalenderansicht dargestellt werden.
Alle diese Entities haben also feste Beziehungen zueinander und bestimmte, vordefinierte Datenfelder, die sich nach Belieben erweitern lassen.
Die Beziehungen im vTiger sind vielfältig und in ihrer Mächtigkeit schnell unübersichtlich. Es gibt Pflichbeziehungen zwischen Entities (eine Person muss auf eine Organsation verweisen), und optionale 1:n und n:m Beziehungen.
Zu Beginn des Projektes war uns klar, dass wir nicht nur die Bordmittel der Konfiguration verwenden werden, sondern potentiell in allen Winkeln der Software Anpassungen vornehmen müssen. Um dennoch später updatefähig zu bleiben, haben wir den gesamten Softwarestand unter Kontrolle des Code-Verwaltungssystems git gebracht: so werden alle unsere Änderungen dokumentiert und können bei vTiger-Updates berücksichtigt werden.
Modellierung der Business-Entitäten
Bei unserem Kunden ist es sehr wichtig, dass die CRM Benutzer die Daten zu Versicherungsverträgen, -risiken und -schäden sehen können. Wie können diese möglichst ökonomisch, also mit wenig Aufwand - in das System gebracht werden?
In diesem Projekt haben wir eine recht unkonventionelle Lösung hierfür gewählt - wir haben vTiger Entities „recycelt“.
Für unseren Kunden war es wichtig, das Sachbearbeiter direkten Zugang zu den Kenndaten der Kunden haben. Diese sind
Versicherungsverträge
Schäden
versicherte Risiken
Für unseren Kunden nicht zweckmäßige, im vTiger aber vorhandene Entities sind
Produkt
Trouble Ticket
Asset(Güter)
Mit einer relativ problemlosen Umbenennung haben wir folgende Änderungen durchgeführt:
Produkt ⇒ Vertrag
Trouble Ticket ⇒ Schaden
Asset ⇒ Risiko
( Die Gesichter-Icons stammen von delekte, lizensiert unter Creative Commons)
Im Zentrum der Aktivitäten steht der Kunde als Person und in der Funktion seiner Organisation.
Lieferanten,
Verträge, Risiken
und Schäden sind die wichtigsten Stammdaten einer Versicherung und sind über den Vertrag mit dem Kunden verknüpft
Leads und
Potentiale sind die Arbeitsdomäne des Außendienst/Vertriebs. Leads werden zu Personen/Firmen bei Vertragsschluss konvertiert
Aufgaben/Termine und
Notizen(Dokumente) sind in fast allen Zusammenhängen hinterlegbar
vTiger zeigt sich ziemlich flexibel bei der Anpassung der Entities (speziell die Erweiterung um eigene Attribute ist kinderleicht). Datenfelder werden übrigens als „echte“ Felder in der Datenbank hinterlegt, das Datenbankschema ändert sich also. Durch diese Technik sind auch große Datenmengen in akzeptabler Zeit benutzbar.
GUI Anpassung
Ein CRM System sieht irritierend komplex aus - wenn man es zum ersten Mal sieht. Im Gegensatz zu optimierten Web20 Oberflächen bekommt man in einem CRM immer eine ganze Menge Informationen um die Ohren gehauen - die Anwender müssen lernen, die Daten zu filtern. Umsowichtiger ist es, den Nutzern hierbei zu helfen und unnötige Informationen oder Bedienfelder zu entfernen.
Die Anpassung kann zum Teil durch die Administration erledigt werden (Ausblenden unnötiger Module), bei manchen Dingen mussten wir aber auch direkt im Code manipulieren.
API Anpassung
In unserem Projekt haben wir umfangreiche Synchronisationsabläufe zu implementieren, die über die vTiger API gehen.
Die vTiger API an sich ist leistungsfähig und gut dokumentiert:
Anfragen und Rückgaben immer im JSON-Format
zweistufiger Login (GET Token + POST Login)
Zugriff und Änderung (Create, Read, Update, Delete) für alle Typen von vtiger Objekten (Users, Accounts, Potentials, Campaings, Events, etc.)
mit der Query-Operation können Abfragen von speziellen Daten via
SQL-Syntax ausgeführt werden; Beschränkung auf einen Objekt-Typen (also keine Joins möglich)
Sync-Operation um alle Änderungen ab einem angebenden Zeitpunkt (optional für ein bestimmten Objekt-Typen) zu erhalten
Leider fehlten uns aber wichtige Funktionen, die wir nachrüsten mussten (ID setzen, Timestamps setzen, Verlinkungen erlauben …).
Die API arbeitet sequentiell Objekt für Objekt. Dies ist problematisch bei Massenupdates, wie sie bei täglichen Synchronisationsprozessen auftreten, da sich durch die sequentielle Bearbeitung eine lange Prozesslaufzeit ergibt. Im Falle unseres Kunden handelt es sich um mehrere 100.000 Kunden…
Die Entwicklung einer CRM Lösung ist eine Herausforderung, die sich nicht am Plantisch entwickeln lässt. Der Bedarf des Unternehmens ändert sich mit den Erfahrungen: ein evolutionärer Entwicklungsprozess sichert die permanente Ausrichtung an den Zielen.
In Unternehmen finden sich über Jahre und Jahrzehnte gewachsene IT-Strukturen, die berücksichtigt werden müssen; die Integrationsarbeit betrifft DV-Einrichtungen, Telefonie, Desktoparbeitsplätze und die Netzwerkinfrastruktur. Die geforderte Flexibiliät an die Lösung ist so hoch, dass diese nicht ab Werk von einer CRM-Lösung bereitgestellt werden kann. Anpassungen und Code-Modifikationen finden auf allen Ebenen der Software statt - im Datenmodell, in den Prozessen, in der Bedienoberfläche.
Die Code-Modifikation ist in einem OpenSource-Produkt wie vTiger technisch möglich und rechtlich zulässig, allerdings ist hierfür ist eine eingehende Beschäftigung mit der Software-Logik des Systems nötig.
Kommentare