CRM goes APP

Die Spannweite der Außendiensttätigkeiten reicht dabei vom Handwerker bis hin zum klassischen Vertriebsmitarbeiter. Häufig ist der Außendienstmitarbeiter dazu angehalten, Formulare vor Ort auszufüllen. Diese werden dann entweder in einer Akte im Büro abgelegt oder von einem Mitarbeiter im Innendienst manuell ins CRM übertragen. Beide Vorgehensweisen bringen allerdings Nachteile mit sich. Während die Daten im ersten Beispiel in der entsprechenden Akte und im CRM-System an unterschiedlichen Stellen abgelegt werden, entsteht im zweiten Beispiel ein doppelter Arbeitsaufwand. Zudem verbrauchen beide Vorgehensweisen unnötig Papier. Ein Umstand, den es gilt im Zeitalter des papierlosen Büros zu vermeiden.

Ein Lösungsansatz wäre mit einem mobilen CRM-System (mCRM) gegeben, da eine mobile Variante sowohl dem lesenden als auch dem schreibenden Mitarbeiter Zugriff auf die Daten des CRM ermöglicht.

Mobiler Zugriff auf das CRM

Neben dem Einsatz von bereits zur Verfügung stehenden Apps, existiert noch die Möglichkeit einer Eigenentwicklung. Der Hauptvorteil einer individuell entwickelten Variante ist, dass sie sich konkret an die Arbeitsweise des Benutzers anpassen lässt. So hat beispielsweise ein Vertriebsmitarbeiter eine andere Vorgehensweise als ein Mitarbeiter im Reparaturservice. Herkömmliche Standard-Varianten sind sehr „CRM-nah“. Das bedeutet, es können bestimmte Entitäten angelegt, geändert, angeschaut und gelöscht werden. Hier wird die Attraktivität einer individuellen Entwicklungsvariante deutlich, da sich dabei der normale Arbeitsprozess abbilden lässt. Der Nutzer muss nicht wissen, welche Entitäten er anlegen oder editieren muss. Hier ist lediglich eine Erfassung der relevanten Daten notwendig. Die App steuert eigenständig, wohin bestimmte Daten ins CRM übertragen werden müssen und was gegebenenfalls als nächstes damit passiert. Die Nutzerakzeptanz einer solchen Lösung wird dadurch sehr viel höher sein.

Die Architektur einer CRM-App

Was ist bei der Entwicklung einer CRM-App zu beachten und wie könnte eine sinnvolle Architektur für die Kommunikation zwischen einer App und dem CRM aussehen? Die einfachste Variante wäre, der App direkten Zugriff auf das CRM-System mittels des CRM-Service und des CRM-SDKs von Microsoft zu erlauben. Das SDK ermöglicht alle relevanten Aktionen, insbesondere die CRUD-Operationen, auf dem CRM-Service auszuführen. Doch trotz dieses scheinbaren Vorteils ist dieser Lösungsansatz in der Praxis nicht empfehlenswert. Ein wichtiger Aspekt hierbei ist, dass die Plattformunabhängigkeit nicht gegeben ist.

Es ist sinnvoller, zwischen dem CRM-System und der App eine Schicht zu schalten. Denn oftmals kommt in einem Unternehmen nicht nur eine App zum Einsatz. Nehmen wir an, verschiedene Abteilungen – beispielsweise Vertrieb oder Service – arbeiten in einem Unternehmen mit einer App, dann lässt sich auf der vorhandenen Architektur aufbauen. Im günstigsten Fall lassen sich sogar bestimmte Code-Bausteine wiederverwenden. Weiterhin spricht für eine Aufteilung der Architektur in Schichten, dass zumindest kleine Änderungen im CRM-System nicht zwangsläufig zu einer Anpassung der App führen und damit – abhängig von der Anzahl der Geräte – auch nicht zu einem hohen Aufwand im Deployment. Stattdessen kann die Änderung in der Zugriffsschicht erfolgen. Doch der wichtigste Grund, der für eine Architekturaufteilung spricht ist: die Entkopplung der Logik zwischen CRM und App. In dieser Schicht („Facade“) sollte die komplette Logik für den Zugriff auf das CRM gekapselt werden. Die Facade „mappt“ dabei die Daten von der App auf das CRM sowie vom CRM auf die App. Bei dieser Vorgehensweise ist die App dann komplett losgelöst vom CRM.

Der Zugriff auf das CRM-System kann häufig nur innerhalb des lokalen Netzwerks erfolgen. Da der komplette Zugriff von der Facade erfolgt, ist die entscheidende Frage, wo sich diese befindet. Befindet sich die Facade innerhalb des lokalen Netzwerkes, ist der Zugriff kein Problem. Problematisch ist dann allerdings der Zugriff der App auf die Facade. Die einfachste Möglichkeit dies zu lösen ist, die App ebenfalls in das lokale Netzwerk zu integrieren – entweder per VPN, CDA oder mit Hilfe eines ähnlichen Tools. In der folgenden Abbildung wird die daraus resultierende Architektur deutlich:

Besteht die Möglichkeit der Netzwerkintegration nicht, lässt sich die Facade alternativ in der Cloud hosten, beispielsweise über Azure. Mit dem Service Bus Relay wird dabei eine Verbindung zwischen den beiden Services, der Cloud und dem lokalen Facade-Netzwerk geschaltet, so dass eine sichere Kommunikation gewährleistet wird:

Das Ergebnis eines solchen Architektur-Modells lässt sich dann folgendermaßen darstellen:

Fazit

Für den Zugriff auf mobile CRM-Systeme stehen bereits verschiedene Apps zu Verfügung. Der Hauptvorteil einer individuell entwickelten Lösung liegt hauptsächlich darin, dass die App den gewohnten Arbeitsprozess des Mitarbeiters nachbildet.

Wie eine sinnvolle Architektur aussehen kann, hängt natürlich vom Einzelfall ab. Ein sehr entscheidender Faktor ist dabei, ob die App direkten Zugriff auf das lokale Netzwerk mit dem CRM hat oder nicht. Die in diesem Beitrag vorgestellten Architekturen zeigen, wie eine mögliche Architektur für das jeweilige Szenario aussehen kann.

Wie bewertet ihr den Nutzen eines mobilen CRM-Systems? Habt ihr bereits positive Erfahrungen mit einer solchen mobilen Variante gemacht und welche der vorgestellten Architekturen würden sich in eurem Unternehmen anbieten? Ich freue mich auf eure Kommentare!