CosmoCode
  • Great software.

  • Bright people.

  • Happy customers!

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

Digitalisierung von Geschäftsabläufen in Vertrieb und Service - die Grenze von CRM und BPM.

Geschäftsprozesse mit Kundenkontakt reagieren sehr sensibel auf Veränderungen. Wer diese Prozesse falsch automatisiert, stößt seine Kunden zurück. Die Choreografie des digitalen Kundendialogs muss dies stets im Blick haben. Automatisierung und Dunkelverarbeitung wann immer es geht; digital gestützte Kommunikation zwischen Sachbearbeiter und Kunde dann, wenn es erforderlich wird. Zur Digitalisierung der Geschäftsabläufe bei einem unserer Kunden haben wir uns klassische CRM Systeme sowie BPML Werkzeuge angeschaut, und sind nach langem Abwägen zu einer Individuallösung gekommen: Dem Service-Workflow-Manager (SWM).

Detlef Hüttemann, 05.07.2018 16:49

Zugehörige Dienstleistungen:
  • Python/ Django

Die Aufgabenstellung

Wenn es um die Digitalisierung des Kundenkontaktes geht, ist es naheliegend, sich auf dem CRM Markt umzuschauen, schließlich sollen CRM Systeme ja die Beziehung zum Kunden managen. Für die Bereiche Marketing und Vertrieb bringen diese Werkzeuge auch vernünftige Instrumente mit; die Salespipeline kann von der Akquise bis zum erfolgreichem Abschluss gesteuert werden. Funktionieren tut dies dann besonders gut, wenn die Kommunikation mit dem Kunden hauptsächlich via Telefon / Mail / Newsletter geschieht. Das CRM dient dann eigentlich nur zur Dokumentation der Kommunikation.

Für Bedürfnisse allgemeiner Geschäftsprozess-Digitalisierung aber zu wenig, es fehlt an einer sinnvollen Unterstützung für ein Prozessmanagement (BPN - Business Process Management). Softwarelösungen in diesem Bereich sind in der Regel individuell und basieren auf Basistechnologien wie beispielsweise BPML oder Workflow Engines wie Camundo. Camundo Workflows werden in BPML modelliert; aus dem Modell können dann die Ablaufumgebungen generiert werden.

Wir haben und das näher angeschaut und sind überzeugt davon, dass dieses Werkzeug gut geeignet ist, um eine hohe Zahl von parallelen Dunkelverarbeitungen zu managen. Aber leider liegt unser Fall anders: Die von uns betrachteten Geschäftsprozesse erfordern in der Regel zwingend die Intervention eines Sachbearbeiters an mehreren Stellen im Prozessablauf - es sind nicht automatisierbare Entscheidungen zu treffen, die den weiteren Prozessablauf betreffen und Dialoge mit dem Kunden integrieren müssen. Ziel ist es dabei, die die manuellen Arbeitsschritte für die Sachbearbeiter so schlank wie möglich zu halten:

  • Für Entscheidungsprozesse sind alle Informationen zusammenzufassen und die wichtigsten hervorzuheben.
  • Dialoge mit dem Kunden sollten automatisiert werden; Rückantworten des Kunden sollten nach Möglichkeit formularbasiert erfolgen und direkt in den Prozessablauf gespielt werden.

Solche individuellen Arbeitsschritte müssen in jedem Fall individuell entwickelt werden, egal ob CRM oder BPM:

  • Ein CRM System bietet hierbei wenig Unterstützung, im Gegenteil - das fehlende Prozessmodell erschwert die Integration.
  • Ein BPML Tool dagegen bietet zwar eine Workflow-Engine, erfordert aber die Modellierung via BPML. BPML-notierte Abläufe sind aber schwer zu verstehen und zu erstellen (Auch wenn das BPML Vokabular übersichtlich ist; die daraus entstehenden Modelle sind es nicht). Als Konzeptinstrument kann sich BPML aber nur eignen, wenn es von allen Beteiligten verstanden wird. Meiner Einschätzung nach ist das eher ein Thema für Konzerne denn für Mittelständler wie unseren Kunden.

Für unseren Kunden aus der Versicherungsbranche sollen zusätzlich zu Marketing und Vertrieb weitere Bereiche automatisiert werden, wie beispielsweise - Schadenmeldungen - Veranstaltungen - Beitragsregulierungen

