So erstellen Sie mit Low-Code einen digitalen Kunden-Onboarding-Prozess

Warum scheitern wir?

Im heutigen Web stehen wir auf den Schultern derer, die vor uns kamen, und bauen auf dem auf, was sie geschaffen haben.

Das Nichterkennen führt zum Scheitern.

Wenn Sie jemals die IT-Abteilung Ihres Unternehmens betreten, gehen Sie in die DevOps-Etage. Sie werden von einem unterbesetzten Entwicklerteam begrüßt, das Kopfhörer trägt und rote Augen vom Starren auf Bildschirme hat. Wahrscheinlich sind sie so konzentriert, dass sie nicht einmal antworten, wenn man ihnen eine Frage stellt.

Warum sind sie so intensiv und verschlafen? Ich habe erlebt, wie traditionelle Entwickler stolz darauf waren, Apps von Grund auf selbst zu entwickeln. Es kann mit genügend Zeit und Ressourcen großartig sein, es lieber selbst zu tun und von Grund auf neu zu entwickeln, aber bei kleinen Projekten mit begrenzter Finanzierung ist es oft der Untergang des Projekts. Wenn Tools wie Low-Code auftauchen, neigen traditionelle Entwickler dazu, sie abzulehnen. Wo ist die Herausforderung!

Apps, die von Grund auf neu erstellt werden, brauchen gefühlt ewig. Wenn man sich nicht auf die Arbeit anderer verlassen kann, kann ein einfacher Build unnötig komplex werden. Die Ironie ist, dass es heute keine reale Anwendung gibt, die nicht auf einer vorgefertigten Bibliothek in Node.js oder Java basiert.

Durch die Nutzung einer Low-Code-Plattform wie Mendix, die es Ihnen ermöglicht, von einem Marktplatz zu beziehen von Mendix- und von der Community erstellte Module basieren auf demselben Konzept wie eine vorgefertigte Node.js-Bibliothek. Es beseitigt die unnötige Komplexität beim Erstellen und ermöglicht Ihnen die einfache Bereitstellung des Endergebnisses.

Manchmal gibt es noch nichts, das Sie nutzen könnten. In diesem Fall müssen Sie umfangreiche und komplexe Codes erstellen und in diesen Fällen möchten Sie, dass diese vom Rest des Unternehmens wiederverwendet werden können. In diesem Szenario würden die meisten Unternehmen immer noch Zeit in die Erstellung wiederverwendbarer Komponenten investieren und Mendix hat versucht, diesen Prozess noch weiter zu rationalisieren, indem ein unternehmensinterner Marktplatz geschaffen wurde, auf dem Sie alle benutzerdefinierten Erweiterungen hosten können, die Ihr Unternehmen erstellt, und auf dem Sie Features und Funktionen zwischen den Websites und Apps Ihres Unternehmens teilen können – in der Gewissheit, dass Ihr geistiges Eigentum geschützt ist.

Traditionell vs. Low-Code: Ein praktisches Beispiel

Um die Unterschiede aufzuzeigen, nehmen wir die Idee, einen digitalen Kunden-Onboarding-Prozess zu erstellen.

Ein Unternehmen bittet sein Entwicklungsteam, an einer App zu arbeiten, die für das Onboarding neuer Kunden verwendet werden soll.

Die App muss über folgende Funktionen verfügen:

• Eine Integration zu Dropbox zum Speichern der Daten und Dokumente der Kunden
• Eine Adresssuche für die Adressen der Kunden
• Die Möglichkeit, wichtige Dokumente zu scannen und Informationen daraus zu extrahieren
• Die Möglichkeit, Dokumente digital zu signieren und zu überprüfen.

Unter Verwendung dieser als Referenz erstellt der Business Analyst des Unternehmens vier User Stories, die von den DevOps-Teams ausgeführt werden können.

1) Als Benutzer möchte ich eine Integration zu Dropbox haben, damit ich die Dokumente der Kunden in der Cloud speichern kann.

2) Als Benutzer möchte ich eine automatische Adresssuche haben, damit ich die Adresse des Kunden einfach finden kann.

3) Als Benutzer möchte ich wichtige Dokumente mit der Kamera des Geräts scannen können.

4) Als Benutzer möchte ich Dokumente digital prüfen und unterzeichnen können.

Da es in der Abteilung zwei Teams gibt und an keinen anderen neuen aktiven Projekten gearbeitet wird, beschließt das Unternehmen, beiden Teams die Erstellung von Apps zu gestatten und sie in einem internen Hackathon gegeneinander antreten zu lassen.

Team 1 ist ein Low-Code-Team, das hauptsächlich Mendix um ihre Apps zu erstellen und zu hosten. Das Team besteht aus einem hochqualifizierten Entwickler, einem Buchhalter aus der Finanzabteilung, der in seiner Freizeit das Programmieren lernt, und einem Designer aus der Marketingabteilung, der ein Talent für die Gestaltung von Websites und Apps hat.

Team 2 besteht aus drei traditionellen Entwicklern: einem Java-Entwickler, einem C#-Entwickler und einem Node.js-Entwickler. In beiden Szenarien haben die Teams auch Zugriff auf die größeren traditionellen Scrum-Stakeholder wie QA und Business-Analysten.

Zwei Wochen später präsentieren beide Teams ihre Apps den Stakeholdern. Dabei demonstrieren sie abwechselnd, wie ihre Apps die für die Challenge festgelegten User Stories erfüllen. Und es gibt einen klaren Gewinner – Team 1.

