IT-Leistungen erfolgreich einkaufen

Joel Kaczmarek: Hallo und herzlich willkommen zu einem neuen Innovate or Die Podcast von Digitalkompakt. Mein Name ist Joel Kaczmarek und heute geht es um das leidliche Thema Einkauf. Des einen freut, des anderen leid und wir wollen heute dafür sorgen, dass es bei allen freut ist. Und zwar wirst du aus dieser Folge mitnehmen, wie man eigentlich einen Einkaufsprozess startet. Und wir reden hier im Prinzip wirklich von IT, wo wir uns mal auf das Thema Kundenfokus auch spezialisieren. Das heißt kundennahe IT-Lösungen. Also da lernst du, wie startest du mit dem Prozess, wie sieht die Timeline dafür aus. Solltest du das als MVP starten, macht es Sinn, sich Proposals, also eine Ausschreibung reinzuholen. Wie setze ich das Ganze um? Welches Budget brauche ich dafür? Und wie messe ich eigentlich den Erfolg? Und wer kann das besser sagen als der gute Boris Lockshin von Spryker. Hallo Boris.

Boris Lokshin: Hallo, guten Morgen.

Joel Kaczmarek: Hast du viel mit Einkauf zu tun bei euch?

Boris Lokshin: Naja, eher mit Verkauf. Also ich glaube, wir sind dann eher auf der verkaufenden Seite. Aber da lernst du natürlich dann auch die Einkaufsprozesse automatisch kennen. Und klar, wir führen natürlich für uns mittlerweile auch diverse Systeme ein. Ob das irgendwie im Sales-Marketing-Umfeld ist, HR, Finance. Aber auch ein neues System jetzt für die Webseite. Also klar, als Konsument für uns selber natürlich schon.

Joel Kaczmarek: Gut, lass uns doch mal wirklich voll rein starten. Also vielleicht umreißt du mal, wie du jetzt die Produktkategorie siehst, über die wir sprechen, damit Leute, die vielleicht Einkauf bei ganz anderen Themen haben, jetzt entscheiden können, ob das für sie spannend ist. Also was für einen Themenbereich willst du denn beim Thema Einkauf wirklich betrachten?

Boris Lokshin: Genau, also ich glaube, das, wo ich am meisten jetzt zu sagen kann, ist wahrscheinlich das Thema kundenzentrische IT. Also all diese Systeme, mit denen am Ende des Tages irgendein Endkunde interagiert. Also das kann ein Commerce-System sein, das kann ein Content-Management-System zum Beispiel sein. Das können Apps sein, also irgendwas, was eben nicht klassisch irgendwie Warehouse-Logistik oder der Einkauf von irgendeiner großen ERP-Lösung ist. Also ich glaube, auch da sehen wir viel. Ich glaube, wir können auch an einigen Stellen das ein bisschen abgrenzen. dann, pro, contra oder schwarz, weiß. Aber ich würde mich heute auf die kundzentrische IT und den Einkauf von diesen Systemen fokussieren.

Joel Kaczmarek: Das finde ich an dir immer sympathisch, dass du über die Sachen redest, von denen du wirklich viel verstehst und nicht wie andere Menschen da draußen. Viel redest du über Dinge, von denen du wenig verstehst. Gut, dann mitten rein. Wie starte ich diesen Prozess? Was sollte so der erste Faktor sein, den ich mir überlege?

Boris Lokshin: Was wir häufig sehen, ist tatsächlich, dass die wesentliche Entscheidung ist, aus welchem Department oder sozusagen aus welchem Business-Bereich entsteht dieser Need oder wo entsteht dieser Need. Ist das ein IT-Projekt, also ist das sozusagen eine IT-Abteilung, egal jetzt, ob sie klassisch oder dann schon wie in den anderen Folgen besprochen, dann eher sozusagen digital native ist. Also ist das ein IT-Prozess, der angeschoben wird, sind das IT-Leute, die das treiben, ist das IT-Budget am Ende des Tages, aus dem dann das Projekt bezahlt wird und das Tool bezahlt wird. Oder ist es das Business? Kommt so ein Need oder die Anforderung eben aus dem Sales Marketing. Sind Sales Marketing, dann sind das die Owner, sind das diejenigen, die das Budget dafür bereitstellen, sind das diejenigen, die hinterher die sogenannten Stakeholder sind, also diejenigen, die auch das Projekt dann eben ownen, intern dann weiter übernehmen, betreiben und dann am Ende des Tages natürlich auch daran gemessen werden. Also das ist ja meistens dann irgendein Tool, was eingeführt wird, idealerweise, um auch eine Aufgabe besser, schneller weiter zu erledigen.

Joel Kaczmarek: Und wie verändert es den Prozess, wenn es jetzt im Prinzip zum Beispiel aus dem Sales kommt, wie du gerade gesagt hast, versus wenn es irgendwie aus der IT kommt? Macht das was mit dem ganzen Prozess? Ist das stark verändert?

Boris Lokshin: Also was man häufiger sieht, ist, dass wenn es ein Business-Topic ist, dann geht es eben sehr stark und sehr häufig um eine Upside-getriebene Denke. Das heißt also, jemand möchte irgendwas besser, schneller weitermachen, man möchte mehr Umsatz machen, man möchte seine Leads besser targeten, man möchte mehr Reichweite aufbauen, man möchte eine bessere Conversion erreichen bei sich auf der Webseite, auf seinem Download von seinem Whitepaper oder das Ansehen von seinen Videos. Man möchte jetzt in einem Commerce-Beispiel, wenn ich ein Commerce-System einführe, möchte ich natürlich mehr Umsatz machen, ich möchte natürlich meine Kunden dann mehr besseren Touchpoints adressieren und da am Ende des Tages eine bessere Marge verdienen. Also das ist häufig eben eine sehr Upside-getriebene Denke. Ich wechsle dann ein System, um eben besser mit bestimmten Anforderungen umzugehen oder überhaupt mich auf neue Anforderungen, die der Markt auf einmal hat.

Zum Beispiel gab es vor 15 Jahren nur im Commerce-Umfeld nur Desktop-Systeme zu adressieren. Fünf, sechs, sieben Jahre später gibt es plötzlich Mobile und Tablets und Phablets und diverse andere Touchpoints und Devices. Das heißt, ich brauche wahrscheinlich ein System, was auch das kann und nicht nur Wenn es ein IT-Projekt ist, dann ist es häufig umgekehrt. Dann sind es häufig Themen wie Verbesserung von Effizienz, von Automatisierung, Effizienz, das Senken von Kosten, das Beschleunigen von Dingen, meistens der Treiber. Das heißt, ich habe irgendwelche Prozesse, die einfach nicht optimal laufen. Ich habe vielleicht viele Google-Sheets und ich möchte die konsolidieren in einem System. Ich habe vielleicht viele manuelle Prozesse oder viele Abstimmungsprozesse. Ich habe vielleicht irgendeine Art von Datenerfassung per Fax. Ich habe Leute, die irgendwas eingeben. Ich habe viel Ineffizienz. Ich habe viel Redundanz. Ich habe keine gute Datenhygiene. Oder ich habe auch einfach Dinge, die mir vom Business gemeldet werden.

Das heißt, ich kriege sogenannte nicht-funktionale Kriterien. Das sind zum Beispiel so etwas wie Geschwindigkeit einer Seite. Funktionale Kriterien sind, ich möchte ein Content-Management-System einführen, was Feature A, B, C bietet. Nicht funktionale Kriterien, sondern ich möchte, dass die Seite schnell ist, dass sie sicher ist, etc., etc. Das heißt, häufig kriege ich von der IT eben auch diese Themen auf den Tisch. Dann heißt das, mein Content Management oder mein Job ist eigentlich super, aber er ist viel zu langsam und im Vergleich zu meinen Wettbewerbern verliere ich.

Also ich glaube, das ist ganz häufig der, mal so ganz grundlegend, dann der Unterschied. Nicht zuletzt natürlich dann auch für denjenigen, der verkauft. Auch wichtig, mit wem redet er da, wer entscheidet und auf Basis von welchen Faktoren. Entscheidet jemand, mache ich einen Pitch für das Business und zeige denen, wie durch die Einführung meines Systems die Leute ihre Business Goals besser erreichen können oder spreche ich mit der IT und erkläre denen, wie die Betriebskosten geringer werden, warum die Seite eben ausfallsicherer ist, warum der Shop performanter wird, warum der Technologie-Stack der gleiche ist wie in Ihrem alten System und Sie deswegen Ihre Leute leicht umziehen können, warum Sie diese Cloud schneller aufsetzen können als irgendein anderes System. Das sind dann Faktoren, die, wenn ich eben einen reinen Marketingleiter pitche, dem ist egal, ob ein System in PHP oder Java vielleicht geschrieben ist oder ob das in der Cloud ist oder auf einem Server von einem Managed Hosting Provider.

