Um den neuen Anforderungen an den Otto Online-Shop, insbesondere dem Zugang über Mobile, gerecht zu werden, wurde otto.de neu ausgerichtet. Dabei wurde der Shop hinsichtlich der Softwarearchitektur (Projekt "LHOTSE") sowie mit Unterstützung der Nexinto GmbH, Spezialist für maßgeschneiderte und leistungsfähige IT Sourcing Solutions, hinsichtlich des IT Betriebs (Systemarchitektur und IT Services) neu aufgestellt (Projekt "SHAR"). Outgesourct wurde damit erstmals der Infrastrukturbetrieb an einen hausexterner IT Dienstleister für Otto.de.
Der neue Shop bietet einen erhöhten Sicherheitsstandard, eine flexiblere IT-, Service- und Prozessarchitektur sowie eine verbesserte Leistungs- und Kostentransparenz. Zugleich läuft der Online-Shop stabiler und performanter. Weiter ist der Shop anpassungsfähiger an neue Gegebenheiten im Markt, so dass neue Funktionen schneller time to market in Betrieb genommen werden können.
Das Ergebnis der Bemühungen: Der neue Shops konnte in einem "fliegenden Wechsel" produktiv gesetzt werden - und zwar im ersten Versuch und in time. Der Relaunch der beliebten Shopping -Website Otto Online-Shop (Projekte LHOTSE & SHAR) ist der Beitrag von Nexinto GmbH und Otto eCommerce Solutions & Technology im Best in eCommerce Award in der Kategorie Bestes B2C-Shop-Projekt (oder Erfolgreichste Performance-Verbesserung (B2C) oder Bester Relaunch (B2B, B2C) oder Bester neuer Shop (B2B), (B2C)
Das Ausgangsszenario
Ausgangspunkt war das Bestreben von Otto, seinen Onlineshop otto.de schneller an Kundenwünsche und Marktanforderungen anzupassen. Die im Jahr 2011 erreichte Plattform deutete seinerzeit bereits an, dass sich das Marktumfeld verändert und agilere Prozesse gefordert waren, um den Anspruch der Kunden an die Plattform und von Otto an seine Handlungsfähigkeit auch weiterhin zu erfüllen.
Der Fachbereich eCommerce stellte also die Gretchenfrage an den Vorstand: "Weiter so" oder "Konsequente strategische Neuausrichtung"? Man entschied sich für die strategische Neuausrichtung.
Dazu wurden zwei ineinander verwobene Projekte, LHOTSE und SHAR initiiert. LHOTSE ist das führende, umfassende und strategischere Projekt, SHAR ist das operative und taktische Komplementär. In LHOTSE ging es für Otto darum, eine bestehende und monolithische Softwarearchitektur mit hoher Abhängigkeit von Drittfirmen durch eine schlanke, modulare Architektur abzulösen.
In Rahmen von SHAR wollte man einen geeigneten externen Partner für den Infrastrukturbetrieb zu finden. Neben der Infrastrukturkompetenz wurde von Anfang an darauf geachtet, dass dieser Partner auch eine IT-Betriebskompetenz sowie eCommerce Erfahrung mitbringt. Denn nur so konnte ein zielgerichtetes Betriebsmodell entwickelt werden, welches aus einer IT-On-Demand Infrastruktur einerseits und einem IT-Betriebsprozess-Modell andererseits besteht.
Die eCommerce-Lösung
Die Neuausrichtung wurde mit einer klaren "Vision", wie otto.de sein sollte und von welchen "Werten" es geprägt werden sollte, gestartet. Diese Vision wurde in ein strategisches Softwareentwicklungsprojekt mit konsequent agiler Methodik eingebracht.
Der neue Shop bietet eine lose gekoppelte JAVA-basierte Softwarearchitektur unter Nutzung von agilen Software-Entwicklungsmethoden. Basis ist eine dedizierten Private-Cloud-Lösung, die die nötige Flexibilität in der Bereitstellung von Ressourcen erzeugt und dabei eine gemeinsame End-to-End Security-Management-Architektur bietet.
In einem agilen Umfeld sind die Grenzen zwischen Projekt und Betrieb fließend, da das Gesamt-System kontinuierlich weiterentwickelt wird. So bestand der fachliche Fokus zum Jahreswechsel 2014/2015 neben anderen Themen primär in der Erweiterung des Webdesigns um eine "Responsive" Komponente, in der Endgerätespezifischer Content ausgeliefert wird. Damit wird beispielsweise die vollständige Integration des mobilen Shops m.otto.de in das System abgeschlossen.
Die e-Commerce Lösung ist auf die speziellen Kundenanforderungen in einem lang angelegten Projektrahmen umgesetzt worden. Die Lösung ist dediziert ausgelegt und setzt grundlegendes Verständnis der existierenden IT-Umgebung bzw. der Applikationslandschaft des Unternehmens voraus.
Die Nexinto Enterprise Cloud Lösung konnte daher nicht 1:1 genutzt werden. Aufgrund von sicherheitstechnischen Anforderungen seitens Otto musste eine dedizierte "Private Cloud"-Lösung geschaffen werden. Otto forderte eine erweiterte Desaster Recovery Lösung über zwei 30km getrennte Rechenzentren und spezifische erweiterte Betriebsprozesse im Rahmen von Incident Management, Problem Management, Availability Management, Capacity Managment und Notfallmanagement.
Die Hürden
Die besondere Herausforderung liegt in der Zusammenführung eines langlaufenden, agilen Softwareentwicklungsprojekts mit einer neuen Infrastruktur bei einem neuen Infrastrukturdienstleister.
Projektsteuerung
Die größte Herausforderung dabei bestand sicherlich in der Projektsteuerung. Dabei sollten alle Beteiligten eine gemeinsame Betriebsverantwortung übernehmen. Ein intensiver Austausch im Projekt- und Servicemanagement erwies sich dabei als sinnvoll und schaffte eine Atmosphäre gegenseitigen Vertrauens. "Breiter" zwischenmenschlicher Kontakt der operativ handelnden Personen verhinderte ein "Lagerdenken." Erhobene Daten wurden schnellstmöglich auf alle Partner verteilt und es wurde eine gemeinsame Toolbasis geschaffen.
Kapazitäts-Management
Die zweite große Herausforderung bestand im Management der Kapazitäten: Es standen nur begrenzte Geldmittel zur Verfügung. Zugleich war die Projektentwicklung jedoch sehr volatil. Per IT on Demand erreichte Otto, dass jederzeit eine kurzfristige Skalierung bzw. Schrumpfung möglich war. Zugleich musste der Dienstleister Überkapazitäten vorhalten. Der Dienstleister wurde zudem verpflichtet, Vorschläge zur Kostenoptimierung einzubringen. Insgesamt wurden die verfügbaren Ziel-Budgets allen transparent gemacht, um somit eine gewisse Budget-Disziplin zu erreichen.
Arbeitsprozesse
Auch die Herausforderung "Arbeitskultur" wurde in dem Projekt berücksichtigt. Bei der Zusammenarbeit von Teams unterschiedlicher Firmen entstehen oft Reibungsverluste, die das Gesamtprojekt massiv gefährden können.
Da starke Prozessen, die die Zusammenarbeit regulieren sollen, kein Garant für die Verminderung von Reibungsverlusten sind, ist man einen anderen Weg gegangen: Man hat nicht die Zusammenarbeit, sondern entstehende Konflikte versucht zu managen. Dazu hat man die Beteiligten interagieren lassen. Das schafft gegenseitiges Verständnis, erzeugt Vertrauen, bildet Gemeinschaft. Zugleich ist man auch mal ins Risiko gegangen und hat Strukturen bedarfsgerecht verändert.
Die vierte Herausforderung bestand in der schier unerschöpfliche Flut von ToDos, Aufgaben und Arbeitspaketen, die bei Projekten dieser Größenordnung eben entstehen. Ausuferndes Projektmanagement mit Meilensteinen und Quality Gates können die Folge sein. Um das zu verhindern, hat man sich auf das Wesentliche konzentriert.
All diese Herausforderungen waren letztlich nicht vertraglich oder kaufmännisch, oder strukturell über Gremien und Eskalations-Prozesse zu lösen. Ein so volatiles und umfangreiches Projekt erfordert von den handelnden Personen, hier die Projekt- und Service Manager auf beiden Seiten, ein Mindestmaß an gegenseitigem Vertrauen, eine hohe Transparenz zu "Impediments" und eine langjährige Erfahrung in vergleichbaren Projekten.
Diese Erfahrung sollte sich dann insbesondere in zwei Richtungen positiv auswirken: Die Fokussierung auf das Wesentliche in einem hohen Grad an Pragmatismus sowie eine gewisse "Gelassenheit."
Der Business-Nutzen
Primärziel war die Schaffung einer höheren funktionalen Adaptionsgeschwindigkeit des Webshops an die Bedürfnisse des Marktes und der Kunden ("Time to Market"). Dies muss die IT unterstützen, indem sie Infrastrukturen on demand "in der Cloud" skalieren kann und indem die Release- und Deployment-Prozesse "Continuous Delivery" unterstützen. Diese Grundsätze zuzüglich eines gewissen Maßes an Offenheit in Richtung neu verfügbarer Technologien ist das Fundament, um "Time-To-Market" optimal zu unterstützen
Zudem wollte Otto seine IT-Strukturen so auslegen, dass Fehler, die ohnehin passieren, passieren können, ohne die Anforderungen an Verfügbarkeit und Performance zu verletzten. Dazu gehören passend zu einem "Continuous Delivery" auch die "Echtzeit-Rollbackfähigkeit" für Features und der Ansatz Robustheit von dedizierten Infrastrukturen in das SW-Design zu verlagern.
Die strategischen Ziele, einerseits die Shop-Entwicklung in die eigene Hand zu nehmen und andererseits den Betrieb auf ein deutlich höheres Qualitätsniveau zu bringen, konnten mit den vorgesehenen Budgets und Personalaufwänden erreicht werden. (rb)