aboutDer erste Teil des Tech Interview mit dem Gründer und CTO von About You sprengt schon alle Podcast Rekorde bei Kassenzone. Wer hätte gedacht, dass Tech Themen mal so gefragt sind, aber die Antworten von Sebastian zur IT Organisation von AboutYou dürften den ein oder anderen Marktbegleiter neidisch gemacht haben. Im zweiten Teil des Interviews geht es nun darum herauszufinden wie ein Tech Unternehmen mit den ständig wechselnden Marktanforderungen bei der „Shopentwicklung“ umgeht. Insbesondere die gängige Fragestellung zu responsive vs. mobilen Seitenvarianten beantwortet Sebastian sehr schlüssig. AboutYou betrachtet (analog zu Spryker) die einzelnen Frontends quasi wie separate Applikationen auf einem gemeinsamen Betriebssystem. Mit jeweils eigenen Teams und Roadmaps.

Das macht auch sehr viel Sinn, wenn man darüber nachdenkt. Mobile Anwendungscases decken sich oft gar nicht mit den Desktopcases. Etwas weitergedacht kann man sich noch viel mehr „Apps“ vorstellen, die AboutYou in diesem Umfeld auf das Backend aufbauen kann.  Sebastian spricht auf der bereits fast ausverkauften Code.Talks Commerce Conference in Berlin Ende April über diese Learnings. Die Conference richtet sich an Developer und Leute im E-Commerce die mit der Produktentwicklung zu tun haben. Mit dem Code „Kassenzone-ctcs-10“ sind die Tickets etwas günstiger zu haben. Viel Spass beim Interview.

Mit dem Laden des Videos akzeptierst du ab jetzt die Datenschutzbestimmungen von YouTube. Mehr erfahren

Inhalt laden
PHA+PGlmcmFtZSBzcmM9Imh0dHBzOi8vd3d3LnlvdXR1YmUtbm9jb29raWUuY29tL2VtYmVkL2FobkJrd1o4SkJnIiB3aWR0aD0iMTAwJSIgaGVpZ2h0PSIzMTUiIGZyYW1lYm9yZGVyPSIwIiBhbGxvd2Z1bGxzY3JlZW49ImFsbG93ZnVsbHNjcmVlbiI+PC9pZnJhbWU+PC9wPg==

Mit dem Laden des Inhalts akzeptierst du ab jetzt die Datenschutzbestimmungen von Soundcloud. Mehr erfahren

Inhalt laden
PHA+PGlmcmFtZSBzcmM9Imh0dHBzOi8vdy5zb3VuZGNsb3VkLmNvbS9wbGF5ZXIvP3VybD1odHRwcyUzQS8vYXBpLnNvdW5kY2xvdWQuY29tL3RyYWNrcy8zMTYwMTU0OTkmYW1wO2NvbG9yPWZmNTUwMCZhbXA7YXV0b19wbGF5PWZhbHNlJmFtcDtoaWRlX3JlbGF0ZWQ9ZmFsc2UmYW1wO3Nob3dfY29tbWVudHM9dHJ1ZSZhbXA7c2hvd191c2VyPXRydWUmYW1wO3Nob3dfcmVwb3N0cz1mYWxzZSIgd2lkdGg9IjEwMCUiIGhlaWdodD0iMTY2IiBmcmFtZWJvcmRlcj0ibm8iIHNjcm9sbGluZz0ibm8iPjwvaWZyYW1lPjwvcD4=

Die Kassenzone Interviews sind verfügbar bei:
Soundcloud, iTunes, Youtube, Facebook oder per RSS-Feed


PODCAST & Interview Transkription – für alle Leser, die Audio & Video nicht so gerne konsumieren. Die Transkription wird gesponsert von PAYBACK – hier mehr erfahren und App herunterladen.

Online-Technologie mit Sebastian Betz (Fortsetzung), AboutYou