Joel Kaczmarek: Und beginnst du so einen Prozess dann schon, also ihr habt das ja auch durchlaufen, aber eher bei den, sagen wir mal, Non-Customer-Facing-Systemen, was ich so mitgekriegt habe, beginnst du das schon, indem du dir zu Beginn KPIs setzt und Ziele oder machst du sowas erst hinterher?

Boris Lokshin: Also ich glaube, das ist super relevant, dass man kein Projekt startet heute ohne a, zu verstehen, was für ein Problem ich eigentlich lösen möchte, egal welches es ist und b, was eigentlich die Metriken sind. Ich glaube, das ist ein ganz häufiger Fehler, den wir auch sehen im Markt, dass Projekte gestartet werden. Ich will jetzt nicht sagen aus der Lust und Laune heraus, aber naja, es wird mal wieder Zeit für ein neues Shop-System oder es wird mal wieder Zeit für ein neues Content-Management-System. oder da hat jemand irgendwelche drei funktionalen Anforderungen, die vielleicht mit dem alten System funktionieren. nicht oder schwierig umzusetzen sind. Und da wird natürlich ein ganz großes Rad sofort gedreht und man geht raus. Oder auch häufig als neuer Stakeholder, ich komme neu rein, ich bin ein neuer E-Commerce-Leiter, ich bin ein neuer IT-Leiter, ich bin ein neuer Produktmanager. Und da muss natürlich sofort ein neues PIM mit eingeführt werden.

Ich will natürlich ein neues System, ich will natürlich vielleicht auch etwas, was ich vorher schon kannte. Ich möchte mich natürlich sofort beweisen, profilieren, so ein schönes Einführungsprojekt irgendwie hinlegen. ohne eben klar abzustellen auf, habe ich überhaupt eine Need und wenn ja, welchen und in welcher Metrik drücke ich ihn eigentlich aus. Ist das sozusagen Umsatz, ist das eben IT-Kosten, ist das Prozessgeschwindigkeit, ist das Vermeidung von Fehlern, ist das Anzahl von neuen Leads. Also wenn ich das nicht klar definiere, dann wird es super schwer, A, hinter den Erfolg zu messen, da kommen wir nachher nochmal drauf und B, auch sauber mir zu überlegen, was ich eigentlich, also de facto so einen internen Bewertungskatalog kann ich dann schwer machen, weil ich dann wieder sehr stark auf Feature-Ebene runtergehen muss. Und dann vergleiche ich, ob System A oder B bestimmte Features aufweisen, ohne aber zu vergleichen, ob sie eigentlich einzahlen auf den KPI.

Ich kann ein witziges Beispiel nennen aus unserer eigenen Geschichte. Spryker als Commerce-Technologie, also eine der Prämissen, als Spryker konzipiert wurde, war Performance. Man hat irgendwie versucht, Erfahrungen zu lösen mit eben den großen Legacy-Systemen, die häufig inperformant waren, also aus Endkunden. Und früher hat man bei Commerce-Systemen einen sogenannten Cache verwendet. Das heißt, man hat quasi die Seite statisch abgespeichert und dann eine Version dieser Seite schnell ausgeliefert. Die musste dann nicht neu berechnet werden. Daten mussten nicht aus der Datenbank genommen werden. Und in der Architektur von Spryker, ohne das jetzt so technisch erklären zu können, wurde das anders gelöst. Also so, dass kein Cache mehr gebraucht hat, dass Daten dann sozusagen in Millisekunden Schnelle zur Verfügung gestellt wurden. Aber wenn du dann jemanden hast, der quasi aufgrund von Features bewertet, da hatten wir eine Situation, bei der wir vom Projektteam sehr gut und sehr hoch gebenchmarkt wurden intern und auch sehr deutliche Signale bekommen haben, dass es mit uns weitergeht.

Und dann gab es einen Anruf von einem Einkäufer, der dann gesagt hat, wir wären raus. Und auf die Frage, warum, hat er dann gefühlt seine Excel-Tabelle geöffnet und hat in Zeile 137 geschaut und hat gesagt, aha, das war eine Zeile, die hieß dann irgendwie Cache. Bei Spryker stand halt No Cache. Und dann waren wir damit quasi disqualifiziert, weil wir hatten eben keinen Cache und das war schlecht aus seiner Sicht und deswegen sind wir dann eben draus. Die Funktion der KPI Performance, auf die hier eigentlich abzuzielen war, wurde quasi gar nicht abgefragt, sondern es wurde ein funktionaler Vergleich gemacht, anstatt zu sagen, hey, wie ist die Performance des Systems, aha, es breitet ein paar Minus, egal wie wir das lösen, das hat eben in dem Fall keine Rolle gespielt. und das ist natürlich dann dumm, wenn ich eben keine Metriken überlege, also immer zuerst Problemdefinition, was möchte ich für ein Problem lösen, für wen, also wer sind die Stakeholder, auch intern, löse ich ein Problem für meine Kunden, für mich selber, für meine Mitarbeiter, für meine, weiß ich nicht, Investoren? und was ist am Ende die Erfolgsmetrik.

Joel Kaczmarek: Das ist ein interessanter Insight, also dass du auch sagst, so ein Einkaufsprozess, wenn man jetzt mal auf der Anbieterseite den Kunden betrachtet, ist manchmal wirklich hart Zeilen-Excel getrieben, also wirklich funktionsorientiert, wie du gerade gesagt hast.

Boris Lokshin: Ja, also das kommt davon, wenn dann tatsächlich eben genau die Dinge nicht richtig zueinander passen, wenn zum Beispiel kundenzentrische Systeme, ich habe ja vorhin gesagt, wir machen eben auch ein bisschen den Abgleich, kundenzentrische Systeme dann eben von nicht kundenzentrischen Leuten eingekauft werden. Du hast halt häufig natürlich gerade im Einkauf, hast du eben Leute, die dann eben 20, 30 Jahre Berufserfahrung haben, die selbst wenn sie IT-Systeme gekauft haben, dann waren es eben meistens nicht kundenzentrische Systeme, sondern sie haben dann Warenwirtschaftssysteme gekauft, Finanzbuchhaltungssysteme, Logistik und sonst was. So müssen die jetzt auf einmal mit ganz anderen Parametern umgehen und können das dann eben nicht richtig einschätzen. Oder du hast eben Leute, die einfach alles einkaufen. Es gibt auch große Firmen, die Einkäufe haben, die heute 10 Tonnen Aluminium bestellen und am nächsten Tag irgendwie das Next-Gen-Commerce-System kaufen müssen. Und dann endest du dann eben in solchen Benchmarks.

Joel Kaczmarek: Ist die Ableitung daraus, dass man darüber nachdenken sollte auf der Einkaufsseite, Leute, die wirklich von der Produktentführung betroffen sind, in so einen Prozess mit reinzunehmen?

Boris Lokshin: Ja, absolut. Also das kann man auch auf unterschiedliche Art und Weise machen. Wenn du deine eigene Struktur, deine eigenen Abteilungen sozusagen nicht umorganisieren kannst, dann sehen wir zum Beispiel immer häufiger im Markt auch dass man sich mit Beratern verstärkt. Es gibt viele gute Leute, die dann aus Ex-Agenturen und Systemintegratoren sind, die selber auch die Implementierungsseite gut kennen, die nicht nur wissen, welche Systeme es gibt, die auch wissen, die auch alle Tricks und Kniffe der Implementierungspartner kennen und dann auch in so einem Pitch sich mal drei, vier Agenturen angucken können, genau die Fragen stellen können, die dann der Einkäufer vielleicht oder der Umsetzungsverantwortliche in der Firma nicht stellen kann. Sowohl zu Referenzen oder Kompetenzen oder Methodik.

Es gibt ja ganz viele Dinge, die dann gerade über Agility Wir haben auch einige Folgen, wo über Agilität und Co. gesprochen wird, ohne so richtig zu wissen, was man eigentlich verkauft oder ob das matcht auf den Kunden. Also da ist auf jeden Fall die Empfehlung, holt euch dann jemanden rein, der euch da beraten kann, begleiten kann. Die Leute gibt es im Markt, die sind verfügbar. Das ist jetzt auch kein unendlicher Zeit- und Kosteninvest. Der ist auch hundertmal refinanzierbar, weil wenn man es eben nicht macht, dann ist das Risiko, etwas einzukaufen oder es dann falsch zu kaufen, sehr hoch.

