Manche Schlachten in den IT-Diskussionen dachte man seien schon geschlagen seit den ERP „Standard vs. Custom Built“ – Diskussionen Ende letzten Jahrhunderts. Stattdessen wird dieses Thema insbesondere bei Online Shop-Systemen wieder intensiv diskutiert – unter anderem auch auf eigenen Konferenzformaten wie den code talks. Dazu habe ich gerade einen sehr lesenswerten Artikel von Roman Zenner in der aktuellen retail technology Zeitschrift gelesen.

Die Kernthesen fasse ich mal in eigenen Worten zusammen und gebe auch meine Einschätzung mit dazu:

  • Es gibt eine Vielzahl an Shopsystemen, die um die Gunst der Entscheider buhlen
  • Anbieter von Standardsoftwaresystemen nehmen für sich in Anspruch die wesentlichen Use Cases und Features abzubilden, die für den erfolgreichen E-Commerce besonders erfolgsversprechend sind
  • Die Herausforderung bei jedem Standard ist das Abbilden individueller Geschäftsmodelle
  • Daher muss jede noch so vermeintlich ausgereifte Standardsoftware durch Agentur-Partner in einem sehr umfangreichen Customizing an die individuellen Anforderungen angepasst werden (so lesen sich jedenfalls die Angebote dieser Implementierungspartner)
  • Gleichzeitig verändert sich „der Standard im E-Commerce“ so schnell, dass man hier eher von einem „moving target“ sprechen sollte und es somit fraglich es, ob die Anbieter dieses Rennen sinnvoll gewinnen können

Roman arbeitet sehr schön die Kernherausforderung heraus: Die größere Freiheit durch Eigenentwicklungen (mit oder ohne „Frameworks“ wie Spryker) erkauft man sich durch eine höhere Abhängigkeit von seinem Integrationsdienstleister oder den internen Entwicklern. Das ist ein Punkt, den ich auch teile: Solche Modelle eignen sich eher für erfahrenere Teams – auf Business- wie technischer Seite – die aus moderner Technologie tatsächlich einen Wettbewerbsvorteil bauen und nicht einfach nur in der zusätzlichen Komplexität untergehen. Der Aufbau und Steuerung von solchen IT Expertenteams erfordert eine gänzlich andere Kultur und Geschäftsverständnis als die meisten Entscheider bisher aufbringen (Scrum, MVP, Lean Startup, Fail fast & try often etc. pp.).

Seine abschließende Schlussfolgerung im Kern auf ein „reifes“ Standardprodukt zu setzen, das aber über mehrere APIs dann doch wieder den technischen Zugriff durch den Händler selbst, ermöglicht, muss nochmals gesondert analysiert werden. Denn hier spricht vor allem der USP des Anbieters für den er aktuell arbeitet. Es kann sinnvoll sein, das würde ich aber gerne nochmals etwas durchdenken.