Sebastian ist Geschäftsführer IT bei AboutYou. Im ersten Teil des Podcasts ging es um die Entwicklung des Unternehmens bis dato sowie darum, was es eigentlich heißt, ein „Tech-Unternehmen“ zu sein und wie man ein Shop-System in der Größenordnung von AboutYou konkret baut. In dieser Fortsetzung werden Fragen aus der WhatsApp User-Gruppe gestellt und Programmierungsansätze vertieft. Wer sich aus entwicklungstechnischer oder betriebswirtschaftlicher Sicht für Fragestellungen rund um Coding in Commerce besonders interessiert, ist zu den Code-Talks Commerce Special am 27.04-28.04 in Berlin eingeladen.

 

 

„Es gibt nicht nicht den einen Feature – und dann ist alles personalisiert!“

Alex fasst die aus dem ersten Teil des Podcasts hervorgegangenen Prinzipien von AboutYou zusammen: Lieber effizienzhalber ein einzelner Standort als mehrere; klare Zuständigkeiten mit vielen kleinen Teams, die möglichst schnell konkrete Ergebnisse erzielen und flexibel zugeschnitten werden können; idealerweise immer nur eine Programmiersprache als Entwicklungsumgebung; und die stetige Bereitschaft, alles neu zu bauen.

4:00

Sebastian: Nur zum Verständnis nach dem letzten Podcast: Wir versuchen zwar schon, die Zahl der verwendeten Programmiersprachen gering zu halten, begrenzen uns aber nicht komplett auf PHP – vor allem im Frontend würde das ja gar nicht richtig gehen, da benutzen wir Java & Co.. Aber generell versuchen wir für jeden größeren Themenkomplex eine einheitliche Sprache zu nehmen.

Alex: Ebenfalls im letzten Podcast haben wir angesprochen, dass von euren 300 Mitarbeitern nicht nur 100 bei dir in der IT programmieren, sondern dass auch in den anderen Bereichen Marketing und Operations Tech-Leute sitzen. So haben schon weitaus mehr als 100 Mitarbeitern bei euch irgendetwas mit Code zu tun, oder?

Sebastian: Insgesamt sind es eher 130-140, die mit Code oder mit IT-Projektmanagement was zu tun haben.

(Alex fragt Sebastian, wie sich seine Erfahrungen in der Aufbauphase mit den vom Spryker CTO Fabian Wesner decken – und ob er es sich hätte vorstellen können, AboutYou mit Spryker aufzubauen, wenn es damals Spryker schon gegeben hätte. Sebastian sagt, das Modulare an Spryker hätte das Konzept schon für einen Anfang interessant gemacht. Generell baue AboutYou aber auf Eigenentwicklung auf.)

6:50

Alex: Erste WhatsApp-Frage also: Wo hostet ihr?

Sebastian: Tatsächlich noch bei einem kleineren Hoster, bei dem die Infrastruktur fast komplett virtualisiert ist. Wir sind aber gerade dabei, zu AWS zu migrieren, weil die Vorteile da überwiegen. Die Möglichkeiten zu skalieren sind zahlreich: Load-Balance ist einfach einzusetzen, die Applikationen kann man schnell rausbringen, und es gibt sehr viele Optionen für die klassischen Stack-Themen. So muss man sich weniger mit den operativen Aufgaben der Infrastruktur beschäftigen.

Alex: Macht ihr Managed-Hosting oder geht ihr direkt an AWS ran?

Sebastian: Wir behalten das in house – auch die komplette Migration. Das ist uns ja extrem wichtig: Die Freiheit, immer die Lösungen zu benutzen, die wir richtig halten in jedem Use Case. Deswegen brauchen wir solche Kompetenzen intern.

Alex: Wie viele arbeiten gerade im DevOps? Und ab wann braucht ein E-Commerce-Projekt ein eigenes Team dafür?

Sebastian: Aktuell sind es bei uns 12. Und brauchen tut man das fast vom Start an. Letztendlich ist das Teil der Wertschöpfungskette: Nach der Entwicklung kommt ja die Frage, wie du das Ganze live bringst? Du kannst Prozesse definieren, die dir dann helfen, deine Software schnell rauszubringen und schnell Fehler zu finden. Wer das also als Teil der Wertschöpfungs- beziehungsweise Entwicklungskette ausgemacht hat, braucht mindestens einen DevOp, vielleicht sogar zwei, vom Anbeginn an.

