Nirgendwo brodelt es gerade mehr als in Berlin. Und mit sovielen Wachstumstreibern vor Ort, muss es nicht wundern, wenn sich Berlin auch für die Shoptechwelt gerade zu einem neuen Mekka entwickelt.
Die Sphere.io-Lösung von Commercetools hat Rückenwind durch Rewe bekommen, das Project-A-Spinoff Spryker hat investorenseitig mit Cherry Ventures („Wo sich die (Ex-)Zalandos jetzt engagieren„) einen illustren Unterstützerkreis angezogen.
Auch Rocket Internet hat seinen Technologiebereich nun ausgegründet („SkyRocket“). Und dann formiert sich in Berlin noch ein weiterer, internationaler Player, der zwar als Mobile Player schon fleissig „Revolutionäre und Visionäre“ sucht, aber erst im Juli an die Öffentlichkeit will.
Bis zur K5 Konferenz wissen wir mehr. Dort haben wir in diesem Jahr einen NewTech-Schwerpunkt, wo wir die neuen Perspektiven im Shoptechbereich darstellen und die jüngsten Entwicklungen unter die Lupe nehmen können.
Wer sich einen Überblick verschaffen will: In unserem letzten Shoptech-Update („Exchanges #90: Shopsysteme gestern, heute und morgen„) hatten wir schon einige der Themen angerissen („Das Shoptech-Jahr 2015 – von händler- zu kundenzentrierten Lösungen„).
Frühere Beiträge zum Thema:
- Das Shoptech-Jahr 2015 – von händler- zu kundenzentrierten Lösungen
- Shopify vs. Demandware: Die Umsatzentwicklung im Vergleich
- Was Stephan Schambach deutschen Shop/Tech-Gründern rät
- Die Spryker-Debatte um die E-Commerce-Systeme der Zukunft
- Die Shoptech-Ambitionen von Spryker, Ongr, Amplience und Wombat
- Exchanges #90: Shopsysteme gestern, heute und morgen
Kategorien:Shoptech
Das Beste Shopsystem kommt aus Hückelhoven. JTL Shop 4.0 und JTL WaWi 1.0
Ein humorvoller Kommentar! Falls Du ihn doch ernst gemeint haben solltest, definiere für uns doch mal den Begriff „das beste Shopsystem“. Zum Vergleich: „Das beste Auto“ wird für einen 20-jährigen Single gewiss ein anderes Modell sein als für den 45-jährigen Familienvater mit 4 Kindern. Würde mich interessieren, für welches Anforderungsprofil der JTL Shop aus Deiner Sicht am besten passt.
Herzlichen Gluckwunsch an die Jungs von Spryker zur gelungenen Finanzierungsrunde! Deutsche Startups haben am Montag schon vermeldet, dass das Unternehmen damit mit einer 8-stelligen Summe bewertet ist: http://www.deutsche-startups.de/2015/06/08/spryker-sammelt-erstmals-millionenfinanzierung-ein/
Es wird spannend, zu beobachten, was aus diesem System wird. Einerseits gibt es schon Shopsysteme wie Sand am Meer, andererseits macht der Ansatz von Spryker auf mich einen guten und durchdachten Eindruck. Einziges Manko dürfte sein, dass jeder Verwender nach dem aktuellen Stand erst erheblichen Entwicklungsaufwand leisten muss, bis er ein produktiv nutzbares System zur Hand hat.
Danke für die Blumen Christian! Das Manko ist ja eine bewusste Entscheidung des Modells. Grundsätzlich ist es mE nicht 1:1 mit klassischen Shopsystemen vergleichbar, aber wenn man im Rahmen der Anforderungsdefinition zu dem Schluss kommt, dass ein Standardsystem (Intershop, Hybris, Shopware…) schon 90% der gewünschten Funktionen mitbringt, dann ist Spryker wahrscheinlich weniger relevant. Unser Wettbewerb ist ja eher die „grüne Wiese“ auf die viele individuelle Modelle gehen müssen. Und da muss man sich als Kunde überlegen, ob man mit Spryker schneller/sicherer….. unterwegs ist. Im aktuellen Setup ist das sehr oft der Fall.
Was allerdings auch zu beobachten ist – viele Partner (oft Agenturen) mit denen wir sprechen würden gerne Spryker verwenden, um Branchenlösungen zu schaffen – z.b. eine E-Commerce Lösung für Versandapotheken. In so einem Fall ähnelt die „Agenturlösung“ dann wieder eher einem Standardsystem – zumindest im Pitch. So könnten die Entwicklungskosten für so eine Lösung auf viele Versandapotheken umgelegt werden und am Ende gibt es trotzdem Support vom Hersteller des Basisframeworks (also uns). Damit fühlen sich mögliche Kunden etwas wohler, weil man sich nicht von einer Agentur abhängig machen muss.
In der Tat ist sehr viel Bewegung im Markt, die sich von außen so gar nicht erschließt. Ende des Monats ist unser Demoprodukt (Sandbox) fertig. Dann können qualifizierte Partner anfangen mit dem System zu spielen und experimentieren. Momentan ist es so, dass fast jeden Tag neue Vorschläge von Partnern und Kunden kommen was man mit so einem Framework doch alles machen könnte. Spannende Zeiten!
Genau der Frameworkansatz ist das was meiner Meinung nach den Erfolg verspricht.
So ist hybris groß und erfolgreich geworden – auch wenn man da das Wort Framework gescheut hat „wie der Teufel das Weihwasser“ :-)
Letztlich geht es im Enterprise-Segment doch darum wie flexibel, offen, modular, skalierbar, investitionssicher usw. eine Lösung ist und nicht um den „Vorfertigungsgrad“. Es geht IMMER darum wie sich die Lösung in eine / mehrere bestehende Infrastruktur- und Prozesslandkarten integrieren lässt.
Richtig spannend – gibt momentan wirklich einige gute Initiativen.
Der Frameworkansatz ist sicherlich Fluch und Segen zugleich. „Manko“ war von mir auch in dem Sinne gemeint, dass der reine Frameworkansatz ohne fertige programmierte Funktionsmodule (mit Admin-Menüs etc) bei der Entscheidung für oder gegen ein System eine gewisse Hürde darstellt, die es zu überwinden gilt. Wenn der Entscheider auf Schlagwörter wie „Standard“ und „Time-to-Market“ steht, dürfte es schwieriger sein, mit Spryker zu punkten. Begeistert sich der Entscheider dagegen lieber für Begriffe wie „Offenheit“, „Flexibilität“, „Performance“ dürften die Chancen viel besser stehen. Dürfte immer eine Frage sein, in welcher Falle der Entscheider zuletzt gesessen hat: Hat er zuletzt eine Individualentwicklung erlebt, die massig Geld verschlungen hat und doch niemals erfolgreich fertig wurde, wird unser Entscheider vermutlich so genannte „Standardsoftware“ lieben. Hat er sich jedoch zuletzt vom starren Gerüst einer „Standardsoftware“ und den damit verbundenen Beschränkungen eingeengt gefühlt, wird er wohl für den Frameworkansatz aufgeschlossen sein. Gefühlsmäßig würde ich sagen, dass momentan eher mehr Leute gerne das starre Korsett einer klassischen Shopsoftware sprengen möchten. Insofern könnte die Zeit für einen Ansatz wie Spryker nun genau richtig sein.
Der Gedanke, dass Partner auf Basis des Frameworks Branchenlösungen basteln, klingt plausibel. Da hätte man dann das Beste aus beiden Welten vereint: Ein Stück Standard gepaart mit der Flexibilität einer offenen und doch zugleich soliden Plattform. Risiko für Spryker: Es dürfte etwas dauern, bis ein solcher Stand erreicht wäre. Andere könnten in dieser Zeit schneller sein.
Das ist ja generell bei Enterprise Systemen der Fall und ich denke genau dort wird / will sich Spryker positionieren – da ist nach der Übernahme von hybris durch SAP in jedem Fall richtig Platz im Markt. JTL werden Sie wohl nicht als direkten Wettbewerber empfinden ;-)
Wenn man 100.000€ pro Jahr(!) für ein Shopsystem ausgeben muss (welches dann noch nicht mal einsatzfähig ist), dann kommen dafür sicherlich nur sehr wenige potenzielle Onlineshopbetrieber in Frage.
Auch finde ich es gewagt, von einer echten Finanzierungsrunde zu sprechen, wenn die eine Otto-Firma die andere Otto-Firma bezahlt.
Spannender finde ich den innovativen Onlineshop-Massenmarkt, wo mit Shopware oder Etailer (Neu!) oder dem ehemaligen Commercetools eine Menge in Bewegung ist.
„wenn die eine Otto-Firma die andere Otto-Firma bezahlt“ :-D
Benjamin Otto hat ja privat investiert. Das hat mit der Otto Group erstmal nicht viel zu tun, ausser halt dem gleichen Namen.
Und Spryker wird auch nicht automatisch zu einer „Otto-Firma“, nur weil einer der Investoren (Project A) einen Fond betreibt, in dem u.a. auch die Otto Group investiert hat. Ich denke auf dem Zoom-Level wird alles irgendwie zusammenhängen.
Das ist der typische Neid-Reflex, den kriegt man aus deutschen Seelen nur ganz schwer raus. Es wird dabei immer suggeriert, dass etwas wenig(er) innovativ ist, wenn es einfach(er) ist, eine Finanzierung dafür zu bekommen. Ich finde es super, dass aus dem „Otto-Umfeld“ soviel Kapital in Innovation fliesst.
Kommt immer drauf an, wie der ROI für die 100k / Jahr ist. Klar, Händler mit weniger als 10 Mio. Jahresumsatz wird das kaum interessieren, ansonsten geht bei den großen Online-Händlern bzw. bei denen, die das werden wollen, der Trend ganz klar zu Individualentwicklungen und da bringt Spryker im Bereich BI und Transaktions-Management und Performance beste Voraussetzungen mit.
Und die 100k ist der Listenpreis. :-)
Unspannend wird die Sache nicht dadurch, wer das Geld dafür gibt. Geld, was in Innovation gesteckt wird, egal von wem, ist erst mal gut.
Es geht auch bei weniger Jahresumsatz, aber grundsätzlich stimmt das schon. Wir brauchen Kunden, die bereit sind in Technologie zu investieren – permanent. Wenn man „nur“ einen Shop braucht, dann verstehe ich schon, dass man da die Kosten gering halten will/muss.
Zum Listenpreis: Ja das ist ein Listenpreis, aber der ist nicht so zu verstehen, dass es da je nach Zahlungsbereitschaft potentieller Kunden mal 10% und mal 90% Rabatt gibt. Das führt zu sehr vielen Zielkonflikten in der Behandlung von Kunden. Grundsätzlich gibt es da gar keine Rabatte, sondern andere Leistungen zusätzlich je nach Case. Heißt: Wenn man die 100k/Jahr nicht in seinem Case abbilden kann oder will, dann wird Spryker keine Lösung sein.
Was mich mal interessieren würde – worin unterscheidet sich Spryker von Sphere, Ongr.io & Co.? Bei Spryker muss ich das ganze selbst hosten, was mich nochmals ca. 80 – 100 K im Jahr kostet, während ich das Hosting bei Sphere schon dabei habe. Wo also liegen die Vorteile von Spryker ggü. Sphere.?
Hallo Mike,
Alex hat das hier anschaulich erläutert: https://m.facebook.com/herrgraf/posts/10153382169656823
Danke, erklärt aber noch nicht die Unterschiede zwischen den modernen Lösungen. Aber das Beispiel mit dem Kurierdienst ist schon sehr gut.
Sphere ist eine Saas Lösung – also technisch so ziemlich das Gegenteil von Spryker, auch wenn man damit Shops bauen kann. Ongr.io konzentriert sich eher auf den Ausgabeteil/Frontend. Stark vereinfacht kann man sagen, dass es dem Yves Teil von Spryker ähnlich ist und für 100k Hosting im Jahr kannst man mit einem Spryker Systeme Umsätze machen, bei dem 100k Hosting keine Stellgröße mehr sind.
Danke für das Feedback – erstreckt sich der Unterschied wirklich „nur“ auf die Technik? Wenn ich es richtig verstehe, ist Sphere eine Plattform welche die grundlegenden Prozesse für Transaktionen bereitstellt. Der Händler / die Agentur dockt daran via API die Kommunikation zu ERP, Onlineshop, CRM etc. an.
Spryker ist grundsätzlich ein komplett fertiger Onlineshop-Baukasten und der Kunde muss sich entscheiden welche Bausteine er nutzen möchte. – richtig soweit?
Wie steht es dann mit Schnittstellen zu ERP etc. – bietet hier Spryker ebenfalls Bausteine an (zu etablierten ERP) bzw. muss sich Händler / Agentur dass dann selbst programmieren?
Disclaimer: Sind für Entwickler jetzt vielleicht blöde Fragen, aber für Außenstehende ist das gesamte Modell, da neu, sicherlich noch erklärungsbedürftig. ;-)
Es gibt schon sehr viele andere Unterschiede, die aber erst klar werden, wenn man weiß welche Herausforderungen sich bei großen E-Commerce Projekten ergeben können. Wir bringen schon für viele Drittlösungen (Payment, Logistik) fertige Komponenten mit und das Konzept erlaubt sehr gut die Anbindung dritter Lösungen. Die Kosten für eine komplette Wirecard Integration dürften dann deutlich kleiner sein als die Anbindung bei einem Standardsystem, aber das architektonische Gründe. In den gestarteten Projekten gibt es immer ERP Anbindungen und sicherlich werden einige zum Standard werden, aber wir erwarten idR, dass viele ERP typische Concerns in Spryker gelöst werden und das ERP nur noch eine Art Lagerverwaltung ist.
Ist es ein Baukasten, den man sich zusammenstöpseln kann, und los geht es. Grundsätzlich ja, wobei das zusammenstöpseln mit Entwicklungsaufwand verbunden ist. Also nicht per Drag & Drop.
Wenn für das jeweilige Geschäftsmodell bestehende Komponenten nicht sinnvoll sind, dann kann man in der Tat einfach rauslassen (Gutscheine) oder ersetzen (Katalog, PIM…). Das macht es ja im Kern später schnell. Dadurch das der Code lange sehr schlank und gut wartbar bleibt, ist es ja schneller in der späteren Entwicklung auf Kundenebene.
Gibt es denn schon Projekte die ausserhalb des „Otto / Project A“ Kosmos gestartet sind?
Wenn nein – habt Ihr denn Ressourcen bzw. ab wann denkt Ihr könnte man ein Spryker-Projekt starten?
@Jörg: Alle bereits gestarteten Projekten auf dem Spryker Core sind außerhalb des Project A und Otto Umfelds. Die Kartenmacherei (war in der PM genannt) hat ja auch nichts mit Otto zu tun. Wir starten im Juni noch maximal ein Projekt und Ende Juni gibt es eine Art Sandbox mit der unsere Partneragenturen & Direktkunden besser geschult werden können. Dann können wir ca. 2-5 Projekte im Monat starten. Bis Ende des Jahres sind wir soweit, dass der initiale Schulungsprozess nur noch ein paar Tage dauert. Dank der Finanzierungsrunde haben wir ausreichend Ressourcen.Wir setzen allerdings nicht selber um. Das müssen die Kunden/Agenturen selber tun. Wir helfen aber dabei die Fehler zu minimieren und coachen aktiv.
@Alexander: Danke für die Info! Ich melde mich per Mail bei Dir.
Das ist leider (oder zum Glück) falsch. SPHERE.IO ist PaaS, oder wenn man so will E-Commerce-as-a-Service, eine Plattform bzw. Framework für Commerce-Funktionen aus der Cloud. Der Kern ist gehosted, aber anpassbar (PIM, Datenmodell, Objekte, in Kürze sogar die ElasticSearch Konfiguration). Alles wird als REST-API ausgeliefert. Die SDKs (Java, PHP, node) sowie Template-Shops, Schnittstellen/Integrationen etc. sind alle Open-Source. Der Unterschied liegt meiner Meinung nach im Detail, aber dafür kenne ich Spryker (noch) nicht so gut, um das beurteilen zu können.
Normalerweise halte ich mich mit den Kommentar-Posts ja zurück, aber wenn Äpfel mit Birnen verglichen werden (wie ich das in den meisten ziemlich Miesen Vergleichen a la Demandware vs. hybris vs. Magento etc. gelesen habe), hilfts wohl nichts, vor allem wenn man selbst erwähnt wird. Wenn wir schon vergleichen, dann auch bitte präzise werden. hybris als Standardsystem einzuordnen zeugt auch davon, keine Projekte damit gemacht zu haben, in erster Linie ist hybris ein Framework mit eigenem Persistenzsystem, das oben drauf E-Commerce Objekte und Funktionalität hat, aber beliebig erweiterbar ist. Wenn Kunden im Schnitt bei 7-stelligen Implementierungen liegen, dann ist “Standard” weit ausgelegt. Ich verstehe, dass man irgendwie vereinfachen muss, sonst wird die Antwort auf eine simple Frage sehr komplex. So ist aber nunmal der Markt in dem wir uns alle tummeln.
Ich werde mich im Sommer jetzt wohl doch mal bemühen, einen soweit möglich objektiven Vergleich bzw. Übersicht relevanter etablierter und neuer Player zu erstellen. Vielleicht bin ich ja zur K5 damit fertig ;) Vorschläge? Ich denke bisher an Demandware, hybris, Shopware, Magento und von den “Modernen” commercetools SPHERE.IO, Spryker und Mozu. Falls wer mitmachen möchte, gerne direkt bei mir per Email melden.
Danke, Dirk! Auch Deine Kommentare sind natürlich sehr willkommen :-)
@Dirk: In der Tat muss man definieren was ein Framework eigentlich ist. Wenn man der Hybris Definition folgt, dann sind viele Shopsysteme Frameworks. Abschließend wird man das nicht lösen können – es ist eine Frage der Definition. Wann ist die Konfiguration einer Schnittstelle eher die Anpassung eines Standards, wann ist es die freie Entwicklung im Sinne eines Frameworks? Dinge die als SaaS gehostet sind und „nur“ konfiguriert werden können bringen Vor- und Nachteile mit sich. Darüber kann man in der Tat sehr gut diskutieren.
@Dirk Sphere.io und Spryker haben tatsächlich auf den ersten Blick viele Gemeinsamkeiten, vor allem die starke Modularisierung und die Notwendigkeit Entwicklern für die Umsetzung einzusetzen (‚out-of-the-box läuft bei beiden erstmal nichts‘).
Aber in der Praxis dürften die beiden Systeme bei kaum einem Händler im selben Consideration Set auftauchen. Bei Sphere.io bekommt man von euch bereitgestellte Funktionalitäten, die man konfigurieren und anbinden kann. Bei Spryker erhält man dagegen den vollständigen Quellcode in Framework-Qualität und baut dann darauf auf. Daraus ergeben sich schlußendlich völlig unterschiedliche Use-Cases.
Wir werden das Thema sicherlich irgendwann mal in einer Podiumsdiskussion präzisieren können. 2013 hatten wir ja schonmal das Vergnügen auf der Exceed.
@Fabian: Ich bin mir da gar nicht mal so sicher, ob die Anwendungsfälle so unterschiedlich sind. Die meiste Entwicklung inkl. individueller Prozesse und Logik spielt sich oberhalb der API ab (grundlegende Funktionen wie eine Steuerberechnung darunter muss ich nicht neu erfinden). Wenn ich als Kunde/Entwickler ganz spezielle Anforderungen habe, die nicht im klassischen E-Commerce verankert sind, dann kann ich mir das bei beiden Lösungen schnell hinzuentwickeln. Spannend wird die Diskussion glaube ich erst, wenn auch klassische „Template-fokussierte“ Lösungen mit am Start sind.
Mir ging es hier auch nur um die Klarstellung der Kategorisierung, nämlich nicht SaaS sondern PaaS oder EaaS. Ich werde mich die nächsten 3 Monate aber jetzt tatsächlich mal um eine Gegenüberstellung bemühen.
>Grundsätzlich gibt es da gar keine Rabatte, sondern andere Leistungen zusätzlich je nach Case.
Klar, so hatte ich das auch verstanden.
Ich finde den Ansatz sehr gut, die Kunden zu adressieren, die bereit sind, permanent in Technologie zu investieren. Amazon ist nicht so groß geworden, weil sie extreme Handelskompletenz haben, sondern weil sie unendlich viel Geld in Technologie investieren.
Danke, Jochen :)