Dein Prozess-Automatisierungs-Dream-Team: Welche Rollen sind wirklich wichtig?

Shownotes

In der fünfzehnten Folge von "Die Prozessphilosophen" dreht sich alles um die Frage: Welche Rollen braucht ein erfolgreiches Prozessautomatisierungsprojekt wirklich? Ausgehend von einem spannenden LinkedIn-Post beleuchten wir, welche Teams und Rollen bei der Automatisierung von Prozessen unverzichtbar sind. Wir sprechen über klassische Rollen wie den Business Analyst und Process Owner, aber auch über unterschätzte Experten wie den UX/UI Engineer. Außerdem werfen wir einen kritischen Blick auf die Kosten solcher Projekte und wie sich die Investition langfristig auszahlt. Natürlich gibt es am Ende auch wieder unsere beliebte Kategorie „Overrated/Underrated“.

Highlights:

  • Wie viele Rollen braucht man wirklich für ein erfolgreiches Prozessautomatisierungsprojekt?
  • Process Owner, Business Analyst und UX/UI Engineer – Warum diese Rollen oft unterschätzt werden.
  • Kann ein kleines Team alle Aufgaben in der Automatisierung abdecken? Wir diskutieren, welche Rollen zusammengelegt werden können und wo es kritisch wird.
  • Overrated/Underrated: Warum No-Code/Low-Code nicht immer die günstigere Lösung ist.

WICHTIG: Schreibt uns eure verrücktesten BPM-Geschichten: Wir anonymisieren alles und garantieren volle Diskretion. Lasst uns zusammen lachen und lernen! Eure Vorschläge für Gäste: Kennt ihr eine Person, die eine echte BPM-Expertin oder ein echter BPM-Experte ist? Dann lasst es uns wissen, wir freuen uns über Empfehlungen!

Abschließende Worte: Danke, dass ihr wieder eingeschaltet habt! Wir hoffen, dass euch diese Folge genauso viel Spaß gemacht hat wie uns. Freut euch auf die nächste Episode, wo wir euch mehr über uns und unsere Erfahrungen erzählen werden. Bleibt neugierig und bis bald!

Kontakt: Habt ihr Fragen oder möchtet mehr über die besprochenen Themen erfahren? Kontaktiert uns gerne über unsere LinkedIn-Profile.

Matúš: https://www.linkedin.com/in/matusmala/ Daniel: http://https://www.linkedin.com/in/danielmatka/ Christoph: https://www.linkedin.com/in/christoph-piller-0a1687145/ Process Academy: Website

Transkript anzeigen

Einen wunderschönen guten Tag, liebe Zuhörer unseres Podcasts. Wir sind die drei Prozessphilosophen.

Das ist diese Wertschätzung für Software. Da bin ich halt extrem kritisch, dass die meisten Menschen einfach keine Wertschätzung für Software haben. Und wenn das das ist, was deinen Firma Geld bringt, wirst du so ein Team brauchen, wenn du etwas bewirken wirst.

Was lustig ist. Wir machen mal eine kurze Brücke. Zweitausendein. Ich merke es auch an meinem LinkedIn Feed, dass alle wieder aus dem Urlaub zurück sind. Auf einmal ist wieder was los. Also das war mal zwischenzeitlich ein bisschen ruhig. Da haben nur die LinkedIn Heinis gepostet.

Heute kein Bashing, bitte.

Wir sind wieder da. Die drei Prozessphilosophen. Zweitausendein. Ich muss sagen, ich habe fast schon das Intro verlernt. Matusch, Christoph, wie geht's euch beiden?

Mir geht's gut. Er holt nach Urlaub.

Alles gut.

Kann mich nicht beschweren. Hat mir tatsächlich gefällt, dass wir eine Folge ausgelassen haben. Ich habe dann mit anderen Leuten gesprochen. War ungewöhnlich.

Mir geht, mir geht's auch gut. Vielen dank der Nachfrage, Daniel. Mir geht's noch immer gut. Es freut mich, dass ich Matuschs Gesicht mal wieder sehe, nachdem er jetzt gefühlt 27 Wochen im Urlaub war. Wie geht's dir, Daniel?

Ich freue mich wirklich auf dem Urlaub oder ich andersrum, ich bin urlaubsreif. Wobei ich die nächsten zwei Wochen es nicht irgendwie ruhiger wird. Ich bin super viel gerade von von Messe zu Messe oder von Kongress zu Kongress unterwegs. Wir nehmen heute am neunter September auf. Morgen geht es nach Hannover zum German Low Code Day. Letzte Woche war ich in Dresden zum Transconnect Business Day und ja, Integration Day oder irgendwie so hieß das. Und die zweitausendein übernächste Woche, Nee, nächste Woche ist in Stuttgart All About Process Management Konferenz. Also jede Woche aktuell viel Reisen plus allgemeiner. Ja, viel Workload. Sonst geht es mir super gut. Ich war am Wochenende bin ich einmal mit dem Rennrad um den Bodensee geschossen. Also gestern quasi Sonntag, deswegen ein bisschen Muskelkater, aber sonst geht es mir sehr, sehr gut.

Hast du zwei Kniebeuge gemacht oder wie?

Genau, so ungefähr.

Jetzt hier. Christoph, komm, erzähl mal. Hast du auch so viele Konferenzen oder kannst du auch arbeiten?

Richtiger Zufall, Daniel. Ich bin nächste Woche auch in Stuttgart auf dieser All About Process Management Konferenz. Vielleicht sieht man sich ja wirklich.

Haben wir nicht schon dreimal gesagt, glaube ich, in den letzten fünf Folgen. Aber hey.

Ja, mir geht es uns gut. Bei mir stehen tatsächlich gerade andere Dinge an, weil morgen ist der erste Schultag meiner ältesten Tochter.

Wow.

Das heißt für mich als Elternteil beginnt ein neues Kapitel. Ich bin ein bisschen nervös.

Wirst du weinen?

Nein, weinen werde ich nicht. Ich werde wahrscheinlich wieder sehr viel Hass gegenüber Schule, Lehrer und anderen Elternteilen verteilen.

Was? Warum das?

Weil, weil ich oft einiges nicht verstehe.

Bist du nicht gerne in die Schule gegangen? Bist du nicht gerne in die Schule gegangen?

Es gibt, man muss dazu sagen, also ja, also in die, in die. Also in Deutschland sagt mir Grundschule, bei uns in Österreich Volksschule, bin ich tatsächlich noch sehr, sehr gern gegangen. Das war richtig lustig. Und jetzt im Nachhinein bin ich natürlich auch gern gegangen, weil es viel weniger Sorgen sind in Wirklichkeit als dann im Erwachsenenleben. Aber man muss dazu sagen, bei uns im kleinen Dorf, es gibt halt tatsächlich ein paar komische Eltern, so helikoptermässig und komische Fragen und so. Brauche ich alles nicht.

Elternabende werden deine Lieblingsveranstaltung werden.

Ja, hoffentlich nicht.

Naja, das wird schon alles. Das ist ja quasi, Matusch hat ja jetzt schon das Glück, das erste Kind wieder raus zu haben. Das ist ja schon wirklich anders. Crazy.

Ja, der ist ja nicht mehr ein Kind mit Achtzehnte. Ja, ja, aber ich habe tatsächlich morgen auch einen ersten Tag. Ersten Tag am Gymnasium von den zweiten.

Cool.

Wirst du warnen, Matusch?

Klar. Hätte er das endlich mal geschafft. Hat.

