Klassische vs. moderne IT-Organisationen

Joel Kaczmarek: Hallo und herzlich willkommen zu einem neuen Innovate or Die Podcast von Digitalkompakt. Mein Name ist Joel Kaczmarek und heute geht es wieder in die Tiefen der IT-Welt mit dem guten Boris Lokschin. Guten Morgen Boris.

Boris Lokschin: Guten Morgen, hallo.

Joel Kaczmarek: Wir sagen beide guten Morgen, aber es ist schon 15.51 Uhr. In der IT wacht man später auf. Ja genau, da gelten andere Zeiten. Aufwachen ist vielleicht ein passendes Stichwort zu unserem Thema heute. Wir haben ja letztes Mal verglichen, wie IT in der alten und in der neuen Welt aussieht. Und dieses Mal wollen wir klassische IT-Projektfehler durchgehen. Da hat man dann auch manchmal ein böses Erwachen im schlimmsten Fall. Kannst du das echt so sagen? Also hast du wirklich so 10 DCT-Fehler, die dir immer wieder aufkommen?

Boris Lokschin: Ja, wahrscheinlich sogar mehr als zehn. Aber ich glaube, man kann da schon eindampfen. Es gibt schon Dinge, die einfach immer wieder vorkommen und die immer wieder in unterschiedlichsten Facetten und bei dem einen mehr, bei dem anderen weniger, aber schon sehr repetitiv sind.

Joel Kaczmarek: Na gut, ehe wir dann mal in die Tiefe tauchen, könnten wir nochmal einen Satz sagen, vielleicht auch fünf, was eigentlich die wesentlichen Herausforderungen in der IT-Landschaft heutzutage sind, dass wir mal so einen kleinen Recap machen.

Boris Lokschin: Genau, also wir haben ja in den vorherigen Folgen uns darüber unterhalten, wie die Organisationen aufgebaut sind, was es für verschiedene Methodiken gibt, letztes Mal insbesondere auch darüber, wie welche Rollen vorkommen und wie der Unterschied zwischen so einer klassischen IT-Organisation ist versus eben einer digitalen. Wie sind die Organisationen inzentiviert, welche Rollen kommen irgendwie traditionell gar nicht vor versus in einer digitalen Organisation umso mehr. Und ich glaube, darauf aufbauend kann man eigentlich auch direkt in diese Fehler einsteigen, die man relativ häufig findet. Ich glaube, das erste und wirklich am häufigsten Vorkommende ist, dass einfach Produkte, Dienstleistungen, die dann digital entwickelt werden, komplett am Kunden vorbei entwickelt werden. Das heißt, so ein bisschen der Fehler der letztes Mal eben auch Anklangorganisationen, die einfach keine nach außen gerichteten, Rollen haben. Dann eben nicht den Product Owner, dann eben nicht die Leute, die sich um die Auswertung von Daten, BI und Co. kümmern. Dann eben nicht die Produktmanager, die dann Interviews führen, sich über Personas Gedanken machen und Customer Journeys, sondern wirklich so klassische EDV-Abteilungen, die dann immer nach innen gerichtet gearbeitet haben, nach innen gerichtet gemanagt wurden und inzentiviert und auch metrikseitig bewertet wurden. Das ist ein ganz, ganz häufiger Fehler. Da entstehen dann Produkte, Dienstleistungen, die einfach für den Endkunden, egal ob das ein B2B- oder B2C-Kunde ist, einfach gar keinen Mehrwert bringen, die de facto darauf abziehen, dass man das, was man heute macht, genauso macht, aber mit digitalem Anstrich. Und das ist dann so eine Asset-Verwertungssicht sehr, sehr häufig, dass man sich überlegt, okay, was habe ich denn hier zur Verfügung? Meine Flotte, meine Läden, meine IT-Systeme, so was kann ich denn daraus irgendwie stricken? Und wenn man dann hart reinfragt, ja, was hat eigentlich der Kunde davon? Bekommt der Kunde irgendwas besser, schneller, günstiger? Dann gibt es darauf wenig bis gar keine Antworten. Das heißt, so nach innen gerichtetes Denken versus eben, hey, lass uns vom Kunden rückwärts denken und überlegen, was wollen wir eigentlich bauen, jetzt unabhängig davon, ob das unser Kerngeschäft ist oder nicht, ob wir das selber machen oder einkaufen müssen oder ob wir die Plattform werden für jemand anderes. Wirklich vom Kunden rückwärts denken und dann, was brauchen wir an Systemen, an Organisationen? Das ist ein ganz, ganz häufiger Fehler und der führt halt zu Projekten, die einfach nicht bestandsfähig sind im Markt.

Joel Kaczmarek: Fairerweise ist das aber auch echt leicht. Also mir ging es auch so. Ich habe auch schon mal ein Produktam Kunden vorbei entwickelt. Das ist ein Schmerz. Da muss man dazu sagen,ich bin irgendwie Design Thinking erfahren. Ich habe das sogar früher unterrichtet. Also das kann einem trotzdem passieren,wenn man dann manchmal so überzeugt istvon seinen Lösungen. dass man so im Elfenbeinturm halt werkelt. Jetzt mag ja der eine oder andere vielleicht fragen, ist das wirklich ein IT-Thema? Also viele sehen vielleicht IT mehr als Umsetzer und weniger als diejenigen, die in so einer Konzeption mit drin sind. Produkt am Kunden vorbei entwickeln ist ja an vielen Stellen auch ein Konzeptionsthema. Würdest du trotzdem sagen, es ist ein IT-Thema und ein IT-Problem?

Boris Lokschin: Ja, ich würde, glaube ich, einen Schritt zurückgehen und ich glaube sozusagen an der Definition des Begriffes Produkt arbeiten. Ich glaube, dass es tatsächlich das, was du sagst, stimmt. Und insbesondere im B2B-Kontext kommt es halt sehr häufig vor, dass das Verständnis davon, was eigentlich das Produkt der Company ist, beziehungsweise viel eher sogar, was das Produkt nach vorne gerichtet ist. ist oder sein sollte, ist halt ein falsches. Ganz häufig wird als Produkt das bezeichnet, was irgendwie im Warehouse hängt oder liegt versus sozusagen das digitale Produkt. Und ich glaube, das ist so eine Kernerkenntnis einfach für die Unternehmen, dass wenn sie eben keine digitale Kompetenz haben und dabei sind, das aufzubauen, das nach vorne gerichtet, sozusagen ihre Plattform, ihre Technologiekompetenz, sozusagen ihre Datenkompetenz, das ist de facto das Produkt, das ist die Plattform oder das ist die App oder der Marktplatz. der dann hoffentlich Ihnen den Kundenzugang, den Sie heute hoffentlich noch haben, sichert oder irgendwie im neuen Umfeld einen neuen Kundenzugang gibt. Und das ist das Produkt, deswegen heißt es ja auch Produktmanagement. Produktmanagement heißt nicht Management des Einkaufs der Schrauben oder der Turnschuhe, wenn ich irgendwie ein Fashion-Unternehmen bin, sondern Management der digitalen Plattform. Und das ist das Produkt, das ist das Asset. Deswegen ja auch letztes Mal oder vorletztes Mal haben wir, glaube ich, viel darüber gesprochen, dass eben eine klassische IT eher so als Cost-Center gedacht wird versus eben als Profit-Center in einer Digitalisierung. Digitalorganisation, weil dort entsteht Value, die Plattform hat irgendwie einen Wert und das ist mein digitales Produkt. Wenn ich das natürlich nicht so sehe und damit wird es, um auf die Frage zu antworten, natürlich auch ein IT-Thema, also ein IT-Technologie-BI-Thema. Wenn ich das natürlich nicht so sehe, wenn ich immer noch glaube, mein Produkt ist irgendwie die Schraube, alles andere ist irgendwie nur der Online-Shop und das ist nur die IT und das ist irgendwie alles austauschbar, dann habe ich es halt schwer. Dann werde ich sozusagen aus der Denke auch nicht unbedingt rauskommen können.

Joel Kaczmarek: Dann lass uns auch mal sagen, was man tun kann, um dieses Problem zu vermeiden. Wie kann ich verhindern, dass ich mein Produkt am Kunden vorbei entwickle?

