IT-Projekte im Finanzressort zum Erfolg führen - die Sicht des Softwareunternehmens Virtivity

00:09:11: Sprecherin: Zielführung starten – der Management-Podcast von CTcon.

00:22:08: Dr. Christian Bungenstock: Ich bin Christian Bungenstock, Partner bei CTcon in Düsseldorf und Gastgeber von Zielführung starten, dem Management Podcast für Themen der Unternehmenssteuerung. Ich freue mich, Sie heute auf eine Tour mitzunehmen, die uns einen Blick auf Erfolgsfaktoren datenintensiver IT-naher Entwicklungs- und Migrationsprojekte im Finanzressort eröffnet. Wir begleiten Marco Becker und Maximilian Reich.

00:44:08: Dr. Christian Bungenstock: Marco Becker ist mit mehr als 25 Jahren Erfahrung als Softwareentwickler, Softwareberater und Softwareunternehmer ein breit anerkannter Experte. Er hat Erfahrungen unter anderem bei IBM und Applix gesammelt. Marco ist heute Gründer und Geschäftsführer der Virtivity GmbH in Hamburg. Mit den Tücken kritischer Migrationsvorhaben in großen Konzernen ist er bestens vertraut. Maximilian Reich ist Projektleiter bei CTcon in München. Max berät seit vielen Jahren große Konzerne in den Bereichen Data Analytics, Datenorganisation und in Data Governance. Marco und Max kennen sich seit mehreren Jahren aus der gemeinsamen Projektarbeit.

01:26:20: Dr. Maximilian Reich: Hi Marco, schön, dass Du heute da bist und Dir Zeit genommen hast für unsere Podcastreihe „Zielführung starten“. Herzlich willkommen!

01:34:01: Marco Becker: Schönen Dank!

01:35:05: Dr. Maximilian Reich: Wir kennen uns jetzt schon seit zweieinhalb Jahren. Ich hab dich damals als TM1-Guru kennengelernt und „Produktisierer“, das heißt sehr stark in der Produktentwicklung von IT- und Daten-Produktentwicklung. Und seitdem überschneiden sich unsere Wege recht regelmäßig; immer dann, wenn wir bei CTcon ein größeres Digitalprojekt im Finanzbereich mit unseren Klienten irgendwie planen und umsetzen, stehst Du uns als Experte mit Rat und Tat zur Verfügung und gibst wertvollen Input. Dein Mindset hilft uns an der Stelle total weiter. Es unterscheidet sich erheblich von dem Mindset des Controllers im Finanzbereich, weil Du dieses IT-Mindset, Product-Mindset an der Stelle mitgibst. Du selber bist Gründer und Geschäftsführer von Virtivity. Ihr habt letzte Woche Euer vierjähriges Bestehen gefeiert. Nochmal herzlichen Glückwunsch dazu.

02:24:01: Marco Becker: Danke.

02:25:04: Dr. Maximilian Reich: Dann mal die Frage für alle Zuhörerinnen und Zuhörer, Virtivity, was ist das eigentlich?

02:31:00: Marco Becker: Ja, Virtivity ist die Ausgründung aus einer Unternehmensberatung. Wir stellen ein Produkt namens Apollo her. Das ist eine modulare Lösung, die bereits vorgefertigten Content enthält, mit dem wir in der Lage sind, viele Finanzprozesse im CFO-Bereich sehr schnell abzubilden.

02:48:11: Dr. Maximilian Reich: Jetzt sind Eure Nutzergruppen ja vornehmlich Controller und kommen aus dem Finanzbereich. Agilität ist ein Stichwort, was mir bei der Produktentwicklung von IT- und Daten-Produktentwicklung direkt in den Sinn kommt. Wir reden in Projekten oftmals von agilen Umsetzungen. Projekte werden agil gefahren. Jetzt wird agil, relativ häufig und relativ inflationär verwendet für Dinge, die im Endeffekt nicht agil zumindest im Sinne der Scrum Definition sind. In der Softwareentwicklung, und daher kommt dieser ganze agile Gedanke, ist das natürlich ganz anders. Von Daher die Frage: Was sind denn so die Erfolgsfaktoren bei der technischen Umsetzung von so einem Datenprojekt bzw. von so einem Datenprodukt? Auf welche Themen legt Ihr Wert? Was muss man beachten, was man in so klassischen Projekten, wie wir sie in der Unternehmensberatung im Finanzbereich kennen, vielleicht gar nicht so sehr auf dem Schirm haben und wie lebt Ihr die agile Entwicklung an der Stelle aus?