Kein no Pressure von der Elternseite.

Ich bin nicht Deutsche. Bei uns ist klar, du gehst Gymnasium und Uni, das ist ohne jegliche Hinterfragen.

Na gut, wenn sie die Intelligenz von Papa geerbt haben, dann geht das ja sowieso easy.

Oh, das war der erste Lob. Habt ihr das gehört? So, pass mal auf, Daniel, ich merke, dass du keine Thema mehr findest, wenn du mich lobst. Das hast du auch Themen verloren. Aber wie gesagt, ich freue mich, dass wir wieder da sind. Ich glaube, wir sollen ein bisschen darüber sprechen, dass wir unregelmäßig waren in den letzten drei Wochen. Wir haben einige technische Issues, oder Daniel, vielleicht kannst du darüber was sagen, damit die Zuhörer, die mir anschreiben und ich habe tatsächlich einige Nachrichten bekommen. Wann kommt die Folge und so weiter. Es waren kurzzeitige Issues, die wir behoben haben.

Ja, so ein Struggle. Also mit dieser zehnten Folge, der Video Podcast Folge, haben wir zweitausendein den Hoster gewechselt, einmal quasi zu einem zweiten, die so einen Videopodcast angeboten haben. Da gab es aber super viele technische Herausforderungen, deswegen habe ich das ganze wieder zurückgewechselt auf unseren ursprünglichen Podcast Host. Die Migration hat lange gedauert. Das Problem ist, ich kriege jetzt die Spotify Connection gerade nicht wieder. Hin. Ich warte noch auf den Support, weil auf allen anderen Plattformen ist ja die letzte Folge verfügbar, nur nicht auf Spotify bin ich dran. Und genau, wir hatten jetzt eine Woche haben wir ausgesetzt, so mini Sommerpause und jetzt geht es wieder los. Ich werde heute Abend wieder fleißig Podcasts schneiden und dann geht hoffentlich alles wie geplant. Donnerstag die Folge wieder online.

Auf alle.

Plattformen außer Spotify, ne, mit Spotify. Also quasi auf allen Plattformen und Spotify. Ja, das ist. Soll jetzt wieder mal ordentlich werden. Das krasse ist, man glaubt immer gar nicht, der Aufwand läppert sich halt über die Zeit mit schneiden. Das ist so ungefähr, das geht noch, das sind irgendwie anderthalb Stunden. Aber halt, wenn das mit den Hostern nicht automatisch verteilt wird und man jeden Link und überall alles manuell hochlädt, das ist dann, dann wird es echt müdelig. Aber hey, wird schon. Ist ja cool, dass die Leute nachfragen, dann sind wir nicht ganz so. Egal. Ich muss sagen, bei mir ist keiner reingekommen, um jetzt einfach ehrlich zu sein. Mich hat keiner gefragt. Deswegen. Christoph, hat dich jemand gefragt, ob die nächste Folge kommt?

Ja, zwei, drei Leute haben mich gefragt.

Ja, cool, cool, cool.

Bei mir vier, fünf.

Naja, schaut mal, so, da haben wir schon mal.

Ich habe gesagt, bei Beschweren bitte bei.

Daniel anrufen, damit kann ich umgehen. Von daher, also das wird wieder kommen. Und man hat aber insgesamt ziemlich krass gemerkt, dass die Sommerpause kickt und dass quasi ganz, ganz viele Leute nicht Podcast hören bzw. Auch nicht online sind. Was mich eigentlich wundert, weil andersrum gedacht, Die Sommerpause wäre ja zweitausendein normalerweise, weil alle anderen großen Podcasts gerade Pause machen, wäre das ja super, dass wir mehr in den Statistiken sind, aber hat nicht so geklappt. Von daher alles gut. Ich freue mich. Jetzt geht es wieder los. Und was lustig ist, wir machen mal eine kurze Brücke. Ich merke es auch an meinen LinkedIn Feed, dass alle wieder aus dem Urlaub zurück sind. Auf einmal ist wieder was los. Also das war mal zwischenzeitlich ein bisschen ruhig. Da haben nur die LinkedIn Heinis gepostet.

Heute kein Bashing, bitte warte. Heute kein Bashing.

Bashing. Wer sich als LinkedIn Heini angesprochen fühlte, muss ja vielleicht selber sich Gedanken machen. Also meine LinkedIn Heinis haben gepostet, aber die normalen Menschen haben quasi oder die weniger aktiven Menschen waren nicht online. Das hat man krass gemerkt. Und heute ist Montag, ganz Bayern und Baden Württemberg ist aus dem Urlaub zurück und jetzt geht es wieder rund.

Okay. Okay. So, kommen wir zu unser Thema Kommissar Jingle.

Kommen wir zur ersten Kategorie. Unser LinkedIn Sporter. Und zwar ich habe eine kurze Frage an euch bzw. Eine vielleicht auch eine Frage an unsere Zuhörenden. Und das ist die Frage nach spannenden Communities oder Gruppen, weil ich kenne zwei, drei Gruppen, die ja existieren, die auch relativ groß sind. Das ist der BPM Club und ich will jetzt nichts Falsches sagen. Gibt 1 s bros. Ist Automation Werbung in der eigenen Sache? Nee. Und quasi die. Ja, der BPM Club ist mit schon der größte, wo wir vielleicht einfach mal sammeln. World BPM Magazin. Das ist das, was ich gesucht habe mit knapp über 2000 Mitgliedern. Vielleicht suchen wir oder sammeln wir mal coole Gruppen auf LinkedIn, wo es sich lohnt, wirklich ein Teil zu sein oder einen Beitrag irgendwie da aktiv zu followen. Habt ihr irgendwas?

Der Prozess Visat Gruppe habe ich gehört, ist ziemlich cool.

Ich habe tatsächlich eine Frage dazu. Also diese Gruppen in in LinkedIn, die sind für mich immer nur so ein okay, es gibt halt eine Gruppe, aber so, dass ich aktiv sagen würde vor voll cool in der Gruppe und ich durchsuche richtig bewusst und absichtlich Gruppen mache ich überhaupt nicht.

Das ist ja die Frage, weil prinzipiell ist das ein super Kanal, relativ schnell an ganz viele Leute mit dem gleichen Interessensspektrum zu kommen. Also wenn ich hier gerade ich habe meinen LinkedIn nochmal aufgemacht. Den Namen der Gruppe, den ich gerade gesucht habe, war auch noch the future of automation is autonomous. Zweitausendein bpm jen ai ML idp rpa. Also so eine echt große gruppe mitglieder schon. Das ist schon mal erstmal eine große audienz irgendwie unter dem gleichen thema gesammelt.

Ist die ist die prozess automation bodies eigentlich schon eine gruppe oder ist es eine Gruppe? Vielleicht sollen wir einfach die Prozessphilosophengruppe. Warum haben wir eigentlich noch keine Prozess Philosophen?

Ich weiß nicht. Gruppen. Wir haben quasi. Vielleicht kommt da ja Automation Buddies and Friends Knowledge Sharing sind quasi 51 Mitglieder.

Siehst du, das ist die Gruppe, da sind nur qualitativ hochwertige Mitglieder.

So eine Lüge. Wir haben dafür Aktivität drin.

Ja, deswegen, weil da nur effektive Leute sind, die zusammen reden. Okay, sich am Meetup treffen, ne, ich bin. Ich bin leider bei Christoph Daniel. Ich bin also auch wenn was heißt leider?