Joel Kaczmarek: Gehen wir jetzt gleich mal in so eine typische Timeline von so einem Prozess einsteigen, sollte man vielleicht vorab mal klären, wie fahre ich sowas eigentlich? Also der eine Weg, den wir auch schon mal besprochen haben, war typisch MVP, also schnell versuchen, schnell lernen, austesten, iterieren oder Ausschreibung machen, also ein bisschen größer angelegt. Vielleicht sollte man das mal als Thema vorwegnehmen, bevor wir dann über Timelines und Umsetzung reden.

Boris Lokshin: Genau. Bei dem Thema RFP versus MVP, also RFP klassisch sozusagen als Request for Proposal oder Ausschreibungsdokument, bei dem ich eben typischerweise erstmal meine Anforderungen irgendwie sehr langwierig maximal detailliert erfasse, also ein sogenanntes Pflichtenheft an der Stelle, auf Basis dessen dann hinterher umgesetzt wird. Das heißt, die Natur, das kommt so ein bisschen aus diesen Wasserfallprojekten, die Natur ist natürlich, der Hintergrund ist der, ich muss genau sagen, was ich möchte, dann kriege ich dafür einen genauen Preis und eine Timeline und dann habe ich da irgendwie einen sehr genauen Vertrag, gegen den dann derjenige liefert. Und jede Abweichung von dieser Spezifikation kostet natürlich dann extra und verlängert dann die Teilnahme. Das kann ich natürlich machen bei absolut standardisierten Projekten und Prozessen.

Wenn ich jetzt irgendwie einfach als Analogie, wenn ich jetzt in der Industrie irgendwie bestimmte Bauteile fertige für einen Flieger oder wenn ich ein Autozulieferer bin, Dann brauche ich natürlich eine sehr exakte Spezifikation von dem Teil. Dann gibt es da keine Interpretation und keine Change Request, sondern ich habe ein bestimmtes Teil, das hat eine bestimmte Konfiguration, das muss absolut genau spezifiziert sein. Dann kann ich weltweit das ausschreiben und mir dann die Angebote aus Deutschland, China und Co. oder auch bei Elektronikkomponenten, wenn ich einen RAM einkaufe oder eine Linse für mein neues iPhone, dann ist natürlich die Spezifikation maximal genau und dann gibt es auch keine Fehlerreihen. Dann bieten die Leute da drauf und das wird dann genau geliefert. Die Linse ist dann genau die, die ich bestellt habe und die baue ich ein.

So, in der Softwareindustrie ist das natürlich anders, also wenn ich in standardisierten Projekten unterwegs bin, also gerade sozusagen in den Backend-Systemen, ja, also Stichpunkt sozusagen nicht kundenzentrisch, ja, also Warenwirtschaft und Co., da habe ich eine, üblicherweise habe ich oder müsste ich haben, vielleicht mal ganz kurz hier an der Stelle, eine sehr hohe Anzahl an Standardprozessen, das heißt an Dingen, die eben einfach vorgeschrieben sind, die gesetzlich vorgeschrieben sind, Finanzbuchhaltung zum Beispiel oder irgendwelche Legal Software, Dokumenten-Management, HR-Prozesse, die bestimmten Anforderungen unterliegen, Inventurprozesse. Das erfinde ich nicht neu, da habe ich ein sehr großes Maß an Standards und da kann ich auch relativ breitflächig Dinge runterspezifizieren und sie mir bestellen und dann versuchen eben maximal viel über Konfigurationen und über leichte Anpassungen zu lösen.

Das Problem ist, man liest häufig, dass eben große, gerade ERP-Projekte scheitern oder nicht gut laufen. Das passiert eben dann, wenn man aus einer Standardlösung eben dann keine Standardlösung macht, sondern sie versucht mit mehreren tausend Manntagen in der etwas zu verwandeln, wofür sie eigentlich gar nicht gedacht war. In den kundenzentrischen Systemen ist es umgekehrt. Da lebe ich ja davon, das hatten wir, glaube ich, in der anderen Folge auch schon jetzt mehrfach hergeleitet, da leben wir alle davon, dass der Markt einfach super dynamisch ist. Kunden ändern ihre Erwartungen permanent. Es laufen neue Devices, es gibt neue Touchpoints, es gibt neue Erwartungen von Kunden im Hinblick auf Customer Experience und Excitement. und wie möchte ich Content konsumieren, wie sieht die nächste App aus. Das heißt, ich akzeptiere, wenn ich kundenzentrisch denke, akzeptiere ich Unsicherheit. Und diese Unsicherheit äußert sich eben darin heutzutage, dass die Halbwertszeit von Softwarelösungen eben sehr gering ist. Das heißt, ich kann eben nicht mehr auf 3, 5, 7 Jahre auf Verdacht einkaufen, sondern vielleicht nur noch auf 12 oder 24 Monate maximal. Und ich muss schon beim Einkauf berücksichtigen, dass wahrscheinlich, was auch immer ich einkaufe, sich eben viel verändern wird.

Das heißt, da bin ich sehr gut beraten. Diese MVP, also Minimal Viable Product Methodik, also einfach in vielen kurzen, eng getakteten Iterationen vorzugehen, immer wieder ein Ergebnis zu produzieren, mit dem Leute arbeiten können, mit dem meine Teams oder Endkunden experimentieren und wo ich schnell Feedback bekomme, das immer wieder einarbeiten kann. Wenn ich das nicht tue, dann riskiere ich eben auch da zwei Jahre mein Shop-System oder mein Content-Management-System zu implementieren und das eben am Markt oder an der eigentlichen Problemstellung vorbei. Von daher, wenn man schwarz-weiß denken möchte, ich glaube RFP-Prozesse sehr gut geeignet für standardisierte IT-Projekte, vor allem eben in der Backend-Welt. MVP-Projekte sehr gut geeignet für kundensensorische Projekte, vor allem in der Frontend-Welt.

Joel Kaczmarek: Gut, besser hätte ich das nicht zusammenfassen können. Was für Timelines entstehen aus sowas? Also gerade das MVP-Thema scheint ja eher eine repetitive Geschichte zu sein, sodass ich wahrscheinlich mehrere Timelines vielleicht sogar innerhalb eines Projekts habe. Wie klassifizierst du das für dich?

Boris Lokshin: Genau, also bei den Timelines, ich glaube, womit man anfangen sollte, ist immer, sich selbst so eine Art Compelling-Event zu setzen. Das heißt, am Compelling-Event de facto quasi irgendeinen harten Anschlag. Idealerweise hat man den schon sozusagen natürlicherweise, indem ich ihm sage, weiß ich nicht, mein Bestandssystem läuft aus, der Support läuft aus, die Lizenzen laufen aus oder ich habe da irgendwie eine große Marketing-Kampagne oder ich habe da ein großes Event und da möchte ich meine Seite gelauncht haben bis dahin oder ich habe jetzt irgendwie eine Messe, bei der ich meinem Kunden die neue App zeigen möchte. Also umso härter dieses Event, umso konkreter, umso besser ist es, weil das natürlich die gesamte Organisation und dann am Ende des Tages auch den Einkaufsprozess und für den Verkäufer auch den Verkaufsprozess maximal streamlined. Ich habe dann einfach eine stringente Vorgabe. Ich kann eben nicht sozusagen monatelang über Verträge reden, sondern ich muss dann schon irgendwie meine Sachen zusammenbekommen, mich dann hinsetzen. mich damit beschäftigen und dann auch irgendwann natürlich in die Umsetzung starten.

Das heißt, so ein Compelling Event entweder natürlich gegeben zu haben oder mir selbst eins zu setzen und sagen, so Leute, das ist jetzt sozusagen der Trigger, da muss das Ding fertig sein oder da muss irgendwie der Relaunch abgeschlossen sein. Das ist, glaube ich, erstmal eine sehr, sehr gute Exercise, weil man einfach die gesamte Organisation fokussiert. Wenn man das gemacht hat, vielleicht sozusagen als Background dazu, warum ist das wichtig? Weil ich glaube, die allermeisten unterschätzen heute, was der wichtigste zu managende KPI ist und in dieser digitalen Welt ist es einfach Zeit. Und das ist ganz eindeutig, das lernen wir selber jeden Tag. Es gibt einfach wirklich gar nichts, was irgendwie einen Monat später für einen günstiger ist. Einfach gar nichts. Weder sind die Leute günstiger, noch wird die Software günstiger oder Online-Performance-Marketing wird nicht günstiger, Software-Lizenzen zu kaufen wird nicht günstiger, Equihires zu tätigen wird nicht günstiger. Also es gibt kein Incentive, was sagt, okay, warte mal sechs Monate für etwas, was du brauchst und dann sparst du Geld.

