Der wahre Preis eines Plattformwechsels

00:04

Architektur entscheidet über Komplexität, über Kosten, über Steuerbarkeit.

00:09

Ich bin David Hohl und heiße dich herzlich willkommen bei Enterprise Architektur wirkt,

00:14

der Podcast zu EAM.

00:21

Servus, grüß dich und herzlich willkommen zu einer neuen Folge.

00:24

Heute möchte ich über ein Thema sprechen, das in vielen Unternehmen, gerade aber auch

00:30

natürlich schon seit längerer Zeit und in der Vergangenheit konkret diskutiert wird.

00:35

Die mögliche Ablöse einer bestehenden E-Commerce Plattform.

00:39

Zum Beispiel von einer Sub-Commerce zu einer Salesforce Commerce Cloud oder von Shopify to

00:45

Vitex oder vielleicht will man sogar von einer WordPress WooCommerce Plattform zu einer Commerce

00:51

Tools wechseln.

00:52

Wie auch immer, was wir hier heute auch uns näher anschauen werden, ist natürlich nicht, welche Plattform was kann und welches Feature dahintersteckt.

01:04

Wir schauen uns an, was passiert mit einem Unternehmen, wenn es seine Commerce-Plattform wirklich wechselt.

01:13

Und vor allem, welche Kosten entstehen, die in keinem Business Case stehen und in keiner wirklichen Planung.

01:21

Darum geht es heute. Viel Spaß und lass uns loslegen.

01:30

Commerce wird oft reduziert auf einen Webshop.

01:33

Aber Commerce ist viel mehr. Das kann ich nur aus meiner eigenen Erfahrung bezeugen.

01:37

Denn mein erster Onlineshop, den entwickelte ich um die 2000 rum.

01:42

Und Commerce ist eigentlich, wenn man es genau nimmt, Kundenzugang, eine reine Umsatzmaschine,

01:49

sondern dergleichen, es definiert die Preise, es hat eine sehr, sehr hohe Datenquellenrate

01:56

und es ist halt wirklich kampagnenfähig.

01:59

Man kann damit sehr schnell interagieren mit den Kunden und auch mit den Partnern und Lieferanten.

02:05

Und vor allem, was es noch ist, es ist eigentlich eine riesengroße, abgesehen von Datenkrage,

02:12

Prozessdrehscheibe.

02:13

Wer Commerce strukturell kontrolliert, kontrolliert aus meiner Sicht einen wesentlichen Teil des Geschäftsmodells in einem Unternehmen.

02:22

Deshalb ist die Plattformfrage keine IT-Frage.

02:27

Sie ist eine unternehmerische Entscheidung, die man bewusst trifft.

02:32

Bevor man über Ablöse spricht, sollte man sich eine Frage, aber eine selten gestellte Frage stellen.

02:40

Was macht unsere Commerce-Landschaft eigentlich wirklich?

02:44

Und dabei sollte man nicht unbedingt dort anfangen, wo die meisten anfangen, an der technischen Front, sondern an der anderen, die viel wichtiger ist, und zwar der geschäftlichen.

02:56

Dabei sollte man sich fragen, zum Beispiel, mit welchen Daten arbeite ich, welche werden gespeichert, welche werden bezogen, welche werden weitergegeben.

03:07

Also man merkt, es ist dann schon einmal in der Tiefe, dann wird es schnell unruhig.

03:13

Bei den Antworten zumindest. Und typischerweise reden wir bei Commerce-Landschaften nicht nur um Kundendaten oder Produkte, denn da ist noch viel mehr dahinter. Eine sehr raffinierte Preis- und Rabattlogik.

03:27

Natürlich hat man verschiedene Bilder und Assets, Marketing, Infomaterialien, Bestellungen, Zahlungsinformationen und so weiter und so fort.

03:38

Und wenn man sich über diese Datenentitäten, also die Datentöpfe mal genauer Gedanken macht, dann wird man nämlich danach schnell eine weitere Frage stellen.

03:46

Woher kommen diese Daten?

03:49

Kommen sie aus dem ERP? Kommen sie aus dem PIM? Kommen sie aus irgendeinem Kampagnen-System?

