Differenzierung an der Kundenschnittstelle? Mit Standardsoftware im Hintergrund?
Wenn in der Firmenstrategie, Digitalstrategie, Multi- oder Omnichannelstrategie drin steht, dass das Unternehmen eine Differenzierung an der Kundenschnittstelle anstrebt, um sich von der Konkurrenz abzuheben, begreife ich nicht, warum das mit Standardsoftware gelöst werden muss, die das nicht nur erschwert sondern sogar verhindert. Ich gebe zu, bei dieser Frage funktioniere ich einfach, aber: Wie soll ich mich mit dem gleichen Zeug spürbar im Erlebnis von anderen unterscheiden? Und so viel vorweg: Es gibt Alternativen zu schlechten Quasi-Standards!
Warum ist der gleiche Kanal bei unterschiedlichen Unternehmen etwas anderes?
Ein führender IT-Mitarbeiter fragte mich in einer Pitch-Präsentation vor einigen Jahren, ob man denn nicht schon alles herausgefunden hätte, wie so eine Website und ein Shop funktioniert und wozu es denn ein Konzept überhaupt bräuchte. Hervorragende Frage, dachte ich. Warum eigentlich? Meine Erfahrung: Selbst wenn es haargenau das gleiche Geschäft ist, inkl. gleicher Lieferanten (was schon seltener ist) und grob gesehen inklusive der gleichen Prozesse, sind die Details von Workflowfreigaben (starker Kultureinfluss bei der Definition von Rollen und Rechten), Abläufen in der Verarbeitung, Bewertung eines Leads im Marketing, Weiterverarbeitung und Leadqualifizierung etc. sehr unterschiedlich zwischen Unternehmen. In diesem Fall hab ich den IT-Verantwortlichen des weltweit tätigen Automatisierungsdienstleisters zurück gefragt, ob sie denn genauso sind wie Zalando und ihm angeboten, dass wir dort kopieren. Und ich fragte dazu, ob er die Darstellung der Schuhe abbilden würde auf die Dienstleistungen, die sie anbieten. Dann benötigt er ausschliesslich sophistiziertes Requirements Engineering, um die Abbildung zu definieren. Aber auch diese Arbeit müsse jemand tun, und am Ende hat er dennoch ein Konzept gemacht. War ein bisschen schnippisch, ich weiss. Da sprang jedoch der Marketingleiter ein, dass das indiskutabel wäre und entfaltete ein amüsiertes Lächeln im Gesicht.
Das, was wir heute unter Standardsoftware verstehen, ist zu eng gefasst
Im Falle einer Website ist die Limitation durch ein CMS, was das Frontend betrifft, jedoch noch nicht so empfindlich. Praktisch alles an kleinen Raffinessen und auch grösseren Besonderheiten lässt sich umsetzen. Die Schwierigkeiten etablierter Standardlösungen liegen hier eher in der out-of-the-box-bad-applied-standards, die Barrierefreiheit und Suchmaschinenfreundlichkeit verhindern. Anders sieht die Sache bei Shops aus. Stellt euch vor, ihr kauft eine Shop-Lösung und dazu noch eine Bezahlapplikation, die ihr eigenes Frontend mitbringt. Uh, da schlottern mir schon die Knie… Konfigurativ lassen sich oft nur die Farben und Logos anpassen. Würden wir einen anderen Use-flow definieren, hätte das Einfluss auf alle Kunden der Bezahlapplikation. Da frag ich mich schon doch das eine oder andere Mal, warum muss denn das so sein? Was ist aus dem guten alten Webservice geworden, den EAI- und SOA-Versprechen? Auch Kundenportallösungen werden so zu Hauf an Unternehmen verkauft. Nicht einmal die Kacheln des Eingangsscreens lassen sich wirklich verändern. Sie sehen überall gleich aus, die Freiheitsgrade sind absurd. Keine Differenzierung an der Kundenschnittstelle möglich, Freunde!
Hier die Einstiegsseiten der Industriellen Betriebe Interlaken und den St. Galler Stadtwerken. Der Unterschied ist legendär!
Was mich in Projekten verfolgt, ist das latente Gefühl, dass es doch nicht sein kann, dass das Interaktionskonzept und das Design durch die Limitationen einer Standardsoftware derartig eingeschränkt werden. Und das nicht nur, weil es uns UXler dann nicht mehr braucht (?), sondern weil solche Touchpoints gerade noch für das Mithalten genügen, nicht aber für den Lead oder das Ausleben einer besonderen, begehrlichen Nische.
Was brauchen wir, um mit Standard und Einzigartigkeit umzugehen?
Was ist der gemeinsame Nenner, wenn es um Standard bei Portalen, Websites und Shops geht? Wir wollen soviel Differenzierungspotenzial wie möglich zu einem möglichst geringen Preis. Dafür kaufen wir uns ein, dass der Anbieter des Standards in Relation zu anderen Kunden, gerne Konkurrenten, selbst entscheidet, ob er eine Anforderung umsetzt oder nicht. Er wird auch entscheiden, wie lange er die Software am Leben erhält und weiter wartet. Er wird auch entscheiden, was konfigurativ anpassbar ist und er oder sogenannte Partner werden Individualentwicklung anbieten. Diese Individualentwicklung – falls auf die Spitze getrieben – führt zum Pappmaché-Problem, also dazu, dass sich die Standardlösung gar nicht mehr upgraden lässt mit der neuen Generation derselben. Letzteres passiert leider all zu oft mit sehr namhaften, «grossen» CMS. In einem Bild gesprochen, stellt man also einen Karton hin (Standardlösung), in den man ein paar Löcher schneidet, mit Pappmaché die Ecken rund macht, eine Seite anstreicht und vielleicht noch ein paar ganz kleine Streichholzschachteln drauf setzt (Individualisierungen). So erreicht man einen etwas anders anmutenden Karton. Jetzt kommt das Upgrade. Es hat die dieselbe Breite und Tiefe wie der Ursprungskarton, nur ist es nicht so hoch. Aufgabe des Upgrades ist es, genau auf den Ursprungskarton zu passen. Aber nein, da sind ja das Pappmaché und die Streichholzschachteln. Das Upgrade passt also nicht mehr. Was muss man also machen? Entweder Pappmaché und Streichholzschachtel wegreissen oder einen neuen Ursprungskarton hinstellen. Das passiert! Also diese Art von Individualisierung sollten wir vielleicht nicht anstreben.
Headless Technology
Eine andere Möglichkeit ist es, die Gesamtaufgabe (z.B. CMS, Shop oder Portal) in Einzelaufgaben zu zerlegen. Jede Einzelaufgabe ist dann möglicherweise Standard, also wie bei den meisten anderen, oder eben nicht, wenn es für mein Geschäft einzigartig ist. Alle Einzelaufgaben setze ich dann zu einem einzigartigen Gesamtkonstrukt zusammen und mische das Beste aus Standard und Individuellem. So lässt sich ein bewährtes Security-Konzept gemeinsam mit dem «Passwort vergessen»-Prozess einsetzen, dafür zusätzliche individuelle Module wie «Produktzuschnitte ermöglichen» oder einen halbautomatischen Offertprozess für teilstandardisierte Dienstleistungen. Dieses Konzept ist das Konzept der Headless Technology.
Das Frontend vollständig vom Backend abstrahieren
Die «kopflose» Technologie verfolgt die vollständige Entkopplung der eigentlichen Businesslogik von der Bedienoberfläche, die wir Nerds Frontend oder GUI nennen. Damit erhalten wir faktisch alle gestalterischen Freiheitsgrade, um über Kombination und Rekombination der Backendmöglichkeiten ein individuelles Anfühlen zu erzeugen. Völlig individuelle Teile der Businesslogik muss ich dann als Käufer dieser Lösungsform selbstredend wieder selbst bezahlen. Aber ich habe beim Upgrade der Komponenten kein Pappmaché-Problem. «Technisch nicht möglich» gibt es nicht mehr.
Alle Komponenten eines headless Backends lassen sich durch ihre Unabhängigkeit vom Frontend auch in anderen Kanälen oder auf anderen Devices wiederverwenden, so auf dem Mobile oder Tablet, in Apps oder IoT-Anwendungen. Der Omnichannel wird erreichbar und die Differenzierung an der Kundenschnittstelle möglich.
Aber auch hier steckt der Teufel im Detail was die Differenzierung an der Kundenschnittstelle angeht
Magento, das als Headless-Shop bereits unterwegs ist, schöpft die Freiheitsgrade bisher nicht aus, da viele Magento-Plug-Ins wegen fehlender APIs nicht verwendet werden können, wenn nicht im Standard- sondern im kundenspezifischen Modus implementiert wird.
Der unchained-Shop hingegen lebt das Ideal der vollständigen Flexibilität und ist auch noch echt swiss-made. Über unsere erste Erfahrung mit dem unchained-Shop berichte ich beim nächsten Mal. Wer nichts verpassen will, sollte sich direkt mit mir vernetzen. Freiheit dem Frontend!