03:43:09: Marco Becker: Ich glaube, das Allerwichtigste im Projekt, das kann man relativ einfach sagen, ist Reden und Zeigen. In diesen Projekten haben wir zwei Arten. Die einen sind fachlich orientiert, die anderen sind wiederum sehr technisch. Und dann haben wir Leute dazwischen, die entsprechend mitteln können zwischen der Technologie und der Fachlichkeit. Das führt grundsätzlich immer zu „Abstimmungs-“ in Anführungsstrichen „-Themen“, die man hat – früher oder später. Deswegen ist es sehr wichtig, dass man in kurzen Abständen immer wieder zeigt, was man gemacht hat, wie man sich das vorstellt und auch wieder Rückfragen stellt, damit alle dasselbe Verständnis haben, dessen, was man tun muss. Wir entwickeln für den Kunden, wir entwickeln nicht für uns. Und Deswegen ist es wichtig, dass der Kunde das akzeptiert. Auch wenn wir vielleicht als Entwickler irgendwas besonders schön finden, findet der Kunde das vielleicht nicht so und insofern ist es wichtig, dass man da seine Sichten und auch seine Verständnisse immer wieder regelmäßig abgleicht, gerade in agilen Projekten. Viele Details hat man einfach auch nicht besprochen und insofern ist es dann wichtig, dass dort ein regelmäßiger Abgleich stattfindet. Also ich glaube, das ist bei jeder Methodik, die man irgendwie dort einbauen möchte, ob das Scrum ist, ob das „getailoredes“ Scrum ist oder ob man es mit Kanban kombiniert, das ist „alles egal“. Wenn die Leute nicht miteinander reden und sich nicht zeigen, was sie gemacht haben. Dann ist das nicht erfolgreich.

04:56:19: Dr. Maximilian Reich: Ja, absolut. Kann ich auf jeden Fall unterschreiben. Jetzt, wie schon gesagt, sind wir relativ häufig im Austausch. Vielleicht noch mal ein Design Principle. Wie können wir Themen entwickeln, im Sinne von: Okay, plane damit, dass es schiefgeht? Das Thema „Design for Failure“.

05:10:06: Marco Becker: Grundsätzlich, wenn Du Migration hast oder Softwareprojekte oder wenn man Sachen für die Cloud entwickelt, dann kennt man nicht alle Details. Du hast immer wieder Überraschungen, die reinkommen. Und der, ein Regelfall, auch in der Softwareentwicklung, ist eigentlich, dass es einen Fehler gibt und wenn zum Beispiel auch große Migrationen geplant werden, dann plant man eigentlich immer – ja, das Detail kann auftreten, das Detail kann auftreten, aber man plant nie die Details, von denen man jetzt noch nichts weiß, die trotzdem auftreten. Und was macht man dann eigentlich? Und deswegen geht halt auch eine Menge schief. Und deswegen benutzen wir einen Ansatz, der es auch klassisch hier im Cloud-Bereich, der nennt sich „Design for Failure“.

05:47:06: Marco Becker: Das heißt, ich lege einen hohen Fokus auch auf das Auftreten von Fehlern und auf meine Fehler-Behandlungsstrategien. Und der Unterschied im Wesentlichen ist, dass eine Änderung im Mindset, dass man sagt okay, ich habe mit dem Fehler gerechnet und ich habe grundsätzlich mit Fehlern gerechnet und das System, was ich habe, ist entsprechend resilient. Oder das Konzept, was ich benutze, ist entsprechend resilient gegen Fehler, und vor allem gegen unerwartete Fehler. Es gibt unterschiedliche Methoden, so was entsprechend umzusetzen. Zum Beispiel über Redundanz kann man so was machen. Das ist auf jeden Fall, was wir benutzen und was sich auch sehr, sehr gut bewährt hat.

06:18:00: Dr. Maximilian Reich: Jetzt sind Eure Nutzer Controller, wo so im Prinzip, sage ich mal vorsichtig, nicht so üblich oder zumindest nicht in aller Munde ist. Wie reagiert denn so Eurer klassischer Ansprechpartner, wenn du sagst, okay, das wird wahrscheinlich schief gehen, aber das gehört zur Entwicklung dazu.