Die Juroren haben die Einsendungen durchgesehen und sie anhand der einzelnen User Storys bewertet. Lassen Sie uns ihre Erkenntnisse näher betrachten.

1) Als Benutzer möchte ich eine Integration zu Dropbox haben, damit ich die Dokumente der Kunden in der Cloud speichern kann.

Team 1 erkannte sofort, dass es ein vorgefertigtes Modul im Mendix  Marketplace. Sie nutzten dies als Grundlage für ihre Arbeit und konnten es bald einrichten. Anschließend konzentrierten sie sich auf die Benutzeroberfläche und die Dokumentation ihres Codes, was sie im Video taten.

Team 2 verbrachte die meiste Zeit damit, die Dokumentationsseiten von Dropbox zu verstehen. Obwohl ihnen eine funktionierende Integration gelang, war die Benutzeroberfläche holprig und klobig.

2) Als Benutzer möchte ich eine automatische Adresssuche haben, damit ich die Adresse des Kunden einfach finden kann.

Team 1 hatte erneut ein Modul zum Download verfügbar und konnte es schnell anschließen, wobei es sich auf die Abrundung der Funktionalität und Dokumentation konzentrierte.

Team 2 hatte einige Schwierigkeiten, sich für einen Adresssuchdienst zu entscheiden. Alle hatten eine Präferenz, welcher Dienst am besten wäre, und verloren viel Zeit mit der Entscheidung. Schließlich gelang es ihnen, es mit Google zum Laufen zu bringen, aber auch dieses Mal war es kein Gegner für Team 1.

3) Als Benutzer möchte ich mit der Kamera des Geräts wichtige Dokumente scannen können.

Team 2 wusste zu diesem Zeitpunkt, dass es im Rückstand war, und bat einen Experten auf dem Gebiet um Hilfe. Wenn Sie schon einmal im Softwareprojektmanagement gearbeitet haben, können Sie das Problem hier nachvollziehen. Ein berühmtes Gesetz in der Softwareentwicklung ist Brookes Gesetz, das besagt: „Wenn man einem verspäteten Softwareprojekt zusätzliche Arbeitskräfte hinzufügt, wird es noch verspätet sein.“ Wenn ein neues Teammitglied zum Erstellen der OCR-Funktion hinzugezogen wird, braucht das neue Mitglied Zeit, um mit dem Projekt Schritt zu halten, und es braucht dann auch Zeit, um die aktuelle Codebasis zu verstehen. Wie immer bewahrheitete sich dies und das Projekt geriet noch mehr in Rückstand.

Team 1 konnte sein Entwicklungstempo beibehalten. Sie nutzten ein – ja, Sie ahnen es – Modul, das ihnen in Mendix, und die Low-Coder ohne Erfahrung in der Bilderkennung haben es schnell geschafft und sich dabei auf ihr technisch versiertes Mitglied verlassen, das sie durchbrachte.

4) Als Benutzer möchte ich Dokumente digital prüfen und unterzeichnen können.

Beide Teams erzielten für diese User Story ähnliche Ergebnisse, aber da das Low-Code-Team seine Geheimwaffe einsetzen konnte (den Buchhalter, der den korrekten Prozess kennt, dem dies im aktuellen System folgt), konnten sie einen Fehler im komplexen Benutzerfluss vermeiden. Sie hatten so viel Zeit übrig, dass sie auch dazu ein Video machen konnten. Team B tat dies nicht.

Mendix gab Team A die Möglichkeit, das Domänenmodell ihrer Apps automatisch zu modellieren, indem es die vorhandene Tabelle hochlud, die automatisch gelesen und im Domänenmodell ihrer App neu erstellt wurde. Schließlich nutzte Team A MendixDie Fähigkeit von, allgemeine Übersichten für alle erforderlichen Daten zu generieren, ermöglichte es ihnen, sich auf alle wichtigen Integrationen für die App zu konzentrieren.

Entscheidungszeit

Die Jury wählte Team 1 problemlos zum Sieger – aber warum?

Im Grunde erfüllten beide Teams dieselben Anforderungen – es handelt sich um dieselbe Technologie, die vom selben Anbieter verarbeitet wird, und dennoch war Team 1 in der Hälfte der Zeit fertig und verbrachte den Rest damit, sein Produkt zu iterieren und zu verfeinern. Hier ist, was sie schaffen konnten.

Das Team hat auch Nacharbeiten an zukünftigen Änderungen in den von ihm verwendeten Modulen vermieden. Wenn beispielsweise die DocuSign-Bibliothek Änderungen erfordert, werden diese vom Marketplace-Ersteller des Moduls bearbeitet, und das agile Team muss den Code nur dann umgestalten, wenn es nach der Aktualisierung des Moduls zu schwerwiegenden Änderungen kommt, die eigentlich vom Ersteller des Connectors hätten bearbeitet werden sollen.

Es ist in Ordnung, sich auf die Arbeit anderer zu verlassen. Das ist ein Fortschritt. Die Menschen und Organisationen, die diese Module und Codebibliotheken erstellt haben, möchten, dass Sie sie verwenden. Sie möchten Ihnen die Kopfschmerzen ersparen, die sie selbst hatten, damit Sie sich auf die Lösung größerer Probleme konzentrieren können. Das Schöne ist, dass Sie diese nutzen können, um Ihr Kundenerlebnis zu verbessern und digitale Onboarding-Prozesse für Kunden aufzubauen. Oder Sie können diese nutzen, um eine beliebige Anzahl von Systemen und Apps in einem nie zuvor möglichen Tempo zu erneuern und zu modernisieren.