03:54

Wem habe ich einen Datenpool von Kundendaten etc.?

03:59

Du siehst, wenn man genau hinschaut, wird man relativ schnell feststellen,

04:04

dass eine Commerce-Landschaft sich mit sehr vielen Systemen verdrahten muss.

04:09

Und sobald man diese Verdrahtung erkannt hat, wird man noch weitere Fragen stellen.

04:15

Nicht nur, woher kommen die Daten, sondern wo müssen sie am Schluss des Tages hin?

04:20

Denn nach einer Bestellung passiert ein bisschen mehr, was der Kunde natürlich nicht sieht.

04:24

Die Daten gehen meistens danach in ein Fulfillment-System oder in ein Order-Management-System, gehen in die Logistik, werden ausgeschifft und dann habe ich natürlich auch noch den Zahlungsprovider, der diesen Zahlungseingang auch noch mithändelt.

04:38

Das Ganze landet wahrscheinlich dann wieder in einem ERP in einer riesen Datenkrake anderer Sondergleichen, die nicht ablösbar ist oder sehr schwer.

04:47

Somit ist das keine IT-Frage, das sind Prozess- und Governance-Fragen.

04:53

Und das muss einem klar sein.

04:56

Ich habe mir mal probiert, eine gesamte E-Commerce-Strecke in einer 13-Schritte aufzuzeigen.

05:04

Und einfach um diese Prozessfindung ein bisschen gröber abzustecken.

05:10

Eine Bestellung ist Preisfindung.

05:11

Es ist eine Rabattlogik, es ist sogar eine Steuerberechnung dahinter.

05:15

Ich habe Zahlungsautokausierung an der Stelle, Auftragserzeugung, auch noch ein sehr komplexes Thema, da glaubt man gar nicht, Übergabe an das Fulfillment, das Lager muss abgeglichen werden, das Ganze muss verpackt und verschickt werden, ich muss Rechnungen erstellen, ich muss die Buchung aktivieren, ich muss gegebenenfalls sogar den Retourenprozess im Auge halten, ich muss Gutschriften ausstellen und ich muss natürlich meinen Bestand korrigieren.

05:43

Dadurch wird Commerce eigentlich zu einer riesengroßen Drehscheibe für den Kunden, für ERP-Systeme, für Financial-Systeme, für Payment-Systeme, für Logistik, für Marketing und Customer Service.

05:57

Wenn ich diese Gesamtdynamik nicht verstehe, weiß ich nicht, was wirklich ablöse, oder?

06:04

Dann ist nämlich ganz schnell Ende Gelände.

06:07

Und das habe ich zu oft gesehen.

06:09

Warum will man jetzt wechseln?

06:11

Viele Commerce-Systeme sind über die Jahre gewachsen.

06:16

Aber warum entstehen diese Monolithen überhaupt?

06:18

Weil es pragmatisch ist. Es ist einfach zu einfach.

06:23

Business-Logik wird direkt im System umgesetzt.

06:25

Sonderfälle werden ergänzt, Preislogiken werden dupliziert und Kampagnenmechaniken werden einfach integriert.

06:34

Und Zahlungsprozesse direkt angebunden.

06:37

Mit der Zeit entsteht ein zentraler Block.

06:40

Und dieser Block funktioniert, solange man nichts ändern möchte.

06:45

Aber je mehr Capabilities, also Fähigkeiten in einem System gebündelt werden, desto komplexer wird jede Veränderung, was am Ende unsere Veränderungsfähigkeit minimiert.

07:02

Angenommen, das Unternehmen unserer Wahl entscheidet sich für eine Salesforce Commerce Cloud.

07:08

Was bedeutet das für Geschäftsebene?

07:11

Nicht technisch, sondern strukturell.

07:14

Erstens, Datenhoheiten müssen einfach neu definiert werden.

07:18

Man muss sich anschauen, wer ist System of Record für zum Beispiel Preise, Produkte und für den Kampagnen des Kunden.

07:27

Ohne klare Definitionen stehen eigentlich nur Parallelwelten.

07:30

Und diese Parallelwelten erzeugen einfach Inkonsistenzen.

