00:00:00,940 --> 00:00:11,980 [Thomas]
Gut, wir haben drüber geredet, wie man letztlich, ähm, die Ressourcen ein bisschen ja hinbekommt. IT ist immer limitiert. Ich glaub, du hast da 'n paar sehr interessante Einblicke und Gedanken zu gehabt. 

00:00:13,540 --> 00:02:06,780 [Jan]
Ja, wir haben, äh, dadrüber gesprochen, wie man dieses ganze Thema besser integriert bekommt. Das Problem ist ja, die IT-Abteilung, wie sie in 'nem klassischen Unternehmen aufgesetzt ist, ist ja eigentlich aus 'nem Konzept erwachsen aus den 90er Jahren. Wir haben IT, die müssen uns die Rechner irgendwo hintragen und aufstellen und da Windows 95 aufsetzen und den Drucker anschließen. Äh, und aus diesen Anforderungen heraus ist so diese klassische IT-Abteilung erwachsen, die halt im Prinzip ein Stück Infrastruktur darstellt für die Leute, die im Unternehmen arbeiten, genauso wie da halt irgendwie Möbel stehen, äh, dass da die Heizung funktioniert et cetera. Das ist so die klassische Idee, wie die IT-Organisation entstanden ist. Und wir haben das in modernen Unternehmen natürlich ganz anders verdrahtet mit dem eigentlichen Geschäft. Vor allen Dingen in Dienstleistungsunternehmen ist das Nutzen von IT wirklich 'n ganz wesentlicher Teil der, des Kerns des Geschäfts. Das heißt, es ist mit der Leistungserbringung tiefst verwoben und ist zum Teil auch gar nicht ohne die moderne IT möglich. Und die organisationalen Gegebenheiten bilden das so in vielen Unternehmen halt nicht ab. Die IT ist separat vom Geschäft und es ist eigentlich 'n ganz wesentlicher Teil, der zum Operations gehört. Und diese Integration haben viele Unternehmen so nicht abgebildet und wir brauchen da neue Modelle, die das, äh, stärker zusammenführen und die auch im Prinzip dann heißen, dass die Leute, die organisatorisch Gestaltung betreiben, dass die nicht nur Ideen und Produkte und Leistungen ersinnen, sondern dass die aktiv, äh, in die Gestaltung der IT-Unterstützung sich einbringen und das vielleicht sogar selber machen können. 

00:02:07,980 --> 00:03:16,140 [Dominik]
Ich glaube, das ist irgendwie auch durch den Gedanken entstanden, etwas effizienter zu gestalten, ne. Also früher, ne, mit ich bestell Laptops bereit. Ich mein, das waren ja, war fertige Software. Das kann man als Art von Plattform sehen, ne. Die IT schafft 'ne Plattform, auf der das Geschäft stattfindet. Und ich glaub, mit dem Gedanken machen das Unternehmen oder heutzutage noch oder haben's auch in den letzten zehn Jahren noch immer gemacht. Wir wollen Effizienz steigern, ne. Wir haben viele Anforderungen, wir wollen die möglichst vereinheitlichen. Dann wollen wir Plattformen bauen, die möglichst alle Anforderungen berücksichtigen. Und wenn wir die Plattform dann mal gebaut haben, dann kann das Business darauf sich digitalisieren und die Prozesse abbilden. Ich glaube, das ist so'n, so'n deutscher Effizienzgedanke, so keine Ahnung. Wir müssen alles vereinheitlichen und irgendwie alles in unsere Strukturen einpressen und dann, wenn wir dann alles irgendwie sämtliche Komplexitäten und sämtliche Fallstricke aufgelöst haben, die es so zwischen Prozessen gibt, also dann, dann können wir, dann, dann haben wir's geschafft. Und ich glaube halt, die Veränderung, die wir einfach durchmachen, ähm, die sorgt halt mehr dafür, dass die Zyklen schneller werden müssen. Und wenn ich schnellere Veränderungszyklen brauch und schneller meine Prozesse anpassen können muss, dann ist halt 'ne zentrale Plattform eher hinderlich, ne, und erst mal gemeinsame Anforderungen. 