Boris Lokschin: Ich glaube, super wichtig ist erstmal überhaupt zu verstehen, wer der Kunde ist. Und das ist gar nicht so einfach, weil natürlich man erstmal, gerade wenn man ein Unternehmen ist, was länger im Markt ist, sehr schnell dazu neigt zu sagen, ich kenne den Kunden ja super gut, ich mache das ja seit 50 Jahren. Sich aber überlegen, okay, was ist denn in einer digitalen Welt der Kunde? Wir dürfen nicht vergessen, gerade im B2B-Kontext, das, was uns hier in Deutschland so groß und stark gemacht hat, häufig Mittelstand, Hidden Champions, das sind Dinge, die ja primär durch Intransparenz entstanden sind. Einfach Intransparenz von Verfügbarkeit, von Preisen, von anderen Faktoren. Das heißt, in einer transparenten Welt, in der ich den Einkauf von Silikon, Isolation fürs Fenster sehr leicht recherchieren kann, Google, Amazon, kann auf Alibaba suchen, kann sehr leicht auch den direkten Zugang zu Herstellern bekomme,mit guter Logistik irgendwie sehr schnellauch die Produkte geliefert bekomme,da funktioniert dann die Welt ein bisschen anders. Und ich glaube,wenn ich versuchen möchte, das zu vermeiden,dann sollte ich mir vorher überlegen,okay, was ist eigentlich der Kundefür mein Produkt nach vorne? Ist es der gleiche, den ich jetzt schon kenne? Sind es vielleicht neue Kundenkohorten,in die ich reingehen kann? Gerade wenn ich Hersteller bin,habe ich die Möglichkeit,vielleicht einen direkten Kundenzugang aufzubauenfür bestimmte Produktsortimente. Wenn ich mir das überlegt habeund eine gute Definition vielleichtvon den verschiedenen Personen das habe,dann ist, glaube ich, nichts wertvoller,als einfach mit diesen Personenin irgendeiner Art und Weise in Kontakt zu treten. Entweder sozusagen direktüber Interviews, Gesprächeoder indirekt, indem ich einfachschnell, leichtgewichtig Dinge eben baue,verteste,gewisse Hypothesen treffe,genauso wie ein Company-Builderdas auch machen würde. Die wenigsten Company-Builderfangen ja an für irgendein Thema,bei dem sie glauben, die mal anzusehen,gleich irgendwas zu bauen. Meistens wird ja irgendeine Landingpage mal hingestellt, da wird so ein bisschen SEO, SEA darauf geschaltet, da guckt man, ob das so ein bisschen so Fliegen und Bauernfängerei, ja, ob da sich überhaupt jemand verfängt, ja, für diesen Begriff und möchte jemand überhaupt, weiß ich nicht, ja, Cornflakes in einer Subscription kaufen jeden Monat, ja, ist das überhaupt irgendwas Relevantes oder ist das total Humbug? So, und wenn man dann merkt, naja, da scheint Demand da zu sein und da scheint irgendwie Nachfrag zu sein, dann fängt man an, irgendwie ein Produkt zu entwickeln, ja. Und ich glaube, das ist super, super wichtig und super relevant. Und wenn man das nicht macht, dann, glaube ich, hat man da ganz, ganz große Schwierigkeiten. Und ich glaube, dieses Sprechen mit dem Kunden, häufig auch sozusagen vielleicht auch an bestehenden Partnern, Handel, Fachhandel vorbei, Verständnis zu entwickeln darüber, was möchte der Kunde, welche Person er ist, welche Kohorten habe ich da, das ist etwas, womit man, glaube ich, auf jeden Fall anfangen muss. Weil ohne das macht man es halt sehr ins Blinde hinein.

Joel Kaczmarek: Also charmanterweise ein Problem, was sich verhältnisweise leicht oder zumindest klar lösen lässt, wo man einen klaren Weg hat. Dann lass uns mal ins Thema 2 abtauchen, vielleicht langsam mal den Komplexitätsgrad auch ein Stück weit steigern. Monolithische Systeme ist ja immer so ein schönes Stichwort, wenn es um IT-Themen geht. Was muss man sich darunter vorstellen und was hat das für einen Impact auf so eine Organisation?

Boris Lokschin: Genau, wirklich ein zweiter großer Fehler ist, dass man eben versucht, zu viel und zu komplex zu denken und zu machen und das sozusagen dann in irgendwelchen monolithischen, häufig sozusagen Standardsystemen mündet. Das heißt, ich überlege mir, ich möchte irgendwie ein Problem lösen und anstatt wirklich dieses jetzt häufig zitierte, agile, kleinteilige, datengetriebene, leicht zu vertestbare Vorgehen anzuwenden, versuche ich mir eben durch den Einkauf von einem großen System, einer großen Warenwirtschaft, einem großen Shop-System, einem großen Verkauf, Produktmanagement oder Contentmanagement-Tool,versuche ich mir sozusagen das Leben künstlicherstmal schwer zu machen. Häufig getrieben aus einervermeintlichen Risikomanagement-Denke,naja, ich kaufe jetzt erstmal irgendwas ein,das ist irgendwie etabliert,das ist ja ein Standardsystem,das hat ganz viele Features,so falsch kann es ja nicht seinund auch ganz viele bunte Logos auf der Webseite. So und ja, ich brauche vielleicht noch gar nichtalle Features, aber die werde ich auf jeden Fallalle in Zukunft brauchen. So, dann kaufe ich mir das ein, stelle mir das hin. Und was dabei passiert, ist eben ganz häufig erstmal sozusagen als Kerneffekt, dass ich mich wieder sehr, sehr langsam mache, weil ich ein großes System gekauft habe, was ich nicht leicht und flexibel anpassen kann, an sich verändernde Marktbedingungen. Und wenn irgendwas sicher ist, dann ist es das. Bedingungen werden sich verändern, Wettbewerb, irgendwie Wünsche der Kunden, neue Touchpoints, Devices, über die dann jemand irgendwie einkaufen möchte. Das heißt, es wird ganz viele Dinge geben, die man eben nicht vorhersehen kann. Viel trauriger ist auch, dass sehr häufig, gerade so in Ausschreibungsprozessen, Systeme eingekauft werden, ohne dafür klare Anforderungen und Stakeholder zu haben. Da sehen wir ganz, ganz häufig den bekannten RFP mit seinen 500 bis 1000 Zeilen. Dann fängt man an, sozusagen in der Analyse dieser Anforderungen, man versucht mit den Personas zu sprechen, die sich Features gewünscht haben und dann stellt man fest, es gibt die gar nicht. Also das Unternehmen X hat sich zwar hier ganz, ganz viel zusammengeschrieben zum Thema Produktmanagement, aber diese ganzen Workflows und Approvals und die Art und Weise, wie Produkte editiert werden sollen, es gibt gar keinen Stakeholder. Es gibt vielleicht ein, zwei Leute, die sozusagen im Category Management unterwegs sind oder zwei, drei Werkstudenten, die dort Produktdaten anreichern. Das heißt, es gibt keinen Stakeholder. Die Wahrscheinlichkeit ist halt sehr, sehr groß und das gleiche im Content Management Bereich auch ganz häufig. Das heißt, man over-engineert. Es gibt auch den Begriff sozusagen future-engineered. Ja, man versucht sozusagen, Leute, die nicht selber Stakeholder der Lösung sind, versuchen, Annahmen zu treffen über den zukünftigen Stakeholder. So, und was passiert ist natürlich, dass dann irgendwann kommt dann der Content Manager oder das Team oder der Produktmanager und die werden sowieso alle Scheiße finden, was vorher eingekauft wurde. So, die werden mit ihren eigenen Expectations kommen und eigene Prozesse, eigene Feature haben wollen. So, und dann hat man sich direkt irgendwie einen Konflikt ins Haus geholt, ja, weil das System einfach als gegeben gesetzt ist. Das ist schon mal ein schöner Nährboden für Austreten jeder Art, warum irgendwas nicht gut funktioniert. weil das ja ein Tool ist, das war schon vor mir da und das hat auch mein Vorgänger entschieden. Also große monolithische Systeme führen A zu langen Projekten, B zu teuren Projekten und C eben dazu, dass du einfach super steif und super unresponsiv bist eben auf irgendwelche Anforderungen. Deswegen nicht zu viel Future-Ingenieren, nicht zu viel sozusagen Andammentreffen über Dinge, die man noch gar nicht weiß. Werde ich in zwei Jahren Produkte so managen? Werde ich diese Features brauchen in CMS oder wird mein Shop das und jenes können müssen? sondern zu gegebenen Zeit dann schlank und kleinteilig auf auftretende Marktveränderungen reagieren, ist, glaube ich, so die Best Practice, die es da gibt.

Joel Kaczmarek: Ja, da können wir doch mal ein Beispiel aus der jungen Vergangenheit auch heranziehen. Wenn ich mich richtig entsinne, war es ja Lidl, das mit SAP zusammen 500 Millionen Euro versenkt hat. Ich glaube, es war ein ERP-System, was sie von denen gekauft haben.