Sondern wahrscheinlich ist das Problem bis dahin größer, wenn du eins gehabt hast, dann ist das größer. Die Einführungskosten sind höher, weil sich dann viele Dinge angestaut haben. Du nochmal 15 Excel-Tabellen konsolidieren musst oder du noch mehr Content in deiner alten Webseite hast, die du migrieren musst oder dein Shop-System so hohe Verluste hat im Warenkorb und Leute aussteigen und die Performance doof ist und die Conversion-Rate auf der mobilen Seite irgendwie nicht gut ist, dass du einfach immer in Schwierigkeiten gerätst. Zeit ist der wichtigste KPI, deswegen Compelling Event setzen und dann eben relativ stringent auch super schnell dieses theoretische PowerPoint-Level verlassen. Was wir häufig sehen ist und auch eine Falle, in die wir selber teilweise auch reingelaufen sind bei der Einführung von eigenen Systemen, ist, dass man viel zu akademisch und mit viel zu viel angenommener Das ist eine vermeintlich angenommene zusätzliche inkrementelle Sicherheit, die man glaubt, durch eben die Länge des Prozesses zu gewinnen, sowas treibt. Man glaubt, wenn man nochmal irgendwie fünf Minuten oder wenn man nochmal irgendwie zwei Wochen sich ein sechstes Angebot nochmal einholt oder wenn man mit dem Anbieter noch ein drittes Mal verhandelt oder wenn man jetzt nochmal bei irgendwie den Analysten anfragt und denen die Charts schickt und dem Hersteller die drei Angebote der Agenturen, die geboten haben, dass man dann mehr Sicherheit bekommt, mehr Preissicherheit, mehr weiß ich nicht. Umsetzungssicherheit. Und das ist halt häufig meistens nicht der Fall, beziehungsweise es ist der Fall.

Ich bekomme dann irgendwie ein Prozent, zwei Prozent mehr Confidence in meinem Projekt, habe aber sozusagen das getauscht im gegen zwei Wochen späteren Projektstart. Und das ist kein guter Trade-off. Das heißt also Compelling Event setzen, das maximal, wenn ein Projekt zu groß, zu komplex wird, im Sinne von die Entscheidungsfindung dauert zu lange, der Scope ist zu groß, berechtigt das halt in kleinere Happen. Also vielleicht kann man eben ein Teilprojekt rauslösen, was man eben schon mal losschicken kann, auf den Weg schicken kann, um dann einfach auch ins Machen zu kommen. Und ein Stück weit auch Prozesse zu parallelisieren. Wir haben zum Beispiel als internes Beispiel jetzt gerade ein eigenes BI-System eingeführt. Ist jetzt kein klassisches kundenzentrisches System, trotzdem sozusagen in MVP-Manier gebaut.

Und initial war der Scope dafür super groß, weil klar, jeder ist Konsument von dem BI-System. Es gibt ein neues Data Warehouse. Jeder hebt die Hand, jeder möchte schöne Daten, schöne Reports, schöne Charts, jeder möchte irgendwie schöne Oberflächen, jeder möchte alles bei Drag & Drop machen können. Also ganz klar, kann man zehn Jahre implementieren, wird nie fertig. Auch da hat sich das eben gut gezeigt, dass man das eben bricht in einzelne kleine Etappen, auf erste Kohorten abstellt. In dem Fall dann z.B. Sales und Marketing bei uns, die natürlich bestimmte Daten brauchen zum Sales Funnel, zu Conversion Rate, zu Sales Cycles. So zu sieht, dass man das implementiert, dass man diese Stakeholder schult, damit sie dann auch sozusagen eigentlich mit dem Nacken sitzen und selbst ihre Dinge bauen können, selbst ihre Dinge konfigurieren und dann eben den nächsten Projektabschnitt sich formen.

Joel Kaczmarek: Gibt es umgekehrt auch Momente, wenn du sagst, es braucht ein Compelling Event, in dem man so eine Timeline sozusagen nicht starten sollte, dass man das nicht anstößt, so ein Prozess?

Boris Lokshin: Mal ganz blöd gesagt, wenn man keinen klassischen, wenn man keinen harten Need hat oder wenn man kein Compelling Event hat, also wenn sozusagen Es gibt eben auch so ein bisschen die Frage, ich glaube in dem Podcast mit Gero, den du machst zum Sales, hat er das auch gut erklärt, wenn ich dieses Why Change, Why Now, wenn es sozusagen kein Why Now gibt, das Why Now gilt eben nicht nur für den Verkäufer, er stellt ja die Frage, sondern gilt auch für den Käufer, wenn ich eigentlich keinen Grund habe, etwas zu ändern, Why Change und Why Now, wenn ich darauf keine Antwort habe, wenn ich das einfach mache, weil ich es mache, weil ich mich hier selbst profilieren möchte oder weil ich gerade ein bisschen spielen möchte, da gibt es wirklich ganz absurde, teilweise jemand spricht, der gar keine Authority hat, also überhaupt nichts zu entscheiden hat, dass das irgendwie eine Spielwiese ist, dass er niemanden intern abgeholt hat, dass er mit drei Abteilungen nicht geredet hat, dass er gar kein Budget besitzt darüber.

So was ist natürlich doof, weil das verschwendet, so ein Projekt, egal wie klein, wie groß es ist, heutzutage ist schon sehr ressourcenintensiv, auf Abstimmungsebene, auf Anforderungsebene, Workshops, Implementierung, wenn ich daran denke, wir führen jetzt auch eine neue Webseite ein, wie viele Abteilungen da involviert sind, von Marketing über Tech über Marketing, Operations, Partner und der will das noch zeigen und Event-Team. Also es sind ja unendlich viele Anforderungen von allen, die da reinfließen. In eine, würde man sagen, vermeintlich simple Webseite. Das ist jetzt kein Commerce-System, was irgendwie meine ganzen Umsätze managt, sondern das ist am Ende eine Webseite. Und so ein Projekt einfach so anzustoßen, ohne klaren Business-Treiber oder ohne klaren technischen Treiber und ohne klare Timeline führt eben genau dazu oder zu dem, was man dann im Markt liest, dass dann eben auch so eine Einführung von einer Webseite dann auch mal 12, 18 Monate dauern kann, wo sich dann jeder am Kopf hat und sagt, wie kann das denn sein? Das ist doch nur eine blöde Webseite, warum habt ihr euch denn nicht vorher überlegt, was ihr machen wollt und wie ihr das migriert und welche Teile ihr übertragt und was ihr neu macht und ob ihr das intern designt oder extern, ob ihr das selber hostet oder nicht. Das ist jetzt auch kein Rocket Science. Also sprich, habe ich keine harte Timeline, habe ich keinen harten Anschlag, habe ich keinen harten Need, dann passiert auch nichts in der Realität. Dann arbeiten die Leute vor sich her, dann ist das so ein bisschen Arbeitsbeschaffungsmaßnahme. Schlimm genug, wenn es interne machen, die Geld verbrennen, wenn da noch externe Berater, Agenturen involviert sind, dann wird es halt noch schwerer.

Joel Kaczmarek: Hast du noch Tipps, wie man so eine Timeline sonst optimiert kriegt? Also du hast jetzt gesagt, Compelling Event, in Etappen denken, KPIs schon vorher im Kopf haben. und wie kann ich trotzdem weiterhin auch schaffen, genau was du gerade beschrieben hast, ich habe viele Stakeholder, die ich abholen muss, viele Interessen wollen gewahrt werden oder zumindest berücksichtigt, einbezogen. Wie schaffe ich es da, so einen Einkaufsprozess und Implementierungsprozess, der sich eben anschließt, stringent straff zu halten?