Alex: Dazu gibt es zwar verschiedene Einschätzungen, aber – geschenkt – ab einer gewissen Größe muss man es auf jeden Fall selber können. Und wer das nicht in house macht, hat quasi ein zweites Team an einem anderen Standort sitzen – was ja eurer Theorie und Praxis widerspricht, alles selber in der Hand haben zu wollen. Vor allem ist es ja der Faktor Zeit.

Sebastian: Dazu muss man auch noch sagen, dass das, was sich in der DevOp-Tooling-Welt in den letzten 12-24 Monaten getan hat, beeindruckend ist. Es gibt jetzt so viele Optionen, wie man Teile des Prozesses automatisieren kann. So hat man heutzutage schnell einen Stack aufgesetzt, der den DevOps dabei hilft, Dinge zu warten, ohne sich in den Server einloggen zu müssen und manuell da Sachen ändern zu müssen. Das Team kann so mehrere Hundert Server warten – mit drei Personen.

10:20

Alex: Eine weitere Frage aus der WhatsApp-Gruppe: Kann aus eurer Lernkurve und eurem System ein Produkt gemacht werden? Also das, was wir mit Spryker gemacht haben: Aus Hundert großen E-Commerce-Projekten wissen wir, wie Code auszusehen hat. Dieses Wissen verkaufen wir eigentlich. Dokumentation, Ökosystem, Partner… Kommt alles, weil wir diese Lernkurve hinter uns haben. Könntet ihr euren Shop quasi als Produkt anbieten?

Sebastian: Definitiv. Unser Frontend würde sich zwar nicht dafür eignen, aber die dahinterliegenden Systeme schon.

Alex: Das würde erfahrene Unternehmen ansprechen, die nicht so sehr auf diese AFI-Prozesse angewiesen sind und ein Shopsystem brauchen, das gut SEO kann. Diejenigen, die noch in AFI gefangen sind und beim Kauf eines Shopsystems das Frontend bewerten, wären eher nicht dafür zu haben…

11:35

Alex: Dann wollen wir uns der Frage nähern: Was macht eigentlich einen guten Onlineshop aus? Heute ist das Thema Mobil schon viel wichtiger als Desktop. Hattet ihr schon eine native mobile Applikation, als ihr gestartet seid?

Sebastian: Ja, aber sie wurde sehr stiefmütterlich behandelt. Der Fokus lag damals in allen Bereichen auf Desktop. Er war im Testen auch immer der Treiber. Das hat sich aber in den letzten Jahren – vor allem in den letzten Monaten – geändert.

Alex: Und gab es eine Version des Desktops für Mobile?

Sebastian: Nein, wir waren nie responsive, sondern haben immer für die einzeln Devices dezidiert entwickelt.

Alex: Heute gibt es viel Diskussion: Mobile First vs. Mobile Only, hybride App vs. native App. Diese Art von Diskussion hattet ihr bestimmt auch intern, nachdem das Ding erst einmal auf Desktop lief: „Responsive ist viel besser im Tracken der User Journey über viele Sessions hinweg.“ „Nee, alleine die Sessions zu synchronisieren, ist viel zu schwierig…“

Sebastian: In der Tat hatten wir relativ wenig solche Debatten, was aber damit einhergeht, dass wir vom Anfang an die Architektur so aufgebaut haben, dass wir diese Tracking-Thema schon gelöst hatten. Wir konnten vom Anfang an – solange das sinnvoll war – Warenkörbe teilen und ein einheitliches Einkaufserlebnis über alle Endgeräte hinweg anbieten.

Zudem hatten wir für uns raus, dass viele Tests (A-B & Co.) je nach Device sehr unterschiedlich laufen. Mit Responsive kann es sein, dass etwas auf dem Desktop gut läuft, aber auf Mobile so gar nicht funktioniert. Schnell stellten wir fest, dass die Leute anders auf Desktop als auf Mobile surfen. So war für uns klar: Wir brauchen eine Prio-Liste und wir entwickeln dann ein Produkt pro Device. So können wir jetzt alle paar Wochen sagen: Dies möchten wir auf Desktop, das auf Mobile umsetzen, ohne dass das gegeneinander priorisiert werden muss.