Boris Lokschin: Genau, es war ein ERP-System, ja, und das war schon irgendwie ein sehr substanzieller Betrag, ja. Da wird es wahrscheinlich eine Milliarde Facetten geben und ich glaube, man muss da auch differenziert drauf gucken, ja, was tatsächlich sozusagen da Wahrheit ist, ja, und was eher jetzt im Markt daraus gedreht wird. Aber ich glaube, am Ende des Tages, ich glaube, was erschreckend ist, ist, wie weit man sozusagen kommt in so ein Projekt, bis man sozusagen eine Reißleine zieht. Ich glaube, das wäre meine Frage sozusagen an das ganze Setup. Warum muss man 500 Millionen versenken? Warum sieht man nicht nach 20 versenkten Millionen, dass es in die falsche Richtung geht oder nach 30 oder nach 50? Warum muss sich erst ein so großer Betrag akkumulieren? Da scheint ja sozusagen ein ganzes Setup und Netzwerk auch an Dienstleistern und anderen Leuten davon profitiert zu haben, die vielleicht nicht unbedingt profitieren. rechtzeitig die Fahne gehisst zu haben, dass da irgendwie was nicht in die richtige Richtung geht.

Joel Kaczmarek: Mal unabhängig davon, wer da jetzt irgendwie Mist gebaut hat oder ob das vermeidbar war, wenn du jetzt ein Lidl wärst und sagen wir mal, es hätte den Fall jetzt nicht gegeben, du sagst, ich möchte irgendwie ein ERP bauen, was sich über x Standorte ausbreiten lässt, über x Länder, es soll dies, das, jenes können und sagst, monolithische Systeme sind problematisch, also wir lassen mal SAP und Oracle irgendwie außer Acht, was soll so jemand denn tun, um dieses Problem zu vermeiden, dass er ein monolithisches System einsetzt oder sogar baut?

Boris Lokschin: Also ich glaube, man muss ein bisschen unterscheiden zwischen zwei Begriffen. Also sozusagen monolithisches System ist erstmal sozusagen einfach der technischere Begriff dafür, dass ich einfach ein großes Stück Software habe. Einfach diesen großen Klotz, ja, versus eben irgendwas sehr Modulares und in einzelne Bauteile zerlegbares. Ich glaube, das muss man abtrennen oder sozusagen abgrenzen von dem Begriff Standardsystem. Also ich glaube schon, dass nicht jeder Prozess in einem Unternehmen und insbesondere nicht sozusagen Backend-Prozesse unterliegt der permanenten Veränderung. Beziehungsweise nicht permanente Veränderungen in der gleichen Geschwindigkeit. Deswegen gibt es ja auch Standardsysteme, wenn ich mir an sowas denke, wie Finanzbuchhaltung, Debitorenmanagement, vielleicht sogar auch Einkauf, Logistik, irgendwelche HR-Themen. Die haben natürlich bei weitem nicht den Anspruch oder die Anforderung, zehn Deployments pro Tag verändert, angepasst und permanent vertestet zu werden, wie vielleicht eher kundenzentrischere Funktionalitäten. Das heißt nicht, dass man die zehn Jahre so belassen muss und dass man da nichts tun muss. Vielleicht im Finance-Legal-Bereich noch seltener, aber im Bereich Logistik-Einkauf kann man sicherlich auch was tun. Vielleicht in einem Quartalsrhythmus oder einem Halbjahresrhythmus. Aber man muss sich überlegen zuerst als eben großer Konzern, was sind eben wirklich Standardprozesse, wo ich eine relativ lange Haltbarkeitsdauer sehe, wo ich mir auch erlauben kann, maximal standardisiert ranzugehen und dann aber auch standardisiert ranzugehen. Also dann nicht sozusagen den Fehler zu machen, naja, ich kaufe jetzt ein Standardsystem und wenn ich dann sozusagen, und das ist so die große Frage, die ich mir dann immer stelle bei solchen Projekten, Wenn ich ein Standardsystem kaufe, dann erwarte ich ja, dass es auch ein Standardsystem ist. Das heißt, meine Expectation wäre, dass ich mit verhältnismäßig wenig Customizing, also wenig für mich speziell entwickelten oder angepassten Funktionalitäten durch die Tür komme. Wenn ich jetzt ein Standardsystem kaufe und trotzdem tausende von Mantagen reinhaue, dann bleibt natürlich die Frage offen, was habe ich denn eigentlich tatsächlich da gemacht. generischer Wissenslogik gekauft. Das heißt, so ein Lidl oder auch andere Konzerne müssen sich eben sehr, sehr gut überlegen, was sind sozusagen Hypothesen über Prozesse, die sehr, sehr nachhaltig sind, wo es wahrscheinlich nicht viele Veränderungen gibt. Da lieber dann Standardsthemen kaufen und die auch schlank und schnell einführen, also standardisiert, dann ist es auch schnell, dann ist es auch kosteneffizient. Und dann sich zu überlegen, okay, wo habe ich denn jetzt Bauteile oder Baustellen, bei denen ich mit großer Wahrscheinlichkeit, weil sich gesetzliche Regeln ändern, weil sie vielleicht länderspezifisch sind, weil sie vielleicht Markt, Preis, irgendwie Dynamiken unterliegen, wo ich relativ genau weiß, dass das nicht fünf oder sechs oder sieben oder acht Jahre konstant sein wird. Und wenn ich dann in so ein Projekt reinlaufe, was dann schon von vornherein auf mehrere Jahre ausgelegt ist und wo ich de facto ein fertiges Pflichtenheft darunter implementiere, dann habe ich schon im Setup was falsch gemacht. Das heißt, ich muss mir, glaube ich, sehr, sehr gut abgrenzen zwischen Standard versus Nicht-Standard und dann eben überlegen, wo habe ich mehr Tempo drauf, wo habe ich wenig Tempo drauf und das dann aber auch sauber konsequent einhalten. Genau das passiert dann eben in der Realität häufig nicht. Ich habe dann Standardprojekte, die dann doch nicht so standardisiert sind. Genau.

Joel Kaczmarek: Ja, das ist schon ein valider Punkt. ERP-System ist halt auch ein sehr spezifisches Beispiel. Wenngleich es ja viele Unternehmen gibt, die daran auch teilweise wirklich pleite gehen. Also es ist ja bei vielen schon so ein Genickbrecher-Thema gewesen. Bietet uns aber, also das zweite Problem, bietet uns auch jetzt eine charmante Überleitung zum dritten. Da sollten wir mal überreden über Synchronisation. Also wenn man interne Systeme parallel laufen hat, aber auch vielleicht gerade in Kontrast zu externen. Ist das was, wo du auch oft Problematiken bemerkst?