Das klingt so. Ich bin leider bei Griff.

Ich weiß nicht, ich weiß nicht, ich weiß nicht. Also alle Einladungen, ne, das darf ich dir sagen. Also die meisten Einladungen, irgendeine Gruppe oder sowas zu folgen, da klicke ich immer auf X. Das also ohne jemandem nahe zu treten, aber ich gehe immer davon aus, dass da nur Werbung kommt. Das ist halt das Problem für mich und ich folge dazu.

Würdest du jetzt sagen oder würdet ihr beide sagen, Gruppen sind out?

Ich weiß es nicht. Ich bin out, weil ich die nicht folge. Vielleicht sollst du fragen, jemand, der alle folgt. Also ich würde nicht. Also in diesen Hinsicht würde ich sagen, ich bin falscher Ansprechpartner. Also.

Ich würde auch nicht sagen Gruppen sind Art. Das Problem dabei ist, für mich waren Gruppen noch nie in. Ich habe noch nie wirklich darüber nachgedacht und ich habe nämlich jetzt auch gerade geschaut. Ich bin in Wirklichkeit nur bei vier Gruppen dabei. Okay, also tatsächlich wäre das ein guter Aufruf an die Community, dass die mal Feedback geben sollen, wer da tatsächlich so dieses Thema Gruppen bei LinkedIn aktiv nutzt und verfolgt und sich anschaut.

Okay, let's go. Let's go. Also Aufruf geht ihr in Gruppen oder nutzt ihr LinkedIn Gruppen? Und wenn ja, welche? Ÿousand das ist, würde ich mal als so eine Frage an den Podcast dranhängen. Schreibt sie uns bzw. Wir machen einen einen Post dazu und dann schreibt da bitte mal rein, welche Gruppen wirklich spannend sind. Das machen wir zur Veröffentlichung. Zur Veröffentlichung dieses Podcast machen wir einen Beitrag, wo quasi eine Abfrage mit drin hängt, welche Gruppen es gibt. Dann kann die Gruppen auch jeder einsehen und wir sammeln die. Und so wie wir schon zwei, drei andere Kategorien gesammelt haben, die Stück für Stück für eine Website entwickelt werden, können wir die dann auch da verlinken und cool.

Und idealerweise postest du das über die Prozess Automation Buddies, über die Gruppe, dann.

Sieht es wieder keiner, weil da wir.

Können die Ari posten.

Doch, doch, hier vermischt das nicht. Das ist quasi, du siehst den Beitrag nur, wenn du in der Gruppe dann drin bist. Das kannst du nicht so wie posten. Die Beiträge bleiben dann in der Gruppe. Das ist jetzt nicht wie so eine Firmenseite.

Wir alle drei posten andere generierte Posts. Alles gut. Also der da entweder der Daniel postet, Daniel postet, Daniel postet einen Aufruf zu welche VPN Gruppen zweitausendein finden die Leute spannend? Machen wir so passt das. Cool. So können wir zum Thema kommen.

Ab ins Thema.

Ich habe es mir gedacht, der Christoph kommt heute nicht mit Thema. Der Daniel will über LinkedIn wieder reden. Sagt ja nichts dazu, aber ich habe tatsächlich ein Thema. Also ich habe jetzt einen Post gesehen von einem BPM Consultant zum Thema.

A.

Properly stuffed process automation team is essential for the success of your program. So, Christoph und Daniel. Daniel, du hast ja Projektleiter von so einem Team. Was glaubt ihr, wie viele Leute und welche Rollen würdet ihr staffeln in ein guten Prozess Automatisierungsprojekt? Also keinen, wo man sagt, ich brauche jetzt ein E Mail lesen oder ein E Mail versenden. Das heißt sowas wie what do you need in your automation dream team? Was würdet ihr sagen? Ich bin echt gespannt, weil wir mit.

Den Rollen starten, welche Rollen wir brauchen. Ich glaube, das lässt sich ganz gut eingrenzen, dass wir erstmal die Rollen aufzählen und dann los, eine nach dem anderen, back to back. Christoph, fang an.

Business Analyst, wir machen gleich mal auch.

Noch ein bisschen Erklärung, was diese Rolle bedeutet, weil ich würde lachen, wenn jemand das wieder vermischt mit requirements engineer.

Okay, okay. Ja, okay. Also Der Business Analyst ist idealerweise so die Schnittstelle zwischen Fachteam und Entwicklung. Das heißt, es wird auch tatsächlich in Requirements Engineering gehen, aber ich sehe den Business Analyst tatsächlich auch so ein bisschen als Prozessmanager, der die der Potenziale entdeckt, b Potenziale bewertet, entdeckt, auswertet, das mit dem Fachteam auch abklärt, dass der Faktor Mensch nicht vergessen wird und das ganze dann so quasi an die Entwicklung weitergibt.

Projektleiterrolle, der quasi das ganze.

Ja, man kann also tatsächlich, also es gibt sehr, sehr wenig Unterschied zwischen Business Analyst oder Projektleiter von Automatisierungsprojekten oder Projektleiter von Prozessverbesserungsprojekten. Ist alles sehr, sehr ähnlich, nur anderes Wording meiner Meinung nach. Genau, aber in die Richtung.

Warte mal, ich habe gerade, damit ich das richtig verstanden habe, du würdest sagen Projektleiter und Business Analyst ist das gleiche.

Also Projektleiter oder Projektmanager für Automatisierungsprojekte nicht.

Das gleiche wie Business Analyst bei dir? Ah, doch, doch.

Also es ist vielleicht nicht 100, %, aber es ist super, super ähnlich.

Nee, das würde ich schon anfangen zu trennen, weil einfach es ist also ich glaube so ein bisschen, es gibt es gibt so ein Product Owner, der quasi das ganze Projekt wirklich pusht und nach vorne und der quasi auch stakeholder Management in die eigene Organisation macht, der die ganzen Finanzen zusammenhält, also wirklich so Projektmanager rollen und der einfach also spätestens wenn ein Projekt größer als zwei oder drei Applikationen oder Grossprozesse hat, einfach der hat so viel zu tun, kann ich einfach aus meiner eigenen Erfahrung sagen, dass du das dann quasi nicht mehr so wirklich vereinbaren kannst, alles zusammenzual.

Du sollst deine nicht weg optimieren. Christoph das war genau seine Rolle. Also Projektleiter, der chief Product Owner, der der Wunsch ist, das ist das Thema oben und am Ende leider auch gerade stehen muss, wenn die Meilesteine kommen oder wenn etwas halt geklärt werden muss, wenn die Termine nicht eingehalten werden und so weiter. Diese, die auch in Eskalationsmeeting ist. Du musst eine auswählen, der das macht. Und da ihr halt aktuell nur zwei Personen habt, kann man das immer noch vereinheitlichen. Aber ich glaube, ihr kommen noch zwei weitere Rollen, dann braucht ihr die Chance.

Ja, genau. Aber genau das ist das Thema, Daniel. Der Product Owner ist der Projektleiter, um dieses Produkt an sich, dieses Produkt des Automatisierung, also nicht z.b. das Produkt UiPath oder das Produkt whatsoever einzuführen und einem laufen zu halten, die strategischen Ziele zu erfüllen etc. Und dann gibt's aber ein fucking konkretes Automatisierungsprojekt, das vielleicht gar nicht so groß ist. Da möchte ich nicht, dass der Product ohne sich drum kümmert, sondern z.B. der Business Analyst die ganze Analyse dafür startet, die Requirements.