06:32:00: Marco Becker: Also das „Design for Failure“ haben wir zum einen in der Softwareentwicklung, wo wir das in unsere Module einbauen. Man kann auch sagen „expect the unexpected“, wo wir eben viele Möglichkeiten haben, das zu lösen. Wir lösen das in der Software zum Beispiel durch einen hohen Grad der Vernetzung durch Datenprodukte, die miteinander verbunden sind, und vielen Fähigkeiten in der, nennen wir es jetzt mal Plattform oder im System, sich untereinander zu vernetzen. Das heißt, wir haben immer die Option, einen entsprechenden Lösungsansatz zu finden. Dieses „Design for Failure“ haben wir gar nicht so stark in unserer Projektmethodik. Das heißt, der Kunde ist im wesentlichen Nutznießer, der Konzepte, die wir eben sozusagen in der Entwicklung benutzen. Wir konfrontieren den Kunden da so direkt gar nicht.

07:11:21: Dr. Maximilian Reich: Wenn Ihr jetzt in ein Unternehmen, bei Euren Kunden, implementiert, da ist natürlich ganz spannend, weil Ihr gleichzeitig mit der IT zu tun habt, also auch dann mit den Nutzern, also mit den Controllern, bzw. der Controlling-Abteilung. Die Probleme, die da gesehen werden, die Herausforderungen, die da gelöst werden müssen, die sind ganz grundverschieden. Also ein ITler, da drückt natürlich ganz woanders der Schuh und der hat ganz andere Bedenken an der Stelle als der Controller. Und da ist es natürlich spannend, irgendwie beide in ein Team zu bekommen bzw. auch mit beiden Seiten erfolgreich zu kooperieren. Was sind denn so die Herausforderungen, die Euch typischerweise begegnen, genau in diesem Zusammenspiel? Und wie habt Ihr die in der Vergangenheit gelöst?

07:49:01: Marco Becker: Herausforderungen, die Du natürlich immer hast bei solchen Sachen sind, wie kriegst Du die Daten von externen Systemen oder wie kriegst Du Zugriff auf bereits existierende Systeme des Kunden? Als Beispiel, du machst eine HR-Planung und das HR-System muss irgendwie noch Daten liefern. Dann musst Du erst mal gucken, wo liegt das System? Wer ist verantwortlich für das System und welche Bedingungen gibt es dann, auf das System zuzugreifen? Wir lösen es eigentlich so, dass der Controller oder wir gehen ins Controlling, fragen den Kunden: Welche Daten braucht Ihr in Euren Systemen und diskutieren dann mit der IT, wie wir an diese Daten rankommen. Oft regelt das auch der Kunde für uns. Das ist dann auch oft sehr hilfreich, weil er seine internen IT-Prozesse kennt und weiß dann, wie er mit der IT sprechen muss. Wir machen dann eben die entsprechende Anbindung. Dazu gehören dann eben solche Sachen wie Security. Auf welche Daten willst Du zugreifen? Darf man auf die Daten zugreifen? Wer darf die Daten sehen usw.? Das sind dann eben entsprechend die Herausforderungen, die in dem fachlichen Use Case gar nicht so da sind, die aber dann durch die Diskussion mit der IT immer wieder aufs Tablett kommen.

08:48:01: Marco Becker: Wichtig ist auch dann eben zu versuchen, nicht gegeneinander zu arbeiten, sondern eben auch dann entsprechende Brücken zu bauen, damit das möglichst schnell auch zu einer Anbindung und zu Erfolgen kommt. Und das Schlimmste, was eigentlich passieren kann, ist, wenn dann die Position irgendwie verhärten, wenn die eine Seite bestimmte Daten haben will, die IT oder die andere Seite dann die Daten nicht rausgeben kann oder nur unter bestimmten Bedingungen rausgeben kann, bestimmte Routen im System nicht gelegt werden können. Da gibt es viele Herausforderungen und wichtig finde ich immer, es ist hierbei sehr lösungsorientiert zu arbeiten, dass man ein Mindset bekommt, wo alle das Thema auch lösen wollen. Und nicht nur, „das jetzt wirklich schnell runter von meinem Tisch“, sondern, wenn alle zusammenarbeiten und sagen so lasst uns überlegen, was sind kreative Möglichkeiten, was sind Ideen, um die Sachen im Sinne aller und zur Zufriedenheit aller von System A nach System B zu bringen oder vielleicht auch eine Onlineanbindung zu machen? Ich glaube, das ist, das ist sehr, sehr wichtig und das sind auch Herausforderung, die man immer, immer wieder hat.