Boris Lokschin: Ja, absolut. Also das ist gerade im Commerce-Umfeld super relevant. Ich kann natürlich sozusagen beim Scopen meines E-Commerce-Projekts relativ gut durch die Tür kommen. Ja, ich kann mir überlegen, wie sieht mein Shop aus? Ich kann vielleicht nochmal dann einen Implementierungspartner ins Boot holen. Ich kann nochmal den kreativen Teil gut abgrenzen und sagen, okay, da gibt es vielleicht jemanden oder es ist vielleicht der gleiche wie der Implementierungspartner, der sich sozusagen um das Design kümmert und die UX. So kompliziert wird es natürlich dadurch, dass selbst eine E-Commerce-Plattform heute ja nicht isoliert im Markt steht, sondern ich habe natürlich diverse Anbindungen zu sogenannten Drittanbietern. Ich habe eine Integration mit Payment-Anbietern, mit Risikomanagementlösungen, Bonitätsprüfungen, Logistikern, irgendeiner externen Suche, externen Empfehlungsengine, Social-Media-Tool, Newsletter-Tool und, und, und, und, und. Also das können ganz, ganz schnell 10 bis 20 kleine Bubbles rund um eine Commerce-Plattform werden, die allesamt ihre kleine Schnittstelle mitbringen, in unterschiedlicher Qualität, vielleicht von unterschiedlichen Leuten entwickelt und irgendwie supportet, mit auch ganz eigenen Timelines. So ein Klassiker, gerade so in größeren Commerce-Projekten ist, ich habe dann meine Lead-Agentur, aber ich habe sozusagen keinen damit beauftragt, eigentlich die anderen zehn Dienstleister mitzusteuern oder die anderen zehn Partner. Der Payment-Provider stellt dann seine Spezifikationen bereit, in der Geschwindigkeit, in der er es möchte, Der Logistiker testet hinterher dann im End-to-End-Test, dass dann wann die Zeit dafür haben, weil einfach keiner den komplett übergeordneten Hut, man nennt das dann auch nicht Projekt, sondern Programm. Ich habe dann ein Programm, Einführung von dem neuen großen E-Commerce-System für Joel. Dieses Programm besteht eben dann aus mehreren Blöcken. Das ist dann irgendwie das Commerce-Thema. Vielleicht führst du parallel ein neues PIM ein. Vielleicht gibt es sogar noch eine CMS-Komponente. Da hast du irgendwie ein neues Warehouse. Und das im Überblick zu behalten, aufeinander abzustimmen, diese ganzen Dienstleister zu orchestrieren, die auch ja alle ihre eigenen Contracts haben, auch festzustellen, wo ich eigentlich Lücken habe. Das ist eine Fähigkeit, die ganz, ganz, ganz häufig fehlt, weil die meisten ja das erste Mal sich oder das erste Mal im großen Ziel sich mit dem Commerce-Thema beschäftigen. Das heißt, du stellst ihn halt hin, selbst wenn du irgendwie einen internen Projektleiter assigned hast, der da versucht, Diagramme zu zeichnen und so einen roten Pfad zu determinieren, dann hat derjenige inhaltlich vielleicht nicht den kompletten Durchblick, also kompletten Durchblick im Sinne von, er macht das erste Mal oder das zweite Mal. Er weiß gar nicht, also er versteht vielleicht inhaltlich nicht, bis wann muss wer eigentlich was getan haben, damit sinnhafterweise Partei X oder Y, wie beim Hausbau, wenn das eine Gewerk nicht fertig ist, dann Ist halt doof, irgendwie da den Boden zu legen, wenn derjenige, der die Fußbodenheizung verlegt, doch gar nicht drin war. Sowas kann ich natürlich nicht auf einem Gantt-Chart lösen, sondern ich muss verstehen, hey, wer muss rein, wer legt irgendwie den Estrich, wer legt den Boden, wie lange trocknet irgendwas. Und diese Art von Verständnis und diese Art von Projektsteuerung, fehlt halt sehr häufig gerade in größeren Projekten. Das ist auf jeden Fall ein ganz, ganz wichtiger Tipp,wenn man das nicht selber im Haus hat,diese Kompetenz, sich die definitiv einzukaufen. Das ist auch eine gute Position,die man gut einkaufen kann,weil dafür gibt es viele Experten,viele gute Berater,die das einfach durchsteuern,durchsteuern, durchsynchronisierenund die auch, by the way,die Accountability haben und auch die Power haben,diese Dienstleister auch anzusprechen, weilganz viele Projekte erlebt, bei denendann der Kunde, die Dienstleistersich sozusagen untereinander ausmachen lässt,und selbst bei maximaler Motivation,maximaler Bereitschaft,alle ein Projekt zum Erfolg zu führen,ist das natürlich super schwierig,weil keiner dem anderen hier rein diktieren kann. Ich kann dich fragen, Joel,bis wann hast du deine Schnittstelle getestet,dann sagst du mir, bis morgen,passt mir jetzt zwar nicht,sag ich, kannst du auch heute,dann sagst du, nee, kann ich nicht,sagst du, okay, ich habe ja gar keinen Durchgriff,ich bin gar nicht dein Auftraggeber. Von daher ist das ein ganz, ganz häufiger Fehler,der zu vermeiden ist.

Joel Kaczmarek: Es klingt doch nicht so trivial. Kann man das wirklich so effizient steuern? Weil in meiner Erfahrung ist immer Projektmanagement mit je mehr Stakeholder, desto more pain und desto mehr Verzögerung eigentlich. Also das ist ja der pure Schmerz.

Boris Lokschin: Was heißt, kann man es steuern? Also die gute Nachricht ist sozusagen, die Risiken bei sowas sind relativ klar. Also es ist sozusagen selten was Überraschendes dabei. Also du musst deine Übersicht haben, du musst sozusagen die Partnerinnen abstimmen. Es gibt irgendwie auch die Tools und die Methodiken, um das zu machen. Es ist jetzt so, kein Rocket Science, aber es ist einfach knallharte handwerkliche Arbeit und das ist wirklich auch nichts, was dann in so einer Rolle abgewickelt werden kann. Also auch häufiger Fehler, man sieht dann irgendwie den Joel in der Firma Y, der hat eigentlich schon 200% zu tun, da wird gesagt, du hast jetzt die Rolle hier Projektmanager für das neue Re-Platforming-Projekt zu sein. Und selbst bei aller maximaler Einsatzbereitschaft kannst du das nicht leisten, weil das ist halt ein Fulltime-Job und eigentlich sogar mehr. Du bist mit allen permanent da, du sitzt im War Room, idealerweise holst du die Partner alle irgendwie regelmäßig an den Tisch. Also man kann es steuern, aber man muss vorher sich darüber im Klaren sein, das ist eine super kritische Rolle, vielleicht eine der kritischsten. Wenn die fehlt dann ist es so, wie wenn der Bauleiter eben nicht auf der Baustelle ist. Kann der Architekt zwar ein gutes Haus designt haben und die Dienstleister haben auch alle gute Materialien dran gekarrt und jeder möchte auch, aber alle werden auch fleißig Rechnungen schreiben für die Stunden, die sie sozusagen leisten, aber am Ende steht dein Haushalt nicht, weil einfach das nicht sauber aufeinander abgestimmt war.

Joel Kaczmarek: Was ja bei dir anklang, das ist ja nicht nur eine Frage von Synchronisation, sondern da kann man wahrscheinlich ein viertes Thema draus machen, letztlich auch eine Frage von Abhängigkeiten. Also was du gerade gesagt hast, Schnittstelle testen, kannst du das bis morgen machen, impliziert ja, ich brauche das aus irgendeinem Grund, weil irgendwas anderes darauf aufbaut. Sind Abhängigkeiten quasi auch in der Form zu sehen, dass man das neben der Synchronisation auch auf dem Schirm haben muss? Was zahlt eigentlich auf was ein? Was ist wie miteinander verheiratet?

Boris Lokschin: Absolut. Man kann hier so ein ganz einfaches, klassisches Beispiel machen, jetzt aus unserem Commerce-Umfeld. Du hast sehr häufig externe Systeme, in denen Produktdaten entstehen, sogenannte PIM-Systeme oder Produktmanagement. Du hast irgendwie Systeme, sogenanntes OMS, Order Management, da fließen irgendwie Bestellungen rein. Du hast vielleicht sogar nochmal irgendwie Systeme oder Services, in denen Preislogiken drin sind. Was Kostenpreis, gerade im B2B-Kontext hast du häufig sehr komplexe Preiskalkulationen, Preisregeln. Wenn du ein System baust, was eben nicht mit diesem Drittsystem sauber kommuniziert oder was dir selbst für den Test nicht die realen Produktdaten zur Verfügung stellt, weil du hast dein PIM-Projekt verzögert oder das Team, was ihm bereitgestellt hat, ein PIM-Tool, hat noch gar keine Daten erstellt, dann hast du natürlich ein Problem. Dann testest du ein Shop-System oder ein Commerce-System, in dem einfach die Daten nicht drin sind oder du mit irgendwelchen Demodaten testen musst, was irgendwie fern ist von dem, was du wirklich hast. So eine Bestellung kommt zwar virtuell rein, aber der Zahlungsanbieter ist nicht angebunden. Das heißt, die Zahlung mit der Kreditkarte vertestest du auch nicht richtig. Und irgendwie die Bestellung wird auch nicht an das Order Manager daraus gegeben. Und du siehst sozusagen den End-to-End-Test nicht, ob das Lager wirklich irgendwas in Päckchen tun würde und das eben dem Joel schickt. Also von daher, wenn sozusagen die Abhängigkeiten nicht klar geregelt sind, also das eine ist eben Kommunikation, aber das andere ist auch Bereitstellung von Daten, von Testdaten, von realen Daten. Oder auch so ganz einfache Dinge wie z.B. Infrastruktur. Wenn ich über sowas nachdenke wie Hosting. Ich brauche für alle Systeme heute irgendeine Form von Hosting-Environment. So habe ich jetzt den Vertrag mit dem Anbieter nicht geschlossen. Schwierig, ja, dann teste ich irgendwie auf dem Rechner des Developers der Agentur, ja, aber mal zu sehen, wie schnell ist der Shop eigentlich wirklich, ja, wie performant ist das, vielleicht auch mal einen Performance- oder Lasttest zu machen und zu sehen, hey, was passiert denn, wenn ich mal so die 1000 oder 10.000, 100.000 Besucher drauf jage, die ich eigentlich auch erwarte, ja, ist das dann immer noch schnell oder ist das irgendwie grottenlangsam? Funktioniert dann halt nicht. Das heißt also, es ist Koordination und Abhängigkeit eben insbesondere von Daten.