Boris Lokshin: Also was super gut sich immer zeigt, ist erstens mal einen klaren internen Champion oder Owner zu haben. Also was überhaupt nicht gut funktioniert ist, wenn eben viele Stakeholder da sind, aber eben keiner am Ende den Hut dafür auf hat. Wenn auch keiner den Hut dafür auf hat, nicht nur den Prozess zu managen, weil managen kann ich ja alles, ich kann auch drei Jahre was managen, sondern den Prozess auch zu treiben. Derjenige muss eben auch darauf incentiviert sein oder darauf gemessen werden, zu sagen, hey Joel, du machst jetzt dieses Projekt, du bist jetzt der Projektleiter, der Projektverantwortliche, dein Ziel ist es, diesen KPI zu erreichen. in den nächsten sechs Monaten und danach wird sozusagen auch dein persönlicher Erfolg und Benefit eben auch bemessen. Wenn das nicht da ist, ist das schwierig, weil einfach die Projekte heutzutage und auch die Produkte alle, ich habe gerade das Website-Beispiel erwähnt, einfach zu komplex sind, also auch einfach akzeptabel. Eine simple Website einzuführen, ist schon ein großes Projekt. Das machst du nicht so eben aus der kalten Hose.

Wenn du vorher nie ein IT-Projekt gemanagt hast und nie einen Einkaufsprozess begleitet hast, dann geht das nicht. Also ganz klare Ownership intern, Punkt 1. Punkt 2, den Kreis der involvierten Leute pro Etappe maximal klein halten. Das ist der Overhead, der Kommunikations-Overhead. Und die Wahrscheinlichkeit einer Nicht-Abstimmung oder die Wahrscheinlichkeit des Findens eines gemeinsamen Nenners, der dann so klein ist, dass man eigentlich gar nichts macht, wächst exponentiell mit der Zahl der Leute, die ich hinzufüge zu einem Projekt. Wenn ich zwei, drei Leute habe im Team, die Dinge entscheiden, dann habe ich irgendwie drei Kommunikationslinien zwischen denen. So erde ich eine vierte Person, habe ich schon sechs. Erde ich eine fünfte Person, habe ich zwölf und so weiter. Das geht dann sozusagen exponentiell hoch. Und am Ende, wenn ich manchmal auf Projekte auch schaue, zu denen wir eingeladen werden, bei denen schon allein das Steuerungsgremium, der sogenannte Lenkungsausschuss oder das auf Englisch Steering Board, Steering Committee, wenn dort schon 14 Leute drin sitzen, das kann nichts werden. Das ist relativ klar, dass das ein Projekt ist, was niemals eine Erfolgsetappe erreicht. Also ganz klare Ownership, haltet sozusagen die Gruppen klein, das ist okay. Es gibt auch den Begriff des Programmmanagements. Ein Programm besteht aus mehreren Projekten.

Ich kann dann so ein Projekt auch in kleinere Teile teilen. Ich kann sagen, okay, ich führe jetzt ein neues Commerce-System ein, das besteht irgendwie am Ende aus einer App, das besteht aus irgendeiner Desktop-Version, das besteht aus vielleicht irgendwie Fähigkeiten zum Management von Produkten, das besteht aus irgendwelchen Anbindungen. Ich kann also die einzelnen Arbeitsgruppen auch klein halten, damit jede für sich autark ist. Und ich kann, wenn ich an sowas denke, wie zum Beispiel Payment, viele Kunden, die ein Commerce-Thema einführen, die müssen sich mit dem Thema Payment beschäftigen. Es gibt 150.000 Payment-Dienstleister, die sich alle gefühlt erstmal nichts nehmen. Die zu evaluieren, sich ganz gut, kann ein eigenes Projekt in sich sein, die sauber zusammengehen. zu integrieren, herauszufinden, wer eine gute Schnittstelle hat, wie die Konditionen sind, etc., etc. Das kann eine kleine Arbeitsgruppe machen. Da müssen die 14 Leute damit beschäftigt sein, die Payment Provider auszuwählen. Das können irgendwie ein oder zwei Leute machen und dann diese Selektion eben sehr straff und dann konkrete Kriterien dann durchführen und dann in diesem großen Programm wieder zusammenführen. So, und der dritte Punkt oder der vierte Punkt ist, das, was ich gerade schon angesprochen hatte, ist, am Ende auch irgendein Steuerungsboard zu haben, also Steering Board oder Lenkungsausschuss.

Das heißt, gerade wenn ich mit externen arbeite, also intern braucht man es nicht so häufig, es sei denn, ich habe eben viele große Arbeitsgruppen, Abteilungen, die involviert sind, aber gerade wenn ich mit externen arbeite, zum Beispiel einer Agentur und einem Softwarehersteller, ist es super sinnvoll, dass alle Stakeholder, die operativ am Projekt arbeiten, auch hinterher eine Möglichkeit haben, Dinge eben nach oben zu tragen für eben etwaige Entscheidungen oder Missverständnisse. Beispiel, jemand führt eine Commerce-Lösung ein, kauft sich Spryker, hat eine Umsetzungsagentur, die sich darum kümmert, das Projekt einzuführen. Auf Kundenseite gibt es auch nochmal zwei Entwickler und natürlich die internen Teams, die das Ganze begleiten und mit Daten anreichen. Das heißt, ich habe irgendwie drei Parteien, vielleicht habe ich noch eine vierte, weil es noch irgendwie parallel ein PIM-Projekt gibt, was mit dem Shop integriert werden muss. Das heißt, ich habe vier Parteien, die alle irgendwie zusammenarbeiten müssen, alle irgendwie auch auf eine Timeline hinarbeiten und alle auch irgendwie ein Gesamtbudget haben. So, wenn ich da jetzt nicht diesen einen Owner habe, der alle vier Streams managt und dann nicht mal einen Lenkungsausschuss, wo ich mal strittige Themen, zum Beispiel, ist das jetzt ein Change Request? Ja, nein. Ist das jetzt ein Projektverzug? Ja, nein. Gibt es jetzt dafür Zusatzbudget? Ja, nein.

Das sind so Dinge, wo man häufig sagt, der Joel als Teilprojektleiter von der Shop-Komponente und der Boris als Teilprojektleiter von der PIM-Komponente und der Markus als Projektleiter vom Kunden, die haben das jetzt zweimal diskutiert, Die haben unterschiedliche Ansichten, die haben jetzt keine Lösung gefunden, wie man mit den zusätzlichen 5-Mann-Tagen verfährt. und bevor die sich jetzt operativ aufreihen, weil die Jungs müssen auch die nächsten 6 Monate zusammenarbeiten, verlassen wir mal diese Arbeitsebene, das tragen wir jetzt mal nach oben und dann sitzen dann eben die, weiß ich nicht, die 3 Geschäftsführer vom Softwarehersteller, der Agentur und dem Kunden und die kriegen dann diese Themen vorgelegt und die müssen dann in staatsmännischer Manier dann über sowas befinden, und dann eine Lösung finden, die dann wieder in das Team zurückgeht.

Also, klingt witzig, kann aber eben tatsächlich manchmal ein sehr gutes Board sein, weil es einfach in der Realität, gerade operativ natürlich, jeder versucht seinen Hof sauber zu halten. Der Projektleiter versucht natürlich seinen Hof, der Agentur sauber zu halten und der Projektleiter, das Budget des Kunden. Das ist aber auch erstmal alles fein. Die Interessen sind aber nicht immer 100% kongruent. Es kann manchmal sein, dass eben die Interessen auseinander gehen, ohne dass jemand was Böses möchte, jemand, ne. Und da ist es schon fein, dass man gerade die operative Ebene jetzt nicht sich komplett aneinander aufreiben lässt.

Joel Kaczmarek: Vielleicht mal eine kleine Randnotiz, wenn du in so einem Pitch drin bist, wo du merkst, okay, von einem ganzen Setup her wird dieser Einkaufsprozess nichts. Würdest du dann Leuten, die auf der Verkaufsseite sind, quasi empfehlen, sich da rauszuziehen oder wenig Energie reinzugeben? Oder was machst du in so einer Situation? Wenn du jetzt zum Beispiel mit Spryker in so eine Situation reinläufst, was du gerade geschrieben hast, Steering Committee mit 14 Members und irgendwie tierisch vielen Prozesse und du kannst schon erahnen, dass das schwierig wird. Wie reagierst du denn auf der Zone?

Boris Lokshin: Also man muss das auf jeden Fall flaggen. Ich meine, das kommt darauf an, wie viel Hebel man dann hat auf den Partner oder auf den Kunden. Mit dem konkreten Beispiel, wenn wir sowas sehen als Projektorganisation, dann sind wir da schon sehr deutlich, weil das einfach ein ganz häufiger Grund für eben das Scheitern von Projekten ist, aus zeitlicher oder wirtschaftlicher Sicht, das muss man schon ganz klar ansprechen und eben das auch protokollieren und festhalten, was man da für Bedenken hat, was man auch vorschlägt. Im allerschlimmsten Fall, wenn das Setup sozusagen ein solches ist, bei dem man einfach aus Erfahrung weiß, dass ein Projekt gelingen nicht zu erreichen ist, dann ist es manchmal auch besser, von so einem Projekt zurückzutreten, anstatt sich da ins Verderben zu stürzen.