00:03:16,140 --> 00:04:01,320 [Thomas]
Du hattest mir mal 'n Buch empfohlen, Träge Transformation. Ich find, das, das zielt so'n bisschen auch darauf ab, dass ich ja eigentlich verschiedene Parteien an den Tisch holen muss, um gemeinsam auszuloten, wie lässt sich ein gewisser Prozess beispielsweise im besten Falle transformieren. Wenn es nur der Fachbereich macht, lass ich technische Gegebenheiten, strategische Richtungen gleich außen vor. Wenn ich's nur technisch treibe, dann fällt aus fachlicher Sicht vielleicht was runter. Und ich glaube halt, dieser, dieser Austausch auf Augenhöhe, dass sich die IT nicht als Umsetzer sieht, ist fundamental wichtig. Also auch, wie du schon gesagt hast, eigentlich auch diese Modelle mit BizDevOps, was es, glaub ich, schon lange als Buzzword durch die Gegend schwirrt, wird so schlecht gelebt, ja. 

00:04:01,320 --> 00:04:46,340 [Dominik]
Oder Team Topologies mit Stream Align Teams, die gesagt haben, eigentlich müssen wir 'n Team schaffen, das von der Anforderungsanalyse bis einschließlich dem Betrieb den kompletten Value Stream abdeckt und alleine ohne ständige Abstimmungen managen kann. Und unten drunter gibt es vielleicht Plattformteams, die Infrastruktur bereitstellen, Laptops, Server, Ticketsysteme, alles, was als Plattform vielleicht aus-- Process Engines unter Umständen, wenn sie als Plattform ausgereift sind und Sinn machen, Process Mining Tools als Plattform bereitstellen, als Tool bereitstellen, auf dem ich aufbauend in meinen autarken Teams Analysen machen kann. Macht ja, macht ja alles Sinn. Nur ich finde, also mir hat zumindest das, auch das Buch Träge Transformation und das Buch, äh, Team Topologies sehr geholfen, so'n bisschen das benennen zu können, was das Problem ist und vielleicht auch 'ne konkrete Lösung irgendwie auch aufzeigen zu können. 

00:04:46,380 --> 00:05:54,660 [Jan]
Ja, in vielen Unternehmen ist es ja so, wir haben diese verschiedenen Zuständigkeiten und solange diese Zuständigkeiten separat definiert sind in unterschiedlichen Silos, gibt's halt die eine Möglichkeit, ich bringe alle zusammen und die einigen sich auf irgendwie ihren kleinsten gemeinsamen Nenner oder das, was ihnen irgendwie am wenigsten gemeinsamen Schmerz verursacht. Das ist so der eine Weg. Der zweite Weg ist, äh, man bezieht irgendjemanden ein, der von der Entscheidungskompetenz über all diesen Leuten steht und das ist in vielen Unternehmen im Moment eigentlich nur die Geschäftsleitung. Das heißt, du musst bis ganz oben gehen, um dann an 'ner Stelle zu gelangen, wo einerseits die IT-Abteilung hören muss und der Fachbereich auch hören muss, was da an wesentlichen Entscheidungen getroffen wird. Und das ist halt total mühsam, dass du halt dafür komplett hoch musst, ne. Und die dritte Möglichkeit ist, äh, sich zu überlegen, wie man andere Organisationsgestaltungen findet, ne, und 'ne Geschäftsarchitektur, die es einem ermöglicht, in, im Kleineren umsetzbare Entscheidungen zu treffen, ohne dass ich die ganze Organisation immer einbeziehen muss. 