15:00

Alex: Ihr habt ja eine krasse App auf iOS und Android, aber wie geht ihr damit um, wenn jemand auf einem Smartphone euch ansurft?

Sebastian: Wir erkennen, dass das ein mobiles Gerät ist und leiten ihn auf m.aboutyou um. Das ist eine eigenständige Applikation, die auf Mobile fokussiert ist. Das Produkt hat ein eigenes Team. Dabei sind wir aufgeteilt in zwei Domänen: Desktop und Mobile. Unterhalb letzterer Domäne haben wir zwei Teams: Einmal für die mobile Website und einmal für die mobile App. So haben wir zur Zeit drei verschiedene Priolisten mit unterschiedlichen Aktivitäten: Wenn etwas bei der mobilen App gut funktioniert, versuchen wir es allerdings auf die mobile Site und eventuell auf den Desktop zu übertragen. Aber in erste Linie verläuft die Entwicklung der drei Produkte schon sehr separat.

(Sebastian zufolge ergibt es Sinn, Desktop und Mobile vom Anfang an getrennt zu behandeln, um auf die unterschiedlichen Kundenbedürfnisse in den zwei Bereichen eingehen zu können. Zudem: Derzeit ähneln sich zwar die mobile Website und die mobile App, aber auch hier wird sich in den kommenden Monaten vieles ändern, weil die Kunden anders in der App integriert sind als in der mobilen Seite. Erstere haben sie schließlich bewusst heruntergeladen. Auf Letztere kommen sie eher zufällig nach einer Google-Suche im mobilen Browser rein.

Alex wendet ein, dass diese Überlegungen für viele eine Ressourcen-Frage darstellen: Einige Neugründungen müssten einem Mobile-First-Ansatz folgen, weil Mobile inzwischen der größte Use-Case sei und überschüssige Kapazitäten für Desktop hätten sie nicht. Diese Umschichtung sehe man bei AboutYou in den Umsätzen, stimmt Sebastian zu: Der Mobile-Anteil liege schon bei 50-60% . Aber selbst wenn Wachstum vorwiegend daher käme, seien die Kunden nicht nur auf einem Device unterwegs. Wer allerdings sehr begrenzte Ressourcen habe, solle schon eher Mobile priorisieren.)

20:00

Alex: Wir führt ihr die Daten für BI und Analytics aus euren drei Schnittstellen zusammen? Ist das schwierig? Muss das vom vornherein in der Architektur berücksichtigt sein?

Sebastian: Das kann man schon nachziehen: Tracking & Co. ist erst einmal separat von der Infrastruktur. Was wir gelernt haben: Es ist extrem wichtig, diese gesamte Customer Journey zu erfassen. So können wir sehen, welche User auf Desktop und auf Mobile unterwegs sind, worin sie sich unterscheiden. Das haben wir in den letzten Jahren stark ausgebaut.

Alex: Ich frage deshalb, weil man meiner Erfahrung nach im Nachgang Probleme mit Attributionsmodellen hat: Wenn die Daten nicht extrem sauber sind, kann man die Kundengewinnungskosten nicht richtig zurechnen. Das führt dann zu pauschalen Entscheidungen à la: „Affiliate-Marketing funktioniert doch gar nicht, nehmen wir mal einfach raus!“ Obwohl man es gar nicht richtig beurteilen kann. Man hat diese 50 Blogs im Netzwerk und weiß nicht, ob sie Traffic und Käufe verursachen oder nicht. Wenn man nicht tief genug gehen kann, um zu sagen: Derjenige, der sich von dieser Seite zu uns geklickt hat, hat auch die App…