Würdest du quasi sagen, in einem größeren Team hast du mehr für jeden Prozess.

Okay, passt ja genau. Ja, ganz genau. Und das ist. Und das meinte ich mit Projektmanager. Also Projektmanager sind wir in Wirklichkeit fast alle. Es kommt halt dann immer nur darauf an, wofür. Genau.

Ich bin voll nicht bei dir.

Also du hast die Rolle Projektmanager, der das quasi.

Also ich würde die Rollen trennen. Also ich würde explizit die Rollen trennen, weil für mich ein Projektleiter oder chief product Owner zuständig ist dafür, dass das Projekt funktioniert. Sein einziges Ziel ist Erfolg vom Projekt, Geld, Kontrolle und so weiter. Und Business Analyse ist für mich zuständig am Ende für Stories, für herausfinden, was man eigentlich machen soll und so weiter. Der unterstützt vielleicht Product Owner und du kannst manchmal bei kleinen Projekten diese zwei Rollen vereinheitlichen in eine Person. Die zwei Rollen würde ich aber nicht per se vereinheitlichen und ich habe das sehr selten gesehen, dass das zusammen war.

Jupp, würde ich auch sagen. Einfach schon von der Workload und wenn ich das selber so erlebt habe, bis zu einer kleinen Teamgrösse, easy machbar. Spätestens wenn es groß wird, hat man einfach viel zu viel zu tun. Nächste Rolle, Christoph ist wieder dran.

Automatisierungsingenieur, der Automatisierungsentwickler. Das heißt, ich brauche irgendjemanden, der das Ganze dann technisch umsetzt.

Okay. Willst du, wie ist es bei dir? Aus deiner Erfahrung heraus? Würdest du es quasi Modellierer und beispielsweise einen Entwickler, der auch Schnittstellen und so entwickelt. Ist das bei dir eins oder sind das auch, also weil wir über viel über Low Code, Low Code, no Code reden und dann, wenn es um Datenschnittstellen geht, das ist ja, wenn wir.

Also ja, also ich würde es, ich würde es. Ich persönlich würde es trennen. Ich würde halt den no code, Low Code Entwickler sehen und der, der die Person, die Schnittstellen entwickelt etc. Das würde ich tatsächlich eher in der IT sehen, die so ganz, die so quasi sicherstellt, dass die ganze Infrastruktur dementsprechend zur Verfügung gestellt wird und läuft und passt.

Meine nächste Rolle, der oftmals vergessene Tester. Musste ich selber auch lernen, wie wichtig das ist und dass man ihn ungern weglassen sollte, weil das böse Erwachen kommt dann meist ein bisschen später, was dann einfach doppelt und dreifach so aufwendig und teuer ist, selbst wenn es low code, no Code ist.

Ja, genau. Also per se oder in der Theorie müssen natürlich die Ingenieure selber testen, das sollen die auch machen, aber gerade in Prozessprojekten, die meistens querschnittlich über unterschiedliche Systeme gehen, brauchen wir auch diese fachlichen Tester, die in so ein Integration System das dann alles zusammentesten, die ganze Zusammenarbeit und auch die Integration Test am Ende schreiben. Finde ich auch sehr wichtig. Man vergisst die manchmal. Ich glaube tatsächlich, dass es eine andere Rolle ist. Der Scrum schreibt, dass das jeder machen soll, aber gerade so das, was ich modelliere oder das, was Low Code ist oder das, was ich programmiere, soll ich auch testen auf der kleinen Teil. Aber sobald ich über Protz Automation Projekte rede, dann verknüpfe ich meistens andere Systeme und dafür brauche ich dann Experten, die das dann so aufbauen, dass Integrationstests auch automatisierbar sind. Zweitausendein eine besondere Rolle. Quality Engineer heißt das bei manchen Unternehmen. Okay, Christoph, deine Runde. Ich schreibe also, wenn jemand Tastatur hört. Das ist deswegen, weil ich halt nett bin und den zwei das alles dokumentiere, damit die nicht anfangen, die gleichen Rollen halt wieder zu schreiben. So, los geht's.

Also wer definitiv auch notwendig ist, aber üblicherweise jetzt nicht oder theoretisch nicht speziell gehired werden sollte und auch nicht, also nur für dieses Projekt im Projektteam mit dabei sein sollte, ist der Prozessmanager und der Prozesseigner von dem jeweiligen Prozess, den man sich zumindest mal anschaut.

Voll wichtig. Extrem. Zweitausendein.

Kommst du mit, wenn ich ihn Prozess Owner nenne?

Es sind zwei unterschiedliche Rollen, Prozess Eigner und prozessmanager Eigner.

Okay, wie unterscheidest du die?

Also der Prozesseigner ist der, der den Prozess und quasi der Entscheidungsträger vom Prozess, der dafür, der dafür zuständig ist, okay, die Prozessziele werden erreicht, der den Prozess überwacht, falls irgendwas nicht passt, der Entscheidungen trifft, wenn angestoßen werden soll etc. Und der Prozessmanager ist so quasi der ausführende, die ausführende Hand des Prozessereigners Hiwi oder.

Wie Hewi oder.

Nicht HIV, sondern der Prozessmanager. Prozessmanager ist der dann, der Prozesseigner stellt fest, hey, die Zahlen passen nicht mehr, dann geht er zum Prozessmanager und sagt hey, warum passen die Zahlen nicht mehr? Und der Prozessmanager kann kann dann starten mit einem Prozessmanagement, also Projekt an klassischen, das heißt ist Analyse Ergebnisse und der Prozesseigener muss aber der sein, der das ganze dann unterschreibt und sagt okay, genau die Maßnahmen führen wir durch, das sind die Probleme. Der Prozessmanager schlagt vor, wir können das das durchführen und der Prozesseigner macht einen Haken. Der Prozesseigener und üblicherweise Prozesseigner ist jetzt auch nicht eine eigene Rolle, wo man sagt, okay, du bist einfach nur prozesseigner 40 Stunden in der Woche. So ein Prozesseigner ist dann üblicherweise z.B. da Abteilungsleiter oder irgendeine irgendein Manager, der die Prozesse mit, also der sicherstellen muss, dass die Arbeit, die die für die er verantwortlich ist, dass die auch wirklich getan wird. Ist in Wirklichkeit nichts anderes für mich.

Für mich ist die aber es sind.

Definitiv, es sind zwei unterschiedliche Rollen.

Spannende Theorie, Christo, ich habe das Let sehr selten gesehen, ich finde es aber sehr cool diese Trennung. Das Problem ist meistens, dass du keinen Prozess owner findest, weil viele Unternehmen in diesen klassischen Strukturen sind und viele Prozesse sind querschnittlich über mehrere Abteilungen und dadurch findet sich häufig kein Prozess Owner. Deswegen kann es sein, dass ich häufiger die Prozessmanager gesehen habe, die dann quasi politisch agieren mussten und mit den Abteilungsleitern von mehreren Abteilungen reden mussten, weil einfach keine Prozessone war. Aus meiner Sicht ist Prozessor einer der verantwortlichsten für Erfolg von diesem Prozess. Das findet aber sehr, sehr selten statt. Sowas wie du hast ein end to End Prozess, das Geld bringt und sehr wenige Firmen sich so strukturiert. Also nach der alten Theorie von BPM sollte es aber so sein, dass du eigentlich der Prozess ownst, dass du dafür verantwortlich bist und dass du halt Möglichkeiten hast. Ich finde es sehr spannend dann diese zwei Rollen zu trennen, wo du sagst okay, mein Prozess muss bessere KPIs haben und so weiter. Und dann hast du einen Prozessmanager, der sich mit den Optimierung fokussiert, sich auf die Optimierung, wie kann er eigentlich diese KPs erreichen und so weiter.