00:05:54,586 --> 00:06:50,032 [Lukas]
Das haben wir zum Beispiel auch gesehen, dieser, diesen pragmatischen Ansatz. Ähm, also es gibt Unternehmen zum Beispiel, die technische Kompetenzen auch auf die Fachseite bringen.Dann sagen wir mal, wir gehen mal mit 'nem Al..., Art Trial-and-Error-Ansatz ran, ne? Auch relativ chaotisch. Die, die IT wird da sozusagen, da gehen direkt alle rote La..., roten Lampen an, sagen, jetzt fangen die dann an, irgendwelche Schatten-IT hochzuziehen, ja. Aber es ist 'n Ansatz, mal zu sagen, hier lass uns doch mal zum Beispiel RPA ist da so'n Beispiel, ja, lass uns doch mal gewisse Prozesse mal quick and dirty automatisieren, mal gucken, wie das funktioniert, dann auch erste Messpunkte generieren, ne? Dann hat man schon mal erste Daten auch, ähm, und dann auf Basis dieser, sag ich mal, vorangestellten Automatisierung dann zu überlegen, okay, lohnt es sich, diesen Prozess jetzt wirklich sinnvoll, vernünftig, auch im Back-End, ne, mit 'nem sch..., mit 'nem schönen Workflow abzubilden? Oder reicht es, wenn wir diese Art von Automatisierung einfach bei der, bei der Fachseite belassen und die sind happy mit ihrem, sagen wir mal, oberflächlichen RPA-Automatisierung, ne? Ähm- 

00:06:50,052 --> 00:07:08,972 [Thomas]
Passiert das? Passiert das dann wirklich, dass sie wirklich hinterfragen, ob es sich dann überhaupt noch lohnt, das, äh, grundlegend neu zu strukturieren, sauber zu gestalten? Oder ist es dann eh so, dass sie so viel Bedarfe haben, dass sie eigentlich dann von einem zum nächsten springen, das sich wie 'n Lauffeuer ausbildet und man dann- 

00:07:09,332 --> 00:08:32,132 [Dominik]
Muss, muss es sauber sein, wenn's funktioniert? Ich hab eher so manchmal das Gefühl, was ich schon häufig gesehen hab, so Fachabteilungen bauen was, dann würden sie's am liebsten der IT übergeben, dass es, [lacht] dass es dann von denen betrieben wird. Ich, ich, ich würde irgendwie versuchen, mit dem Gedanken hinzugehen, dass es cross-funktionale Teams gibt, die sowohl die Fachexpertise des Prozesses, was muss sich wie verändern, als auch die technischen Fähigkeiten, die für die Art, wie man sich entschieden hat, diesen Prozess zu automatisieren. Es gibt ja, ja, ich kann den SAP customizen, ich kann 'n Standardsystem einführen, ich kann den selber programmieren, ich kann Low Code mit BPMN-Engines machen, Pega, whatever. Ich brauch aber diese Tech..., meiner Meinung nach die technischen Fähigkeiten, die Entscheidungshoheit und die Prozessexpertise in einem Team. Sonst bin ich ja wieder irgendwo ... Die Fachabteilung, da hab ich wieder beim Kunden erlebt: „Ja, hätten wir nur dieses eine Feature noch in dem RPA-Tool mit eingebaut, dann könnten wir ja noch den und den Prozess, äh, umsetzen.“ Also, häufig hat man dann wieder das Problem, ich brauch ja 'ne Plattform, das heißt 'ne RPA-Platt..., irgendwas, um anfangen zu können. Und dann ist die für manche Use Cases nicht ausgereift genug. Dann muss ich wieder in Abstimmungen gehen. Dann gibt's eine IT-Abteilung, die verantwortet das RPA-Tool, hat von zehn verschiedenen Leuten irgendwelche Anforderungen mit Konnektoren, die sie brauchen, weil RPA dann doch nicht für alles funktioniert und so. Das ist, ich weiß nicht, das ist immer so, das-- Ich glaub, Kopplung ist das größte Problem, das wir in Organisationen heutzutage haben. Nicht die Technik, sondern die Kopplung zu verschiedenen Teams, die- 

