Aktuelle Themen im E-Commerce verweisen auf den Einsatz von Recommendation-Systemen:

• Produktkataloge werden immer umfangreicher. Kunden benötigen Hilfestellungen, um sich in ihnen zurechtzufinden.
• Methoden zur automatischen Segmentierung von Benutzern, und einer darauf aufbauenden individuellen Angebotspräsentation sind inzwischen allgemein bekannt und verfügbar. Auf solche Empfehlungsalgorithmen zu verzichten, bedeutet einen Wettbewerbsnachteil.
• Konkurrenzdruck führt zu sinkenden Margen. Ein immer individuelleres, zielgenaueres Upselling und die positive Emotionalisierung des Einkaufserlebnisses rücken in den Mittelpunkt der Shopkonzeption.

Am Markt haben sich Standardprodukte und -lösungen etabliert. Je nach betrachtetem Produkt und dessen Reifegrad zeigen sich folgende Nachteile:

• Fertige Produkte bzw. Software-as-a-Service-Lösungen bieten meist nur item-based Recommendations.
• Die Anpassungsfähigkeit und Ausbauoptionen sind begrenzt.
• Gleiches gilt für die Kombination mehrerer Recommender-Algorithmen, z.B. für user- 
und content-based Recommender.
• Es fallen erhebliche Lizenzkosten an.
• Die Auslagerung der Recommendation-Logik bedeutet eine Abhängigkeit vom 
betreffenden Anbieter.

Als Alternative bietet sich eine Individuallösung auf Basis von Open-Source-Technologien wie Apache Hadoop, Apache Mahout und Apache Solr an. Im folgenden Teil wird skizziert, wie das Big Data Analytics Team ein solches Projekt bestreitet.

Vorgehen

Das Einsatzgebiet von Recommendation-Engines ist sehr weitreichend. Neben dem E-Commerce gibt es bereits erfolgreiche Anwendungsszenarien z.B. im Online-Advertising, in der Finanz- und Versicherungsbranche und in der Partnervermittlung. Solche Systeme basieren immer auf spezifischen, kontextabhängigen Daten und werden individuell für ihren Einsatzweck ausgelegt. Es gibt also keine allgemeingültigen Empfehlungssysteme, die Gemeinsamkeit solcher Projekte liegt vielmehr in ihrem explorativen Ansatz, der auf die folgenden Meilensteine abzielt:

• Use Case Discovery: Formulierung von Anwendungsfällen, Prüfung auf Relevanz, Bestätigung oder Widerlegung der praktischen Machbarkeit
• Validierung der Datenbasis: Sicherstellung der Verfügbarkeit und Eignung der zugrundegelegten Rohdaten

Erst nach der Abstimmung dieser Eckpunkte mit allen Stakeholdern lohnt sich eine Investition in die Umsetzung einzelner Features. Hier empfiehlt sich der Einsatz agiler Methoden wie Scrum oder Kanban, zur Sicherstellung der folgenden Vorteile:

• Schnelle Bewältigung von Unsicherheit: Agile Entwicklungsmethoden ermöglichen dem Entwicklerteam, in kurzer Zeit eine Vielzahl von Algorithmen und Konfigurationsvarianten durchzutesten.
• Laufende Qualitätssteigerung: Ein Vorgehen in Iterationen sichert die laufende Erkennung und sofortige Nutzbarmachung von Erkenntnissen, sobald sie während der Entwicklung entstehen.
• Laufende Performanceoptimierung: Dass sich eine einmal programmierte Funktion beliebig skalieren lässt, ist eher die Ausnahme als die Regel. Scrum integriert die Notwendigkeit des Reengineerings, und verhindert so grössere Relaunch-Projekte.

Exemplarischer Projektplan

Validierung der Datenbasis

Das Data Engineering Team von YMC leistet in diesem ersten Schritt:

• Identifizierung von Zieldaten,
• Bestandsaufnahme von Datenquellen und aktuellen Workflows, auch hinsichtlich Drittsysteme,
• Identifizierung der wichtigsten Stakeholder, sowie deren Zusammenhang zu vorhandenen Ressourcen und Projekten sowie
• Evaluation und Auswahl von Hadoop-verwandten Technologien, einschließlich Sprachen, Clustering-Algorithmen und Recommendation-Systemen

und verfolgt damit folgende Ziele:

• Sichtung der verfügbaren Datenbestände,
• Validierung der Datenbestände aus technischer Sicht,
• Entwicklung eines “Big Picture” zur Identifizierung werthaltiger Auswertungschancen,
• Konzeption zusätzlicher Datenerhebungen (User-Tracking und -Profiling) und
• Konzeption und Abstimmung der funktionalen Umsetzung.

Abschliessend wird diese Phase schriftlich dokumentiert, wobei Antworten auf die vorgenannten Zielsetzungen enthalten sind und die Projektstrategie aktualisiert und detailliert wird. Je nach Art und Umfang der Ausgangsdaten planen wir hier einen Zeitraum von 1-3 Wochen ein.

Im nächsten Schritt werden Modelle im “supervised learning”-Modus entwickelt. Mehr dazu können Sie im kommenden Beitrag erfahren.