Meistens sehe ich die Rolle zusammen.

Aber ist das so ein Großkonzern? Ich würde ja sagen, dass jeder Mittelständler uns dafür auslacht.

Nee, ich glaube gerade Mittelständler haben das einfacher. In Großkonzern funktioniert selten. Also wenn du in so eine große Bank kommst und alles wo du halt Abteilung hast, das heißt Modellrechnung oder Berechnung, der andere heißt Kunde, der andere Konto und so weiter und die meisten Prozesse gehen zweitausendein, überall Abteilungen, hast du selten einen Prozessor Owner. Das war eines der größten Probleme, wenn wir Prozesse automatisiert haben bei Finance. Ich gehe davon aus, wenn du zu kleineren kommst, sind die eher flexibel zu sagen, okay, dieser Auslieferungsprozess gehört eine Person. Und du findest meiner Meinung nach gerade bei Mittelständlern und kleineren Unternehmen sehr schnell, also viel, viel schneller in Prozessoren, weil du weniger bürokratische Hürde hast, wo jemand dann sagt, nee, dieser Teil gehört mir, ÿousand und. Also ich würde gerade anders sagen, Daniel, dass es bei großen schwieriger ist.

Okay.

Aber ich finde diese Trennung sehr spannend, Christoph, weil ich bis jetzt immer an Oberprozess Owner gedacht habe, der meistens fehlt, aber ja. Cool. Weitere Rolle, komm.

Ich würde den Prozessarchitekten nominieren, der so ein bisschen in zweierlei Richtungen schaut. Einerseits, dass die richtigen Patterns verwendet werden, zweitausendein, dass die Lösung, die entwickelt wird, in die richtige Richtung geht. Also so ein. Ja, einfach einer, der wirklich auch den technisch und fachlichen Hut auf hat. Also eher technisch, fachlich ist der falsche. Fachlich ist, glaube ich, das falsche, aber ja, der so diesen Gesamtüberblick hat.

Ja, wenn du mich vergessen würdest, Daniel, dann wäre das natürlich nicht sehr nett.

Ja, sowas wie Matusch.

Christoph. Also nicht sowas wie ich, aber ich habe das sehr häufig gemacht. Also ich habe sehr häufig diese Rolle gehabt. Christoph, hast du die nächste? Also jetzt seid ihr so weit, dass ihr Analyse habt, Projektleiter, damit könnt ihr das Projekt schon irgendwie fahren. Ihr habt das Team, würde ich sagen, also mit den Automation Engineer, mit dem Model oder Local Developer Tester und der Architekt. Jetzt habt ihr auch Prozess Owner und Prozess Manager, wahrscheinlich sogar mehrere, wenn ihr mehrere Prozesse habt. Was fehlt euch noch?

Ich habe was ganz spezielles, was vielleicht nicht jedes mal notwendig ist, was aber vor allem die letzten Jahre immer relevanter geworden ist, und zwar einen einen Data Engineer.

Cool.

Speziell, wenn es dann in die Richtung, also wenn es in die Richtung Process Mining geht, dann sowieso.

Das brauchst du in jedem Teil, meiner Meinung nach. Brauchst das überall, ob du Low Code bist oder nicht, wie du deine Daten speicherst, bearbeitest, zweitausendein, wie du historisierst, wann löst du und so weiter. Das sehr häufig haben das aus meiner Sicht die Brotz Automation Ingenieur innen. Ich finde, dass es auch eine besondere Rolle ist und wir hatten die zusammen. Wir haben einige Data Engineers gehabt, mit.

Die wichtigsten, weil am Ende die bringen einen signifikanten Anteil an der Effizienz von dem ganzen Projekt oder an dem, dass das wirklich einen richtigen Impact hat.

Die werden auch sehr häufig vergessen. Cool.

Daniel, dein Turn auch eine Kategorie sehr oft vergessen oder komplett vernachlässigt. Und ich finde das fast eine der wichtigsten Rollen der UI UX Engineer, weil in scheiße weiblicher Version gibt es da. Engineer ist genderneutral. Ÿousand ja, wie auch immer.

Engineer innen.

Ja, englisch geschrieben ist es glaube ich, genderneutral. Nee, einfach, das ist so ein krasses Thema, dass die Prozess Eingabemasken oder dass die Eingabemasken und die ganze Führung und ja, dass die Nutzung von der Applikation, die man entwickelt, einfach so crazy intuitiv sein soll. Ja, in der Regel oder oftmals, ich habe schon einige Beispiele gesehen, wird einfach eine Excel nachgebaut, aber dann ist der Effekt wirklich so gar nicht da.

Kann ich nur unterschreiben. Eine der, oh ne, das ist eine der meisten unterschätzte Rollen. Also das ist definitiv die wie ist unsere Kategorie?

Underrated.

Also das ist der meistens underrated Roller aus meiner Sicht viel zu viele Prozessmanager und so weiter unterschätzen, dass deren Kunden auch irgendwie was ziehst du eine Schnute kosten arbeiten. Der Christoph hat einfach keinen Wert für Schönheit.

Mittlerweile müsst ihr wissen, dass ich Pragmatiker bin, oder?

Also ich bin einer der meist underrated Rollen. So, Christoph, deine.

Okay, was wir vergessen haben und es steht definitiv nicht hier. Also diese Rolle kann eventuell oder speziell in kleineren Teams wird dir die ein oder andere Rolle, die hier aufgelistet ist, ausfüllen. Aber es ist tatsächlich eine super wichtige Rolle und zwar für jedes Team eine Führungskraft, ein Teamleiter.

Okay, in welchem Kontext gehen euch die.

Rollen aus oder in welchem Kontext?

Nein, aber das ist, also wir bauen uns, wir bauen uns ja gerade dieses Team oder Automatisierungsprojekt.

Ich möchte nicht nehmen wir die. Also nicht, dass ihr jetzt anfangen mit hr und wir brauchen noch eine Putzfrau und sowas. Ÿousand.

Nein, nein, das tut man.

Also für die muss die Firma haben. Ich bin tatsächlich auch der Meinung, dass wir Führungskräfte brauchen, die die Personen entsprechend weiterentwickeln. Ich glaube aber nicht, dass er Teil von diesem Team ist, sondern hat es ein Teil von der Personenverwaltung innerhalb von der Company. Aber ja, finde ich gut. Jetzt versuche ich noch fachliche Rollen zu finden, Jungs. Komm, zweitausendeinousand.

Ich hätte noch einen. Das ist jetzt ein Projekt, eine, die Matusch immer geliebt hat und in jedem zweiten Meeting gepusht hat, ist die Plattformrolle. Die Plattformrolle, die sowas wie auch die ganzen Berechtigungskonzepte aufbaut. Also so tausend Sachen, die man in so einem Prozessautomatisierungsprojekt nicht sieht. Alles, was irgendwie. Also ich glaube UI, UX ist auch so im Plattformteam drin, aber ja, so eine Plattformrolle.