Joel Kaczmarek: Gut, also beides ein Stück weit verheiratet lerne ich. Also nochmal zusammengefasst, erstes Thema Produkt am Kunden vorbei entwickeln, zweites Thema monatliche Systeme, drittes schlechte Synchronisation, viertes starke Abhängigkeiten. Du hast ja auch noch einen Punkt gesagt, den kann man vielleicht auch zum eigenen Problem nochmal machen, denke ich, was du gesagt hast mit dem Thema Ownership. Also es klang für mich jetzt so raus, dass du sagst, der Geist ist willig, aber das Fleisch ist schwach. Sprich, man hat gar kein Fleisch benannt, was dem Geiste da folgen soll. Ist das eine häufige Problematik?

Boris Lokschin: Also es tritt sehr häufig auf. Also entweder das, was ich vorhin gesagt habe, dass du sozusagen Owner hast, die eigentlich mehr eine Rolle sind. Und demjenigen, der das Projekt sozusagen der Sponsor, wie man so schön sagt, des Projekts ist, dem ist halt nicht klar. Oder er spart einfach am falschen Ende. Da wird eben nicht der Produkt oder Projektverantwortliche gestellt. Und es gibt sozusagen nicht denjenigen, der, wie man so schön sagt, 100% accountable ist dafür. Das ist natürlich schwierig, weil ich am Ende des Tages in heutigen digitalen Setups sehr viele verschiedene Gewerke oder Rollen zu koordinieren habe. Wie gesagt, Drittabhängigkeit, intern Abhängigkeiten, ganz viele interne Teams. Ich habe irgendwelche Leute, die irgendwas testen. Ich habe Leute vielleicht aus dem Customer Service. Ich habe Leute aus der Produktanlage, aus dem Produktmanagement. Ich habe Vertrieb Marketing, die da drauf gucken müssen. Wenn ich da keine Ownership haben, wenn niemand sich sozusagenend-to-end verantwortlich fühlt. Wenn niemand da sitzt und sagt, hey,das ist mein Baby, das ist sozusagen meine Plattform,da schiebe ich auch nicht den schwarzen Peter hin und her,sondern ich bin derjenige, der Leuten hinterherläuft,der Dienstleister steuert und der am Ende gernegemessen werden kann an den Business KPIs,die hoffentlich so ein Projekt dann auch hat,was auch immer das ist, ob das jetzt Umsatz istoder Marge oderMarkanteil oder Kundenhappiness. Dann ist es super, super schwierig, sowas zu zukommen. Weil dafür ist die Komplexität heute in den allermeisten Projekten eben sehr, sehr groß. Wird nochmal künstlich größer gemacht durch die vorher benannten Fehler, ja, große Anforderungen, modische Systeme. Das kann ich natürlich alles klein schneiden und dann so mit einem sehr agilen, sehr MVP-lastigen Vorgehen das Risiko senken. Aber wenn ich das nicht tue, dann ist üblicherweise eben das ein ganz großer Block. Und dann habe ich keinen Owner und dann sitzen da zehn Leute und im besten Fall haben alle zwar einen guten Job gemacht, aber trotzdem passt das nicht zusammen. Und im schlechten Fall ist einfach nichts passiert. Alle haben irgendwie gearbeitet und waren irgendwie da, aber dann hört man sowas wie, ja, ich dachte, du wolltest das machen. Ich dachte, du? Und ich dachte, ich habe dir doch letzte Woche die Mail geschickt. Ja, aber da war ich doch nur in CC. Und und und, da habe ich solche Diskussionen. Und dann kommt eben nichts auf die Straße.

Joel Kaczmarek: Wie oft passiert sowas in der Praxis?

Boris Lokschin: Sehr häufig.

Joel Kaczmarek: Woran liegt das? Ich meine, du kannst noch nicht was Neues starten und eigentlich keinen in Vollverantwortlichkeit haben.

Boris Lokschin: Es liegt daran, glaube ich, dass die Komplexität des Vorhabens massiv unterschätzt wird. Das ist so ein bisschen so wie, vielleicht ist dieses Hausbeispiel auch ganz gut. Es gibt ja immer viele Leute, die dann versuchen, an dem Bauleiter oder an dem Projektleiter zu sparen und sagen, komm, ich mache das selber. Ich fahre halt jeden Tag raus auf die Baustelle. Ich habe jetzt ganz viele Freunde, die irgendwie in den letzten Jahren gebaut haben und die sagen irgendwie alle das Gleiche. Das ist halt die komplette Hölle. Am Ende lebst du auf dieser Baustelle und bist jeden Tag dort. Am Ende wird trotzdem alles 20, 30 Prozent teurer. Und wenn du jetzt nicht gerade selber Ingenieur bist und das irgendwie überblickst, dann verstehst du die Sachen halt auch nicht gut. Dann managst du das einfach nicht effizient. Und genau so ist es hier auch. Ich glaube, viele, die jetzt mit dem Commerce-Thema starten, gehen dann auch ein bisschen zu leichtfertig ran, sehen das eher noch so als, naja, das ist halt ja irgendwie ein Shop-System oder das ist ja irgendwie eine Website. How hard can it be? Und dann verstehen sie eben nicht, dass das der Core des Geschäfts nach vorne raus,dass das eben integriert ist mit 10Drittanbietern, mit deiner Warenwirtschaftverheiratet, dass du dairgendwie nochmal 15parallele Verträge schließen musst,mit der Agentur, mit dem Design-Dienstleister,mit einer Firma, die das vertestet,mit dem Hoster, mit dem Payment-Provider. Also dass es sozusagen nicht nur technischund technologisch, sondern auch einfachadministrativsuper komplex ist. Und da kannst du eigentlich nur verlieren. Dieses Geld, was du dann versuchst einzusparen,das legst du halt hinterher 3, 4, 5 mal drauf,weil natürlich dann alle Dienstleister Ohne, dass sie dir was Böses wollen, einfach, wie gesagt, fleißig ihre Rechnung schreiben werden. Dann hast du ihnen diesen Projektkoordinator unnötig gespart.

Joel Kaczmarek: Mal ganz bodenständig gesprochen. Es geht ja am Ende des Tages viel um Innovation, um eine gewisse Ambition vielleicht auch. Also so eine gewisse Ambitionsbereitschaft. Kann das auch ein Thema sein, was am Ende des Tages zu einem Problem wird? Also, dass man das entweder gar nicht tut, also dass man diese Innovations- und Ambitionsentscheidung entweder gar nicht trifft oder falsch trifft?