07:36

Und vor allem verdammt viel Abstimmungsaufwand.

07:39

In meiner Vergangenheit hatte ich mal Großprojekte im Commerce-Bereich,

07:43

wo sich mehrere verschiedenste Arten von Produkt-Ownern gefeiert haben, gekämpft haben,

07:49

um im Endeffekt die Datenhoheit zu erlangen.

07:52

Ist doch einfach nur wahnsinnig, oder?

07:55

Denn daraus entstehen sogenannte operative Mehrkosten,

07:59

die nicht im ersten Schritt sichtbar sind,

08:02

sondern eigentlich dann über die Zeit und die Jahre danach richtig, richtig ins Geldbräsel reinspringen werden.

08:09

Prozessverantwortung verschieben sich, wenn Commerce stärker von CM getrieben werden.

08:15

Also das ist gerade im B2B-Bereich sehr oft der Fall.

08:19

Und dann verändert sich auch das Budget und die Entscheidungshoheit.

08:23

Oft ist genau an diesen Ebenen, wenn man B2B-Commerce-Lösungen baut, die CM getrieben sind,

08:30

Dann entscheidet das CM, wie der Commerce-Prozess läuft.

08:34

Das habe ich so oft gesehen.

08:35

Und da gibt es dann keine Governance mehr.

08:37

Weil dann wird einfach nur von oben herunten getrampelt und das war's.

08:41

Und wer priorisiert eigentlich das Ganze am Ende des Tages?

08:43

Ist es die IT? Ist es Marketing? Ist es Sales?

08:47

Spannend, ne?

08:48

Bei Commerce ist es in der Regel Marketing.

08:50

Das ist echt interessant.

08:51

Die IT hat hier überhaupt nichts zu melden.

08:53

Das ist auf der anderen Seite gut.

08:55

Der Vertrieb, der ist gerade bei B2B-Commerce-Lösungen aktiv.

09:00

Also es kommt so ein bisschen darauf an, wo man einsteigt.

09:04

Wenn wir uns ein bisschen auch dahinter jetzt mal diese versteckten Kostentreiber anschauen,

09:09

gerade in der Enterprise-Architektur sind sie entscheidend.

09:13

Und wenn wir halt gerade weiterdenken, auch für unsere nächste Zusammenhörzeit,

09:21

über Kostentreiber, da reden wir auch danach viel über Total Cost of Ownership

09:25

und weiteren Themen in diesem Kontext,

09:28

Dann gibt es sogenannte Koordinationskosten, also Mehrabstimmungen zwischen den Bereichen.

09:34

Weiteres, gerade bei solchen Commerce-Umstellungen, sind die Komplexitätkosten extrem hoch,

09:40

denn ich habe eine sehr hohe Übergangsphase von einem System zu einem anderen System.

09:46

Auch die Strategie dieses Rollouts ist entscheidend.

09:48

Ob es im Endeffekt Big Bang ist, also ich gehe mich sofort live,

09:51

habe ich einen kleinen Curve-Out, also das heißt, ich springe innerhalb des gesamten Kaufprozesses

09:56

zu den neuen System schauen.

09:59

Und was noch dann natürlich als weiterer versteckter Kostenreiber mit sich kommt,

10:05

ist die Veränderungskosten.

10:06

Also jede neue Idee muss plattformkonform sein.

10:11

Nur weil es früher funktioniert hat, heißt das nicht,

10:14

dass es auch in der nächsten Plattform funktioniert.

10:16

Und Architekten sollten gerade auf dieser Flughöhe genauer hinschauen.

10:22

Und zwar diese Entkopplungskosten.

10:25

Also spätere Strategiewechsel, die passieren.

10:29

Das ist keine Frage.

10:30

Strategien verändern sich jedes Jahr.

10:32

Aber die werden dann nachher teuer.

10:33

Und ich muss als Architekt genau darauf achten, dass diese Plattform das auch aushaltet.

10:39

Diese Kosten tauchen in keiner Lizenzrechnung blöderweise auf.

10:43

Aber sie bestimmen die Wirtschaftlichkeit über die nächsten Jahre.