Es ist eine zentrale Steamrolle, Christoph. Wenn du mehrere Prozesse hast, die wiederfindbare Elemente owned oder sich um Sachen kümmert, damit alle anderen Teams. Also wenn du so Domänen hast oder Use Cases funktionieren kann, würde ich auch sagen, dass es bei größeren Projekten, wo du mehrere use Cases, also der domain driven Design Sinn macht oder so. Das ist sowas wie Center of excellence, wie auch immer. Aber euch fehlen noch so viele Rollen in der Berei. Also jetzt seid jetzt so, dass ihr der Projekt starten könnt, würde ich sagen. Es fällt euch aus. Mein sich auch eine Rolle, die in diesem Post ist. Und ich sage euch auch klar. Welche Post war das? Aber wie wie haltet ihr eure Projekt eigentlich so, dass er läuft? Da fällt euch noch was. Daniel, wo ist dein Mario?

Oh Gott, DevOps haben wir vergessen. Ciao. Sorry. Ja. Autsch. Das komplette ja, backend, backend und DevOps. Ich bin gerade meine Teampyramide durchgegangen. Eigentlich habe ich dann alle Cluster, die wir hatten. Zweitausendein.

Ja, eine hast du vergessen, weil du die vergessen hast, auch im Projekt. Nein, hast du nicht, aber die kommen erstmal später. Eine wichtige Rolle habt ihr vergessen.

Lasst uns mal Öl mal lass mal Checkliste machen. Also wir fangen mal ganz unten an. Wir können die Applikation hosten mit DevOps. Wir haben ein wir haben die Architekten, die das ganze so technisch übersehen. Wir haben ein Data Data Engineer. Wir haben auch einen Entwickler, der die Schnittstellen programmiert. Wir haben den Modellierer, wir haben den Automatisierer, wir haben die Tester, wir haben die Business Requirements Engineers oder Data wie heißt du es genannt? Business Analyst Requirements Engineers. Wir haben die Process Owner, wir haben die Prozess Manager und wir haben den Projektleiter, das Management, das Geld freigibt. Ist aber keine Rolle, was zu Alarm vergessen.

Sobald das Projekt vorbei ist und der Team wieder sich anderen Projekten widmet. Brauchst du noch eine Rolle?

Den Legacy Entwickler?

Sorry, nein, der nicht, aber du brauchst die Wartungsperson, jemanden, die Operatoren, jemand, der einfach die Applikation weiterhin auf am Leben hält. Das wäre quasi noch die Rolle, die auch in diesem Post ist. Deswegen finde ich cool. Aber was spannend ist, die domain experts habt ihr noch nicht. Also nicht so, dass die fällen oder sowas, aber auch in diesem Post. Und das war glaube ich dann ja auch bei uns unterscheiden zwischen denen, die die Story schreiben, also Business Analyse und so weiter und zwischen den Prozess Owner, wo du sagst okay, du bist verantwortlich für diese Use Case, für diese Prozess, für was auch immer und Leuten, die aus der Domäne kommen, die du brauchst, um Business Analyse entsprechend zu machen. Das war quasi da. Also Post ist von Thomas, kennt ihr, weil er aktiv ist. Der hat so eine. Der Post fängt mit einem Bild, das ich nicht ganz genau mag, weil es in diesen Sales Richtung properly stuff pro Automation team ist essential for success of your program. Es klingt nach sehr vielen Sales Posts, [sos/eos], aber der beschreibt das ungefähr in der gleichen Richtung. Also er sagt, damit du ein Dream Team aufbauen kannst und die meisten Fehler vermeidest, sollst du ein Team von Domain Experten haben, die haben Insights vom Prozess und wollen das verbessern.

Sind am Ende auch die Alphatesters, das sind die Leute, die vielleicht nicht die 100 % Zeit haben, aber das sind die, die sich in der Prozess am meisten auskennen, obwohl die nicht die Rolle vom Prozess Owner haben. Dann hast du Business Analyst oder requirements engineers, WHO hat er das strukturiert, die haben dann machen die Arbeit von diesen Rollen, das heißt, versuchen natürlich die Anforderungen entsprechend zu beschreiben. Idealerweise haben die BPMN Knowledge und so weiter. Dann hast du die Prozess Owner spannender beschreibt, das kriegst du so, da sind die Produktmanager zweitausendein, die sind dafür responsible, dass die halt eigentlich die KPIs und alles für diese Prozesse haben oder für die Use Cases für die Prozesse. Die ganzen Entwickler, was ihr hier habt und die UI UX haben die ein Scrum Team, das ist ja okay. Dann haben die noch die Leute, die das laufen lassen. Du hast die aus DevOps definiert, die haben das als SRS Spezialisten und Operatoren, die das dann später first Level Support machen und kann das eigentlich fixen. So fand ich sehr spannend. Also ich habe das quasi komplett getroffen. Jetzt eine Frage, jetzt eine Frage, weil da sind auch natürlich ein paar.

Ein.

Paar Kommentare, die, warum ich mir quasi diesen Post ausgesucht habe und einer der Kommentare war das ist aber dann ziemlich teuer, oder?

Geilster Kommentar ja, das Thema ist halt klar, du brauchst relativ viele Personen und man kann es natürlich mit EDA Kosten machen oder andersrum. Wenn man es extern vergibt, wird es vermutlich recht kostenintensiv, wenn man sich die reine Zahl anschaut mit den Tagessätzen unserer heutigen ITler sind leider nicht mehr die billigsten. Aber das Spannende, was ja quasi, was viele dann völlig übersehen, ist der brutale Impact auf die Organisation, der langfristigen Mehrwert, den man damit erzielt und so viele auch kleinere Ziele, die quasi sowas wie Wissensspeicherung und Wissensenabling überhaupt. Ich glaube, wenn man das gegenrechnet, ich hatte letztens erst wieder mit einem Bekannten zusammengesessen, wo man über einen sogenannten, ja so ein bisschen ROI Kalkulator oder diese Bedeutungsmatrix drüber gegangen sind und da relativiert sich viel oder Fehlerkostenrechnung. Also viele produzierende Unternehmen, ich bin jetzt im Manufacturing sehr intensiv drin und das ist schon eher so meine Lieblingsdomäne, allein diese ganze Fehlerkostenminimierung, die man mit Prozessmanagement und Prozessautomatisierung erreichen kann, was die einfach, sagen wir mal, einsparen kann der Firma. Und klar, da muss man halt auch mal ein bisschen Geld in die Hand nehmen.

Ja, aber Daniel, du hast schon im ersten Satz was falsch gesagt. Wir haben jetzt über Rollen gesprochen und nicht über Personen. Das heißt theoretisch in einem so ein Einzelunternehmer, wenn er das machen wird, würde einfach alle Rollen ausfüllen. Das heißt, die Frage ist tatsächlich die Größe des Unternehmens, weil Domänenexperte ist nichts anderes als der Mitarbeiter, der den Prozess durchführt. Punkt. Ich brauche keine Domänen Experten einstellen. Ich habe die Domänenexperten in meinem Unternehmen.

Die nicht andere Arbeit machen kann.

Ja, aber die kosten mich, die kosten, die kosten mich ruhig das Projekt.

Das meinte ich mit EDA kosten. Das meinte ich mit EDA kosten stuffen, also Leute, die sowieso in der Unternehmen sind und man kann es quasi mit externen auffüllen. Aber ich würde, warte mal ganz kurz, eine Sache, das würde ich jetzt mal challengen. Ich glaube nicht, dass man all diese 14 Rollen, die wir jetzt aufgezählt haben, mit einem zwei oder drei Mann Team abdecken kann, weil davon dann bleibt extrem was auf der Strecke.