Boris Lokschin: Das sehen wir sehr, sehr häufig. Das passiert, glaube ich, schon vorher. Also das ist dann tatsächlich erstmal noch gar nicht ein IT-Problem, sondern es ist ein grundsätzliches strategisches Problem, was so Digitalisierung angeht. Und das würde ich schon irgendwie in zwei Dritteln der Fälle mindestens sehen, zumindest jetzt in dem Szenario, in dem wir auch unterwegs sind. Was passiert konkret? Leute starten sowieso schon viel zu spät in die Digitalisierung, in den meisten Verticals, also viel zu spät gemessen an dem, was für ihre Produktkategorie schon da ist. Es gibt meistens dann schon sehr gute digitale Wettbewerber, es gibt dann vielleicht irgendwelche Marktplätze, es gibt Amazon immer oder fast immer für jeden Produktbereich. Das heißt, ich starte schon viel zu spät, ich bin jetzt gar nicht der Greenfield Case. Was bedeutet das? Das bedeutet ja, dass es eine gewisse Mindestbarriere, einen gewissen Threshold an Kundenerwartungen gibt. Der Kunde hat irgendwie schon gelernt oder dem wurde beigebracht von jemand anderem, was sind Minimalanforderungen, minimale Features, die ich erwarten kann, eine minimale Geschwindigkeit der Seite, an die ich mich gewöhnt habe, dass ich jeden Tag Dinge zurückschicken kann. Wie muss eine Suche funktionieren? Also diese technische und anforderungsseitige Hürde muss ich erstmal nehmen. Ich habe auch eine Minimalanforderung im Hinblick auf Marketing und Online-Marketing, weil man darf nicht vergessen, der Kernskill, den sich die Leute ja auch aneignen müssen, ist ja gar nicht irgendwie eine schönere Hose einzukaufen, sondern Kundenakquise und Kundenretention zu lernen. Also wirklich digital, Customer Acquisition und Retention müssten ja eigentlich die digitalen Skills sein, die ich brauche. Das heißt, dazu gehört auch eben effizient mit Performance-Markten, Online-Markten, BI umzugehen. In den allermeisten Verticals oder Industrien, die sind ja schon insofern gut digitalisiert, als dass ich ja nicht der Erste bin, der auf irgendein Keyword bietet bei Google, Facebook, Amazon und Co. Das heißt, auch da ist es ein relativ teurer Spaß. So, wenn ich dann jetzt diese ganzen Parameter zusammenbringe und sage, naja, ich habe einen Händler zum Beispiel, der relativ spät schon startet mit Digitalisierung allgemein, der dann startet in einem schon vorhandenen Wettbewerbsumfeld, bei dem Kunden eine relativ hohe Erwartung haben an Funktionalität, Technologie, Komplexität des Setups im Backend, das einen hohen Marketing-Threshold gibt und dann gehe ich rein und möchte aber mit wenig Geld irgendwie einen kleinen Shop hinstellen, ja. budgetiere komplett sozusagen am Markt vorbei, also setze Budgets auf, die mir wirklich vor zehn Jahren mich hätten irgendwie nochmal nach vorne bringen können, aber bin einfach total unambitioniert, dann führt das meistens zunächst. Dann kann ich das Geld de facto sparen, weil das, was ich da baue, wird auf gar keinen Fall zum Erfolg. Es muss nicht immer ein Budget ausgerichtet sein. Häufig kann es auch ein Anforderungsthema sein. Das heißt, ich baue de facto etwas, was absolut Standard ist, also was Da gibt es so diesen Begriff, so Customer Excitement. Da gibt es so Dinge, mit denen überrasche ich einen Kunden. Da sagt ein Kunde, hey, der verkauft zwar das gleiche Produkt wie Firma XYZ, aber macht das halt besser, schneller, weiter. Ich kann jetzt endlich über, weiß ich nicht, Voice kaufen oder ich habe jetzt endlich eine coole Mobilapplikation. oder hey, die haben verstanden, wie man super personalisiert. oder hey, die liefern das schneller, weil die irgendwie eine smartere Logistik haben. Wenn ich mir nichts überlege, was irgendeine Form von Customer Excitement oder auch USP oder Differenzierung bringt, sondern einfach nur von zehn Websites die Feature zusammen kopiere und klaue in meinen RFP, ich möchte so ein Checkout wie X und eine Suche wie Y und Filter wie Dann baue ich natürlich einfach eins zu eins den Markt nach. Das mache ich dann meistens natürlich ein paar Monate lang. In der Zeit haben diejenigen, von denen ich kopiert habe, sich ja schon wieder weiterentwickelt. Und dann ist mein Ambitionslevel komplett falsch. Und da muss man sich dann schon die Frage stellen und die Frage geht dann auch nach ganz oben. Was wollt ihr eigentlich? Also ist das ein Lippenbekenntnis? Wollt ihr einfach mal ein System hinstellen, um alles hinzustellen? Oder habt ihr hier seriöse Ambitionen? Wollt ihr Marktanteile gewinnen? Wollt ihr auch online der Category Leader sein für das Produkt? Und dann muss man von den Anforderungen, von der Budgetierung, vom Teamsetup ganz, ganz anders rangehen. Also Team ist auch so ein Thema. Dann sagen die Leute, wir wollen jetzt ernsthaft digitalisieren. Dann fängst du an mit denen darüber zu sprechen,was sie denn planen für ein Team aufzubauen,dann sagen sie so, okay, wir haben jetzt hierfür die nächsten zwölf Monate haben wir jetzt hierzwei Planstellen bewilligt. Da sagst du, okay, Leute, ganz ehrlich,dann lasst es lieber, dann nehmt dieses Geldund kauft die zwei Leute eben von einer guten Agenturnochmal dazu, weil das ändert gar nichts. Das ist so total unambitioniert. Das ist nichts halbes und nichts ganzes. Du wirst weder ohne eine schmibbige Technologie,du wirst eigentlich nur der Agentur im Weg stehen,weil die zwölf Leute, die auf der Agenturseite arbeiten,werden es total doof finden, dass da irgendwiezwei Leute mit einzufangen sind. Also Ambitionslevel, budgetseitig oder scropeseitig muss richtig gesetzt werden und auch ausgerichtet sein an der Upside. Also ich muss mir auch überlegen, das ist so die letzte Übung, was ist denn eigentlich ein relevantes Outcome? Also ein Beispiel, was wir häufig zitieren, mal hier anzubringen, als ich angefangen habe mit E-Commerce vor 15 Jahren und die ersten Händler zu uns kamen, die Businesspläne uns gezeigt haben und davon geträumt haben, 10 Millionen online umzusetzen, Das war viel, also das galt als groß. 10 Millionen online, das ist schon irgendwie super krass. So, dann irgendwie ein paar Jahre später war relativ klar in Bereichen wie Fashion und Co., dass wenn ich nicht die Ambition habe und am Horizont mal die 100 Millionen Umsatzmarke sehe, dann werden sich viele der Investitionen, die ich jetzt eigentlich tätigen muss in Customer Acquisition, Retention, Tech, Online-Marketing, werden sich nicht mal auf dem Papier refinanzieren lassen. Also der Business Case wird de facto nie fliegen. So, wenn ich jetzt heute darauf gucke, wieder, ja, Fashion, Elektronik, irgendwie andere Bereiche, dann ist ja ganz häufig eigentlich die Milliarde mittlerweile die Größe. Wenn ich heute versuche, im Fashion-Bereich loszulegen und ich habe nicht eine Ambition, dort ein Milliarden-Business draus zu machen online, dann werde ich alles, was ich investieren müsste, um mindestens auf Level X zu sein mit den entsprechenden Wettbewerbern, Da werde ich nie einen positiven ROI irgendwie draus ziehen. Und das muss ich mir natürlich vorher überlegen. Das muss nicht immer so viel sein. Es gibt natürlich ganz viele Verticals, wo ich mir deutlich weniger Euros, trotzdem noch einen profitablen Case nach vorne rausbauen kann, theoretisch. Wenn ich das aber nicht mache, diesen Dreisatz, dann werde ich nie matchen, ob das Investment, weil Investment ist ja immer relativ. Ich kann sagen, ich investiere jetzt eine Million Euro und das ist vielleicht für einen Case, bei dem ich irgendwie 100 Millionen Euro rausholen kann, ja eine super, super Wette. Wenn ich irgendwie eine Million investieren muss, um im besten Fall zwei rauszumachen, ist vielleicht keine so gute Wette. So, das muss ich schon noch tun.

Joel Kaczmarek: Kannst du nochmal ein bisschen plastischer machen, warum diese Gap nochmal größer geworden ist? Also der Laie hört jetzt vielleicht zu und sagt sich, naja, Moment, die Erstellungen für so einen Shop sind aber doch die gleichen. Warum muss ich jetzt schon eine Milliarde Umsatz machen und nicht mehr irgendwie 100 Millionen? Wenn ich da mithalten will, ist das Investitionsvolumen so stark gestiegen. Was macht da eigentlich quasi den Benchmark aus? Also woher kommt das Delta?