Denn das ist, glaube ich, schon was, was dann eben die Dienstleister und die Agenturen, die Hersteller häufig sehen, die sehen viele Projekte, Und irgendwann gibt es eben auch gewisse Muster, warum Dinge gut laufen, warum Dinge nicht gut laufen. Und das ist ja auch so ein kleiner Lackmustest, wenn der Kunde sich schon in dem Step als beratungsresistent erweist, ohne Grund. Es kann ja auch manchmal Gründe geben. Es kann auch manchmal sein, ich habe einen Lenkungsausschuss, ich habe jetzt auch mal ein Projekt gesehen, das war ein großer Intentional Corporate, die sozusagen eine Dachgesellschaft von mehreren Marken war, Untermarken. Und jede dieser Marken war dann in mehreren Ländern präsent. Dann hast du halt ein Projekt, was sehr komplex war, weil es quasi ein Corporate-IT-Projekt war. Also es wird bezahlt aus dem zentralen Budget. Die Anpassungen für die Länder werden bezahlt aus den Ländern slash den Marken.

Das ist also eine zwei-, dreidimensionale Budgetstruktur. Und wer die Musik bezahlt, der bestellt sie auch. Wenn drei Leute die Musik bezahlen oder der eine bezahlt 80 Prozent, der andere 20, wird es komplex. hast halt eine komplexe Steuerung, da sagt natürlich Corporate, okay, von uns sitzt da jemand drin, weil wir sind sozusagen derjenige, der das Zentralsystem betreibt, aber jetzt von der Marke A und B sitzen Joel und Boris jeweils drin, und dann gibt es aber nochmal den Peter, der sitzt für die Marke A, drin aber für Frankreich, und jemand für das Land Deutschland, weil das die ersten zwei Länder sind, die ausgerollt werden. Also es kann manchmal sinnhaft sein, es kann manchmal sozusagen auch eine Logik dahinter sein, dann muss man eben auch im Steering Committee klare Regeln festlegen, wie hält man sowas straff, was entscheidet man da? und typischerweise bei solchen Konstrukten Ist dann natürlich auch die Arbeitsebene entsprechend weiter gefächert. Ich habe also viel mehr Leute, die hoffentlich vorher schon viel mehr Sachen abgefangen und entschieden haben. Und dann tritt eben auf so einem Board dann nicht mehr ganz so viel. Und dann schafft man dann eben bei einem Stake die meisten Dinge auch zu besprechen.

Joel Kaczmarek: Gut, wenn wir jetzt also mal ein kleines Zwischenfazit ziehen. Wir hatten am Anfang Unterschieden zwischen MVP und RFP. Also MVP vor allem eher die Kundenladengeschichten, weil man da schnell iterieren muss. Da gut geeignet. Während das nicht so gut geeignet ist, wenn ich eher standardisierte Sachen wie zum Beispiel Fakten, Und wenn jetzt deine Tipps in Sachen Timeline strukturieren, einerseits ein compelling Event haben, in Etappen denken, möglichst auch das Treiben incentivieren, sich immer fragen, gibt es überhaupt jetzt sozusagen einen Grund, sich zu verändern? und warum jetzt, den Overhead klein halten und gleichzeitig so ein Steuerungsbord zu haben. Hast du jetzt basierend auf all den Dingen, die du gesagt hast, vielleicht auch mal ein Praxisbeispiel für so eine Umsetzung aus dem, was du erlebt hast bei euch? Du hast eben schon gesagt, du hast irgendwie ein BI-System bei euch eingeführt, vielleicht hast du ja noch andere Beispiele, dass man das nochmal ein bisschen plastisch,

Boris Lokshin: hervorheben kann. Ich glaube wirklich die einfachsten Beispiele sind ja die, die wir jeden Tag sehen, also wie gehen Leute eben mit der Einführung um von dem, was wir jetzt als Produkt verkaufen, das ist ja ein kundenzentrisches System dann als Commerce-Technologie, da hast du quasi genau diese ganzen Bausteine, du hast dann häufig die Frage, wer kauft das und was sind die Motivationen, das muss man eben vorher verstehen und da auch den Companies ein bisschen helfen, ist das eben ein IT-getriebenes Denken, möchte man eben IT-Metriken optimieren oder ist das eben Business. Beides ist fein, man muss es vorher nur wissen, Man muss dann eben hart reinchallengen und reinfragen, was am Ende der KPI ist, an dem hinterher auch dieser Einkaufsprozess hängt. Kauft jemand nach Kosten der Lösung? Kauft jemand nach Funktionsumfang dieser Lösung? Kauft jemand nach erwartetem Ergebnis aus dem, was man kauft? Es gibt ja ganz unterschiedliche Treiber.

Klar, Timeline ist wichtig. Ich glaube, was wir noch gar nicht thematisiert haben, ist am Ende auch, wie budgetiere ich das? Das ist nochmal ein häufiger Punkt, gerade bei kundenzentrischen Lösungen, also Stichpunkt Agilität, MVP, gehe ich anders mit Budgets um, als eben in dieser ERP-nahen Backend, RFP. Welt. Sprich, ich habe ja eher dieses Dreieck aus Scope, Budget und Timeline in einem normalen Projekt. Und in einem Gen-Projekt sage ich, dass quasi die Zeit sollte idealerweise die Konstante sein. Das ist in klassischen Projekten nicht so. Wenn du dir ein normales Projekt überlegst, dann ist es häufig so, der Scope ist konstant. Stichwort RFP. Ich habe einen Ausschnitt. Ich habe genau aufgeschrieben, was ich möchte. Dann bietet der Joel darauf, dann gibt es einen Preis, der ist auch konstant, also fester Preis. Ich möchte, dass Joel genau für die 100.000 Euro das liefert, was hier in dieser Spezifikation steht. Und die Zeit leistet, das ist quasi die Variable, weil natürlich in jedem dieser Projekte gibt es dann irgendwie Änderungen. Natürlich bleibt man eben auch da nicht vom Markt verschont. Es gibt irgendwie neue Anforderungen, es gibt neue Ideen, es gibt Change Requests, es gibt Dinge, die man nicht zu Ende gedacht hat. Das heißt, am Ende streckt sich die Timeline und auch das Budget. Das heißt, am Ende des Tages hört man immer wieder over time, over budget. Das sind dann die Effekte. In agilen Projekten ist es umgekehrt. Wenn man dieser Zeit als der wichtigste KPI-Denker folgt, dann ist eher Zeit die Konstante. Das heißt, ich sage mir, hey, ich habe ein compelling Event oder ich habe den Meilenstein, den möchte ich erreichen, der ist in acht Wochen, in zehn Wochen erfolgreich. Da wird auch nichts daran gerüttelt.

Da sagt man nicht, okay, ich arbeite jetzt nochmal acht Wochen an der App, sondern das ist der Mainstein. Der muss zu diesem Event da sein. Ich möchte so schnell es geht ins Testen und ins Validieren kommen. Was dann eben variabel ist, ist natürlich der Scope. Das heißt, ich sage dann, okay, ich muss eben schauen, wie viel mein Team bis dahin oder das Team des Dienstleisters bis dahin schafft. Die sogenannte Team Velocity, also die Geschwindigkeit, in der das Team gewisse Dinge abarbeiten kann, die variiert dann. Am Anfang ist das Team ein bisschen langsamer, weil die sich finden müssen. Irgendwann ist es dann schnell genug und liefert auch Eine konstante Velocity, also quasi konstant Output an Ergebnissen. Und ich habe natürlich dann als Kunde die volle Freiheit, auch die Anforderungen zwischendurch zu ändern. Weil ich habe eben nicht vorab investiert, mit dem Partner alles runterzuschreiben, alles runterzuspezifizieren, sondern ich kann dann eben zu Beginn des nächsten Sprints oder der nächsten Iteration kommen und sagen, hey, ich habe jetzt eine neue Idee. Wir haben jetzt hier parallel schon wieder gelernt, dass das oder so und so funktionieren muss. Ich brauche die Suche dann doch anders. Und weil kein großer Aufwand da bisher reingeflossen ist, kann man es halt ändern. Das führt aber eben zu einem anderen Umgang mit Budget.

