Das Verständnis, was Cloud bedeutet, hat sich in den letzten 20 Jahren deutlich weiterentwickelt. Heute geht es nicht mehr nur um Speicherkapazitäten in einer global verteilten Infrastruktur oder um die Bereitstellung von Softwarefunktionen über das Internet. Inzwischen ist die Cloud auch der Ort, an dem komplette Anwendungen in virtuellen Plattformen wie AWS, Salesforce oder Azure ausgeführt werden. Das betrifft auch die Kundenkommunikation (Customer Communication Management = CCM) als einen Schlüsselbereich der IT-Infrastruktur.
Oft entdecken Firmen bei der Migration in die Cloud die große Heterogenität an entsprechenden Tools. Es ist nicht ungewöhnlich, dass fast jede Fachanwendung eine eigene Datenbasis für die Kundenkommunikation führt (Silos), die dann bei jedem neuen Kommunikationskanal entsprechend angepasst werden müssen. Abgesehen vom hohen Aufwand: Diese Ad-hoc-Anpassungen garantieren nicht, dass die entsprechenden Anwendungen in der Lage sind, alle im Laufe eines Kommunikationsvorganges gesammelten Informationen an ein zentrales System für die Verwaltung der Kundenbeziehungen – zum Beispiel als CRM-System - zurückzugeben. Doch genau darin besteht der Nutzen einer stringenten, alle analogen und digitalen Kanäle umfassenden Kundenkommunikation: die zentrale Verfügbarkeit aller mit einem Geschäftsvorgang verbundenen kundenrelevanten Daten.
Dazu folgendes Beispiel eines europäischen Dienstleisters: Wie viele große Provider steht auch dieses Unternehmen vor der Herausforderung, die steigenden Kundenanforderungen an die Reaktionsfähigkeit mit den begrenzten Skalierungsmöglichkeiten der CCM-Funktionen seiner Business-Applikationen in Einklang zu bringen. Es muss sich mit der zunehmenden Zahl digitaler Kommunikationskanäle sowie mit einem sich immer weiter beschleunigenden Tempo auseinandersetzen.
Hinzu kommt: Infolge von Akquisitionen und Fusionen war das Unternehmen in den letzten Jahren stark gewachsen – und damit auch die Heterogenität in der IT-Landschaft; ein Wildwuchs unterschiedlicher Anwendungen. Der Dienstleister entschloss sich daher, zu Salesforce zu wechseln, einer der weltweit führenden CRM-Plattformen auf Cloud-Basis.
Langfristiges Ziel des Unternehmens ist es, CRM und CCM im Interesse einer optimalen Kundenkommunikation eng miteinander zu verknüpfen, die CCM-Fähigkeiten der verschiedenen Anwendungen miteinander zu harmonisieren und schrittweise in die Cloud zu verlagern. Wichtig dabei: Sämtliche Informationen aus den verschiedenen Kommunikationsvorgängen (digital wie analog) sollen in das neue CRM-System einfließen und dort zentral vorgehalten werden – und zwar aus allen Kanälen. Wäre diese Rückkopplung unvollständig (zum Beispiel Beschränkung auf die digitale Interaktion), würde das zu einer „zweiklassigen Kommunikation“ führen.
Wie Sie Dokumente in der Salesforce Cloud erstellen und drucken
Lesedauer: 7 Min
Der Dienstleister entwickelte daher eine Infrastruktur mit einer einheitlichen, aber personalisierten Basis an Funktionen, auf die alle Anwendungen zugreifen können – unabhängig davon, ob diese noch auf den Servern des Unternehmens laufen oder bereits in der Cloud. Diese Funktionen werden in der „Wolke“ in Form von Containern zur Verfügung gestellt. Auf diese Weise wird die Komplexität der bisherigen Infrastruktur (viele heterogene Tools und damit verbundene permanente Anpassungen) erheblich reduziert.
Eine zentrale Rolle in dieser neuen Infrastruktur spielen die Lösungen DocBridge® Gear und DocBridge® Impress (abgelöst durch die DocBridge® Communication Suite). Während erstere die zentrale Plattform für die Konfiguration und Automatisierung von Prozessen der gesamten Kundenkommunikation ist – für Fachanwendungen genauso wie für Salesforce-Applikationen -, ist DocBridge® Impress zuständig für die Dokumentenerstellung einschließlich interaktiver Funktionen für die Erzeugung personalisierter, formularbasierter Dokumente (Guided Interactive). Über eine leistungsstarke, von Compart zur Verfügung gestellte Schnittstelle (REST API) werden alle Geschäftsanwendungen und Datenquellen in eine einzige Cloud-Infrastruktur zusammengeführt.
Prozesse für folgende CCM-Szenarien können mit den beiden Lösungen konfiguriert werden:
Ein wichtiger Aspekt in diesem Zusammenhang ist die ereignisgesteuerte Überwachung der Kommunikation bzw. die Rückkopplung aus dem Versand (Closed Loop): Mittels DocBridge® Gear sollen erweiterte Workflows entwickelt werden, die beispielsweise erkennen, dass eine per E-Mail versandte Rechnung nicht empfangen wurde. In diesem Fall könnte beispielsweise automatisch eine SMS oder eine WhatsApp-Nachricht an den Empfänger erzeugt werden (vorausgesetzt, die Telefonnummer ist bekannt), die ihn darauf hinweist, das ein wichtiges Dokument für ihn bereitliegt. Reagiert der Kunde darauf ebenfalls nicht, würde im nächsten Schritt ein Workflow greifen, der ihm die Rechnung automatisch als klassischen Brief an die postalische Adresse schickt.
Tatsache ist: Solche fortgeschrittenen Szenarien sind für die moderne Kundenkommunikation eines Unternehmens mittlerweile unerlässlich. Mittels einer intelligenten CCM-Infrastruktur wird es in die Lage versetzt, nahezu ohne manuelles Eingreifen auf transaktionale Vorgänge empfängerspezifisch zu reagieren. In einem immer stärkeren Wettbewerbsumfeld, wo die Qualität der zu erbringenden Dienstleistung allein nicht mehr ausreicht für eine langfristige Kundenbindung, kann gerade diese proaktive Kommunikation den entscheidenden Unterschied ausmachen.
Dieses Prinzip der Proaktivität ist auch ein Zeichen dafür, dass sich die Beziehung zwischen CRM und CCM grundlegend verändert hat. Beide Bereiche sind durch dieses Projekt hinsichtlich Zugänglichkeit und Skalierbarkeit in der Cloud gleichgestellt und spiegeln das neue Rollenverhältnis eines CRM-Systems wider: Es verwaltet nicht nur Kundendaten und –erfahrungen, sondern stützt sich, um in Aktion treten zu können, auf eine robuste Infrastruktur für die personalisierte Omnichannel-Kommunikation. Diese ist in der Lage, nach und nach alle Datenquellen und Kommunikationskanäle zu integrieren, die für die Unternehmensleistung erforderlich sind.
Mehr als zwei Millionen Kommunikationen täglich
Die von Compart entwickelte Architektur besitzt einen hohen Benutzerkomfort. Vor allem der Zugriff auf die Funktionen von DocBridge® Gear und DocBridge® Impress (abgelöst durch die DocBridge® Communication Suite) über leistungsstarke REST API ist ein großer Vorteil. Mehr noch: Die Schnittstelle ermöglicht es, verschiedene Datenquellen abzufragen und die Ergebnisse „on the fly“ anzupassen. Jede Geschäftsanwendung, die Daten im JSON- oder XML-Format austauschen und verarbeiten kann, hat damit Zugriff auf das gesamte Funktionsspektrum der CCM-Basis. Die Gefahr, dass „Kommunikationssilos“ oder eine „Kommunikation der zwei Geschwindigkeiten“ entsteht bzw. fortbesteht, ist damit gebannt.
Darüber hinaus wird die neue CCM-Architektur mit DocBridge® Gear als zentraler Plattform die standardisierte, automatisierte Verarbeitung von mehr als zwei Millionen Kommunikationsvorgängen pro Tag beim Dienstleister ermöglichen, davon anderthalb Millionen SMS und eine halbe Million E-Mails; ein Kommunikationsvolumen, für das Cloud-basierte Plattformen nicht per se ausgelegt sind – mögen sie auch noch so leistungsfähig sein. Mit dem Architekturansatz von Compart ist das kein Problem.
Die Plattform DocBridge® Gear ist eine zentrale Komponente der Produktfamilie DocBridge® für die Automatisierung von Upstream- und Downstream-Prozessen in der Kundenkommunikation. Auch typische Prozesse wie Dokumentenerstellung einschließlich interaktiver Kommunikation, Konvertierung, Bündelung zu portooptimierten Sendungen, Versand auf analogen und digitalen Kanälen sowie Abläufe der Qualitätssicherung (Dokumentenprüfung, Validierung, Freigabe) lassen sich anwenderspezifisch konfigurieren und im Verbund mit anderen Systemen als komplexe Workflows umsetzen.
Grundprinzip von DocBridge® Gear (abgelöst durch die DocBridge® Communication Suite) ist der Gebrauch von wiederverwendbaren „Worklets“, die für ganz bestimmte Funktionalitäten und Teilprozesse stehen. Diese Worklets können sehr granular sein (kleine, überschaubare Abläufe), aber auch sehr groß (mehrfach verschachtelte Abläufe/Berücksichtigung verschiedener, komplexer Kriterien) sein. Trotzdem lassen sich Änderungen in den Worklets problemlos berücksichtigen, ohne dass eine aufwändige Neuprogrammierung notwendig ist.
DocBridge® Gear richtet sich in erster Linie an Unternehmen, die sich mit der weitgehenden Automatisierung und Digitalisierung der Kundenkommunikation (Customer Communication Management) beschäftigen und eine IT-Lösung zur nahtlosen Integration verschiedener Business-Anwendungen suchen.
DocBridge® ist eine skalierbare, plattformunabhängige und Cloud-fähige Software für das seiten- und geräteunabhängige Erstellen von Dokumenten und Vorlagen (Templates), die sich auch von Anwender ohne profundes IT-Know-how bedienen lässt. Die mit der Lösung von Compart generierten Dokumente sind omnichannel-fähig und barrierefrei gemäß PDF/UA. Mit DocBridge® erhalten Benutzer einen schnellen Zugang zu allen modernen, digitalen Kommunikationskanälen. Jedes Dokument braucht nur einmal erstellt zu werden und steht ohne größeren Aufwand für alle Medien zur Verfügung.
Produkt-Demo anfragen
Haben Sie Fragen - unsere Experten beraten Sie persönlich
DocBridge® Impress (abgelöst durch die DocBridge® Communication Suite) bedeutet einen Paradigmenwechsel im Dokumentendesign: Die Erstellung erfolgt unabhängig von einer vorgegebenen Seitengröße und basiert auf offenen Standards. Außerdem lässt sich DocBridge® Impress als interaktives Briefschreibsystem für die Erstellung individueller Dokumente auf der Basis vorgefertigter Templates einsetzen. Diese auch als Guided Interactive bezeichnete Art der Dokumentenerstellung ist besonders für Unternehmen mit einem hohen Anteil an interaktiver Kommunikation wichtig, bei denen standardisierte Vorlagen (Formulare) noch spezifisch durch den Sachbearbeiter angepasst werden müssen (z. B. Steuerbescheide, Kreditverträge, Vertragsänderungen).
Die Architektur von DocBridge® Impress basiert auf der konsequenten Trennung zwischen einem web-basierten Editor (Impress Designer) und der eigentlichen Composition Engine (Impress Engine). Somit lassen sich je nach Einsatzszenario beide Komponenten gemeinsam nutzen, aber auch einzeln als Microservices, die direkt an bestehende Applikationen über Webservices angebunden werden können.
Weitere Details zu den Komponenten:
Mit diesem Tool entwirft der Anwender (z. B. Textadministrator) über eine intuitiv zu bedienende Oberfläche sein Dokument (Template) und ergänzt es bei Bedarf um Angaben zum Layout für die digitalen Kanäle bzw. für den Druck.
Er kann dort Regeln der Geschäftslogik hinterlegen und bestimmen, ob das Dokument allgemein zugänglich (Barrierefreiheit gemäß WCAG-Standard PDF/UA) sein und in welchen Sprachen es zur Verfügung stehen soll.
Außerdem möglich:
Sie ist das „Herz“ von DocBridge® Impress und führt die im DocBridge® Impress Designer erstellten oder bereits anderweitig vorliegenden Templates mit den variablen Daten ("Rohdaten") aus Geschäftsanwendungen zusammen und erstellt unter Anwendung der definierten Regeln und der bereitgestellten Ressourcen (Bilder, Textbausteine, etc.) die fertigen Dokumente.
Eine zentrale Rolle im Customer Communication Management (CCM) von Unternehmen, Behörden und Organisationen spielt die Überwachung der Kommunikation. Schließlich will man nicht „ins Blaue“ hinein kommunizieren. Wenn die E-Mail als Bounce zurückkommt oder im Spam-Ordner des Empfängers landet, ist das ärgerlich – vor allem bei rechtsrelevanten Dokumenten bzw. Vorgängen. Wie stelle ich also sicher, dass das Dokument tatsächlich den Empfänger erreicht und von ihm gelesen wird (Ensured Delivery)?
Mit anderen Worten: Das CCM-System muss in der Lage sein, bei Bedarf auf einen anderen Kommunikationskanal zu wechseln, damit das Dokument bzw. die Nachricht den Empfänger auch wirklich erreicht. Im Idealfall passiert das automatisiert, wobei zunächst immer der günstigste und schnellste Kanal verwendet wird. Das heißt: Kann beispielsweise eine E-Mail mit einem wichtigen und zeitkritischen Dokument nicht zugestellt werden (weil beispielsweise die Adresse falsch oder der Posteingangsserver überlastet ist), könnte das System daraufhin über einen entsprechend konfigurierten Workflow eine Messenger-Nachricht (SMS) an den Empfänger mit dem Hinweis verschicken, dass ein wichtiges Dokument für ihn zum Download (z. B. im Kundenportal) bereitliegt – vorausgesetzt, dessen Telefonnummer ist bekannt. Reagiert er nicht auf diese SMS, wäre die nächste Option der klassische Briefversand.
Erforderlich ist also eine CCM-Architektur, die auf Situationen dieser Art automatisch reagiert. Eine wichtige technologische Komponente bzw. Methode für die Etablierung eines solchen ereignisgesteuerten Systems (Event Driven Architecture) sind sogenannte Web-Hooks – eine Art Request mit Informationen zu aufgetretenen Ereignissen („Event“) innerhalb eines Kommunikationsvorganges, zum Beispiel dem Status-Code einer versuchten E-Mail-Zustellung sowie eine ID, mit der sich die ursprüngliche Transaktion jederzeit „identifizieren“ lässt (Welches Dokument soll an wen verschickt werden?)
Über diesen Request, der praktisch eine URL darstellt, interagieren das CCM-System und andere Anwendungen (z. B. Mail-Server) miteinander. Wenn also ein Dokument auf dem elektronischen Weg (E-Mail) nicht zugestellt werden kann, bekommt das CCM über den Web-Hook die entsprechende Meldung, woraufhin über den oben beschriebenen Workflow ein anderer Kommunikationskanal angesteuert wird. Über die enthaltene ID lässt sich das Dokument ja identifizieren.
Mit Lösungen wie DocBridge® Communication Suite lassen sich solche Workflows konfigurieren – beispielsweise, um im oben beschriebenen Beispiel den „E-Mail-Bounce“ automatisch abzufangen und eine neue Transaktion auszulösen. Diese erweiterten Verarbeitungsszenarien, die sich auch in der Cloud umsetzen lassen, gehören inzwischen zu den Grundanforderungen eines modernen CCM.
CCM steht für Customer Communication Management, auf Deutsch Kundenkommunikations-Management.
Ziel eines modernen Customer Communication Managements muss es sein, Kundenkommunikation auf allen analogen und digitalen Kanälen zu generieren, zu verwalten und bereitzustellen im Interesse eines konsistenten, personalisierten Kundenerlebnisses (Customer Journey). Automatisiert, unter Verwendung von Technologien wie Cloud, API, Docker, basierend auf einer stringenten Kommunikationsstrategie sowie unter Anwendung des Prinzips einer konsequenten Entkopplung von Empfang, Erstellung und Versand von Dokumenten (Digital-First-Design). Eine innovative CCM-Software bietet dafür entsprechende Unterstützung.
Nachfolgend die wichtigsten Aspekte eines modernen Customer Communication Managements (CCM):
Transportcontainer in der Logistik ermöglichen es, Waren jeglicher Art in einer standardisierten “Verpackung” flexibel und schnell mit unterschiedlichen Verkehrsmitteln zu verschicken und zu verteilen – ob per Schiff, Flugzeug, Bahn oder LKW. Ähnlich operieren Container in der IT: Sie verpacken eine Anwendung und alle zu ihrer Ausführung erforderlichen Dateien in ein handliches Paket.
Das vereinfacht sowohl die Installation und den Betrieb von Server-Anwendungen als auch deren Management und Verteilung. Somit erleichtern Container den Umgang mit komplexen Server-Anwendungen und ermöglichen eine weitgehende Automatisierung von Rollout-Prozessen im Rechenzentrum. Das ist besonders bei der Bereitstellung von skalierbaren, verteilten Anwendungen innerhalb von Cloud-Umgebungen wichtig.
Eine wesentliche Problematik beim Rollout von neuen Anwendungen oder neuen Releases ist es, dass jede Anwendung von gewissen Elementen ihrer Umgebung abhängt. Hierzu zählen beispielsweise lokale Einstellungen oder Funktionsbibliotheken. Oft unterscheiden sich die Einstellungen in der Entwicklungsumgebung von denen der Testumgebung und der Produktion. Dann kann es schnell passieren, dass eine Anwendung in der Produktion wider Erwarten anders oder gar nicht funktioniert.
Weitere Faktoren, die einen reibungsloses Rollout stören können, sind das der Anwendung zu Grunde liegende Betriebssystem, dessen Version und Einstellungen, alle hinzugefügten Pakete und Module oder die Konfiguration des Netzwerks. Die Bereitstellung mehrerer Anwendungen über unterschiedliche Plattformen ist also eine Herausforderung. Hier bietet der Einsatz von Containern unmittelbare Vorteile: Entwickler verpacken so ihre Anwendungen inklusive aller Abhängigkeiten wie Bibliotheken und Konfigurationsdateien in einem Container. Die Anwendungen werden also nicht mehr direkt auf den Zielsystemen installiert. Die Container stellen somit die komplette Laufzeitumgebung der Applikation in einem Paket bereit.
So haben Entwickler die Möglichkeit, Anwendungen zwischen verschiedenen Umgebungen hin- und herzuschieben – zum Beispiel für Tests in einem spezifischen Hardware-Umfeld und den Betrieb in einem anderen. Oder sie betreiben Applikationen erst auf einer physikalischen Maschine und dann in einer Private, Public oder Hybrid Cloud.
Container machen Anwendungen unabhängiger von der Umgebung, in der sie ausgeführt werden. Sie agieren damit ähnlich einer virtuellen Maschine (VM). Während eine VM jedoch ein vollständiges Betriebssystem sowie Applikationen enthält, teilen sich mehrere Container einen Betriebssystemkern. Jede Anwendung erhält lediglich einen neuen User Space und damit eine komplett isolierte Umgebung. Container verbrauchen also im Vergleich zu VMs deutlich weniger Ressourcen wie Rechenleistung, Hauptspeicher etc. Und es dreht sich hier um Megabytes bei Containern im Vergleich zu Gigabytes bei VMs. Daher passen auf einen Server sehr viel mehr Container als virtuelle Maschinen. Zudem sind Container schneller einsatzbereit: Während VMs manchmal mehrere Minuten zum Start benötigen, stehen Anwendungen hier beinahe sofort zur Verfügung.
Container ergänzen die Virtualisierung
Trotzdem werden Virtualisierungs-Lösungen weder überflüssig noch komplett ersetzt werden, da sie nicht für alle Anwendungsszenarien passen. So eignen sich Container zum Beispiel sehr gut für Infrastrukturen, in denen eine große Zahl von Applikationsinstanzen parallel laufen. Sie sind zudem ideal für Anwendungen, welche häufigen Updates und funktionalen Erweiterungen unterliegen. Bei Applikationen, die aus unterschiedlichen Komponenten bestehen und auf einer Microservices-Architektur basieren, bieten Container ebenfalls eine effiziente Möglichkeit, neue Rollouts ohne großen Overhead zu implementieren.
Für andere Anwendungsfelder hingegen ist die Virtualisierung mit Hypervisoren nach wie vor die bessere Wahl: Beispielsweise für die Bereitstellung und den Betrieb von Standard-Serverdiensten wie Datenbankservern, Directory Servern oder auch Webservern – also im Prinzip für standardisierte Anwendungen, die längeren Aktualisierungszyklen unterliegen und von Dritten bereitgestellt werden. Somit sind Container eher eine sinnvolle Ergänzung zur Virtualisierung als ein Ersatz.
Mit WebHooks wird ein nicht-standardisiertes Verfahren zur Kommunikation von Servern bezeichnet, das im Rahmen des verteilten Rechnens oder der nachrichtenorientierten Middleware genutzt wird. Im Prinzip ist ein WebHook nichts anderes als eine Nachricht in Form eines http-Requests (URL mit Inhalt).
WebHooks informieren eine Server-Software darüber, dass ein bestimmtes Ereignis eingetreten ist, um daraufhin eine Reaktion auszulösen. Wenn eine Anwendung über ein Ereignis mittels WebHook informiert, müssen an diesem Vorgang interessierte andere Applikation kein Polling betreiben, um davon Kenntnis zu erlangen. Das reduziert das Nachrichtenaufkommen zwischen den Systemen.
WebHooks kommen als einfaches Callback-Verfahren in der Daten-Synchronisation, externen Berechnung und Daten-Validierung zum Einsatz. Technisch wird dazu eine http-POST-Message an eine dafür vorbereitete URL gesendet, welche die angeforderten Daten zurückliefert. Im Gegensatz zu SOAP (Simple Object Access Control) verwenden WebHooks keine zusätzliche Transportschicht verwendet und sind im Unterschied zum Atom Syndication Format nicht auf das XML-Format festgelegt.
Außer WebHooks gibt es weitere Technologien für das Design und den Betrieb von Event Driven Architekturen, beispielsweise Apache, Kafka. Diese verwenden kein REST API, sondern Message-Queues.
Quelle: Wikipedia
Docker ist eine Open-Source-Software zur Isolierung von Applikationen in Containern (Virtualisierung). Docker vereinfacht die Bereitstellung von Anwendungen, weil sich Container, die alle nötigen Pakete enthalten, leicht als Dateien transportieren und installieren lassen. Container gewährleisten die Trennung und Verwaltung der auf einem Rechner genutzten Ressourcen. Das beinhaltet laut Aussage der Entwickler: Code, Laufzeitmodul, Systemwerkzeuge und –bibliotheken – alles, was auf einem Rechner installiert werden kann.
Docker basiert auf Linux-Techniken wie Cgroups und Namespaces, um Container zu realisieren. Während anfänglich noch die LXC-Schnittstelle des Linux-Kernels verwendet wurde, haben die Docker-Entwickler mittlerweile eine eigene Programmierschnittstelle namens libcontainer entwickelt, die auch anderen Projekten zur Verfügung steht. Als Speicher-Backend verwendet Docker das Overlay-Dateisystem AuFS, ab Version 0.8 unterstützt die Software aber auch btrfs.
Prinzipiell ist Docker auf die Virtualisierung mit Linux ausgerichtet. Docker kann allerdings auch mittels Hyper-V (Standard) oder VirtualBox auf Windows und mittels VirtualBox auf macOS verwendet werden. Da die Ressourcentrennung alleine mit den Docker-Techniken nicht völlig sicher ist, hat die Firma Red Hat Unterstützung für die sicherheitsrelevante Kernel-Erweiterung SELinux implementiert, welche die Container auf der Ebene des Host-Systems zusätzlich absichert.
Veröffentlicht wurde die Software Docker vom Unternehmen dotCloud im März 2013. dotCloud nannte sich im Oktober 2013 in Docker um; dotCloud selbst wurde zu einem Platform-as-a-Service, der im August 2014 an das Berliner IT-Unternehmen cloudControl verkauft wurde.
Im Jahr 2014 wurde die Open-Source-Software zunehmend bekannter und populärer. Inzwischen ist Docker ein fester Bestandteil der Linux-Distribution von Red Hat. Auch im Lieferumfang der Linux-Distribution openSUSE ist die Software enthalten. Im Sommer 2014 schlossen sich die Firmen Docker, Microsoft, IBM, Red Hat, CoreOS, Saltstack und Mesosphere dem Kubernetes-Projekt an. Dieses Projekt wurde von Google angestoßen und hat zum Ziel, Container auf allen öffentlichen, privaten und hybriden Cloud-Umgebungen bereitzustellen.