Boris Lokschin: Also im Wesentlichen sind es zwei Komponenten. Die einfachere ist, was kostet es mich, Kunden heute zu akquirieren? Das ist wirklich so vereinfacht gesprochen das Online-Marketing, da Online-Marketing ja primär über Plattformen passiert, Google, Facebook, Amazon und Co. Und diese Plattformen schlauerweise natürlich alle als Marktplätze in so einem Mietermodell unterwegs sind, das heißt also de facto einer ganz klaren Mieterlogik unterliegen und Leute die, wenn drei Händler ein blaues T-Shirt von Marke X verkaufen wollen, dort die entsprechenden Keywords oder die entsprechenden Landingpages bewerben. Da wird natürlich das Facebook oder das Google oder Amazon denjenigen nach oben stellen, der mir am meisten Geld gibt. Und da es natürlich immer mehr Willige gibt pro Kategorie und immer mehr sozusagen zur Auktion erscheinen und mitbieten wollen, steigt natürlich der Preis. Wer profitiert? Natürlich die Plattformen. Die verdienen sich dumm und dämlich, wie man ja auch schön aus der Presse sehen kann, was die sozusagen für Milliardengewinne und mit welchen Wachstumsraten, die unterwegs sind, führt dazu, dass natürlich der Margendruck bei mir eben erstmal als Händler in dem E-Commerce-Umfeld total zunimmt. Also das ist das eine. Und wie gesagt, da sind einige Branchen stärker davon betroffen. Natürlich umso einzigartiger mein Produkt oder umso spezieller mein Produkt, umso einfacher habe ich es. Wenn ich irgendwas bewerbe, was keiner hat, dann kann ich mich natürlich leichter positionieren, habe aber vielleicht wahrscheinlich auch eine kleinere Mark zur Verfügung. Also umso generischer so ein Produkt ist, umso schwieriger. Das ist das eine, also Marketing, Online-Marketing. Und das andere ist, das, was ich vorhin eben gesagt habe, die Erwartung des Kunden an Funktionalität. Um das vielleicht so plastisch mal zu sehen, nochmal am persönlichen Beispiel, am eigenen Beispiel, als wir angefangen haben mit E-Commerce vor 15 Jahren, war es relativ simpel. Da kamen die Leute und da war der Katalog auch nicht so lang. Da haben sie dir so den Print-Katalog auf den Tisch gelegt, diese Produkte, die müssen auch online gezeigt werden. Meistens war noch nicht mal die Anforderung da, dass Bilder da sind. Man wollte einfach nur sozusagen die Texte, Wenn du Bilder gesendet hast, das war schon ein Customer-Excitement-Faktor, da waren Kunden schon begeistert. Da hattest du nicht 10 Zahlarten und irgendwie 15 Integrationen und hier Risikomanagement und Bonitätsprüfung, Adresscheck im Checkout. Da hattest du irgendwie eine Zahlart, meistens auch noch auf Vorkasse, weil alle Angst hatten, beschissen zu werden. Da hattest du irgendwie einen Logistiker und aus die Maus. Das war ein relativ einfaches Setup und wenn du das Produkt dann wirklich auch geliefert bekommen hast, warst du der König. hast du super viele Antworten, was die Suche angeht. Du kannst super viele Feature da einbauen in die Art und Weise, wie Produkte gezeigt werden und Autokorrektur und Vorschau-Funktionen und kleine Bilder und dann auch noch am besten anhand der Lagerbestände irgendwie die Produkte nach vorne stellen. Dann hast du Personalisierung, dann hast du irgendwie super Filter, dann hast du auch nicht nur den Desktop, sondern du hast irgendwie x Plattformen. Du hast nicht mehr einen Browser wie vor 15 Jahren, sondern du hast irgendwie 10 Browser in verschiedenen Versionen. Du hast mobil Du hast responsiv. Du willst vielleicht was an einem Voice, Chatbot, etc. Device, irgendwie Touchpoint machen. Du hast zehn Logistiker angebunden. Und, und, und. Diese Komplexität nimmt natürlich zu und wird natürlich primär auch wieder durch die großen, erfolgreichen Spieler im Market-Team, die sich das auch leisten können, die genau das Richtige tun, nämlich permanent mit großen Teams dem Kunden immer wieder neue Dinge beibringen und vorsetzen im eigenen Interesse. Sag, hey, guck mal hier, Joel. eine noch bessere Suche. Oder guck mal hier, du kommst jetzt mit noch weniger Klicks zu deinem Kauf oder du kriegst jetzt hier noch schöne Bonuspunkte und ein schönes Loyalty-Programm. Du kannst jetzt auch per Sprache kaufen. Und umso häufiger das passiert, umso mehr lernen wir natürlich als Konsument. Und irgendwann wird das zu einer Basiserwartung. Ein schönes Beispiel, glaube ich, einfach für alle nachvollziehbar, Wenn du sowas wie, hat jetzt nichts mit IT zu tun, aber wenn du sowas wie eine kostenlose Rücksendung, die glaube ich von Zalando wirklich sehr stark in den Markt gepusht wurde, dem Kunden beibringst, dann wird das zu einem Standard und damit eben zu einer de facto Mindesterwartung. Dann hast du natürlich als jederjenige, der heute startet und plötzlich irgendwie 14 Tage oder 30 Tage Rücksendung anbietet und 4,99 Euro vielleicht haben will und nicht kostenlosen Versand, hast du eben direkt einen Nachteil geschaffen, weil das nicht der Basiserwartung entspricht. Und diese beiden Faktoren, Marketing und Feature, steigen permanent und führen eben dazu, dass sozusagen Kosten und Anfangsinvestitionen und dann natürlich im Hintergrund Logistik wird komplexer und mehr Produkte, mehr Sortiment, also es gibt noch mehr Faktoren, aber das sind glaube ich die zwei größten, wesentlichsten.

Joel Kaczmarek: wieder das Thema mal vertiefen, ganz kurz, weil irgendwie das betrifft dich ja relativ direkt. Kannst du ja vielleicht mal erklären, wie ihr das eigentlich macht? Weil ich meine, ihr seid ein Shop-System oder ich darf euch eigentlich nicht Shop-System nennen, ihr seid ja ein Commerce-OS, sagt ihr ja immer. Also ihr stellt euch ja hin und sagt, wir sind jetzt kein Magento, weil wir sind nicht irgendein steifer Laden, der nach einer Struktur arbeitet und vorgibt, sondern wir sind eigentlich stark modular, Microservice getrieben und so weiter und so fort. Das heißt, du bist genau in diesem Windsturm drin, dass du diesen ganzen Scheiß, der irgendwie innovativ ist, ich will jetzt per Chatbot kaufen oder per Alexa oder Keine Ahnung, es muss irgendwie Smartphone-tauglich sein. Das musst du mir alles liefern. Wie macht ihr denn das, dass ihr diesen Innovationsgrad und diesen Investmentgrad irgendwie hinkriegt auf der Ambitionsseite?

Boris Lokschin: Das ist eine gute Frage. Also ich glaube, was uns sehr stark leitet und das ist auch, dass jeder auf sich mappen kann. Ich glaube, der Jeff Bezos hat von Amazon das mal sehr, sehr gut definiert, dass das einfach bei einem permanent hohen Veränderungsdruck im Markt, dass es nicht so schlau ist, zu versuchen, all diese Variablen, die sich halt permanent drehen und viele der Zahnräder sind ja auch ineinander greifend. Du drehst am einen Rad und dann passiert irgendwo anders wieder was. Es ist nicht so schlau zu versuchen, diese zu managen, sondern lieber für sein Geschäftsmodell die Konstanten zu finden, also Dinge, die sich nicht verändern. Also im Fall von Amazon haben die das sehr gut definiert, haben gesagt, hey, das ist irgendwie der geringe Preis oder der tiefstmögliche Preis, das ist eine große Produktauswahl und das ist eine gute, schnelle Logistik. Das sind die Cornerstones, das sind die drei Konstanten. Es ist nicht denkbar, dass in zehn Jahren jemand kommt und sagt, hey, ich möchte irgendwie das Doppelte für das Produkt zahlen oder ich bin jetzt fein damit, dass es drei Tage später kommt. Wie die Lieferung dann passiert, also das Wie wird sich ändern, ob das eine Logistik ist, ob das eine DHL ausliefert oder die eigene Flotte oder ob das die Drohne bringt oder so gebeamt wird, das wird sich ändern. Daran muss man arbeiten, das wird permanent sozusagen mutieren, aber die Konstante ist eben die eigentliche Kundenerwartung. Das ist in unserem Fall genauso. oder in jedem Business muss man danach suchen, das ist vielleicht für ein Lebensmittelunternehmen sowas wie Frische, das wird sich nicht verändern, da wird keiner den Fisch für 50% Discount haben wollen, aber der Fisch lag dann schon drei Tage. Das heißt, das ist wahrscheinlich die Konstante, an der man arbeitet. Für uns sind das dann so Dinge wie im Time-to-Market oder irgendwie ein guter ROI, also schnelle ROI oder eine gute Total Cost of Ownership. Ich kann nicht absehen, dass ein Kunde zu uns in zwei oder drei Jahren kommt und sagt, hey, hör zu, ich möchte, dass mein Projekt jetzt doch wieder zwei Jahre dauert und nicht irgendwie innerhalb von 100 Tagen oder innerhalb von irgendwie 50 Tagen auf die Straße kommt. Ich bin fein damit, dass die Gesamtkosten für diese Plattform steigen, dass ich mehr Hardware brauche, mehr Lizenzkosten, mehr Developer-Tage, um sie zu customisieren, sondern Wir gehen davon aus, dass diese drei Parameter, ROI, TCO und Time-to-Market, die sind, die wir verbessern müssen. Und um die entlang versuchst du dann quasi zu bauen. Also ich weiß nicht, an welchen Touchpoints unsere Kunden oder die Kundinnen unserer Kunden werden kaufen wollen in drei, vier Jahren. Ich weiß nur, dass unser Job ist, das zu enablen, dass es eben maximal leicht ist, diesen Touchpoint anzubinden. Das heißt, dieses Thema API-first, Headless, also Unabhängigkeit von dem Touchpoint. Das ist das, was uns treibt. Wir überlegen uns, hey, wie kann ich sicherstellen, dass wir morgen irgendwie doch Wearables auf einmal hot werden, dass man das schnell adaptieren kann, dass es nicht wieder zu einem Zwei-Jahres-Projekt wird. Wie kann ich sicherstellen, dass wenn der Markt morgen in eine Richtung geht, in der Produktmanagement oder Ordermanagement dann in einem externen System passiert, dass dann die Leute nicht aufführen, Spryker zu nutzen, sondern einzelne Bausteine austauschen können. Das sind dann Dinge, die uns dann eher von der Denke her treiben. Also finde die Konstante in deinem Modell und versuch sozusagen, um sie herum dann zu innovieren.