Sebastian: …wobei man sagen muss: Wenn man schon größere Marketing-Budgets in die Hand nimmt, dann sollte man schon in der Lage sein, genau diese Auswertung zu machen und sollte Attributionsmodelle aufgesetzt haben. Egal zu welchem Zeitpunkt man es macht – ob direkt am Anfang oder nachgezogen – sollte man es vor solchen Kampagnen haben.

(Daraufhin will Alex wissen, welche Features und Bereiche bei AboutYou den größten Aufwand verursachen. Mit wachsendem Produktbestand sei beispielsweise selbst bei Amazon die Suche irgendwann ein Problem. Gerade im Modebereich, antwortet Sebastian, komme die typische, rein semantische Suche schnell an ihre Grenzen. Dabei gehe die Bedeutung der Suche zurück; Navigation durch die Kategorien komme wieder zum Zuge. Sebastian fügt hinzu, dass Tracking-Daten auch noch helfen, eine bessere Suche zu bauen.

Technisch aufwändig seien, so Sebastian, ebenfalls die Backend-Prozesse: Die Echtzeitaussteuerung von Verfügbarkeit etwa verschlinge viele Entwicklungsstunden – zumal die Komplexität durch die wachsande Zahl an Lieferanten, Lagern usw. zugenommen habe. Daraufhin will Alex wissen, wie genau das bei AboutYou gehandhabt wird. Sebastian beschreibt die Architektur und die Prozesse der Produktverfügbarkeit-Maschine.)

29:00

Alex: Abgesehen von dieser Echtzeit-Anpassung würde ich gern einen zweiten entscheidenden Hebel mit dir besprechen: Die Personalisierung. Davon seid ihr ja prominente Vertreter. Im Idealfall kriegt jeder Kunde auf Basis seiner Historie ein superindividuelles Angebot: „About Sebastian“ wird sich von als „About Alex“ wohl merklich unterscheiden. Wie schwer ist es, das hinzukriegen?

Sebastian: Wenn man das für jeden User anbieten will, egal wie er zur Seite kommt und woher, dann ist das extrem schwer – fast unmöglich. Wenn man aber eher guckt, was man schnell erreichen kann – Tarek sagt, wir sind so ungefähr bei 10% dessen, was möglich ist – und stets aus Kundenperspektive da herangeht, ist vieles lösbar. Man geht eben anders vor bei Leuten, die man schon kennt und von denen man eine Kundehistorie hat. Es bedeutet aber eben viel Arbeit – und diese Arbeit ist nie zu Ende. Es gibt nicht den einen Feature – und dann ist alles personalisiert! Alles muss man auf User-Gruppen runterbrechen und stark testen: Hat es einen Mehrwert für den Endkunden?

(Alex vergleicht personalisiertes Einkaufen mit dem individuellen Facebook-Feed und gibt zu Protokoll, dass er es gern ausschalten können würde, weil Seiten immer wieder anders aussehen: Verklicke man sich und navigiere man zurück, sei die Seite, wie sie war, schon weg. Danach spricht er das Kaltstart-Problem sowie den Themenkomplex „Einzelnes Userprofil, mehrere Konsumenten“ an: Was sind hier die technischen Möglichkeiten? Sebastian empfiehlt nochmals, Erwartungen herunterzuschrauben und in der Personalisierung stets darauf bedacht zu sein, was einzeln operationell umzusetzen sei.

Beispiel: Die T-Shirt-Größe eines Kunden auf das ganze Sortiment zu übertragen, sei arbeitsintensiv bis unmöglich. Die Größen variierten einfach zu stark von Marke zu Marke und zwischen Kleidungskategorien. Informationen über Äquivalenzen zwischen Marken und Größen könne man zwar kaufen oder selber aufbereiten, aber die Anwendung in der Personalisierung sei sehr komplex.)

38:30

Alex: Ist ja interessant: Ihr seid zwar, gemessen am Markt, in der Personalisierung sehr weit vorne. Ihr sagt aber, ihr seiet erst am Anfang dessen, was möglich ist. Dabei habt ihr den ganzen Tech-Stack selber unter Kontrolle. Ich glaube, dass Personalisierung zukünftig mehr bringen wird als, sagen wir mal: die Verdoppelung des Sortimentes.