Als Touchpoint für den Kunden dient stets die Website (Typo3); über dort integrierte Formularprozesse kann der Kunde Geschäftsprozesse starten oder in ihnen interagieren.

Die Architektur

Die technische Plattform des SWM besteht aus dem Django-Framework. Kernstück ist hier das generische Prozess-Modell. Für jeden zu integrierenden Geschäftsablauf wird ein spezifische Prozess aus dem generischen abgeleitet.

Die Kernfunktionen des generischen Prozesses sind:

  • Statusverwaltung: zwischen den Basis-Status NEW, INWORK und DONE sind beliebige Zwischenstufen möglich. Die Auswirkungen des Prozess-Status sind vom Geschäftsprozess abhängig
  • Dokumentverwaltung: Dokumente entstehen auf vielfältige Weise: vom Nutzer eingegebene Daten werden als PDF Report erstellt; für Seminarteilnahmen werden Rechnungen und Teilnahmezertifikate generiert. Nutzer können bei Schadenmeldungen Attachments hochladen. Alle Dokumente werden mit dem DMS der Kern-IT synchronisiert, hierzu müssen entsprechende DMS Klassifikationen bestimmt oder im Einzelfall auch vom Sachbearbeiter individuell zugeschlüsselt werden
  • Actionlog: Alle Aktionen im System werden protokolliert und sind im Prozess selbst wie auch in einem zentralen Actionlog einsehbar
  • gesicherte REST-API: Das SWM System sitzt hinter einer Firewall und kommuniziert nur über eine Rest-API mit dem Typo3-CMS
  • Tokens: Zugriffe auf das SWM werden zusätzlich mit Tokens abgesichert. Tokens können revoked werden; das ist ungemein nützlich: So kann man z.B. beim Terminieren eines Geschäftsprozesses alle an den Kunden verteilten Upload Links sperren.
  • Transfer-Tasks: Das SWM kommuniziert zudem mit IT Systemen des Unternehmens. Hierzu sind Duplex-Schnittstellen vorbereitet, die kontinuierlich überwacht und in der Detailansicht eines Prozesses beauskunftet werden können.
  • einen auf headless-Chrome basierenden PDF Generator, der aus allen Detailansichten saubere PDFs erzeugt.

komplexe Formulardaten im User-Frontend

Für die Schadenmeldung musste ein sehr komplexer Formularprozess mit mehreren Entscheidungspfaden aufgebaut werden; in der Summe enthält der Prozess über 600 Felder. Die Implementation des Prozesses war quasi ein eigenes Micro-Projekt, dass seinerseits über Besonderheiten verfügt:

  • Die Formulardaten werden als JSON im Prozess abgelegt (also keine ER Auflösung in einer relationale DB, sondern ein "schemafreier" Ansatz)
  • Das Formular selber wird aus einer JSON-Steuerdatei generiert. Diese "Formular-DNA" wird im SWM verwaltet und ist versioniert abgelegt.
  • Die Formularprozesse lassen sich unterbrechen und wiederaufnehmen
  • Dank der Versionierung können auch Daten älterer Versionen korrekt dargestellt werden, da einfach die zu den Daten passende Formular-DNS geladen wird
  • Dir Formular-DNA enthält zudem für jedes Feld die Kennungen, unter der es im Laufe des Prozesses in die Kern-IT des Unternehmens synchronisiert wird.
  • Dank der Versionierung kann der Formularprozess weiterentwickelt werden werden; alte Prozesse mit bestehenden Formular-Altdaten werden einfach mit der passenden Formular-DNA gerendert.
  • Der Formulargenerator hat zudem einen Report-Generator, der die eigegebenen Daten als flache Struktur in lesbarer herausgibt

Mehr zum Thema

  • CRM Einführung mit vTiger, Teil 2: Datenflüsse, Modellierung, Softwareanpassung und Fazit
  • Redesign + Relaunch TheLabelfinder
  • Avoid these pitfalls when you use a thermal printer in your next web project
  • CRM Einführung mit vTiger, Teil 1: CRM, Ziele, Werkzeuge und Vorgehensweise
  • Professionelles Lead-Management mit iPad für Messen und Kongresse
  • CosmoCode realisiert Casting Portal für UFA

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