Joel Kaczmarek: Letzte Frage zu unserem sechsten IT-Problem der Ambitionsentscheidung. Du hast gesagt, man sollte sich an der Upside orientieren. Ich erlebe das seltenst. Also die meisten orientieren sich immer eher an der Downside, an den Kosten und haben ja auch schon eine gewisse Legacy, die sie mitschleppen. Was kann man tun, wenn man solche Entscheidungen in seiner Firma eigentlich sozusagen forcieren möchte, also auch als Führungskraft?

Boris Lokschin: Also ich glaube, es ist super wichtig, der Kollege Florian Heinemann, glaube ich, hat im diversen Podcast das auch schon sehr, sehr schön erklärt, in den meisten digitalen Modellen, genauso wie auch in einem Venture-Capital-Umfeld-Fonds, ist es eher wirklich die Suche nach den zwei, drei Optionen, die mir hoffentlich irgendwie mein Geld wieder zurückspielen, versus eben Das Management von Risiken. Die Downside-Protection bringt halt nichts, weil die allermeisten im Markt, also wirklich die allermeisten, starten ja schon aus der Hinterhand. Das soll gar nicht so negativ klingen, aber sind halt dann nicht das Amazon oder nicht das Zalando, haben nicht Best-in-Class-Digital-Talent zur Verfügung, haben nicht den besten, coolsten Standort, haben vielleicht nicht die Corporate-DNA oder die Company-DNA, die sozusagen auch Leute anzieht, innovative Projekte denen bietet, haben vielleicht nicht die Kapitalausstattung, um so zu agieren. Das heißt, ich starte schon mit einem Setup, was erst mal gemessen an Market-Leadern in meinem Vertical vielleicht nicht das allerbeste ist. Und jetzt kann ich natürlich überlegen, ich kann entweder versuchen, die Downside zu managen, genauso wie eben auch ein Fonds versuchen kann, sich um die zwei, drei, vier Companies im Portfolio zu kümmern oder irgendwie ein Aktien-Fondsmanager, der kann natürlich versuchen, so die zwei, drei Aktien nochmal schnell abzuverkaufen, wo er vielleicht nicht die allerbeste Marge hat. Oder ich versuche eben tatsächlich in großer Geschwindigkeit die zwei, drei Kracher zu finden in meinem Portfolio oder in meiner Company. Also die zwei, drei Ideen, die zwei, drei digitalen Projekte. Gerade große Konzerne haben ja meistens nicht irgendwie das eine Projekt, sondern haben ja durchaus viele digitale Initiativen. Wenn ich da die Chance habe, mich auf das zu konzentrieren, was die größtmögliche Upside verspricht, das ist erstmal per se der richtigere Weg, als mich eben sozusagen managementtechnisch und auch kapitaltechnisch zu lange darum zu kümmern, ob ich jetzt nochmal 50.000 Euro mehr oder weniger verbrenne. Die Frage ist sozusagen, was sind die Incentives? Und da muss man fairerweise sagen, das ist etwas, was dann auch sehr häufig in Richtung der Eigentümer der Companies geht, also gar nicht so sehr in Richtung der Manager oder in Richtung des Ziellevels, sondern die Family Offices, die Private Equity Fonds, die Aktionäre, die müssen im Management richtige Incentives setzen. Die müssen sagen, solange ich den Joel, egal wie super talentiert du bist, daran messe, wie ein EBDA zum Beispiel aussieht, werde ich natürlich am Ende des Jahres immer versuchen, Kosten zu cutten und werde immer versuchen,sozusagen die zwei, drei Projekte noch schnellerzu killen, um da nochmal die 50.000 Euro hierund 150.000 Euro da auf der EBDA-Seite zu retten,würde ich eigentlich sagen, naja, hör zu,meine Management-Attention und irgendwie auchmeine Investitionspriorität liegt eigentlichauf den zwei, drei Projekten, die, wenn sie funktionieren,durch die Decke gehen, die mich dann wiederzum digitalen Leader machen für meinen Bereichoder die mich zum digitalen Leader machenin der Kundenkohorte, an der ich interessiert bin. Also richtige Incentive setzen, ja, durch eben Eigentümer der Companies, weil das sehen wir eben ganz, ganz häufig, ich kann den allerbesten Digitalmanager holen, ja, so wenn in seinem persönlichen Arbeitsvertrag, Bonusvertrag, Jahresbonus, Targets drinstehen, ja, die nicht digitale Transformation befeuern. Dann ist es sehr, sehr schwierig. Dann ist es, glaube ich, auch komplett menschlich und auch nicht zu erwarten, dass derjenige dann sozusagen gegen sein persönliches Interesse handelnd das Richtige für die Company tut.

Joel Kaczmarek: Aber gutes Stichwort. Was ist denn mit dem Faktor, dass es in solchen Betrieben, gerade wenn sie größer sind, immer unterschiedliche Abteilungen gibt? Dann hat ja jede Abteilung so ein eigenes Abteilungsziel. Und wir haben ja auch schon mal Cost-Center versus Profit-Center diskutiert gehabt, heute ein bisschen angerissen, letztes Mal etwas ausführlicher. Ich stelle mir als einen Faktor vor, der so eine Problematik auch sehr stark ansteuert, dass du halt Abteilungen hast, die eigene Ziele haben, die gar nicht auf so ein Gesamtziel irgendwie orchestriert sind.

Boris Lokschin: Ja, das ist doof, wenn das so ist. Und auch hier kommt wieder sozusagen das Führungsteam ins Spiel, jetzt nicht die Eigentümer, sondern wirklich sozusagen Management. Also gerade wenn ich versuche zu digitalisieren, zu transformieren oder zumindest der Digitalisierung ein größeres Gewicht zu geben, dann habe ich sehr, sehr häufig natürlich A, alte Welt versus neue Welt. Ich habe Leute, die vielleicht noch im klassischen Vertrieb unterwegs sind, Telefon, Kunden, Accountmanager sind, ja. die ja auch alle noch Jahresziele, Jahresboni und Co. haben und die auch erreichen wollen. Ich habe klassische Konflikte zwischen Sales und Marketing. Ich habe Konflikte eben zwischen Offline versus Online. Ich habe EDV versus eben vielleicht digitale IT, die unterschiedliche Tools, Methodiken, Systeme bauen. Da ist es eine nicht delegierbare Aufgabe, sozusagen für den Vorstand oder für das Management, sicherzustellen, dass allen klar ist, was eigentlich der KPI ist. Und auch da muss ich mir dann eben genau die übergeordneten Metriken, OKRs, KPIs, was auch immer überlegen, die Das kann vielleicht sowas sein wie, was ist sozusagen der Prozent unseres digitalen Umsatzes oder was ist sozusagen der Prozent der Durchdringung in irgendeiner digitalen Zielgruppe. So, wenn ich das nicht mir vorher setze als Ziel und auch alle daran messe, sondern jeder am Ende des Tages nach Hause geht und sagt, naja, Ich habe meinen Job zwar super gemacht, aber der Kollege, der den analogen Vertrieb steuert, der hat natürlich ein ganz anderes Interesse. Der möchte ja gar nicht, dass seine Außendienstler jetzt irgendwie alle nichts zu tun haben. Der sieht eigentlich das Digitalisierungsteam als Gefahr für seinen persönlichen Bonus. Das ist natürlich etwas, was nicht gut ist. Das ist häufig verhaltensmäßig leicht zu lösen, indem sozusagen alle allein sind, indem ich auch ganz klar die Strategie vorgebe, auch ganz klar allen den Benefit aufzeige und sage, hey, hör zu, wir bauen jetzt eine Strategie, die deine Kunden und deinen Accountmanagernicht aus dem Spiel bringen,sondern ihr sollt mehr Zeit haben,euch vielleicht auf größere Accountszu konzentrieren,über die kleinen und mittleren,da wollen wir jetztSelf-Service-Mechanismen schaffen,ja und auch die Zuteilung vonUmsätzen oder Bonikann ich ja auch darin ausrichten,umso mehr deiner kleinen und mittleren Kundendu in dieses Self-Service-Modell bewegst, Auch das soll reinziehen in deine Jahresincentives. Auch du sollst davon was haben, weil das ist ja besser für uns als Company. Wir haben eine bessere Marge, wir haben mehr Geld zu verteilen hinterher. Du hast mehr Zeit, dich auf die großen Accounts zu kursieren, kannst da wiederum mehr rausholen. Also wenn ich das nicht orchestriere und alleine, sondern das sozusagen sich selbst überlasse, dann ist das etwas, was meistens eben nicht gut ausgeht.