Sebastian: Da glauben auch wir sehr stark daran, vor allem unter dem Aspekt Mobile. Der User hat am Smartphone einen viel begrenzteren Bildschirm: Da können wir der Kundin keine 15.000 Kleider zumuten, so nach dem Motto: „Such dir was aus!“ Vielmehr muss die Treffsicherheit der ersten 40-50 Produkte für die Kundin so hoch sein, dass sie auf Anhieb sagt: „Cooler Shop – und das Kleid interessiert mich.“ Sonst haben wir die schon verloren.

Dabei muss man sich gedanklich von einzelnen Devices lösen. Die Personalisierung muss sich auf allen Touchpoints wiederspiegeln. Man muss im CM-System in der Lage sein, genau dann den Trigger an den Kunden rauszuschicken, wenn er wirklich Bedarf hat – oder man meint, einen Bedarf durch eine sehr persönliche Empfehlung erwecken zu können. Perspektivisch ist das übertragbar auf viele andere Kanäle: Von Push-Benachrichtigungen bis On-Site-Events wird vieles kommen. Das wird allerdings die Komplexität noch einmal erhöhen.

Alex: Das macht mir in vielen Segmenten Hoffnung, dass man doch noch gegen Amazon bestehen kann. Wenn man sich um eine Produktkategorie oder eine Zielgruppe kümmert, kann man in der Personalisierung eine ganze Menge rausholen.

Andere Frage: Ist euer Open-Commerce-Ansatz eurem Mobile-Fokus zum Opfer gefallen? Macht es der begrenzte Platz auf einem mobilen Bildschirm nämlich schwierig, Dritten den Zugang zu ermöglichen.

Sebastian: Was wir gelernt haben: Wenn man seine komplette Infrastruktur öffnet, jedermann Anwendungen schreiben lässt – und dann möglicherweise versuchen muss, den Kunden von der App in die mobile Webwelt hineinzuziehen und dann zurück in den Shop zu bekommen – kommt einfach kein cooles Kundenerlebnis dabei raus.

Daher ist es sinnvoller, den Kunden auf AboutYou halten zu wollen, statt ihn in drei oder vier verschiedene Sub-Apps weiterzuleiten. Dabei bauen wir ein AboutYou-Kosmos auf, mit der Möglichkeit, eigenen Content und eigene Inspiration beizutragen. Das versuchen wir mit der Profil-Logik zu erreichen: Dass die Leute beispielsweise ihre Outfits reinstellen. Aber die Integration der ganzen externen Applikationen ist aus Kundensicht zu schwierig. Auch andere merken das: Mittlerweile ist auch auf Facebook so, dass du, wenn du auf einen Link klickst, auch nicht mehr stark hinausgeleitet wirst. Auch bei Google mit A&P kommst du dann auch nicht wirklich weg von Google. So sieht man, wie sinnvoll es ist, den Kunden innerhalb seines Ökosystems bei der Brand zu halten.

(Alex spricht Sebastian auf die zahlreichen Awards an, mit denen AboutYou ausgezeichnet worden ist. Er will wissen, ob sie es darauf abzielen, so viele zu gewinnen. Sebastian antwortet, dass sich die Entwicklung zwar immer kundenzentriert und nach funktionalen Features ausrichte, dass Details aber auch wichtig seien.

Daraufhin fragt Alex, ob sie nur noch optimiert wird, oder ob ein neuer, großer Wurf denkbar ist. Das sei, erwidert Sebastian, eine gute Frage – und eine, mit der er sich auch beschäftige. KPI-orientierte Produktoptimierung sei wichtig. Aber man dürfe nicht den Blick dafür verlieren, was an der Infrastruktur des Produktes geändert werden könnte. Neue Entwürfe für ganze Elemente müsse man dann bauen und testen. Der Status Quo sei immer zu hinterfragen.)

46:50

Alex: Habt ihr eigentlich noch aus eurer „Love-Brand“ Edited noch einen Nutzen, oder lernt ihr das meiste jetzt von AboutYou?