09:45:20: Dr. Maximilian Reich: Absolut. Und da sprichst du mir aus der Seele, das begegnet uns auch tagtäglich in den Projekten. Hast Du vielleicht ein, zwei konkrete Tipps oder sogenannte „War Stories“ aus der Vergangenheit, wo du sagst, okay, das hat uns noch mal irgendwie näher zusammengebracht und damit haben wir uns irgendwie genau an diesem einen Strang gefunden, an dem wir gemeinsam ziehen können, IT und Fachabteilung – an der Stelle – oder Controller?

10:09:03: Marco Becker: Ich glaube für alle ist es interessant, ein erfolgreiches Projekt zu machen und jeder ist stolz da drauf, wenn er das Projekt erfolgreich zu Ende gebracht hat. Und das ist oft, oder es kann oft ein Punkt sein, der einen dann auch eint, wo man sagt: Guck mal, das ist jetzt ein gemeinsames Team-Ergebnis, was wir hier geliefert haben, zusammen aus Fachbereich, IT und Beratung und allen Leuten, die daran beteiligt waren. Das ist oft einen Erfolgs-Treiber

10:33:00: Dr. Maximilian Reich: Eine andere Herausforderung, die uns auch wieder häufig begegnet, ist der erste Ansatz. Wir sprechen mit der Fachabteilung, wir sprechen mit dem Controlling und sagen in Digitalisierungsprojekten: Ja, wir wollen und auch das wird immer, immer wichtiger, jetzt, wenn wir Unternehmenssteuerung denken und an „Entscheidungen treffen“ – die Verschneidung der Daten, dieses Harmonisieren der Daten, das Verknüpfen der Daten aus den unterschiedlichen Bereichen, auch da die Finanzsicht zu haben, die operative Sicht zu haben, meinetwegen die Marketingsicht, alle möglichen Töpfe, die man so hat, zu verschneiden. Die erste Reaktion, die wir häufig erleben: Ach, unsere Daten, das ist viel zu komplex, das wird nie was, das klappt nicht, an der Stelle keine Chance. So. Dann ist das natürlich ein Hebel, der uns verloren geht, um später noch erfolgreicher Entscheidungen im Unternehmen zu treffen. Und natürlich auch noch später in Richtung AI, ein wahnsinniger Hebel, der uns da verloren geht, wenn diese Daten eben nicht verknüpft werden und diese Datensilos beibehalten werden. Was ist da Dein Ansatz?

11:36:05: Marco Becker: Ich glaube, es ist auch so ein bisschen natürlich Mindset. Wir können uns oft und viel erklären, warum es nicht geht, aber besser ist, wir sprechen darüber, wie wir es machen. Wir versuchen immer über den Use Case zu gehen, zu sagen, welches Problem wollen wir denn eigentlich lösen und welche, nennen wir es Daten- Produkte, sind auf diesem Weg notwendig. Das führt zu relativ konkreten Anfragen an die Vorsysteme oder an die zuliefernden Systeme. Die ganze Komplexität, von der man vorher eigentlich ausgegangen ist, verschwindet dann, wenn man entsprechend vom Use Case kommt, miteinander redet und genau sagt, wir brauchen das, wir brauchen das, wir brauchen das. Dann wird es meist deutlich einfacher als man vorher gedacht hat und man ist in der Lage sehr lösungsorientiert das Problem zu lösen.

12:14:05: Dr. Maximilian Reich: Das ist ja schon das Argument für IT-Migrationsprojekte, um da auch die Komplexität ein Stück weit rauszunehmen. Vielleicht kannst Du da auch noch mal die Zuhörerinnen und Zuhörer mitnehmen, was denn Dein Blick Richtung Projektplanung und -vorgehen bei eben solchen größeren IT-Migrationsprojekte angeht.