Die Frage ist, ob ein zwei, drei Mann Team das braucht. Also die ganzen Rollen und ihr habt es selbst erwähnt, da brauche ich irgendeine bestimmte Unternehmensgröße, dass ich all das brauche.

Also ich würde das, ich will euch zwar nicht unterbrechen, aber ich persönlich bin der Meinung, dass du für die Keyprozesse schon ein großes Team brauchst. Und das ist es, was die meisten Unternehmen aus meiner Sicht unterschätzen, dass wenn du, also ich rede hier über die Prozesse, wo du wirklich sagst, ich will hier anders sein, ich will hier besser sein, ich will hier schneller sein, ich will hier besser skalieren, ich will einfach Vorteil gegenüber meiner Konkurrenz haben und das ist mein Hauptprozess. Und ob das jetzt Amazon ist, als ganz blöde Beispiel, oder ob du das mit BPMN machst oder eigene Workflow, jeder unterscheidet sich, wenn er sowas macht. Und wenn wir über sowas wie HR Prozess, also nach der klassischen Prozess Supporting oder Management, da würde ich es nicht machen. Also für sowas wie Urlaubsantrag sollst du dir ein fertiges Produkt kaufen, klar, weil das ist halt nicht etwas, wo du jetzt halt ein 1000000 Projekt aufsetzen sollst. Aber für die KI Prozesse finde ich schon, dass die besten Projekte, wo ich unterwegs war, die halt wirklich auch Spaß gemacht haben, wo wir etwas bewegt haben, waren mindestens fünf plus und du brauchst so viele Personen, du brauchst nicht so viel rollen.

100 %. Da bin ich schon bei dir, Christoph. So ein so ein domain Experte ist vielleicht 1020 %, weil der braucht eine Business Analyse, aber ein Product Owner, das für mich quasi Schrägschicht der Business Analyst ist eine, der halt einfach Anforderungen macht, der brauchst du. Du brauchst Architekt gerade am Anfang, sehr, sehr viel später vielleicht nur für die spannenden Sachen. Du brauchst ein Team und dein Team ist halt nicht ein Mann, sondern halt zwei, drei, die das umsetzen, die da auch in den Urlaub gehen können. Also sehr viele unterschätzen das statt irgendein Projekt, Automatisierungsprojekt oder so, also nehmen sie sich eine Person zweitausendein und dann wundern die sich, wenn er in zwei Wochen in Urlaub ist. Weißt du? Und das ist halt etwas, wo ich wir reden, also ich rede hier nur über die Keyprozesse und wenn du sowas hast, musst du meiner Meinung nach die Arbeit für Softwareverbesserung wertschätzen, was ja nicht passiert. Und diese Projekte kosten dann aus meinen sich genauso viel. Und ich bin nicht der Meinung, dass es viel ist. Ich bin der Meinung, dass du fair die Keyprozesse genau so was aufbauen sollst. Da muss ich echt ein bisschen Lob den Thomas geben, dass er das so beschrieben hat, dass er das auch so definiert hat.

Und ich glaube, da hat auch jemand andere dann geantwortet. Wenn du auf die Corporates gehst, musst du dich committen und ein committen man heißt, du musst ein Team aufbauen, der deine wichtigste Prozesse, die dir Geld bringen, entsprechend aufbauen, dass du halt einfach ein erfolgreiches Dream Team aufbaust. Finde ich richtig cool.

Tut mir leid, dass ihr mein über absichtlich übertriebenes Beispiel mit dem Einzelunternehmer jetzt hernehmt. Mir ist klar, dass nicht einer alle Rollen ausfüllt, weil wie ich erwähnt habe, wird der Einzelunternehmer hier nicht, der wird nicht irgendwie einen Data Engineer brauchen oder einen Process Architekt oder so. Aber fünf Leute, ein fünf Leute Team zu haben, ist noch immer 10 Personen weniger als die 10 Rollen, Daniel. Und das habe ich damit gemeint. Wir müssen aufpassen und dürfen nicht rollen mit Personen gleichs mit M, weil am Ende M, weil was ziemlich sicher auch passieren wird in den meisten Unternehmen und das hast du gesagt, Matusch, sowas wie Business Analyst und Process Manager wird wahrscheinlich auch von einer Person ausgefüllt werden, weil es ein sehr, sehr verwandte Tätigkeiten sind. Also mich würde es wundern, wenn der Process Manager, also bzw. So herum, das ist meine Behauptung, wenn der Process Manager nicht das kann, was der Business Analyst kann jetzt die Rolle, dann ist es nicht so ein cooler Process Manager in Wirklichkeit. Die Rolle kann von einer Person leicht ausgeführt werden. Dann der Tester, das hast du gesagt, Matusch, Ÿousand, wer sind die besten Tester? Ja, die Domänenexperten sind die besten Tester.

Die haben nicht immer aber Zeit, aber trotzdem, weißt du das, was ich damit sagen will ist, wenn der, also wir hatten das bei Daniel gerade und ich habe das in anderen Projekten auch gesehen, du hast domain Experten, die haben Zeit und du musst die extrem effektiv nutzen. Du hast vielleicht Domain Experten, die mehr Zeit haben, die kann auch testen. Da bin ich bei dir. Am Ende reduzierst du die Personentage nicht. Weißt du, was ich damit meine? Das heißt, wenn du jetzt 1020 % hast, dann ist der domain Expert, spielt er nur die Rolle von domain Expert und nicht von Fachtester oder Abnehmer oder wie auch immer. Wenn er 100 % Zeit hat, könnte er sogar die Prozess owner Rolle übernehmen. Also die meisten Prozess Owner, würde ich sagen, sollen auch Domain Experten sein. Die sollen sich auskennen, wie sie der Prozess eigentlich haben wollen. Aber bezogen auf die Person würde ich eher unterschreiben, dass du halt zwei, drei Entwicklungsmannschaft brauchst, DevOps und so weiter, kommst du sicherlich fünf, sechs, sieben Personen würdest du schon brauchen, wenn du ein Prozessautomatisierungsprojekt haben willst, dass deine Core Prozesse automatisiert. Also das ist ganz wichtig, nicht wenn du ein Prozess Automatisierung Projekt haben wirst, das HR automatisiert, wo du halt einfach fertige Tools kaufen kannst.

Und ich glaube, das war auch tatsächlich in der Kommentare, wenn ihr euch das anschaut, eine der Kritiken, schon ein ganz großes Team. Die Frage ist, wofür, Ÿousand, weißt du? Und ich glaube schon, dass wenn du ein mittelgroßes, wie auch immer, und das ist diese Wertschätzung für Software, da bin ich halt extrem kritisch, dass die meisten Menschen einfach keine Wertschätzung für Software haben. Und wenn das das ist, was deinen Firma Geld bringt, wirst du so ein Team brauchen, wenn du etwas bewirken wirst.