Bedeutet, ich kann Energie in Projekten dann auf zwei unterschiedliche Art und Weise budgetieren. Ich kann entweder eine sogenannte kapazitative Berechnung machen. Also ich kann mir dann sagen, okay, ich habe ein Team zur Verfügung von sechs Leuten. Die sechs Leute haben dann eine Rolle. Es gibt einen Projektleiter, es gibt einen Tester, es gibt einen Entwickler etc., Und diese Leute sind eben auf dem Projekt. Ich kenne die Tagessätze von den Leuten und ich kenne die internen Kostensätze dieser Leute. Und ich weiß sozusagen, was dieses Team mich pro Monat, pro Woche, pro zweiwöchigen Sprint mich kostet. So, und die Aufgabe ist, okay, das ist sozusagen das Budget. Und was dieses Team schafft, ist eben die Variable, der Scope. Also ich kann mich sozusagen über das Team-Budget leben lernen. Das ist auch so die häufigste Methodik, die eigentlich angewandt wird. Ich kriege meistens schon irgendeine Form von Schätzung. Das heißt, irgendeine Form von Scope wird dann so High-Level geschätzt. Das ist dann nicht komplett verbindlich. Das kann auch links und rechts auch ausarten, auch wenn man natürlich das nicht gern sieht als Kunde.

Es wird meistens gemacht, um eben die Kapazität zu berechnen. Das heißt also, der Dienstleister guckt sich eben an, okay, was möchte ich machen? Und sagt, Joel, das, was du dir gewünscht hast, das glaube ich, hat einen Umfang von 300 Manntagen. So plus, minus 20, 30, 40 Prozent. Also vielleicht mal so als Zwischenwert 300 Tage. Dann sagst du, okay, super Boris, 300 Tage, die muss ich liefern in drei Monaten. Da ist mein Compelling Event und zwar End-to-End mit Testing mit allem. So, das heißt, ich muss liefern 100 Tage pro Monat. Also ein Monat hat 20 Tage. Nach Adam Riese ergibt sich quasi daraus die ungefähre Teamgröße von fünf Leuten, vielleicht plus, minus eine Person, weil natürlich auch Krankheit, Urlaube. So wird das quasi rückwärts engineered. Das heißt, ich muss auch auf der Einkaufsseite muss ich damit eben einhergehen, was eben ganz häufig nicht funktioniert ist, dass man alle Vorteile von Agilität mitnehmen möchte. Also auf der Kundenseite, ich möchte, dass mein Projekt schneller ist, dass ich mehr und häufiger demonstrierbare, verwertbare Zwischresultate habe, dass ich meine Anforderungen permanent ändern kann. Ich will all diese Vorteile haben, aber zu einem fixen Preis und zu einer fixen Timeline.

So, das funktioniert natürlich gar nicht. Das ist auch ironischerweise auch tatsächlich eine Falle, in die man selbst als jemand, der diese Dinge auch anderen erzählt, reinläuft. Also du hast ja gefragt nach Beispielen. Auch wir gucken uns jetzt dann Dienstleister an oder Partner an für zum Beispiel unsere Salesforce-Einführung. Und wenn man da in dem Workshop sitzt, dann erwischt man sich selber dann auch dabei, dass man dann sobald sozusagen die ersten Schätzungen, der erste Skop da ist, versucht eigentlich den Partner in einen Festpreis rein zu verhandeln, indem man das dann agiler Festpreis nennt oder sonst was. Und eigentlich dieses Sicherheitsbedürfnis, was man natürlich versucht normalerweise eben Kunden auszureden, hat. Aber zusammengefasst, ich glaube, Budget ist super wichtig an der Stelle. Ich muss einfach anders mit Budget umgehen. Mir muss klar sein, dass wenn ich Scope und Anforderungen permanent ändern möchte oder die sich in so einer Mutation befinden, dass ich dann eben auch entsprechend Budgetpuffer brauche oder im Zweifel eben hart über den Scope managen muss. Das heißt, wenn ich nur ein gewisses Budget habe, was meistens der Fall ist, ja, und ich habe eben vielleicht nicht 100.000 Euro eingeplant, sondern 130, da muss ich natürlich trotzdem das Projekt permanent anhalten, mich auch zu informieren darüber, dass, wenn Anforderungen geändert werden, ob das eben einen Impact hat auf den sogenannten Cash Burndown oder Cost Burndown.

Ich mache mal ein Beispiel, ich habe irgendwie für 100.000 Euro mir 150 Features bestellt und jedes Feature ist einen Montag wert und ich bin natürlich fein damit, dass permanent mein Projektteam da auch Anforderungen ändert. Wenn dann natürlich Anforderung A im Wert von einem Montag rausgenommen wird, mit Anforderung B ersetzt wird, was fünf Montage wert ist, wenn ich nicht unterwegs irgendwo einspare, bin ich ja vier Tage am Ende über Budget. Das heißt, diese inkrementelle Veränderung muss man dann managen. Also das heißt, so ein bisschen andere Anforderungen an das agile Projektmanagement. Das ist dann nicht mehr ganz so leicht wie in einem klassischen Projekt, wo ich einfach nur sozusagen abhake, ist das dann, ist das dann, ist das dann, aber eigentlich immer mich kostenmäßig in so einem Konzept bewege. Und ich muss permanent die drei Kurven, also Burndown von Scope, also wie brenne ich meinen Scope runter, Zeit und Geld monitoren.

Und vor allem die drei Kurven im Verhältnis zueinander. Jeder einzelne für sich ist erstmal noch gar nicht so relevant. Du könntest auf eine Kurve von Zeit gucken und sagen, ich habe jetzt irgendwie eine Verlängerung, das Projekt dauert eine Woche länger, aber vielleicht ist die Scope-Kurve dafür auch länger, vielleicht liefere ich weniger und die Budget-Kurve dafür kürzer. Ich liefere mehr, in der Woche weniger, aber für weniger Geld. Das ist vielleicht alles in Summe immer noch okay. Also ich muss immer diese drei Sachen auf einmal monitoren, aber budgetmäßig muss ich einfach anders planen, andere Puffer mir stellen und dann eben mir von vornherein mir bewusst sein, dass ich nicht nur die Vorzüge nehmen kann.

Joel Kaczmarek: Sehr spannend. Ich bewundere das immer, wie strukturiert du solche Sachen angehst. Finde ich wirklich beeindruckend. Darf ich dir mal ein Kompliment machen? Hast du noch einen Tipp, wenn jemand jetzt in der Lage ist, wir haben ja ganz am Anfang gesagt, es gibt manchmal IT-getriebene Einkaufsprozesse und manchmal auch Business-getriebene Einkaufsprozesse. Und ich habe zum Beispiel mal eine wo man sich gerade diesem IT-Faktor sehr verschrieben hatte, da war oft der Punkt, IT hat oft das Problem, dass es genau das, was du gerade gesagt hast, wir sind schon fast auch ein bisschen jetzt in Richtung Erfolgsmessung gleich, diesen Scope oder diesen Effekt nicht so gut sichtbar machen kann bei einem Business-Stakeholder.

Das heißt, du brauchst etwas aus technischer Sicht, kannst es aber jemandem, der non-technisch ist, nicht so leicht erklären und kriegst das Budget schwer freigeschaltet. Hast du Tipps, wie man Budgets sozusagen oder die Budgetallokation für Einkaufsprozesse optimieren kann, wenn man zum Beispiel gerade eben nicht der Business-Entscheider ist?