Stehen Sie vor der Herausforderung ein Empfehlungssystem einzuführen oder zu konzipieren? Dann wird Ihnen dieser Beitrag sicher helfen. Alle weiteren Details erläutere ich Ihnen gern persöhnlich.

Unter dem Motto “Mit Agilität zuversichtlich in die Zukunft” fand letzten Freitag die mittlerweile fünfte Ausgabe der Lean, Agile & Scrum (LAS) in Zürich statt. Unter den Teilnehmern waren vorwiegend Einzelpersonen und Organisationen, die die Schweizer Lean/Agile Community aktiv mitgestalten – also auch YMC. Und ganz im Sinne von Mitgestaltung äussere ich hier meine persönlichen Gedanken zur LAS…

Starpotential: Kanban

Auf der LAS 2013 hat sich erneut mein Eindruck bestätigt, dass Kanban speziell gegenüber Scrum zunehmend an Popularität gewinnt. Obwohl beide Ansätze als Vorgehensmodelle nur schwer direkt miteinander vergleichbar sind (Framework vs. Tool) bzw. komplementär zueinander sind (Scrumban), treten sie in der Praxis oftmals in Konkurrenz zueinander. Gerade in Organisationen, in denen Scrum(but) bereits implementiert ist, besteht oftmals der Wille, für Folge- oder Teilprojekte zu Kanban zu “wechseln”. Nachdem ich diese Beobachtung bereits durch meine persönliche Projekterfahrung und dem Feedback aus der Swiss Limited WIP Society machen konnte, haben mir die Kanba(h)n Success Story bei der SBB von Michael Beyer und Siegfried “Siggi” Kaltenecker, sowie der Talk von Michael Rumpler über “Continuous Flow vs. Timeboxes” die möglichen Gründe hierfür aufgezeigt:

Es ist nicht nur der Umstand, dass Kanban mit nur 3 Praktiken “leichtgewichtiger” daherkommt als Scrum mit seinen 3 Rollen, 5 Events und >3 Artefakten (siehe auch Henrik Knibergs Kanban and Scrum – making the most of both). Es ist vielmehr auch die bessere Praxistauglichkeit von Kanban, eine Organisation zur agilen Organisation zu transformieren: Kanban kann leichter schrittweise um agile Praktiken erweitert werden. Im Extremfall kann das schlussendlich sogar (wieder) hin zu Scrum führen. In diesem Fall geschieht das dann aber “emergent” im Rahmen von Kaizenund nicht strategisch geplant.

Grossartig: Networking-Möglichkeiten

Bei Konferenzen im Allgemeinen sind die Möglichkeiten Networking zu betreiben mindestens so interessant wie die Sessions an sich. Für eine Konferenz zum Thema Lean/Agile gilt das um so mehr. Schliesslich treffen hier Menschen zusammen, die im Entwicklungsprozess die unterschiedlichsten Rollen ausfüllen und sich sonst eher selten über den Weg laufen. Das hat sich bei der LAS 2013 erfreulicherweise auch in der Konferenzagenda widergespiegelt. Neben fünf parallelen Tracks mit jeweils einem thematischen Fokus (Scrum, Leadership, Lean Innovation, Methoden & Tools, Kanban) hatten selbst die beiden Keynotes der Konferenz grundverschiedene Zielgruppen: Während die erste Keynote (Erik Dörnenburg: “Architektur ohne Architekten”) ein Thema mit starkem Engineering-Bezug aufgriff, hatte die zweite Keynote (David Snowden: “Making Sense of complexity”) das Cynefin-Framework und komplexe adaptive Systeme zum Thema.

Auch organisatorisch hat der Konferenzveranstalter, die Fachgruppe Lean, Agile, Scrum der SwissICT, seine Hausaufgaben gemacht: Neben grosszügigen Pausen zwischen den Sessions gab es im Anschluss der Konferenz einen Apéro, so dass genug Zeit und Gelegenheit blieb, mit dem ein oder anderen Konferenzbesucher oder Speaker Diskussionen aus den Sessions fortzusetzen oder einfach nur etwas aus dem agilen Tagesgeschäft zu plaudern.

An die Organisatoren der LAS in Zürich – Vielen Dank. Alles hat gepasst. Die erste Konferenz auf der es ununterbrochen Espresso gab:) #laszh

— Boris Gloger (@borisgloger) September 6, 2013

Vermisst: #NoEstimates

Wenn es in der Lean/Agile Community derzeit einen Trend gibt, dann gehört die #NoEstimates-Bewegung sicherlich dazu:

By estimating, rather than fixing, cost we have no greater insight into the value, which is also estimated. Essentially we are increasing our risk by estimating both cost and value rather than just value, which is what #NoEstimates promotes. – Neil Killick

Mein positiver Gesamteindruck von der LAS 2013 ist deshalb leicht getrübt, da es keine Session zu #NoEstimates gab, obwohl das Thema gar Keynote-würdig gewesen wäre. So muss ich mich auf das nächste Event zu diesem Thema vetrösten.