12:31:05: Marco Becker: Wir hatten ja heute auch schon das Thema „Design for Failure“ und ich glaube, das „Design for Failure“ aus der Softwareentwicklung auch bei großen Migrationsprojekten helfen kann, so man große IT-Migrationsprojekte hat. Nehmen wir mal an, wir migrieren ein größeres ERP-System von A nach B bzw. auf eine neue Version. Dann kann ich natürlich planen und auch wahrscheinlich relativ detailliert planen, was intern in dem System passiert und wie ich es umsetzen will. Was ich in dem Moment nicht weiß oder womit ich eigentlich immer rechnen muss, ist, das an diesem System noch andere Systeme dranhängen, die im Zweifelsfalle auch vital sind. Also ich hatte das mal jetzt beim Kunden, da sagt mir eine Fachabteilung, ja, die migrieren jetzt unser ERP-System, aber wir wissen gar nicht, wie wir nach der Migration an unsere Daten kommen. Das ist natürlich ein schwieriges Ding. Und wenn das ein vitales System ist, kann natürlich dann so eine Migration auch zu Schwierigkeiten führen. In so einem Falle ist natürlich das „Design for Failure“- Paradigma wieder sehr gut. Zu sagen, was machen wir denn, wenn mein System da ist? Oder wie ist grundsätzlich unsere Verfügbarkeit oder wie stellen wir unser System auf? Wenn wir jetzt ein System mal vergessen haben, was da noch irgendwie dranhängt? Sollte natürlich nicht passieren, aber passiert eigentlich. Sieht man halt immer und das ist das, was dann oft solchen Migrationen entsprechend scheitern lässt bzw., wo man dann sagt, „ja“, war nicht so erfolgreich oder wir hatten hier Probleme und wir hatten da Probleme. Deswegen ist es wichtig, wenn man das Projekt dann managt, solche Fehler vorzusehen.

13:53:05: Marco Becker: Es ist auch ebenfalls wichtig bei solchen Migrationsprojekten, wenn man anfängt, sich zu überlegen, wo ist denn der „Point of no Return“, wann kann ich denn nicht wieder zurück? Ich habe das mal verglichen mit dem „V1-Moment“ beim Flugzeug. Wir sind die ganze Zeit auf der Rollbahn und, das Flugzeug rollt und irgendwann gibt es diesen „V1-Moment“. Das ist dann die Geschwindigkeit, wo die Rollbahn zu kurz ist, um noch abzubrechen. Das Flugzeug muss dann fliegen, das muss dann in die Luft. Und solche Sachen gibt es im Projekt auch. Und in dem Moment, wo das passiert, wo man nicht mehr zurückkommt, muss sich dann auch die Fehlerbehandlungsstrategie verändern. Und zwar ist dann dieses „Design for Failure“ in dem Moment absolut richtig und absolut wichtig, dass man viele Optionen hat, dann die Fehler noch zu korrigieren. Wenn man mit dem Ding schon in der Luft ist, weil man dann nicht mehr zurück kann.

14:35:05: Marco Becker: Was ich auch wichtig finde, ist das gerade bei Neuprojekten, vergisst man dann die reine Flugphase. Und das ist übrigens auch ein Konzept vom „Design for Failure“, dass, wenn ein Projekt dann erfolgreich ist, dann kommen immer mehr Leute auf das System und dann stößt oft die Skalierbarkeit an seine Grenzen und dann geht wieder die User-Akzeptanz nach hinten. Das ist auch wichtig, dass man das auch schon vorsieht. Das heißt, was passiert denn, wenn ich jetzt erfolgreich mit meinem Projekt bin. Mein Projekt jetzt so tolle Daten produziert, dass alle drauf wollen und alle feststellen, dass das so toll ist.

15:07:05: Marco Becker: Das habe ich in meiner Zeit bei IBM relativ häufig erlebt. Wenn dann Systeme vom Fachbereich entwickelt wurden, die dann ganz toll von allen Leuten angenommen wurden und da waren immer ganz viele Leute drauf auf dem System und das System skalierte nicht mehr. Das ist dann immer ganz wichtig, eben in solchen Projektphasen, auch in laufenden Migrationsphasen und in der Einführung von Neuprodukten diese Skalierbarkeit, nennen wir es „Flugphase“, entsprechend mitzudenken. Das ist wichtig, damit man, wie gesagt, die Akzeptanz des Projekts auch hochhält. Ansonsten geht der Flieger hoch, fliegt einen Augenblick und ist dann relativ schnell wieder am Boden, weil genau in dem Moment die Leute sich auch zurückziehen, wenn sie feststellen, ach nee, ich kriege doch keine Daten aus dem System. Ich weiß gar nicht, was die alle gemacht haben. Und deswegen ist die Skalierbarkeit des Systems eben auch wichtig, dass man in der Lage ist, wenn man erfolgreich gestartet ist, das Ding auch länger in der Luft zu halten.

15:54:00: Dr. Maximilian Reich: Okay, plane damit, dass es schiefgeht. Das Thema „Design for Failure“.