10:47

Kommen wir zu meinem Lieblingsthema.

10:50

Die technischen Schulden.

10:52

Der ganz stille Wegbegleiter jedes Architekten.

10:55

und vor allem Entscheider.

10:57

Ein weiterer Punkt, der oft unterschätzt wird,

11:00

das sind wirklich immer wieder diese technischen Schulden.

11:04

Und ich rede hier nicht vom schlechten Code oder so,

11:07

oder das Dissen jetzt, dass irgendwann das Sein-Pattern falsch angewandt worden ist,

11:13

sondern im Sinne von strukturellen Schuldanhäufungen,

11:17

die ich im Endeffekt mir selbst angeeignet habe.

11:22

Denen bin ich mir oft gar nicht bewusst.

11:25

Diese technischen Schulden, die kommen viel, viel später aus riesengroßen Fliegenklatschen obendrauf.

11:31

Wo entstehen die eigentlich?

11:33

Wo entstehen diese technischen bösen Schulden?

11:38

Vorrangig habe ich sie gesehen bei Prozesse, die kurzfristig gelöst werden müssen.

11:44

Also zum Beispiel eine Payment-Integration musste schnell umgestellt werden

11:50

und dann musste man dazwischen eine Middleware machen,

11:53

weil es technisch nicht anders möglich ist,

11:55

um die Kundendaten abspeichern zu können oder weiter zu verarbeiten.

11:59

Und dann kam die DSGVO oder GDPR-Klatsche obendrauf

12:02

und sagte GDPR, ja, da darfst du das nicht tun und jenes nicht tun

12:06

und dann wird es richtig böse.

12:08

Ein weiterer Fall, wo es auch sehr häufig passiert,

12:10

sind die Business-Logiken im System, die dort fest verankert werden.

12:15

Etwas, was ich immer probiere zu vermeiden.

12:18

Business-Logik hat in diesen E-Commerce-Plattformen so gut wie nichts verloren.

12:23

Die müssen außerhalb gelöst werden.

12:26

Denn umso mehr Business-Logik in einer so einer Plattform verankere,

12:29

umso abhängiger bin ich dann nachher bei einer Veränderung

12:33

oder sogar vielleicht einer Ablöse- oder einer Exit-Strategie.

12:38

Weitere Fall sind Sonderfälle, die dauerhaft bleiben.

12:42

Das heißt, ich mag schnell was ändern,

12:45

ich möchte das haben und jenes haben, kannst du nicht mal?

12:49

du kannst das lieber lassen gleich

12:52

und was auch sehr häufig passiert sind

12:54

Integrationen, weil sie ja so schnell und einfach sind

12:58

da fügen wir nochmal ein Feldchen hinzu

13:00

da machen wir da ein größeres Datenobjekt rein

13:04

und so weiter und so fort

13:06

gerade bei Integrationen, da kommen wir wahrscheinlich bei der einen oder anderen Folge noch drauf

13:11

wie katastrophale Entscheidungen da entstehen können

13:14

welche Security Incidents ich dabei auch noch auslöse, nur weil ich da ein neues Feld hinzugefügt habe.

13:22

Diese technischen Schulden, das sind natürlich nur kleine, aber es gibt noch viel heftigere,

13:28

die gerade geschäftskritisch und geschäftsschädigend sind.

13:33

Das Feine bei solchen Sachen sind, gerade bei seiner Transformation,

13:38

kommen viele dieser Schulden rüber und werden sichtbar.

13:43

Man muss sich plötzlich erklären, warum existieren fünf Rabattpfade, warum sind Retouren manuell überhaupt korrigiert worden, warum darf ich das, warum darf ich Bestellungen manuell verändern, warum stimmen ERP und Commerce nicht überein.

13:59

Technische Schuld wird zum Transformation Schuld. Das macht sich gerade sehr spannend, cool. Es ist sogar wahr. Davon bin ich überzeugt.

14:11

Was nämlich vorher unbequem war, wird plötzlich teuer.

14:17

Deswegen kannst du drei Sachen vielleicht merken an der Stelle.

14:20

Es gibt drei Ebenen dazu.