00:08:32,759 --> 00:11:10,913 [Jan]
Das ist, glaub ich, auch 'n Punkt, den, den du beschreibst, dass, äh, in vielen Situationen viel zu sehr in Projekten gedacht wird. Also, es ist irgendwie die Idee im Raum, wir müssen uns jetzt mal zusammenreißen und, äh, den großen Sprung machen und jetzt geben wir drei Monate mal Gas und dann ist das Projekt erledigt und dann funktioniert alles vermeintlich, hoffentlich. Und dann sind, äh, sind die Entwickler wieder weg, äh, oder die Berater oder die externen Kompetenzen. Äh, und dann ist genau die Frage, ja: Was passiert 'n dann, wenn ich jetzt entdecke, dass ich da irgendwie den Knopf links statt rechts bräuchte? Muss ich dann wieder 'n neues Projekt machen, ja? Und, ähm, ich, ich glaub, das funktioniert dann halt gut, äh, wenn man das in der Tat so versteht, dass man, ähm, 'ne Prozesskompetenz definiert. Der Prozess wird fortlaufend bearbeitet. Also, da, da gibt's kein Ende, ja? Also, wenn der Prozess so wichtig ist, muss ich mir fortlaufend Gedanken machen: Wo krieg ich den Prozess einerseits effizienter hin oder wo krieg ich auf der anderen Seite, ähm, hübsche Funktionalitäten rein, dass das meine Kunden begeistert oder dass das meine Mitarbeiter entlastet? Und das ist 'n kontinuierliches Arbeiten. Also, ich hab's einmal gesehen beim großen Automobilhersteller. Die hatten sich dann auch überlegt, wir wollen 'n gewissen wichtigen Bereich mit 'ner Workflow-Engine unterstützen. Und das war kein Projekt. Die haben einfach diesen, diesen Prozess aufgesetzt und haben den fortlaufend bespielt, verfeinert, ausgeweitet, ähm, äh, und verbessert. Ähm, wir hatten das dann, ähm, mit 'ner Masterstudie über 'n Zeitraum begleitet und beobachtend begleitet. Der Prozess, äh, da wurd jede Woche irgendwie was verändert und dazu gebaut an den Prozess. Äh, und, ähm, wir konnten dann diese Veränderungshistorie dann betrachten und verstehen, wie der Prozess fortlaufend besser und ausgefeilter wurde. Und das ist, äh, für die meisten Prozesse gibt's da halt nicht diesen einen Punkt, wo das dann halt irgendwie vorbei ist, ne? Also, es gibt immer irgendwelche neuen Ideen und es passieren Dinge im Umfeld des, der Organisation, es passieren Dinge im Umfeld, im Kundenkreis, die, ähm, das Unternehmen dazu zwingen, neu nachzudenken, ob das denn alles noch so sinnvoll ist, äh, wie das, äh, irgendwann mal aufgesetzt wurde. Äh, und, ähm, es ist 'ne gute Architektur, zu überlegen, wie kann ich 'ne fortlaufende Kompetenz bei mir etablieren, sodass ich nicht irgendwie bei jedem kleinsten Ding mir überlegen muss, wo krieg ich 'n jetzt das Budget her, dafür irgendwie 'n Projekt zu definieren?

00:11:10,992 --> 00:11:19,952 [Thomas]
Produkt aufsetzen eigentlich. Also, letztlich brauch ich ... Also, der Process Owner in dem Falle ist dann der Product Owner, der kontinuierlich weiterentwickelt. 

00:11:19,952 --> 00:11:55,612 [Dominik]
Dass ich frage, ne, wie, wie entscheid ich, wo es sich lohnt, eigene Produkte zu bauen? Wo entscheid ich, wo es sich lohnt, 'n Low Code, also auf Low-Code-Basis und, und bestehenden Plattformen was zu bauen? Wo nehm ich lieber Standardsysteme? Was davon lager ich aus? Also, ma..., es ist-- Manche Organisationen gehen da auch zu idealistisch, so Make-or-Buy-Entscheidung. So, kauf ich das oder mach ich ... Voll oft so das Geld. Was ist, was ist im ersten Schritt im Sinne eines Projektes günstiger? Nicht, was ist strategisch aus Produktsicht sinnvoll fürs Unternehmen? Wo differenziere ich mich? Wo möchte ich das vielleicht selber in der Hand haben? Wo ist es eigentlich Commodity? Wo ist es einfach fertig und, und für mich irrelevant? Wo kann ich's einfach dazu kaufen? Ich find, das ist auch so'n bisschen so'n- 