15:55:00: Marco Becker: Warum planen wir denn für den „Erfolg“? Wir müssen doch planen, was machen wir, wenn es schiefgeht, weil es schiefgehen wird! Das ist doch der Weg in dem Moment. Und das ist ja auch gar nicht schlimm, wenn Du halt vorbereitet bist und wenn Du dein System so aufgestellt hast, dass es resilient genug ist, für so was. Und wenn Du eben überlegst, dass die Intelligenz der Grad der Vernetzung ist – hat mal ein schlauer Mann gesagt, kommt nicht von mir – dann ist ein intelligentes System, ein möglichst weit vernetztes System. Und das erreichst Du durch Schnittstellen, dass ich keine Closed Shops habe und dass ich in der Lage bin, eben möglichst schnell meine Systeme miteinander zu vernetzen und das entsprechend in meiner Architektur und in meinem Projektplan vorsehe.

16:32:15: Dr. Maximilian Reich: Und wie siehst du das aktuell jetzt mit Blick eben auf deine Projekte, mit Blick auf die Unternehmen, in denen Du unterwegs bist? Wie siehst Du die da gerüstet, sozusagen auch IT-seitig? Da spielen ja auch wieder alle Fachbereiche rein, die IT, die Fachabteilung, das Controlling etc., der Finanzbereich eben als solches? Wie siehst du da diese Abteilungen – Stand heute – wie siehst Du diese gerüstet?

16:55:19: Marco Becker: Ich glaube eher schlecht. Oft wird nicht weit genug gedacht, oder werden andere Systeme nicht mitgedacht. Manchmal gibt es Teams, die sich eben nur mit der Technologie ihres eigenen Systems beschäftigen und auch das in ihrem Kämmerlein weiterbetreiben. Dann läuft ihr eigenes System wunderbar und fehlerfrei und alle Nachfolgesysteme schauen in die Röhre, was oft zu unschönen Nebeneffekten führt. Nennen wir es mal so.

17:18:19: Dr. Maximilian Reich: Das heißt jetzt werden ja Migrationsprojekte, IT-nahe Projekte als solches, nenne ich jetzt mal, werden ja in Zukunft nicht weniger. Die Unternehmen müssen die Daten aufnehmen, da ist der Harken dran, sage ich mal, die Daten sind vorhanden – aber die Daten eben auch irgendwie effektiv verwenden, um damit zu steuern, um damit die richtigen Entscheidungen zu treffen. Wo siehst Du denn die größten Blind Spots heute noch in den Unternehmen? Wo muss denn am dringendsten gehandelt werden?

17:45:00: Marco Becker: Ich glaube, in unterschiedlichen Strategien, die Daten zusammenzubringen. Das kam jetzt ja auch immer wieder zur Sprache, dass man die Datenprojekte oder Datenprodukte entsprechend generieren kann. Und ich glaube, dass da noch eine Menge Herausforderungen liegen. Datenprodukte müssen auch nicht immer erst so entstehen, dass ich alles in einen großen Data Lake kopiere und dann da irgendwas erzeuge. Vielleicht brauche ich nur ganz bestimmte Informationen aus einem System, die ich auch vor Ort erzeugen kann. Ich kann auch vielleicht Daten direkt vor Ort abgreifen und muss sie gar nicht erst irgendwo anders wohin kopieren. Gerade, wenn man mal mit transaktionalen Daten arbeitet, dass das schon sein kann, dass in dem Moment, wenn man die Daten einmal umkopiert hat, transaktionale Daten auch schon zu alt sind und keine Relevanz mehr haben. Und ich glaube, dass wird da mehr Strategien brauchen, um solche Themen entsprechend zu lösen.

18:31:23: Dr. Maximilian Reich: Absolut wichtiger Punkt, der uns natürlich bei CTcon auch extrem beschäftigt. Stichwort Datengetriebene Steuerung. Genau dieses Vernetzen, dieses Zusammenbringen operativer Daten, der Finanzdaten und alle anderen Daten im Unternehmen und das eben zu ermöglichen. Genau mit der vorhin schon angesprochenen Herausforderung. Es ist ja viel zu komplex, es sind ja viel zu viele. Und genau dieses Thema da zu adressieren, in Form von Datenprodukten, ist natürlich eine extrem sinnvolle Strategie, da voranzukommen und das da erfolgreich zu entwickeln.