Ja, jetzt wiederholst du dich ein bisschen, aber was ich z.B. beim Tester auch sehe, was ganz viele völlig vernachlässigen, gerade wenn es um viele Daten geht, Zweitausendein, es ist nicht immer nur dieses Prozesstesten oder dieses Funktionaltesten, sondern du hast auch so viele technische Tests, so viel technisches was im Hintergrund. Und eine ganz wichtige Sache, die ich selber auch jetzt im Projekt erlebt habe, wenn der Process Owner zu viele, sagen wir mal null, ach 15 Bucks mitbekommt oder so, Kinderkrankheiten andauernd beschossen wird, dann hast du auch ganz viele Prozess Owner, die relativ schnell sagen, boah, was ist denn das für ein Mist hier mit dem Prozessmanagement oder mit der Prozessautomatisierung. Klar, du kannst mit Entwicklertests auch vieles schon vorher abfangen, aber ja, so ein Testteam hat wirklich deutlich mehr die Zufriedenheit gesteigert. Ja, aber ich gehe auch ein bisschen mit dir mit, Christoph. Es ist definitiv eine große Anzahl an Personen, die auch, egal ob das jetzt EDA Kosten sind oder externe Kosten, immer recht viel Geld sind auf der Rechnung und so ein bisschen in Mathe Richtung, das muss ich halt natürlich rechnen. Ja, Stuffing ist immer ein sehr, sehr spannendes, sehr, sehr spannendes Thema.

Das einzige, um das schnell noch abzuschließen, ich bin halt kein Freund, wenn einer Person vier, fünf, sechs Rollen übergeholfen werden, weil man dann auch ganz schnell eine völlige Überlastung kommt und dann werden halt alle Rollen nur so halbherzig gemacht oder halb nur mit wenig Expertise. Ja, alle nicht.

Ich glaube, was eigentlich mit dem Posen auch mit dieser Folge klar sein soll, wenn du jetzt nicht ein Mann Show bist, Christoph, weil klar, da musst du einfach auf andere Lösungen gehen, keine Ahnung, da musst du dir halt einfach irgendwie helfen. Aber wenn du in richtige Prozessautomatisierung, Digitalisierungsprojekte gehst, das ist aus meiner Sicht schon ungefähr so ein Teil, da musst du hin und halt irgendwie dazu zu kommen, jemand kann das für dich in drei Tagen zusammenklicken und dann hast du den nächsten Amazon gebaut, wird einfach nicht passieren. Und das wäre eigentlich das, was ich gerne aus meiner Abschlussworte habe.

Ich habe eine Idee, lasst uns einen Aufruf starten. Und zwar alle, die in diesem Thema was Verrücktes erlebt haben oder irgendwo in der Richtung ja selber entweder Teil des Projektes waren oder was davon gehört haben, meldet euch. Das wären, glaube ich, sehr spannende Geschichten für den BBM Selbsthilfe Club.

Genau, also wie ein Person sowas probiert hat, das würde mir tatsächlich gefallen und wie viel Zeit er dafür gebraucht hat pro Woche. Cool. Andere, also ich habe meine andere schon gesagt, für mich tatsächlich, vielleicht nicht zu der Thema, aber ein Uiux Engineer, Steffen, definitiv anderertet. Und für mich sind aus auch die zweitausendein Wertschätzung für die Softwareprojekte anderertet. Also die viele wertschätzen das überhaupt nicht und gehen dann irgendwie wirklich mit Erwartungen, die fern der Realität sind und würden sich dann, wenn der Projekt doch so viel kostet, overrated irgendwas, Erwartung, dass du das mit Low Code, no Code Tools viel, viel günstiger schaffst. Zweitausendein, das würde ich also rated, ich würde einfach sagen, das sind einfach andere Rollen, die du brauchst, aber Kosten wären plus, minus gleich.

Underrated ist für mich die Rolle des Process Owner, weil sie aufgrund unserer hierarchischen Strukturen, die unternehmen nicht einfach. Es gibt einfach keine Process owner, was schade ist. Overrated m also ich würde auch sagen matusch no code oder mithilfe von no Tools und zwar nicht günstiger ins Ziel kommen, sondern. Doch ich würde auch also boah. Overrated ist der Gedanke, dass ich mich hinsetze als nicht ITler und mit no Code Tools Kernprozesse komplett automatisieren kann. Das ist 100 % overrated, weil das ist nicht das Leben. Ich persönlich glaube schon, wenn man so ein Team hat, dass das insgesamt günstiger ist, als wenn ich eine komplette IT habe, die das irgendwie hardcoden muss und dann warten muss. Also ich glaube schon, dass no locatur zumindest schneller zum Ziel führen und dadurch günstiger sind, aber nur wegen Faktor Zeit. Weißt du was ich meine?

Matus Faktor Qualität holt aber dein Geld wieder zurück. Also ich bin ich bin Vertreter von low code no hold Lösungen. Ich sage, dass ich Verantwortlichkeiten und Termine verschieben. Du bist schneller. Meine du bist schon schneller bei Lösung. Du brauchst aber andere Rollen, das manche unterschätzen und du musst was die Qualität angeht genau das gleiche machen, also genau testen und so weiter und viele unterschätzen einfach einige einige Vorgehen und dadurch ist hast du dann qualitativ Probleme. Warum viele jetzt halt Low Code no Code bashen. Ich bin wie gesagt Vertreter ja davon. Ich persönlich habe auch lange mit Locotool gearbeitet habe er meine Vermutung ist nicht, dass du damit sehr viel. Also ich kann. Ich würde halt die Preisfrage gar nicht stellen, weil ich da keine valide Berechnungen habe. Wir haben aber Probleme in dem, dass wir keine Entwickler haben und die kannst du mit Low code no Code reduzieren, weil du einfach andere Rollen enablen kannst, also weniger technische Personen und dadurch kannst du viel mehr Projekte machen, weil du mehr Personen enables Lösungen zu schaffen. Aber ich verstehe dich. Overrated würde ich dann hinzufügen citizen developer ist keine Person, die man als citizen bezeichnet nach englischer Definition.

Das heißt jemand der einfach irgendwo lebt. Das sind schon technisch avisierte Person.

Gut, passt. Würde ich so unterschreiben. Hätte ich jetzt auch nichts hinzuzufügen, was nicht sich wiederholen würde.

Cool, also der Aufruf können wir starten? Ich würde mich freuen für weitere idealerweise ganz schlechte Ideen bei Projekten. Es können auch solche sein, wo man halt Projekte mit 100 Personen gestartet hat und nach einem Jahr immer noch zu nichts gekommen ist oder wo man gesagt hat ja das haben wir in drei Monaten mit einem Mann und dann haben die herausgefunden, dass es Zellmau so teuer war und Zellmau so lange kann man gerne über solche Sachen dann diskutieren. Wie gesagt, der Post fand ich sehr cool. Bei ein paar Kommentaren kann ich den zweitkommentierten zustimmen. Weißt du, was mich zweit kommentiert? Meine? Der antwortet auf den ersten Kommentar.

Passt. Dann würde ich sagen, also liebe Leute, weil wir heute aus der Sommerpause kommen, haben wir im Nachhinein heute mal keinen Sorgenclub, keine BPM Selbsthilfegruppe. Ich würde sagen, vielen lieben Dank, dass ihr wieder eingeschaltet habt. Schön, dass ihr zuhört bei den drei Prozessphilosophen. Und ja, bis nächste Woche. Ich würde sagen, Christoph Matusch, vielen, vielen lieben Dank. Und wenn ja, wollt ihr noch was sagen? Wollt ihr euch verabschieden?

Ciao, ciao, ciao.

Bis bald.

Tschüss, baba.

Neuer Kommentar

Dein Name oder Pseudonym (wird öffentlich angezeigt)
Mindestens 10 Zeichen
Durch das Abschicken des Formulars stimmst du zu, dass der Wert unter "Name oder Pseudonym" gespeichert wird und öffentlich angezeigt werden kann. Wir speichern keine IP-Adressen oder andere personenbezogene Daten. Die Nutzung deines echten Namens ist freiwillig.