00:11:55,692 --> 00:12:01,792 [Thomas]
Muss ich den Urlaubsantrag neu erfinden, ne? Also, warum, warum muss ich ein, einen Urlaubsantrag mit Tieren- 

00:12:01,832 --> 00:12:05,572 [Dominik]
In der Behörde ist immer die Antwort: Ja, die rechtlichen Vorschriften sind so komisch. [lacht] 

00:12:05,612 --> 00:12:06,432 [Thomas]
Das muss man machen. 

00:12:06,512 --> 00:12:08,752 [Dominik]
Das ist keine fertige ... [lacht]

00:12:09,888 --> 00:13:21,688 [Jan]
Mhm. Ja, es ist aber andererseits natürlich auch 'ne Frage, wenn man diesen Gedanken jetzt weiterführt, führt er einen natürlich auch dahin, klar, Prozessarbeit auch als Innovationsarbeit zu verstehen und anzunehmen. Und ich glaub, wir haben in der Tat, äh, in verschiedensten Bereichen in Unternehmen eine Investitionsscheue, Dinge auszuprobieren, Geld in die Hand zu nehmen, um mal neue Ideen in die, äh, Produkte, in die Leistungen zu bringen. Äh, und das ist 'n Problem. Das ist in anderen Ländern einfacher und dynamischer, äh, und, ähm, das sieht man auf verschiedensten Statistiken, dass wir allgemein in der Breite, äh, zu wenig Investitionsfreude haben in den Unternehmen. Das Geld muss wieder in Verbesserungen reinfließen, in neue Ideen, äh, und, ähm, der Markt steht nicht still. Äh, viele Unternehmen spüren das im Moment bedauerlich stark, dass sich Druck aufbaut in verschiedensten Branchen, die wir als, ähm, etabliert bei uns wahrgenommen haben. Und, ähm, wir müssen da den Wettbewerb annehmen. 

00:13:23,488 --> 00:13:34,168 [Thomas]
Hat auch viel mit Fehlermanagement zu tun. Wenn ich mir anschaue, was bei den ein oder anderen Kunden bei mir alles getan wird, um Fehler zu vermeiden, dass man nicht was ausprobiert, was danach floppt. Das ist immens- 

00:13:34,188 --> 00:13:34,788 [Dominik]
Tail and Error. 

00:13:35,448 --> 00:13:37,308 [Thomas]
Ja, aber das, der Error, den wird- 

00:13:37,328 --> 00:13:38,368 [Dominik]
Trial and Success. 

00:13:38,368 --> 00:13:40,568 [Thomas]
Es gibt nur Trial and Success, genau. Mehr- 

00:13:40,728 --> 00:14:25,328 [Dominik]
Mal war's mehr erfolgreich, mal ein bisschen weniger, aber es war immer erfolgreich. Nein, also, aber auch-- Ich finde, da gibt's auch zwei Perspektiven. So einmal, was sind, was ist strategisch wichtig, vielleicht durch Prozessmanagement anzugehen, umzusetzen? Also was ist irgendwie vielleicht eher größere, nicht revolutionäre, aber größere Änderungen und einmal, was sind auch kleine inkrementelle Schritte? Und ich glaube, häufig fehlt die Rechtfertigung und da ist gerade das Tool mit, mit Nurea, mit Process Mining, kann ich vielleicht auch Prozessmanagern oder jetzt in dem Fall vielleicht Spiel mal ein Teams auch ein Mittel an die Hand geben, das zu rechtfertigen, dass es budgetmäßig sinnvoll ist, diese Prozessverbesserung anzugehen. Weil häufig ist es ja gar nicht messbar, was aus meiner Sicht nicht immer messbar sein muss, aber man muss es ja irgendwie rechtfertigen. Also wa-warum gebe ich jetzt Geld für 'ne Prozessverbesserung aus? 

