CosmoCode
  • Great software.

  • Bright people.

  • Happy customers!

CosmoCode GmbH
  • Start
  • Geschäftsfelder
  • Über uns
  • Referenzen
  • Blog
  • Open Source
←
Alle Blogposts
→

CRM Einführung mit vTiger, Teil 2: Datenflüsse, Modellierung, Softwareanpassung und Fazit

CRM Einführung mit vTiger, Teil 2: Datenflüsse, Modellierung, Softwareanpassung und Fazit

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. * Teil 1: CRM, Ziele, Werkzeuge und Vorgehensweise * Teil 2: Datenflüsse, Modellierung, Softwareanpassung und Fazit

Detlef Hüttemann, 25.05.2011 14:37

Zugehörige Dienstleistungen:
  • Python/ Django, 
  • vTiger CRM

CRM Einführung mit vTiger, Teil 2: Datenflüsse, Modellierung, Softwareanpassung und Fazit

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.

  • Teil 1: CRM, Ziele, Werkzeuge und Vorgehensweise
  • Teil 2: Datenflüsse, Modellierung, Softwareanpassung und Fazit

Datenflüsse

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.

Modellierung

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.

Softwareanpassungen

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)

  1. Im Zentrum der Aktivitäten steht der Kunde als Person und in der Funktion seiner Organisation.
  2. Lieferanten,
  3. Verträge, Risiken
  4. und Schäden sind die wichtigsten Stammdaten einer Versicherung und sind über den Vertrag mit dem Kunden verknüpft
  5. Leads und
  6. Potentiale sind die Arbeitsdomäne des Außendienst/Vertriebs. Leads werden zu Personen/Firmen bei Vertragsschluss konvertiert
  7. Aufgaben/Termine und
  8. Notizen(Dokumente) sind in fast allen Zusammenhängen hinterlegbar
  • gelbe Pfeile: die wichtigsten Beziehungen zwischen den Stammdaten
  • blaue Pfeile: mögliche Zuordnung von Aufgaben und Notizen

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…

Fazit

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.

1) Ich verwende hier den Begriff Entity - im vTiger heissen sie Module
2) Man muss sich entscheiden, ob man die Person oder die Organsiation wählt. Nimmt man die Personen, so sieht man die Daten übrigens nicht automatisch in der betreffenden Organsiation - das ist bisweilen ärgerlich

Mehr zum Thema

  • CRM Einführung mit vTiger, Teil 1: CRM, Ziele, Werkzeuge und Vorgehensweise
  • Synchronisation von vTiger und OpenEMM
  • Checkliste CRM Einführung mit vTiger
  • vTiger Synchronisation mit TYPO3
  • Digitalisierung von Geschäftsabläufen in Vertrieb und Service - die Grenze von CRM und BPM.
  • Professionelles Lead-Management mit iPad für Messen und Kongresse

eBusiness Experten gesucht?

CosmoCode entwickelt seit 2000 Softwarelösungen für das Internet und unterstützt Unternehmen bei der Digitalisierung.

Im kostenlosen Erstgespräch können wir Strategien diskutieren und einen groben Kostenrahmen abschätzen.

Interesse?

 

 Dann freuen wir uns über Ihre Kontaktaufnahme über das Kontaktformular am Ende der Seite.

  • Interesse?

Kontakt

Wir freuen uns sehr über Ihr Interesse!
Sie erreichen uns hier:

CosmoCode GmbH

Prenzlauer Allee 36G
10405 Berlin

Telefon: +49 30 814 50 40 70

Telefax: +49 30 2809 7093


mail: info@cosmocode.de

CosmoCode GmbH  
   

© CosmoCode 2021 | Impressum | Datenschutz | Cookies verwalten

Schließen
Deutsch Englisch
  • Jobs