Boris Lokshin: Mit den Leuten reden. Also ich glaube, das ist tatsächlich der einfachste Tipp. Also ganz häufig ist diese Übersetzungsarbeit gar nicht so schwierig. Ich glaube, die Leute versuchen viel zu häufig alleine sich davor zu kämpfen. Wenn ich irgendwie auf der Entwicklerseite bin oder auf der technischen Seite und ich habe zum Beispiel eine nicht funktionale Anforderung wie Performance und ich bin mir nicht sicher, ob und welchen Impact sie hat, dann muss ich einfach mit dem Business-Counterpart mich zusammensetzen und dann guck mal, was hätte das denn für Effekte, wenn die Webseite nicht mehr eine Sekunde lang lädt, sondern nur noch eine halbe, da gibt es doch bestimmt irgendwie Daten zu und da gibt es bestimmt irgendeinen Einfluss auf die Conversion, kannst du mir da helfen, dann gibt es da irgendwie Studien zu, können wir einen A-B-Test machen, können wir das ableiten. Also einfach sprechen mit den Leuten, weil ganz häufig sind die Ziele sozusagen hoch aggregiert gar nicht so unterschiedlich. Ich habe dann irgendwelche betriebswirtschaftlichen KPI meistens, die ich versuche dann zu steuern über verschiedene Parameter. Also sowas wie zum Beispiel Umsatz ist auch nicht eine Metrik. So einen Umsatztreiber gibt es vielleicht hunderte, die auf den Umsatz einzahlen. Aber wenn ich eben als IT-Person das nicht komplett überblicken kann, ich kann auch sowas wie vage Faktoren, wie zum Beispiel, hey, ich habe weniger Leute oder ich habe weniger Bedarf an Leuten, die sich mit der Pflege eines Systems beschäftigen. Ich habe ein System, was aufgrund der Eigenschaften, der Architektur, der Funktionalität leichter, schneller zu warten ist und ich habe jetzt ein Entwicklungsteam von 10 und da werden zwei Leute frei.

Und ich will natürlich jetzt nicht als IT-Person da hingehen und sagen, okay, wir können zwei Leute, der Benefit für die Company ist, dass ich zwei Leute entlassen kann, sondern dann gehe ich zum Business und sage, Joel, guck mal, du hast doch hier mit deinem Sales-Marketing-Team einen permanenten Backlog. Stell dir vor, was wäre denn, wenn wir 20% mehr Kapazität hätten, wenn wir sozusagen 20% schneller liefern könnten oder mehr pro Monat an euren Ideen abarbeiten, dann könntet ihr schneller interagieren, ihr könntet mehr ausprobieren, ihr könnt wahrscheinlich die Umsatztreiber oder die Kostentreiber sozusagen schneller identifizieren. Lass uns doch mal damit hier mal irgendwie eine Überschlagsrechnung machen, was das für uns als Organisation an Speed bedeutet. Alleine ist immer schwierig, ich glaube, da macht es total Sinn, sich einfach zu erleiden und die meisten Sachen kriegt man auch gut zusammen. Gut, abschließend.

Joel Kaczmarek: Erfolgsmessung haben wir ja schon in Aussicht gestellt, dass wir darüber noch sprechen wollen. Wie würdest du einen erfolgreichen Einkaufsprozess messen?

Boris Lokshin: Am Ende des Tages die drei Dimensionen. Klar, sozusagen Budget, Timeline, Scope. Was habe ich mir am Anfang vorgenommen? Was wollte ich umsetzen? Also gerade in Relation zueinander, diese drei Kurven. Die muss man, glaube ich, dann übereinander legen, um das Projekt, sozusagen das Einkaufsprojekt zu verifizieren. Und dann geht es natürlich in die eigentliche Erfolgsmessung, sozusagen zurück auf los. Wir haben gesagt Was habe ich für ein Problem? Das muss am Anfang definiert werden. Plus welchen KPI? Das muss ich mir natürlich sofort überlegen. Und dann eben schauen, okay, ich habe das Ganze angefangen, um, weiß ich nicht, eine höhere Sichtbarkeit im Markt zu haben, bessere SEO-Auffindbarkeit, bessere mobile Experience für meine Kunden. Also was waren die Ursprungsmetriken? Und dann muss ich ins Messen kommen.

Und ironischerweise fängt dann wieder alles quasi bei Null an. Das ist ja genau die Art von eben diesen agilen Projekten, das heißt, ich habe diese Metriken mir gesetzt, ich habe den ersten Teilabschnitt ausgeliefert, eingekauft und ich bin dann quasi genau da, wo ich vorher auch war. Ich messe, ich bekomme Daten rein, Dinge, die meine Annahmen vom Anfang verifizieren, andere Dinge, die sie widerlegen und ich gehe in den nächsten Projektteilabschnitt. Das ist jetzt, also unser internes Salesforce-Projekt ist, glaube ich, jetzt auch in fünf oder sechs Abschnitte geschnitten, unser BI-Projekt auch in vier Abschnitte, wo wir natürlich auch nicht nur in weitere neue Anforderungen reingehen, sondern auch immer wieder die Learnings aus dem ersten Abschnitt oder dem vorherigen dann reingehen und dann auch mit umgesetzt oder umgebaut werden.

Joel Kaczmarek: Aber kannst du das immer so sauber trennen, dass du da auch feine Messpunkte setzen kannst?

Boris Lokshin: Also ich glaube, wenn man smart reinschaut, kannst du ja immer schneiden. Du kannst funktional schneiden, du kannst als Stakeholder schneiden. Also wieder solche Beispiele, auch wenn es jetzt nicht so die kundenzentrischen Beispiele sind. In unserem BI haben wir jetzt nach Stakeholdern geschnitten. Okay, wir wollen zuerst Sales Marketing abdecken. Danach wollen wir sozusagen unsere interne Projekt- und Produktsteuerung sozusagen da mit reinholen. Danach kommen HR-Daten, HR-KPIs. Also du kannst schon so nach Stakeholder das berechnen. In einem Salesforce-Projekt ähnlich. Da gibt es irgendwie erst mal Sales Marketing, die abgedeckt werden. Dann kommt unser ganzer Partner-Management-Bereich. Danach kommt Customer Success. Man findet immer schon sinnvolle Punkte und man muss dann einfach sich intern auch dann fragen, wo ist das Problem, der Schmerz am größten.

Natürlich will jeder sofort rein und wenn du sagst, ich baue ein neues BI, dann schreien das mal alle auf und sagen super, aber es ist glaube ich schon super, super smart, wenn ich eben einfach Meilenstein habe, die auch, das darf man aber nicht vergessen, die auch dem Projektteam auch ein Erfolgserlebnis geben. Weil nichts ist besser, als wenn du dann so einen Zwischenabschnitt hast oder so eine interne Präsentation von dem BI und dann irgendwie zeigen kannst, wie leicht irgendwie Sales Marketing sich jetzt selber Dashboards bauen können. Das ist ja auch für die Projektverantwortlichen dann super befriedigend. Und auch vom Einkaufsprozess ist es am Ende eine Form von Risikosteuerung. Ich kann jetzt mich hinsetzen, also Salesforce, um wieder das Beispiel von uns zu nennen, ist eine riesen Applikation oder eigentlich ein Applikationsuniversum mit tausenden von Apps, tausenden von Modulen, tausenden von Schnittstellen.

Gefühlt kannst du alles da drin machen und da kannst du dich natürlich hinsetzen und bevor du das alles dir überlegt hast, 37.000 Lizenzen ans Bein binden. Oder eben Schritt für Schritt vorgehen, dann immer nach Bedarf einkaufen und dann erstmal sehen, Dinge ausprobieren, sie für 30 Tage irgendwie ein Trial geben. Und wenn du dann siehst, okay, dieses Feature oder dieses Modul oder diese App erfüllt wirklich den Zweck, die Stakeholder sind zufrieden und alles passt, so, dann behalte ich das. Die Alternative, sich da erstmal sozusagen wie ein Weihnachtsbaum vollzuhängen mit irgendwie Kugeln, und Lizenzen, ist, glaube ich, keine gute heutzutage.

Joel Kaczmarek: Hervorragend. Ich glaube, das war ein wirklich spannender und auch, wie gesagt, immer so schön strukturierter Ritt durch das ganze Thema Einkauf. Und haben wir noch was vergessen? Nee, ich glaube Eigentlich war es das im Wesentlichen, ne? Also vielleicht nochmal ganz kurz zusammengepasst. Also wir haben angefangen damit, dass wir mal darüber geredet haben, womit ich eigentlich starte. Ja, also ist das eine IT-getriebene oder eher eine Business-getriebene Entscheidung? Welche KPIs setze ich mir und sind dann eingetaucht in das ganze Thema MVP versus RFP? Also sprich, mache ich eine Ausschreibung oder iteriere ich in kleinen Schritten? haben viel über die Timeline gesprochen und über die Umsetzung, sind dann zum Thema Budget gekommen und last but not least zum Thema Erfolgsmessung. Und uns interessiert auch immer der Input unserer Hörer. Also wenn ihr da draußen auch solche Prozesse habt und noch Input, den wir vergessen haben, schreibt uns gerne E-Mails oder kommentiert unter unsere Podcasts. Wir freuen uns darüber und ich freue mich schon aufs nächste Mal mit dir, lieber Boris. Für heute schon mal vielen Dank.

Boris Lokshin: Danke, ciao.