00:14:25,908 --> 00:14:40,768 [Lukas]
Es ist für, für Priorisierung halt wichtig, ja. Also mal zu verstehen, wo, wo hängt der Prozess jetzt wirklich am, am meisten? Wo bleibt am meisten Zeit liegen? Wo bleibt am meisten Geld liegen? Ähm, dann kann man davon ausgehen, dann hoffentlich bessere Entscheidungen treffen, auch wo ich als Nächstes ansetze. 

00:14:41,188 --> 00:15:08,868 [Thomas]
Dafür hast du ja auch was Interessantes mit dem Impact Board gebaut, wo sich dann natürlich da auch ein paar ... Ja, bin ganz gerne-- Aber das fand ich auch sehr, sehr praktisch, weil du da eben zum einen Quick Wins ja beziffern kannst, zum anderen aber auch sehen kannst, wo lohnt es sich gerade rein zu investieren und was hol ich daraus, dass man wirklich quantifizierbar sehen kann auf einem wiegearteten Board auch immer, ähm, wo man jetzt als Nächstes dran anfassen sollte und wie die Reihenfolge dessen aussieht. Das ist, find ich, unglaublich viel wert. 

00:15:09,608 --> 00:16:20,528 [Lukas]
Ja, absolut. Also aus unserer Sicht jetzt, also ich hab quasi dieses Impact Board, was wir bald mal auch vorstellen werden, ähm, also die Erfahrung der, der letzten Jahre der Process-Mining-Projekte sozusagen einfließen lassen. Und in der Tat, das ist halt das Wichtige, dass man wirklich zeigt, was steckt eigentlich auch für ein konkreter Euro-Wert hinter 'ner Optimierung? Ja, was, was ist der ROI, wenn ich, wenn ich das angehe, auch dann quasi gegenüberzustellen, was bringt es mir für Einsparpotenzial, aber auch was kostet es, ja? Und dann kann ich mir daraus eben ganz gut 'n ROI raus-rausrechnen, weil das, was viele auch ignorieren oder, oder nicht ganz unbedingt immer aufm Schirm haben, ist, dass wenn ich, wenn ich einen Prozess optimiere, dann ist der ja nicht nur einmal optimiert, sondern die Kosten, die dann sozusagen auch in den nachfolgenden Jahren angefallen wären, werden dadurch reduziert. Ja, das heißt, man kann echt auch 'ne viel, 'ne viel, äh, langfristigere Rechnung machen, ähm, und das kann sich dann schon sehr, sehr stark auch kumulieren, ne, die Einsparpotenziale. Ähm, wir machen das oder ich versuch das immer ganz gern darzustellen wie diesen Cost of Inaction, ne. Was kostet es uns eigentlich, wenn wir jetzt inaktiv sind und die Prozesse einfach mal so weiterlaufen lassen, wie sie schon die letzten zehn Jahre gelaufen sind? Ähm, da steckt einfach viel Potenzial. Genau das haben wir mit diesem Impact Board, ähm, sichtbar gemacht. 

00:16:20,528 --> 00:16:24,548 [Thomas]
Auf wie viel Jahre rechnest du normalerweise so'n Business Case für eine Optimierung? 

00:16:25,788 --> 00:16:31,948 [Lukas]
Das, das ist schwierig, aber ich, jetzt mal aus, aus dem Hüfte geschossen gesagt, äh, fünf Jahre. Fünf Jahre, das reicht- 

00:16:31,988 --> 00:16:36,628 [Thomas]
Ist mir auch bisher immer so mitgekommen, aber dachte mir, vielleicht hast du da 'ne super Größe anhand- 

00:16:38,288 --> 00:16:52,808 [Dominik]
Kommt auf vieles an, ja. Wenn ich jetzt so Intralogistik, äh, Einführung von Intralogistiksystemen und Prozessänderungen und so große Verteilzentren und so, da ist Total Cost of Ownership-Berechnung eher zehn Jahre, weil ich ändere ja nicht so häufig. Ich kann ja gar nicht so häufig was daran ändern, ne? 

00:16:52,868 --> 00:16:53,728 [Lukas]
Ja, absolut. 

00:16:54,268 --> 00:16:54,488 [Thomas]
Und ...