19:05:13: Marco Becker: Also wenn man sich die Frage stellt, was ist mein Use Case, welches Thema will ich lösen und welche Datenprodukte brauche ich auf dem Weg und wer kann sie mir liefern? Wenn man diese Frage stellt, dann lässt sich ein Problem, ein vermeintlich großes Problem, relativ schnell kleinkochen und in einzelne Lösungen überführen. Das muss man eben machen. Und ich glaube auch, dass man die, die Strategie, die man früher so ein bisschen gefahren hat, ich kopiere erst mal alles zusammen und dann überlegen wir mal, dass man das so ein Stück weit auch überdenken muss; dass es nicht unbedingt notwendigerweise zu was führt.

19:33:00: Marco Becker: Ganz oft gibt es im Unternehmen auch Daten, die sind dann auch nur „so da“ und die brauche ich vielleicht gar nicht, um ein Thema zu lösen, aber ich habe sie dann trotzdem in einem anderen Projekt, wo ich gesagt habe, ich mache jetzt hier so eine Datenintegration, habe ich alles erstmal schön integriert über Jahre und dann festgestellt, ach von dem, was ich da jetzt brauche. Das ist vielleicht 20 Prozent, was ich vorher integriert habe. Also wie gesagt, deswegen ist mein Plädoyer: Lass uns vom Use Case kommen, lass uns genau angucken, welches Problem wir lösen und dann lass‘ uns überlegen, was wir dafür brauchen.

20:00:10: Dr. Maximilian Reich: Sehr schön. Das unterstreicht die Erfolgsfaktoren bei der technischen Umsetzung von so einem Datenprojekt bzw. von so einem Datenprodukt. Aber so fundamental ist die Welt aktuell und das sind genau diese Grundlagen, die meines Erachtens jetzt auch die meisten Unternehmen merken, dass da Handlungsbedarf ist , weil die tollste Methode auch nichts wirkt, wenn man nicht diese Basisarbeit gemacht hat.

20:20:00: Marco Becker: Ohne den Use Case stehst Du nämlich nur da und sagst, ja wir machen irgendwas mit einem schlauen Computer. Aber was genau? Mache ich Machine Learning? Mache ich jetzt Large Language Model? Mache ich jetzt Algorithmen? Was mache ich denn jetzt? Und diese Frage kannst Du gar nicht beantworten, wenn Du gar keinen Use Case hast dafür.

20:36:00: Dr. Maximilian Reich: Absolut. Und das sind genau die Fragen, die uns aktuell begegnen. Ja, wir müssen jetzt auch einmal, was mit AI machen. Wir müssen jetzt auch was mit GenAI machen. Das sieht dann toll aus. Und dann kann man sagen, man hat was gemacht, aber ist man danach besser? Ist man danach effektiver? Ist man danach effizienter? Das ist die große Frage. Und die Use Cases da aktuell, die sind noch nicht so klar, glaube ich, allen vor Augen und die muss man eben rausstellen und die muss man dann eben auch bedienen können, so dass man dann vom Use Case entsprechend über die Datenprodukte diese dann aufsetzen an der Stelle.

21:05:04: Marco Becker: Es gibt viele, viele ganz hervorragende Lösungen, finde ich, mit Large Language Models zum Beispiel oder mit anderen größeren AI-Modellen. Die haben aber alle eines gemeinsam, die kamen alle vom Use Case. Die haben alle ein Problem gelöst, was man hat. Und ich glaube, das ist auch der Erfolg, AI sinnvoll einzusetzen. Und eben, was Du gerade sagtest, wenn wir jetzt sagen, lass mal was mit AI machen, dann ist das jetzt nicht, das nicht lösungsorientiert, das ist hier ist die Technologie, wo ist Dein Problem?

21:34:55: Marco Becker: AI ist einfach ein – AI und alles das, was dazugehört – und auch die Entwicklung der letzten Zeit – ist einfach ein tolles Werkzeug in meinem Werkzeugkoffer und ich kann damit ganz viele tolle Probleme lösen. Aber ich sollte damit Probleme lösen und ich sollte den Schraubenzieher nicht in die Hand nehmen, nur weil ich einen Schraubenzieher habe.

21:51:01: Dr. Maximilian Reich: Vielleicht doch noch am Ende der Blick in die Glaskugel. Was macht denn jetzt diese, nennen wir Generative AI also eben neuestes bzw. neu ist auch schon übertrieben, aber eben als glühendes Beispiel der rasanten AI-Entwicklung?