14:22

Einmal die Prozessschuld, also Geschäftslogik, die gewachsen ist und einfach nicht dokumentiert wird.

14:27

Oder noch viel schlimmer, einfach in das System mit reingeschustert wird.

14:32

Das Zweite sind die Integrationsschuld, also Schnittstellen, sind historisch, was auch immer das heißt,

14:40

entstanden und einfach nicht dokumentiert

14:42

worden oder nicht bewertet worden

14:44

und das letzte und die ist noch

14:46

viel, viel, viel interessanter

14:48

für uns alle hier, die Entscheidung

14:50

schuld, denn wir entscheiden

14:52

eigentlich und wir sind eigentlich die Schuldige

14:54

dahinter und am Ende

14:56

weiß keiner mehr, dass ich diese Entscheidung

14:58

getroffen habe und warum das

15:00

so ist und genau das

15:03

verlängert diese Projekte

15:04

und Transformationprojekte

15:06

und Zeit ist Geld

15:08

und das hast du sicher auch schon erlebt, oder?

15:11

Die gefährliche Illusion ist, viele glauben,

15:15

wenn wir diese Plattform wechseln, sind wir alle schuldenlos.

15:20

Das ist alles weg.

15:22

Das stimmt aber nicht.

15:24

Man kreiert sie jetzt.

15:26

Sie nehmen einfach mit.

15:27

Das ist so ein scheiß Virus, den du nicht loskriegst.

15:30

Oder man baut sie dann nachher noch neu auf.

15:33

Technische Schulden sind keine Systemprobleme.

15:37

Sie sind ein Strukturproblem, also ein Architekturproblem.

15:43

Die eigentliche unternehmerische Frage, die man eigentlich nicht stellen sollte,

15:47

in unserem Beispiel hier, ist Salesforce Commerce Cloud moderner?

15:53

Nein, das ist die falsche Frage, sondern man sollte sich eigentlich diese Frage stellen,

15:58

wie stark sind unsere Capabilities gekoppelt?

16:02

Wo sitzt unsere technische Schuld am höchsten und am tiefsten?

16:06

Wie hoch sind am Ende die Entkoppelungskosten dahinter?

16:10

Und welche Macht geben wir am Schluss des Tages auch ab,

16:14

die ich jetzt habe und nachher dann vielleicht nicht mehr haben werde?

16:18

Und welche Flexibilität gewinne ich dazu wirklich?

16:22

Meine Erfahrung lautet, gerade zur letzten Frage, wir geben sie ab.

16:25

Die Flexibilität wird oft weniger, da diese Sasslösungen uns gar nicht mehr so viel erlauben,

16:30

wie wir das früher machen konnten noch als Coder.

16:34

Erst wenn diese Fragen, aber natürlich viele andere beantwortet sind, ist die Entscheidung strategisch wirklich fundiert.

16:41

Davor ist das nur heiße Luft.

16:44

Wenn wir zum Schluss kommen, oder als Fazit, wenn man so schön sagt,

16:48

ein Plattformwechsel in dieser Größenordnung sollte kein IT-Projekt sein.

16:52

Und es sollte auf gar keinen Fall von der IT gesteuert sein.

16:56

Jetzt kriege ich wahrscheinlich 14 Steine in meine Richtung geworfen, ich nehme sie alle mit.

17:00

Es ist eine strukturelle Festlegung.

17:04

Und es verändert etwas.

17:06

Es verändert etwas in der Unternehmensarchitektur.

17:09

Und zwar die Datenhoheit, die Verantwortlichkeiten und auch die Budgetlogik dahinter.

17:19

Aber vor allem noch zwei weitere Themen und die sind meistens nie diskutierbar.

17:24

Und zwar die Abhängigkeitsstruktur und Veränderungsfähigkeit durch die einzelnen Teilbereiche.

17:31

Und genau deshalb reicht dir am Schluss auch nicht der TCO alleine aus.

17:36

TCO sieht nur die Preise, aber die Architektur sieht ihre Wirkung.

17:42

Und Wirkung entsteht über Wirtschaftlichkeit.

17:45

Servus und Baba und bis auf bald.