Sebastian: Das ist sehr bereichabhängig. Beim Thema Eigenmarken können wir für AboutYou extrem viel von Edited lernen. Beim Tech ist das Lernpotenzial eher beschränkt, weil es sich um einen ganz anderen Use Case handelt. Edited und AboutYou teilen ja die Backend-Prozesse, aber das Frontend von Edited ist ein eigener Tech-Stack. Da haben wir die Möglichkeit, Sachen auszuprobieren. So haben wir beispielsweise das Shop-Frontend und dann die Mobile-App von Edited mit React Native geschrieben. Wir konnten das auf einer kleineren Besucherzahl validieren und lernen, wie so Sachen wie Tracking in so einem React-Stack funktionieren.

Alex: Und? Wir AboutYou jetzt in React gebaut?

Sebastian: Ja. Weil wir merken, dass das ein sehr gutes Frontend-Framework ist.

(Sebastian geht dann detailliert auf die – vor allem serverseitigen – Vorzüge von React ein. Andere am Markt würden auch eine ähnliche Entwicklung durchlaufen, um gerade im mobilen Anwendungsfall an Schnelligkeit zu gewinnen.)

51:30

Alex: Ich habe noch Fragen zum PIM und zum CRM. Zuerst: Ist das Produkt-Informationsmanagement bei euch eine diskrete Applikation und immer noch Teil des Backend-Stacks bei euch?

Sebastian: Ja, das haben wir komplett selber gebaut. Das ist mit Themen wie Produktverfügbarkeit sehr stark verwandt und ist uns daher wichtig, weil wir sehr komplexe Logistik-Prozesse haben. Das ist alles eigentlich in einem System bei uns: Wir haben nicht mehr ein Produkt, das aus einem Lager kommt. Wir greifen zum Teil auf das Otto-Lager zurück und auf Produkte von Otto-Group-Firmen. Dazu haben wir unsere eigene Ware im Lager und zudem noch Versandpartner. Mittlerweile bekommen wir Produkte von verschiedenen Logistik-Strängen und normalisieren sie bei uns. Eine externe Lösung wäre da sicherlich aufwendiger als die Eigenentwicklung gewesen.

Alex: Und verhält es sich beim CRM genauso?

Sebastian: Da sind wir mit einer gängigen Marktlösung gestartet, sind aber letztens dazu übergegangen, das selber zu bauen. Wir haben gemerkt, wie wichtig es ist, wirklich alle Daten, die man vom Kunden irgendwie bekommt, standardisiert reinspeisen zu können. Es soll doch kein diskretes E-Mail-Marketing-Tool und dann noch ein App-Marketing-Tool usw. geben. Im CRM sollte man eine einzige Kundensicht abgebildet haben, aus der man Aktivitäten über alle Kanäle – von Online-Marketing bis zur Postwurfsendung – steuern kann. Mit so einem System kann man dann auch im Logistik-Prozess eingreifen: Welcher Flyer soll in welchem Paket bei welchem Kunden liegen? Wir sind damit erst vor einem Monat in einem geringen Umfang gestartet, aber perspektivisch werden wir dort alle Kundeninformation haben und werden selber bei jedem Touchpoint festlegen können, wie und was genau wir kommunizieren.

Alex: Also: Alles, was mit dem Kunden in Kontakt kommt, habt ihr selber in der Hand. Aber Lagerverwaltung und ähnliches baut ihr nicht selber?

Sebastian: Solange wir mit der Lagerverwaltung zufrieden sind, bauen wir sie nicht selber! (Allerdings sind wir gerade sehr zufrieden.)

Der Podcast wird mit Informationen zu den Code-Talks Commerce Special am 27.04-28.04 in Berlin sowie ein Hinweis auf offene Stellen bei Spryker abgeschlossen.

Neue Beiträge per E-Mail abonnieren.

Deine Anmeldung konnte nicht gespeichert werden. Bitte versuche es erneut.
Danke! Bestätige deine Anmeldung bitte in der Mail, die wir dir soeben geschickt haben.