22:07:00: Dr. Maximilian Reich: Unterschied jetzt natürlich AI, Data Science, Machine Learning, alles, was man jetzt darunter subsumieren kann, das war natürlich etwas, was die Data Scientists und die Techies, so nenne ich sie jetzt mal, bedienen konnten und dann eben Anfragen bedienen können aus dem Business.

22:24:00: Dr. Maximilian Reich: GenAI ist jetzt quasi die AI für jedermann. Da kann jetzt jeder sehr einfach drauf. Sehr einfach verwenden und somit wird, das jetzt eben und das ist natürlich auch dann ein Grund für die Popularität von solchen Modellen, das sie jetzt eben von jedem da ganz einfach verwendbar sind, daher auch, wenn es wahrscheinlich eine ziemlich schwierige Frage ist am Ende: Was ist Dein Blick in der Zukunft? Was wartet denn da noch auf uns? Wie geht es denn weiter mit diesen Themen Richtung AI, GenAI? Wie sieht es denn da aus? Auch mit Blick vielleicht auf den Finanzbereich, vielleicht mit Blick auf die Architekturen, die in den Unternehmen vorhanden sind.

23:00:00: Marco Becker: Also ich glaube, dass die Modelle, werden ja immer größer. Wenn man jetzt guckt, was Microsoft plant, was Nvidia plant, dann werden die Modelle alle viel viel größer werden und werden noch komplexer und werden noch besser. Wir sehen ja jetzt schon beeindruckend, was zum Beispiel ChatGPT 4.0 liefern kann, finde ich. Aber das wird noch besser sein und da wird auch noch eine Menge mehr kommen.

23:17:10: Marco Becker: Ich glaube, wenn man diese Modelle richtig einsetzt, dann kann man die ganze Planung und auch die ganze Bedienung von Maschinen usw. deutlich vereinfachen. Und auch das, was Du gerade sagtest, was früher vielleicht Data Scientists vorbehalten war, kann auch der "normale User" ohne technische Skills entsprechend machen.

23:37:00: Marco Becker: Die Gefahr, die natürlich immer besteht, ist, dass das, was da produziert wird, vielleicht nicht hundert-prozentig stimmt. Nachvollziehbarkeit, Überprüfbarkeit ist immer ein bisschen schwierig.

23:46:00: Marco Becker: Wir haben das auch in der Softwareentwicklung gesehen. Wir haben über längere Zeit auch Tools getestet, sage ich es mal, die Code generiert haben. Das war auch manchmal ganz beeindruckend. Über lange Zeit merkt man aber, dass man sich etwas einschenkt, das sich „technische Schuld“ nennt. Das muss man halt immer – sozusagen – ansehen, was da passiert.

24:04:00: Marco Becker: Ich glaube, das über die Zeit sowas deutlich besser wird und so was weiter rausgeht und AI immer stärker nutzbar wird und "Probleme" oder technische Schulden, die man sich damit anhäuft, deutlich geringer werden. So, das sehe ich eigentlich auch in der Zukunft und vor allem, dass auch das Vertrauen in diese AIs auch seitens der Anwender deutlich zunimmt.

24:26:16: Dr. Maximilian Reich: Absolut, absolut. Das wird auf jeden Fall spannend, da weiter am Ball zu bleiben. Auch natürlich aus unserer beiden Sicht, aus Sicht von Virtivity, aus Sicht von CTcon, sind wir da mit dabei und begleiten die Finanzbereiche.

24:38:00: Dr. Maximilian Reich: Vielen Dank, Marco, für die Einblicke. Total spannend, die Hebel von Dir zu erfahren, die erfolgreiche Projekte ausmachen, da in Zukunft der Finanzbereich noch viel häufiger befähigt werden muss, aus den Daten eben das Beste rauszuholen.

24:51:00: Dr. Maximilian Reich: War sehr spannend. Ich danke Dir, Marco.

24:54:20: Marco Becker: Danke Max, ebenfalls, fand ich auch wie immer ein Vergnügen.

25:00:00: Dr. Christian Bungenstock: Im September startet unsere nächste Tour zu einem managementrelevanten Thema der Unternehmenssteuerung. Abonnieren Sie unseren Podcast „Zielführung starten“ kostenlos, um keine Folge zu verpassen. Wir freuen uns, Sie auf weitere Expertenrunden mitzunehmen. Bis dahin.

25:35:10: Sprecherin: Das war „Zielführung starten“, der Management-Podcast von CTcon.