Immer wieder habe ich in den vergangenen Monaten Vorträge mit dem Titel “An Online Shop Won’t Do The Job” gehalten. Was ich darin versuche zu beschreiben ist, dass im B2B Digital Commerce im Jahr 2019 keine Differenzierung mehr mit dem bloßen Vorhandensein eines Online Shops möglich ist. Dies ist natürlich etwas überspitzt formuliert. Es gibt nach wie vor noch B2B-Branchen, in denen die reine digitale Verfügbarkeit schon Differenzierungskriterium genug darstellt. B2B-Händler und -Hersteller mit einem Online Shop, der nicht nur den Produktkatalog digital abbildet, sondern auch echten Zusatznutzen für die Kunden außerhalb der digitalen Transaktion abbildet, sind in ihrer Nische meist im vorderen Drittel dabei. Als Verantwortlicher im Unternehmen würde mir das jedoch bei Weitem nicht ausreichen. Für mich gehen diese inkrementellen Weiterentwicklungen der bestehenden Digital-Commerce-Infrastrukturen nicht weit genug. Die Kollegen von Spryker haben parallel in einem lesenswerten White Paper einige ihrer Gedanken dazu zusammengefasst: “08/15 ist kein Sieger-Code“, das mich zu diesem Artikel hier mit inspiriert hat.
Meinen Vortragstitel müsste ich eigentlich ändern zu “Standard Software Won’t Do The Job”. Ich bin mir sicher, dass für die Verfassung oder Fortschreibung erfolgreicher B2B Digital Commerce Cases in den nächsten 10 Jahren der Trend immer stärker in Richtung “Technology Ownership” gehen muss, wenn sich Unternehmen am Markt beim Kunden weiter differenzieren wollen. Die Zeit der Konfigurationssoftware im B2B Digital Commerce ist für alle Unternehmen vorbei, die zu den Top 3% Ihrer Branche gehören wollen. Zukünftig einfach immer die neuste Version einer Standard-Software zu launchen und die eigenentwickelten Spezialfunktionen nachzuziehen halte ich für den falschen Weg. Wer weiterhin erfolgreich sein möchte wird immer weniger mit Standard-Software-Lösungen auskommen. Dafür gibt es vor allem drei Gründe.
- Bis zum heutigen Tag sind klassische Standard-Software-Angebote, insbesondere im E-Commerce, eine Aggregation von Funktionen, die in der Vergangenheit gebraucht, umgesetzt und erfolgreich am Markt etabliert wurden. Somit ist sie, mehr als jede andere Software, bereits ab der ersten Installation theoretisch schon veraltet. Neue technologische Möglichkeiten oder Schnittstellen, die heute noch nicht auf der Tagesordnung stehen, morgen jedoch hohe Relevanz für Kunden besitzen können (z.B. zuletzt IoT-Anwendungen, Voice, etc.), werden durch Standard-Software selten antizipiert. Ihre nachträgliche Integration ist meist schmerzhaft und oft nur über Zwischenlösungen und Middelwares abbildbar. Doch genau die Möglichkeit der schnellen Nutzung bzw. des schnellen Testens dieser kurzfristig verfügbaren, neuen digitalen Potenziale bietet für B2B-Hersteller und -Händler die Chance, sich durch neue digitale Anwendungen und Services mit Wertschöpfung aus Kundensicht von Wettbewerbern zu differenzieren.
- Durch die flächendeckende Nutzung von Standard-Software hängt ein Unternehmen immer vom Release-Zyklus des Softwareherstellers ab. Ich habe selbst erlebt, wie in Projekten ganze Business Cases zusammengebrochen sind, weil die bestehende Standard-Software, egal ob nagelneu oder jahrealt, ein neues Feature oder einen Serviceprozess nicht abbilden konnte. Software-Hersteller sind in ihren Releases leider selten der Zeit voraus, sondern sind auf die Behebung technischer Probleme und das Nachziehen “neuer” Features für den gesamten Lizenznehmerstamm ihres Produktes fixiert. Da bleibt wenig Platz für individuelle Anforderungen.
- Der erste und zweite Grund für Tech Ownership und gegen Standard-Software fließt nahtlos in den dritten mit ein. Vor allem Händler, aber auch Direktvertriebsunternehmen, die sich im B2B von Ihren Wettbewerbern massiv unterscheiden und sich Vorteile sichern wollen, tun dies heute immer weniger über das Produkt- sondern das Service- bzw. Prozessangebot. Die Differenzierung liegt für B2B-Unternehmen immer weniger im “was verkaufen”, sondern im “wie verkaufen”. Dazu muss Software individuell auf die aus Kundensicht perfektionierten Prozesse angepasst werden. Ich habe in meiner Beraterzeit mit vielen Unternehmen gesprochen, die zwar gerne Prozess A wie Amazon und Prozess Z wie Zalando abwickeln würden, für die Prozess-Architektur aber nur ihren Magento-Shop in der Version 1.X und die zwanzig Jahre alte AS400 zur Verfügung haben.
“Der Einsatz von Standard-Software macht es oft nötig, die Geschäfts-
Alexander Valet, Head of Platform & Technology CERTEO (Quelle: Spryker White Paper “<08/15> ist kein Sieger-Code!“, S.10)
prozesse an die Software anzupassen. So ist keine Differenzierung zum Wettbewerb möglich. Ebenfalls schwierig ist die Abhängigkeit von der Feature- Roadmap und den Release-Zyklen des Anbieters, auf die man nur wenig Einfluss hat.”
In die Lage, kurzfristige technologische Entwicklungssprünge mitzumachen, müssen sich Unternehmen erst bringen. Auch jene, die sich durch die jahrelang erfolgreiche Konfiguration von Standard-Software Stand heute einen Platz in der ersten digitalen Reihe in Ihrer Branche gesichert haben. Die Beherrschung der Programmierung und des Managements von Softwareprodukten muss dazu die Kernkompetenz eines Unternehmens werden, wenn sie wirkliche Wettbewerbsvorteile in der nächsten Runde des B2B Digital Commerce bringen soll. Wir haben uns 2012 bei Hahn+Kolb (5 Jahre bevor der gefürchtete Wettbewerber Hoffmann Contrion schluckte) schon überlegt, eine eigene Webentwicklungsabteilung zu gründen, vordergründig mit der Idee, den damals genutzten Magento-Shop von betriebsausstatter24 selbst weiterentwickeln zu können. Es kam leider anders, doch hätten wir das damals umgesetzt, gäbe es heute dort sicher ein branchenerfahrenes Webentwicklungsteam von 4-6 Software-Architekten und -Entwicklern, die digitale Lösungen, unabhänig von Magento, viel schneller zur Marktreife entwickeln könnten, als das der Wettbewerb mit externen Ressourcen und “passenden” Standards umsetzen könnte.
“Die Menge an Besonderheiten einzelner Branchen und Geschäftsmodelle im B2B-Bereich machen es einer Standard-Software schwer, eine hohe Feature-Abdeckung zu erreichen. Das erhöht den Anteil an Anpassungen, die vorgenommen werden müssen und verringert wiederum die Update- Fähigkeit.“
Alexander Valet, Head of Platform & Technology CERTEO (Quelle: Spryker White Paper “Interfaces ändern sich – auch im B2B: Vom Desktop Online Shop über IoT zu Augmented-Reality-Anwendungen (Quelle: Spryker White Paper “Digitalisierung auf der Türschwelle: Vernetzung von IT und Business” beschrieben. Tech Ownership in Silos funktioniert definitiv nicht. Tech Ownership hat nicht nur Sonnenseiten, wie Alexander Valet von Certeo im White Paper beschreibt:
Die initialen Kosten und auch die Kosten nach Ende eines Projekts, das von einem Dienstleister umgesetzt wurde, sind oft geringer als für eine Plattform, die von einem In-house-Team als Produkt weiterentwickelt wird. Ich denke, dass das immer noch abschreckend wirkt, aber natürlich mittel- bis langfristig zu einer effektiveren und effizienteren Weiterentwicklung führt.“
Alexander Valet, Head of Platform & Technology CERTEO (Quelle: Spryker White Paper “
“Ja klar”, wird sich der informiert fühlende Leser jetzt denken. “Eigene Entwicklungsteams, die Spezialsoftware entwickeln – das ist was für große Unternehmen mit viel Geld und Ressourcen”. In meinen Augen ist das eine trügerische Fehleinschätzung. Beispiele von mittelständischen Unternehmen, die es geschafft haben, sich aus Kundensicht in ihren internen Prozessen und Abläufen zu spezialisieren und diese Spezialisierung und Kundenorientierung “in Code zu gießen” gibt es. Dazu gehört, neben dem hier drei Mal zitierten “Certeo” (Teil der Takkt AG), z.B. der Dachauer technische Händler Ludwig Meister, dessen CEO Max Meister mittlerweile ein alter Digitalspezl von mir ist und der bereits vor einem Jahr im Podcast “Fangt’s an und diskutiert’s nicht! Digitalisierung im Mittelstand mit Max Meister” beschrieben hat, wie es auch ohne große Budgets geht, dass Mittelständler digital nach vorne kommen. In seiner “Gewichtsklasse” ist Ludwig Meister (ca. 110 Mio. EUR Umsatz 2018) das digital führende Unternehmen. Mit dem eigenen Team wurde z.B. ein CRM entwickelt, das hochindividuelle Vertriebs- und Marketingkniffe für die Branche zulässt. Ein kleines Beispiel hierfür ist, dass Kunden automatisch über sich verändernde Wiederbeschaffungszeiten per E-Mail informiert werden und rechtzeitig reagieren können. Über 10% Wachstum im ersten Jahr des produktiven CRM-Einsatzes sind der Lohn für die Mühen. Auch der Online Shop wurde nicht mit Standard-Software, sondern mit Pimcore als Open Source Framework entwickelt. Die neusten Einblicke gibt Max übrigens bei Alex Graf im Kassenzone-Podcast “Der beste technische Großhändler – Max Meister von Ludwig Meister“.
Mehr zum Thema: Auch der Carpathia-Blog in der Schweiz hat diese Woche in einem Artikel veröffentlicht, dass Unternehmen immer mehr auf Eigenentwicklung setzen.
Alles schön und gut, aber ist es nicht so, das Würth seine zahlreichen innovativen Angebot auf Grundlage einer (auf Headless umgebauten) Intershop Lösung realisiert? Also Tech-Ownership gemischt mit solider Standard Commerce Engine und Rest-APIs?
Hi Martin!
Irgendwann hatte Würth mal Intershop als Basis, richtig. Mittlerweile sind da meines Wissens nach über 3.000 Manntage an Individualentwicklung reingeflossen. Würth hat z.B. einen Registrierungsflow oder einen Berechtigungsflow entwickelt, den Intershop dann übernommen hat und in seinen Core gemerged hat. Würth ist ja auch nicht auf der neusten Intershop-Version. Ich glaube, weil eine “Migration” auf eine neuere Version garnicht mehr möglich ist. Den Such-Server hat würth selbst auf SolR-Basis gebaut – da frage ich mich eher, ob ein Standard wie FACT-Finder oder andere nicht besser wäre?
Es ist definitiv nicht so, dass alles individuell sein muss. Den Ansatz mit Standard wo Standard funktioniert (z.B. Payment) und API-Fähigkeit ist schon mindestens ein Level weitergedacht, als das, was viele heute noch machen.
Viele Grüße
Lennart
Achtung Werbung ! Genau diese Aussage hätte ich mir am Anfang des Beitrages gewünscht. Plakativ mal eben ganze Branche in die Ecke gestellt und dabei noch schöne Werbung für Spryker gemacht. Glaubwürdigkeit, Unabhängigkeit und eine ausgewogene Darstellung: leider Fehlanzeige. Schade Lennart, hier habe ich mehr erwartet. Ich hoffe nur, dass Deine Leser differenzierter denken.
Ich bringe im Beitrag meine persönliche Meinung zum Ausdruck. Ob die für dich glaubwürdig oder unabhängig genug ist, interessiert mich dabei nicht. Das hier ist ein Blog, nicht das Software-Amtsblatt. Ich habe in den letzten 10 Jahren selbst genug Projekte gemacht um meine eigene Einschätzung zu dem Thema zu haben. Und ja, wenn man mich fragt, habe ich eine klare Meinung und von meiner Vorliebe für Spryker habe ich bislang auch keinen Hehl draus gemacht. Diese rührt übrigens daher, dass Alex Graf, Boris Lokschin & Co. zu meiner persönlichen Erfahrung in E-Commerce- und Software-Projekten passend vermitteln, dass Erfolg im digitalen Geschäft auch und vor allem mit der selbstständigen Beherrschung von Technologie zu tun hat. Diesen Ansatz habe ich bei Würth vertreten, den habe ich bei Votum / Turbine Kreuzberg vertreten und habe ihn in Etribes-Beratungsprojekten proklamiert.
Ich hoffe auch, das meine Leser differenziert denken und nicht immer nur glauben, mit der Installation und Konfiguration eines Standard-Software-Produkts, egal ob Shop, PIM, CRM etc., wäre das digitale Pferd ein Stück weiter in die richtige Richtung geritten. Viele Software-Hersteller suggerieren ja genau das, das ist die Kehrseite der Medallie. Ich helfe ihnen dabei, mit meinem Senf einen weiteren 45° Winkel der Perspektive zu bekommen.
Schöner Produktmarketing-Post für Spryker. Schade das hier solche Gefälligkeits-Artikel geschrieben werden.
Meine Perspektive dazu: Wir erleben viel mehr, dass gerade im Mittelstand der Fokus auf Standardisierung der Software gesetzt wird. Die wenigsten wollen sich von immer teureren Commerce-Entwicklern abhängig machen. Mittlerweile kennt jeder Entscheider in seinem Umfeld teure, gescheiterte Online/Commerce Projekte, sodass die Risikobewertung für hochindividuelle IT Projekte häufig negativ ausfällt und der Markt gerade vermehrt den Gesetzmässigkeiten der ERP Welt folgt: mehr Standard – weniger Projekt. Wie gesagt, dass gilt für den klassischen B2B Mittelstand. Die Tatsache, dass viele Systemanbieter – selbst Shopify – standard B2B Applikationen zukaufen/integrieren kommt ja auch nicht daher, dass der Markt kleiner wird und alle “Individualisieren”…
Hi Sebastian,
wie du schon der Antwort an Matthias entnehmen kannst, handelt es sich um meine persönliche Meinung und nicht um einen Gefälligkeitsartikel, wie du schreibst. Deine Argumentation, dass gescheiterte Individualprojekte dazu führen, dass sich Standard durchsetzt, halte ich insofern für Quatsch, dass Unternehmen sich mit Standard eben nicht im Wettbewerb differenzieren können. Wenn du dein Geld mit dem Verkauf von Standard-Software verdienst, dann kann ich deinen Groll gegen meine persönliche Meinung aber natürlich nachvollziehen.
Das sich der Standard durchsetzt, wie in der ERP-Welt, sehen wir ja an SAP. Es ist ja nicht so, dass Lidl über eine halbe Milliarde Euro in einem SAP-Projekt versenkt hat, dass es eine ganze Industrie an teuren SAP-Beratern und -Entwicklern gibt, von denen Mittelständler immer abhängiger werden, oder dass man z.B. bei Würth ein Projekt zur globales Projekt zur Einführung eines einheitlichen ERPs innerhalb eines Geschäftsmodells eingestellt hat. 😉
Die lange Liste schwieriger und gefloppter SAP-Projekte: https://www.wiwo.de/unternehmen/it/haribo-lidl-deutsche-post-und-co-die-lange-liste-schwieriger-und-gefloppter-sap-projekte/23771296.html
Ja und warum ist das Lidlprojekt gescheitert? Genau wegen dem Satz: Die Software muss sich dem Unternehmen anpassen und nicht umgekehrt. So schwer kann das ja nicht sein den Bestand nach dem VK zu bewerten und wenn das halt nicht SAP for retail standard ist dann bauen wir’s halt um. Wir sind schließlich Lidl, wir sind innovativ und ownen die Technologie.
Bum halbe Milliarde weg, sieben Jahre im Arsch.
Nicht weil man auf Standards setzt sondern weil man von Standards abweicht.
Ich glaube, Aussagen wie “So schwer kann das ja nicht sein, dass…” sind nicht Teil der Lösung, sondern des Problems. SAP im Standard funktioniert für wenige Unternehmen, da fließen zu den sechsstelligen Lizenzkosten immer mindestens sechsstellige Anpassungskosten rein.
Ein Handelskonzern wie Lidl bzw. die Schwarz-Gruppe mit mehr als 100 Mrd. EUR Umsatz ist meiner Erfahrung nach nicht deshalb so erfolgreich, auf Standards von “irgendwelchen” Software-Herstellern zu setzen. Bei den Mengen, die Lidl dreht, ist z.B. die Frage nach der Bewertungsbasis des Bestands eine Frage von mehreren Milliarden Euro. Da immer zu unterstellen, dass die Leute dumm sind und man Policies und Procedures einfach ändert, weil SAP im Standard was nicht hergibt, ist naiv und kurzsichtig, was du ja sonst nicht bist 😉
Das ist in der Realität wohl etwas komplexer und klingt von den Betroffenen bei Lidl auch etwas anders. Die Projektrealität sieht bei ähnlich komplexen SAP Projekten im Handel auch nicht anders aus wie bei Lidl, nur geben die sich damit zufrieden, dass es viel länger dauert und am Ende etwas live geht was dem Business nicht hilft.
Ich finde ja, dass Tech Ownership und Standardsoftware kein Widerspruch sind, im Gegenteil. Spryker ist auch irgendwie Standard, man erwartet halt noch mehr zu tun, bevor es als Lösung läuft. Klar, nen Magento kann ich mir installieren (lassen) und direkt loslegen, aber dass kann ich mit dem Spryker Demo Shop auch. Die eigentliche Frage ist komplexer als dass.
Der Punkt ist glaube ich eher, dass es eigene Tech Ownership braucht, wo dann auch Architekturentscheidungen – wie z.B. die genutzten Softwarekomponenten – entschieden werden. Und Dinge umgesetzt werden. Wer eine Make or Buy Entscheidung nicht selber treffen kann, kann auch keinen digitalen Prozess effizient entwerfen. Business Prozess und IT müssen bidirektional verknüpft sein, wenn es gut werden soll.
Natürlich ist es ideal, wenn es eine komplett fertige Standardlösung gibt, die genau mein (bzw. das vom Kunden) Problem löst. Erfahrungsgemäß ist das selten, oder ich habe einfach noch nicht lange genug über das Problem nachgedacht.
Amen Alex! Ich glaube, es gibt nicht das eine Grundproblem, aber die Herausforderungen, den Tech Stack zu “ownen”, also selbst darüber Herr zu sein. Standard-Software suggeriert den Anwendern immer, dass man es einfach nutzen kann. Die hören das und glauben es natürlich gerne. Das ist aber Blödsinn und wird vor allem in Zukunft immer schlechter funktionieren, inbesondere in der Wettbewerbsdifferenzierung.
Die Kernaussage ist richtig. Erfolgreiche Händler und Hersteller zeichnen sich dadurch aus, dass sich ihr Geschäftsmodell vom Standard abhebt. Differenzierungskriterien sind u.a. Sortiment, Preis, Service, uvm.. Natürlich gilt selbiges auch für die Software, die dieses Geschäftsmodell digital abbildet. Als Differenzierungsfaktor reicht daher eine unveränderte Standardsoftware wie Oxid, Magento oder Spryker in vielen Branchen heute nicht mehr aus.
Im Kern ist das Geschäftsmodell immer der Handel bzw. die digitale Transaktion. Alle Differenzierungsversuche drehen sich um diesen Prozess, sie machen ihn einfacher, günstiger, effizienter, emotionaler usw. Wendet man diese Erkenntnis auf den Software-Anschaffungs- und Entwicklungsprozess an, so macht es entgegen der Aussage im Beitrag absolut Sinn zunächst eine Standardsoftware als Basisinfrastruktur für die Kernprozesse (Kunde, Produkt, Transaktion => Kanal) einzusesetzen. Wichtig ist, dass diese Software, wie oben von Martin erwähnt, entsprechend einfach erweitert werden kann. Und Erweiterbarkeit ist absolut nicht, wie im Beitrag angedeutet, lediglich eine Domäne von Spryker. Martin nennt ein gutes Praxisbeispiel, welches beweißt dass sich selbst das in die Jahre gekommene Intershop entsprechend erweitern lässt. Andere Tools wie Magento bringen sehr zeitgemäße synchrone und asynchrone REST-API mit 100% Feature-Coverage schon längst mit und weiten derzeit die Unterstützung von GraphQL aus. Selbst Oxid hat unlängst eine GraphQL-Initiative gestartet, von nativen Cloud-native oder Headless-Lösungen wie Commercetools oder Salesforce ganz zu schweigen.
Da ich seit einiger Zeit stark mit Magento beschäftigt bin, bin ich selbst überrascht, wie gut und stabil die Erweiterbarkeit und Integrierbarkeit dieser Lösung auf Basis der mächtigen API ist. Als etablierte Software hat Magento immernoch eine wesentlich höhere Feature-Abdeckung als die neuen Player im Markt, auch wenn diese langsam nachziehen. Klar, die Core-Architektur ist im Vergleich zu modernen Lösungen veraltet und schränkt in einigen Bereichen ein, was allerdings für viele Mittelständler zunächst, d.h. in den ersten Schritten einer E-Commerce- oder Digital-Strategie kaum spürbar sein wird.
Ein Händler oder Hersteller sollte bei der Softwareauswahl den Feature-Umfang, die Core-Architektur und die Erweiterbarkeit einer Lösung prüfen und mit der eigenen Strategie abgleichen. Eine Standardsoftware (und dazu zählt Oxid, Magento, Shopware, Intershop, Hybris, Salesforce CC und Spryker) kann die richtige Grundlage für eine Kunden-, Produktkatalogs- oder Transaktions-Infrastruktur sein. Je nach Strategie kann die Erweiterung um ein zentrales, cloudbasiertes Customer Identity and Access Management oder die Auslagerung des Produkt-Katalogs in performantere oder effizientiere Cloud-Lösungen dabei Sinn machen.
An dieser Stelle ist evtl. auch eine Ergänzung zu obiger Aussage “Die Programmierung und des Managements von Softwareprodukten muss dazu die Kernkompetenz eines Unternehmens werden, wenn sie wirkliche Wettbewerbsvorteile in der nächsten Runde des B2B Digital Commerce bringen soll” angebracht, um Unternehmen die Angst vor einem solchen Unterfangen zu nehmen: Es ist nicht unbedingt notwendig, gleich ein internes Development- und Operations-Team aufzubauen. Damit solche Teams funktionieren und Spaß machen, müssen sie oft eine kritische Masse überschreiten, was den Unterhalt sehr teuer macht. Es kann mehr Sinn machen, auf gute Partnerschaften mit Software-Partnern und Agenturen zu setzen, da diese intern größer und stärker fokussiert sind und flexibler einsetzbar sind. Um solche Partnerschaften effizient zu steuern braucht es dann nur noch einen guten Software-/Enterprise- Architekten bzw. Designer (natürlich mit Dev-Skills).
Hallo Valentin,
vielen Dank für deinen ausführlichen Kommentar! Du selbst bist doch ein super Beispiel dafür, dass es für Mittelständler funktioniert, Tech Ownership aufzubauen. Du setzt dich offensichtlich für dein Unternehmen mit E-Commerce-Systemarchitektur auseinander und hast die von dir beschriebenen, notwendigen Kompetenzen. Wie viele andere Unternehmen machen das in dem Detailgrad? Ich kenne da leider wenige.
Und ja: Dev-Teams müssen eine kritische Masse überschreiten. Ich war diese Woche bei einem kleineren Fachhändler, der einen eigenen App-Entwickler und einen Full Stack Dev eingestellt hat. Die harmonieren auch gut. Es muss nicht immer gleich ein Triple-A Team sein, das ist richtig. Trotzdem: Wer sich in der digitalen Welt differenzieren will, muss halt auch mal gute Entwickler einstellen, nicht nur gute Außendienstler.
Über einen Zeitstrahl der letzten 20 Jahre gesehen, kommen Unternehmen aus einer best-of-breed Welt. Nachdem es immer mehr Silos gab, haben sie sich dann jahrelang mit frickeligen Schnittstellen beschäftigt. Danach kam die große Phase der Systemkonsolidierung in Richtung einer one-single-Vendor-Architektur, zuletzt auch via Cloud. Das Ziel dabei war immer Innovationsfähigkeit und Geschwindigkeit. Im Vergleich zu früher hat sich das auch für die meisten eingestellt, auch wenn man nun an die Roadmaps der großen Stack-Vendoren gebunden war. Immer noch besser, als wenn einem dauernd die Schnittstellen um die Ohren fliegen.
Die dritte Phase ist nun weder best-of-breed, noch Platform, sondern Individualentwicklung und voller Code/Stack-Ownership. Zunächst einmal ist das damit die LANGSAMSTE und mit großem Abstand auch die teuerste aller 3 Evolutionsstufen. Die von Dir angesprochene Geschwindigkeit, Agilität und Wettbewerbsvorteile, erreicht man nur unter der Voraussetzung sich DevTeams >10 Personen leisten zu können. Zunächst einmal machst Du idR nämlich nichts anderes als mit Frameworks à la Spryker überhaupt mal den Marktstandard à la Shopware/Magento für viel Geld nachzubauen und erst DANN, wenn Du noch Geld in der Kasse hast, kannst solch ein Framework überhaupt ausfahren und zum Pionier werden.
Mit zu viel Individualisierung läuft man meiner Meinung nach Gefahr, leicht den greifbarsten und wichtigsten Wettbewerbsfaktor heutzutage zu verspielen: Kostenführerschaft! Jede shopify/Amazon/eBay-one-man-show zieht kostentechnisch gnadenlos an Dir vorbei, völlig egal wie toll individualisiert Dein Shop und Deine Prozesse sind. Am Ende zählt nur Marge.
Meine 2 Theses lauten somit:
1) Frameworks wie Spryker sind eine gute Idee. Man muss den Ferrari, den man sich teuer einkauft aber dann auch ausfahren und in die Pionierphase kommen
2) Individualisierung ja, aber Kostenführerschaft schlägt am Ende Individualisierung! 😉
“Zunächst einmal machst Du idR nämlich nichts anderes als mit Frameworks à la Spryker überhaupt mal den Marktstandard à la Shopware/Magento für viel Geld nachzubauen ”
Wie kommst du darauf? Hast du schon mal mit Spryker gearbeitet oder dir mal die Demos angeschaut? Es ist eben nicht so, dass man alles teuer nachbauen muss, sondern schon deutlich weiterentwickelt startet. Aber ja, du hast Recht. Man muss es auch nutzen und dafür braucht man auch nach dem Launch Developer. Ohne die geht es nicht.
>Hast du schon mal mit Spryker gearbeitet oder dir mal die Demos angeschaut? Es ist eben nicht so, dass man alles teuer nachbauen muss, sondern schon deutlich weiterentwickelt startet.
Wir haben sowohl Spryker, Shopware, Magento,… im Haus und glaube ich daher eine ganz gute Sicht. Sicher startet man nicht ganz bei zero mit Spryker und hat einen lauffähigen Basis-Shop. Dennoch, eine marktgerechte UX zu erreichen Spryker vs. Shopware, ist insbesondere durch das immense und laufend wachsende Plugin-Ökosystem von Shopware, mit Shopware wesentlich schneller und günstiger zu erreichen. Da kann Spryker nicht mal annähernd mithalten. Wenn einem der Spryker-Basis-Shop + 20% Eigenentwicklung ausreicht, klasse, aber in diesem Fall hätte man sich ja niemals für Spryker entschieden 😉
Hallo Daniel!
Vielen Dank für den Kommentar. Ich glaube auch, das Framworks insofern einen Nachteil haben, dass man gewisse Dinge, die im “Standard” schon da sind, erst mal in der Ausprägung “nachbauen” muss. Ist halt wie beim Lego vs. Playmobil: Das eine stellst du einfach hin und spielst im Rahmen der vorgesehenen Möglichkeiten damit – wenn du aber was anderes damit machen willst, brauchst du Heißkleber und eine Plastiksäge. Das andere baust du nach deiner Kreativität zusammen und kannst damit viel schneller experimentieren und ausprobieren. Ich war halt eher ein Lego-Kind.
Klar muss man den Ferrari auch fahren können. Das Problem ist aber, dass viele Teilnehmer des B2B Digital Commerce denken, sie können mit ihren Golf VII 2.0 TDIs an der Formel 1 teilnehmen können, kommen dann aber nicht mal aus der Box. Nachhaltige digitale Erfolge und Differenzierung? Not going to happen.
Kostenführerschaft finde ich ein zunehmend schwieriges Differenzierungskriterium. Wie kannst du nachhaltig dein komplettes Sortiment z.B. günstiger anbieten, als das 10.000 Händler auf Amazon tun können? Und: Welche Unternehmen im B2B kennst du, die Markt- und Kostenführerschaft gleichzeitig haben? Ich kenne keines.
Meiner Meinung nach braucht ein Händler keinen Shop. Im fehlt schlicht die Reichweite. Also vergesst Spyker und Co.
Wichtiger ist es dort seine Angebote zu platzieren wo es Reichweite gibt – auf den relevanten Plattformen.
Plattformen ploppen in jeder Industrie auf und verzeichnen immense Wachstumsquoten. Erst letztens auf den EHI Omnichanneldays hat die DIY Branche über Industry Aliens gejammert, die eine vierfach höhere CAGR erzielten. Es ist durchaus wahrscheinlich, dass Commodities am sinnvollsten über Plattformen gehandelt werden, weil hier die Grenzkosten gegen Null gehen. Das würde jeglichen eigenen Vertriebskanal – egal ob Framework oder Standardsoftware – in Frage stellen. Es würde eher grundlegend das Geschäftsmodell in Frage stellen. Sinnvoll erscheint es dann Services um Produkte zu etablieren, um kundenspezifische Mehrwerte zu bieten.