Kaizen 2 go 306 : Berufsbild Workflow-Analyst


 

Inhalt der Episode:

  • Woraus ist der Impuls entstanden, über ein neues Berufsbild nachzudenken?
  • Wie sieht die typische Tätigkeit aus?
  • Welche Probleme werden damit in den Unternehmen gelöst?
  • Welche Ausbildungselemente werden in dem neuen Berufsbild zusammengeführt?
  • Welche sozialen Kompetenzen sollte ein Workflow-Analyst idealerweise schon mitbringen?
  • Welche Voraussetzungen müssen Unternehmen bzw. Organisationen mitbringen, damit die Arbeit eines Workflow-Analysten erfolgreich werden kann?
  • Wie können kleinere/mittlere Unternehmen mit der Situation umgehen, dass die Tätigkeit möglicherweise kein Fulltime-Job ist? Lässt sich die Tätigkeit nebenher ausführen?
  • Was können Unternehmen heute schon tun, die vor o.g. Herausforderungen stehen?

Notizen zur Episode:


Mitmachen?

Wenn Sie selbst ein interessantes Thema für eine Episode im Umfeld von Geschäftsprozessen haben, können Sie mir das auf dieser Seite mit Vorbereitungsfragen vorschlagen.

Ich freue mich darauf!

Ihnen hat der Inhalt gefallen? Dann bewerten Sie die Episode bitte bei iTunes.
Jetzt eintragen und Artikel zukünftig per eMail erhalten.

Artikel teilen auf ...


(Teil)automatisiertes Transkript

Episode 306 : Berufsbild Workflow-Analyst

Herzlich willkommen zu dem Podcast für Lean Interessierte, die in ihren Organisationen die kontinuierliche Verbesserung der Geschäftsprozesse und Abläufe anstreben, um Nutzen zu steigern, Ressourcen-Verbrauch zu reduzieren und damit Freiräume für echte Wertschöpfung zu schaffen. Für mehr Erfolg durch Kunden- und Mitarbeiterzufriedenheit, höhere Produktivität durch mehr Effektivität und Effizienz. An den Maschinen, im Außendienst, in den Büros bis zur Chefetage.

Götz Müller: Heute habe ich Björn Richerzhagen bei mir im Podcast Gespräch, schon zum zweiten Mal. Er ist Experte im modellbasierten Prozessmanagement. Beim ersten Mal haben wir uns über BPM und Lean unterhalten und heute ein spannendes Thema, aber da werden wir gleich dazu kommen, erstmal hallo Björn.

Björn Richerzhagen: Hallo Götz. Danke, dass ich wieder da sein darf.

Götz Müller: Ja, wir haben, gerade schon angedeutet, ein spannendes Thema heute, aber stell dich vielleicht nochmal den Zuhörern in zwei, drei Sätzen intensiver vor, die die 1. Episode nicht angehört hatten.

Björn Richerzhagen: Ja, gerne. Also ich bin der Björn, Björn Richerzhagen. Ich bin der Gründer der MINAUTICS GmbH in Berlin. Wir sind eine Beratung für das Thema Prozessmanagement und fokussieren uns da insbesondere auf das, was wir modellbasiertes Prozessmanagement nennen. Das heißt, wir nutzen Modellierungssprachen nicht nur, um Prozesse zu visualisieren, sondern mit modernen Modellierungssprachen sind wir auch in der Lage, Prozesse zu automatisieren, also es gibt Software-Produkte, die diesen Modellierungssprachen dann ausführen können und damit Prozessautomatisierung ermöglichen. Und das ist unser Steckenpferd, mit dem wir diverse Leistungsangebote für unsere Kunden platzieren. Das sind zum einen Trainings, also diverse Schulungsangebote in diesem Kontext, sind aber auch beratend unterwegs und setzen auch Projekte bei unseren Kunden um. Ja, ansonsten bin ich 44 Jahre alt, gelernter Kaufmann, Wirtschaftsinformatiker, hab eine Industrie-Historie hinter mir, bin aber im Moment ganz viel in Dienstleistungsunternehmen unterwegs.

Götz Müller: Ja, und ich glaube eben, dieser Kontext Prozessmanagement in Verbindung mit modellbasiert, man könnte es jetzt fast so ausdrücken, schreit ein Stück weit an Menschen, die sich mit dem Thema ganz intensiv beschäftigen und vielleicht eben, und das ist ja unser Thema, oder nicht bloß vielleicht, sondern eben auch, man kann sich die Frage stellen: Braucht es dafür ein neues Berufsbild, eben dieses, wie genannt Workflow Analyst? Und jetzt zum Einstieg die Frage: Wie ist denn der Impuls entstanden, über ein neues Berufsbild entstanden, über ein mögliches neues Berufsbild, über die Notwendigkeit nachzudenken?

Björn Richerzhagen: Ja. Also wir erleben in den Projekten, in denen wir unterwegs sind, in denen wir dann diese Modellierungssprachen für die Automatisierung beispielsweise einsetzen, zu denen gehören die BPM, das ist die Modellierungssprache, über die wir im letzten Podcast gesprochen haben, insofern gerne der freundliche Verweis, wenn jemand interessiert ist, sich das nochmal anzuhören, es gibt aber auch andere Modellierungssprachen wie die DMN oder die CMN auf Basis derer eben wir, ja, Automatisierungsprojekte umsetzen. Und wir erleben bei unseren Kunden, dass es da durchaus Menschen gibt, die sich damit beschäftigen, Software zu spezifizieren auf der einen Seite und dann das beispielsweise aufzubereiten für einen Softwareentwickler, der es dann umsetzen soll. Auf der anderen Seite gibt es aber auch eine Zielgruppe oder ein Berufsbild in der Organisation, die man vielleicht eher so als Qualitätsmanager bezeichnen würde, die haben per se auch schon die Aufgabe, sich mit Prozessen zu beschäftigen, denen ist aber der Zugang zu solchen Workflow-Systemen ein Stück weit verwehrt geblieben bislang und sehen häufig IT auch als etwas, was, na ja, ein stückweit unveränderlich ist und im Ergebnis gehen sie dann hin und organisieren Prozesse, um die Systeme herum als gemeinschaftlich sowohl die fachlich menschlich ausgeführten Prozesse, gemeinsam mit den technisch ausgeführten Prozessen aufeinander abzustimmen und diese zu optimieren. Und ja, das ist im Grunde genommen das, was wir so beobachten. Also es gibt diese beiden Lager, entweder die sehr IT-affinen, die es halt gewöhnt sind, in solchen IT-Projekten unterwegs zu sein und auf der anderen Seite gibt es eine Zielgruppe, die ja organisatorisch unterwegs ist. Und beide Seiten haben in unserer Wahrnehmung wiederkehrende Probleme, also auf der einen Seite haben wir diejenigen, die eigentlich in der Technik zu Hause sind, die heißen manchmal Business-Analysten oder Product Owner, oder ähnlich, die haben die Aufgabe irgendwie ein Software-Produkt zu konzipieren und dafür Lösungen zu konzipieren, und während sie das tun, kommen sie an einen Punkt, wo sie feststellen „Ah, Moment, eigentlich müssten wir den Prozess erstmal optimieren, bevor wir ihn automatisieren.“ und dann passieren so verschiedene Dinge, das Projekt kommt ins Stocken, man macht erst mal eine Pause, man muss erstmal innehalten. Dann stellt man fest, für eine Prozessoptimierung hat so ein Business-Analyst eigentlich gar keinen Methoden-Portfolio, also die Wissen im Zweifel gar nicht wie das geht, die machen das sehr hemdsärmelig und schlimmstenfalls läuft das irgendwie parallel. Also, während man Anforderungen versucht, irgendwie einzusammeln, verändert man parallel noch kurz den Prozess, über den man eigentlich oder für den man eigentlich eine Lösung bauen möchte.

Götz Müller: Ja, und im Grunde beschreibst du aber schon fast den positiven Fall, dass man merkt, man sollte da etwas optimieren. Ich kenne durchaus auch die anderen Fälle, und das Stichwort ist dann der digitale Scheißprozess, wo man halt irgendwas digitalisiert und halt im Grunde Mist digitalisiert im Extremfall.

Björn Richerzhagen: Ja, genau also die Fälle kennen wir natürlich auch, da ist das Kind grundsätzlich schon fast in den Brunnen gefallen. Da macht man mit viel Aufwand oder baut man mit viel Aufwand Lösungen für eigentlich unzureichend standardisierte Prozesse oder optimierte Prozesse. Genau das ist so das, was man dann meist eher so am Ende der Projektlaufzeit vielleicht merkt oder wenn vielleicht sogar das Tool ausgerollt wird, aber es gibt durchaus auch ein paar Business-Analysten, die das am Anfang schon merken und sagen „Okay, ich habe hier eigentlich einen Auftrag, ich sollte eigentlich die Anforderungen dafür zusammentragen, aber wenn ich in den Fachbereich gehe und nach den Anforderungen Frage, kriege ich da total diffuse Antworten, die gar nicht erkennen lassen, dass es da einen eindeutigen Prozess gibt und dann stehen die da ein bisschen methodisch auf dem Schlauch und kommen nicht weiter. Und das ist dann, ja, wie soll ich sagen, ein Lager, was ein wiederkehrendes Problem hat. Auf der anderen Seite haben wir die Organisatoren, die Qualitätsmanager in Unternehmen, die sich ja durchaus auch mit Prozessen beschäftigen, die haben witzigerweise eine Menge Methodik, um über Prozesse nachzudenken und die durchaus hin auch auf ein Ziel zu optimieren, denen ist aber die Tür zur IT häufig verschlossen, also denen fehlt irgendwie die Möglichkeit und das Vokabular mit Leuten aus der Technik, also aus der IT zu sprechen und für die wollen wir natürlich auch einen Zugang legen und, ja, diese beiden Lager, also das ist sozusagen die Kernidee gewesen, für die braucht es eigentlich ein Angebot, dass die verstehen, dass das andere Lager in anderen Methodenschatz hat, aber dass die Kombination dieser beiden Werkzeugkästen eigentlich das ist, was wir zukünftig für die Automatisierung und Digitalisierung brauchen, um eben genau diesen Effekt, den du gerade angesprochen hast gesprochen hast, Götz nämlich Scheißprozesse zu automatisieren, damit wir danach digitale oder automatisierte Scheißprozesse haben, das wollen wir genau verhindern und dafür braucht es eben die Kompetenzen aus beiden Lagern. Genau, und da sind wir auf die Idee gekommen, dafür eine Veranstaltung ins Leben zu rufen, die sich da eben nennt Workflow-Analytica.

Götz Müller: Mhm ja. Da ist die Assoziation, glaube ich schon, die steckt schon im Namen drin. Mir kam jetzt bei deiner Erzählung in den Sinn, im Grunde gibt es ja sogar noch ein drittes Lager, könnte man es fast nennen, nämlich, man könnte es auch so ausdrücken, den Rest der Welt oder den Rest des Unternehmens, nämlich die Menschen, die halt in irgendwelchen Prozessen in irgendeiner Form unterwegs sind, die man ja bei ihrer Tätigkeit unterstützen möchte und deshalb auch über Automatisierung, Digitalisierung und solche Dinge nachdenkt und die ja wiederum weder ins eine noch ins andere Lager gehören, natürlich ihren fachlichen Kontext haben, aber oft eben IT auch so 3 Kreuze machen oder eben die, manchmal überspitzt ausgedrückt, ich will ja jetzt niemandem eintreten, wenn die Qualität ums Eck kommt, auch 3 Kreuze machen und dann entsteht da, glaube ich, so ein klassisches Dreiecksverhältnis, könnte man es auch nennen.

Björn Richerzhagen: Ja, also die sind natürlich auch immer mit im Boot und auch thematisch mit im Boot, denn wenn es so ein Projekt richtig mies gelaufen ist, sind dies natürlich am Ende diejenigen, die es ausbaden müssen und da erleben wir schon auch in einigen Unternehmen, dass aus dem Kreise der Nutzer, so möchte ich es vielleicht mal nennen, durchaus auch der Wunsch besteht, davon mehr zu verstehen und auch mehr Einfluss darauf zu nehmen, also auch für die schaffen wir da durchaus ein Angebot, aber wenn ich das jetzt vielleicht mal so gewichten würde, die beiden von mir skizzierten Lager plus die Nutzer, so würde ich sie jetzt mal nennen, haben wir auf dieser Veranstaltung, im letzten Jahr haben wir sie das erste Mal ausgeführt, jetzt also 45% technikaffine Leute, 45% eher nicht so technikaffine Leute, die aber meist organisatorisch mit der Aufgabenstellung betraut sind und dann gibt es halt noch so wenige Interessierte, die man vielleicht eher so einem Fachbereich zuordnen würde.

Götz Müller: Ja, ich glaube, das passt auch in, ja, sagen wir mal in mein Weltbild, im Grunde weiß ich ja von dem Thema nichts, bis es mich das erste Mal trifft, also, bis ich eben auf so ein Automatisierungsthema stoße als Nutzer jetzt. Das heißt, es fehlt mir so ein bisschen, ohne das jetzt vielleicht negativ andeuten zu wollen. Es fehlt vielleicht da das Problembewusstsein.

Björn Richerzhagen: Ja, das ist so. Man weiß halt nicht, was man nicht weiß. Das ist halt irgendwie ein blinder Fleck. Das gilt aber eigentlich für alle Beteiligten. Also das gilt sowohl für diese IT-affinen als auch für die Fachbereiche als auch die, die aus der Organisation oder da so aus dem Qualitätsmanagement kommen. Da gibt es nur sehr wenige, die sagen: „Ja, ist mir natürlich völlig klar, was ich nicht kann.“ Wenn die das sagen würden, dann sind die vielleicht auch nicht unsere Zielgruppe für die Veranstaltungen, sagen wir es mal so, wenn denen das klar wäre, aber wir versuchen da, die Welten miteinander, ja, zusammenzubringen, da Türen zu öffnen und ein Verständnis für den gegenseitigen Sprachgebrauch zu schaffen. Also vielleicht mal so als Beispiel, im letzten Jahr war das Thema Lean natürlich ein Thema, weil Lean natürlich auch ein Ansatz ist, um irgendwie über Prozesse nachzudenken, Verschwendung zu eliminieren und so weiter. Ich glaube, Lean hat da eine Menge Potenzial, etwas zu bewirken und wenn das erfolgt ist, dann kann man mit Automatisierungstechniken das Ganze einfach nochmal ein Stück weitertragen. Wenn ich mir allerdings vorher keine Gedanken darüber gemacht habe, wie ich eine verschwendungsfreien Prozess organisiere, dann na ja, jetzt wiederhole ich mich, wird der Prozess, den ich da nachher technisch umsetzen, natürlich auch nicht sonderlich gut sein.

Götz Müller: Okay.

Björn Richerzhagen: Oder noch mal einen anderen Aspekt vielleicht aus dem letzten Jahr. Wie muss ich eigentlich oder woran mache ich eigentlich fest, dass ein Prozess gut ist oder nicht? Also was ist das Kriterium, an dem ich festhalte, dass der Prozess jetzt gut läuft oder nicht? Da kann ich mir natürlich Dinge überlegen, aber das muss natürlich irgendwie etwas mit der Unternehmensstrategie, mit der Unternehmensorganisation, mit der Gesamtausrichtung des Unternehmens zu tun haben und auch da Werkzeug und Argumentationsketten zu kennen, die einem helfen, da die richtigen Entscheidungen zu treffen. Da gibt es Werkzeug zu, da gibt es methodische Ansätze zu, die wir in so eine Veranstaltung einbringen, damit im Zweifel derjenige, der nur im Projekt unterwegs ist, auch, sage ich mal, den großen Rahmen darumziehen kann und das Gesamtverständnis entwickeln kann, warum er denn jetzt den Prozess A in seinem Unternehmen auf Kosten optimieren muss und was das mit der Unternehmensstrategie B zu tun hat. Also wir sind da sehr umfassend unterwegs. Das hat strategische Aspekte, das hat organisatorische Aspekte, das hat technische Aspekte. Wir haben noch ein paar Produktanbieter da, die aber eher als Beispiel präsent sind, also die eher so Use Cases präsentieren, damit man vielleicht von der Gattung Software mal einen Eindruck bekommt, ob die jetzt hilfreich ist für mein Problem oder nicht und wir leben von ganz viel Austausch. Also wir haben es im letzten Jahr hingekriegt und ich hoffe, das werden wir dieses Jahr auch wieder hinkriegen, dass diese diversen Lager, die da präsent sind, gemeinsam ein Gespräch finden, von ihren Problemen berichten und sich gegenseitig auch Unterstützung anbieten im Sinne von „Hey, ich kenne da die Methode XY, wende die doch mal an, die kann dein Problem lösen“.

Götz Müller: Mhm ja, ich höre da auch raus aus deinen Erzählungen, es ist so etwas wie eine Schnittstellen-Tätigkeit, aber nicht bloß eine reine Schnittstelle, sondern auch eine Art von, ja, vielleicht Dolmetscher im übertragenen Sinne zumindest, eben Sprachgebrauch hast du vorhin als Stichwort angedeutet, man hat ja als IT-ler, als Software-Mensch hat man eine bestimmte Begriffe in seiner eigenen Blase, kann man es ja auch fast nennen, die halt außerhalb nicht bekannt sind und andere haben dann wieder andere Begriffe.

Björn Richerzhagen: Das ist mit Sicherheit so. Also ich bin jetzt durchaus in der IT unterwegs und ich werde auch einen gewisses Vokabular unbewusst nutzen, da verprelle ich vielleicht den ein oder anderen mit, jetzt kann ich mich natürlich darauf konzentrieren und gucken, dass ich dort, ja, wie soll ich sagen, allgemein verständliche Begriffe nutze, die eben nicht aus meiner Bubble oder aus meiner Blase kommen. Das will ich auch immer tun, das ist auch meine Aufgabe. Auf der anderen Seite ist das natürlich auch ganz gut, wenn mir der andere Bereich entgegenkommt. Wenn jetzt beispielsweise ich, der sich eher in der IT verorten würde, auf jemanden im Qualitätswesen zukommt und der schon mal ein paar Vokabeln kennt, die ich vielleicht nutze. Das ist die Idee dieser Veranstaltungen so die Brücke zu schlagen und die Schnittstelle … Schnittstelle heißt, also ich finde Schnittstelle immer, den Begriff mag ich nicht so sehr in dem Bereich, weil Schnittstelle heißt immer, ich mache eine Brücke zwischen Dingen, die getrennt sind und hier ist das eigentlich eher so und so verstehe ich diese Veranstaltung, wir wollen die Dinge gar nicht mehr trennen. Der IT-ler, der einen Prozess automatisiert, der sollte sich vielleicht auch durchaus mal ein paar Gedanken machen, ob da nicht eine FMEA vielleicht im Vorhinein mal sinnvoll ist. Das ist eine Methode, die üblicherweise in der IT nicht vertreten ist. Der Organisator oder Qualitätsmanager, der vorher aufwendige Verfahrensanweisungen irgendwie in Word niedergeschrieben hat oder in irgendeinem anderen Tool, der soll natürlich auch Möglichkeiten kennen, wie man das vielleicht durch Software besser steuern und umsetzen kann, um da Medienbrüche beispielsweise auszumerzen. Also ich glaube, man muss beide Welten verstehen, man muss diesen Methodenkoffer, diese Werkzeuge, also man muss dann am Ende einen Werkzeugkoffer haben, indem sowohl die Werkzeuge aus dem organisatorischen Umfeld als auch aus der IT reinpassen und man nimmt dann eben das, was passt und was man gerade braucht.

Götz Müller: Mhm. Ja, wenn wir über ein neues Berufsbild reden, dann, in meinem Begriffsweltbild, dann hat so etwas ja auch eben Ausbildungselemente, die ich dort zusammenfasse und das möchte ich noch ein bisschen vertiefen, auch zum Beispiel vor der Frage und da passt die IT ja auch im Grunde wieder, weil das kann einerseits ein akademisches Berufsbild sein, dass ich Informatik studiere, aber es gibt ja eben auch IT-Berufe, die Ausbildungsberufe sind. Was ist da so dein Gedanke, welche Ausbildungselemente fasse ich zusammen in diesem neuen Berufsbild, um jetzt hier nicht, natürlich macht es ja nicht so viel Sinn, zu sagen „Man muss halt beides können, dann braucht er halt 10 Jahre, bis er es kann und dann kann er es“?

Björn Richerzhagen: Ja. Gut, das weiß ich ehrlich gesagt gar nicht, also ob das 10 Jahre dauert. Ich weiß auch nicht, ob das eine akademische Ausbildung ist oder einen Lehrberuf ist an der Stelle. Vielleicht muss man die Frage auch gar nicht beantworten, sondern sich die Frage, also vielleicht muss man die einfach unbeantwortet lassen. Ich habe auf der letzten Veranstaltung mehrfach bestätigt bekommen, dass es ein Tätigkeitsfeld gibt im Unternehmen, insbesondere wenn diverse Automatisierungs- und Digitalisierungsprojekte laufen, die nach diesen Kompetenzen Fragen, von denen ich gerade gesprochen habe. Und jetzt kann ich natürlich hingehen und sagen, jeder macht seine Ausbildung wie gehabt und ich habe die alle in unterschiedlichen Abteilungen verortet, und die ziehe ich projektbezogen zusammen, das kann man ohne weiteres tun, resultiert aber trotzdem weiterhin im Ergebnis, dass man ein gewisses Unverständnis füreinander hat, ich glaube vielleicht, dass die Ausbildung so wie sie sind, ja auch gar nicht schlecht sind, die haben ja auch in der Vergangenheit gute Ergebnisse gebracht, aber vielleicht muss man auf beiden Seiten mal so zehn, fünfzehn Prozent der Inhalte, die man da so vermittelt oder die man über die Jahre und Erfahrungen gesammelt hat, einfach mal in einem anderen Bereich sammeln, ja, um a) diese sprachliche Brücke hinzukriegen und b) aber auch seinen eigenen Methodenschatz zu erweitern. Ich sage mal so ein Beispiel, ich bin gerade bei einem großen Automobilzulieferer, die Nutzen noch kein BPMN, das ist ja jetzt per se erstmal nicht schlimm, aber das ist ein Methodenschatz, der seit 15 Jahren State of the Art ist, so würde ich das vielleicht mal nennen, in vielen Branchen große Verbreitung gefunden hat und wo junge Leute, die aus der Ausbildung kommen, die aus dem Studium kommen, die sind mit dem Wissen ausgestattet und die nutzen aber so eine proprietäre Modellierungssprache, die nur visuell irgendwie einen Prozess darstellen kann, was ja schon auch nicht so schlecht ist, ja, also besser als gar nichts, aber das ebnet natürlich nicht den Weg, irgendwie irgendwann mal einen Automatisierungsprodukt darauf fußend umsetzen zu können. Oder die haben noch ein Verständnis davon, dass Prozessmanagement das ist, was man macht, wenn man einen Workshop einrichtet und danach ein Modell erstellt, ja, auch das ist kein modernes Verständnis von Prozessmanagement und ich glaube, da braucht man einfach beide Welten. Man muss da ein Verständnis dafür haben, um aktuell im Prozessmanagement tätig zu sein, und da braucht es sowohl die alten Tugenden, nämlich die klassischen IT-Ausbildungen und Qualitätsmanagement-Ausbildungen und so weiter und ein gutes Stück des Kuchens vom anderen, so würde ich das vielleicht mal nennen. Und ein Bewusstsein dafür zu schaffen, das versuchen wir auf der Workflow Analytica und wenn das Bewusstsein dafür da ist, dann kann man sich, glaube ich, die dazu passenden Ausbildungen auch durchaus suchen.

Götz Müller: Ich habe auch so ein bisschen rausgehört, auch wenn du es als direkten Begriff noch nicht verwendet hat: soziale Kompetenzen. Also wenn ich halt unterschiedliche Bereiche zusammenbringen will und muss, kann man ja durchaus so sagen, dann gibt es ja manchmal auch Abgrenzungsschwierigkeiten, Reibereien, und das ist so meine Erfahrung, auch da gewisse soziale Kompetenzen an dieser, ich bleibe mal bei meinem Begriff Schnittstelle, an diesem … oder vielleicht Sandwich-Position, zwischen den Dingen, was ist da deine Erfahrung, was sollte da jemand mitbringen? Also der der klassischen Nerd, glaube ich, wird eben die gleichen Herausforderungen haben, die halt der klassischen Nerd hat.

Björn Richerzhagen: Mhm. Also vielleicht müssen wir da die Schubladen mal aufziehen. Ich glaube, die Ausbildungsstellen, sei es jetzt Hochschule oder Berufsausbildungsstellen, die kennen natürlich auch diese Schublade und deren Wunsch und deren Aktivitäten zielen nicht darauf ab, einen Nerd auszubilden. Ich glaube, das ist aber das, was häufig mit diesem Berufsbild irgendwie verbunden wird. Ich kenne zahlreiche junge Menschen, da gibt es fähige Programmierer, die durchaus in der Lage sind, sich in ein Sozialgefüge einzubinden, dort Beiträge zu leisten und eben nicht das verkörpern, was man vielleicht noch so vor 15 Jahren unter einem Softwareentwickler verstanden hat, nämlich der arbeitet im Dunkeln, im besten Fall im Keller und die Tür unten im Keller ist ein Stückchen höher als alle anderen, damit man einen Pizzakarton unten drunter durchschieben kann. Ich glaube, diesen Typus von Softwareentwicklern, den gibt es nicht oder zumindest nicht aufgrund seiner Ausbildung. Das mag allenfalls ein Charaktermerkmal sein und dann wäre es fast egal gewesen, ob er Informatik studiert oder Lehramt oder Rechtsanwalt geworden wäre oder was auch immer. Die Sozialkompetenzen sind aber ohne weiteres ein riesiges Thema. Wir brauchen ja immer den multidisziplinären Ansatz für die meisten Probleme, insofern macht es total Sinn, dass man eine gewisse, ja, mit offenen Armen auf andere Disziplinen durchaus zugeht und ein Verständnis für diejenigen entwickelt und wenn es dann noch eine gemeinsame Sprache gibt, ja, beispielsweise, bleiben wir mal beim Beispiel der Prozessdarstellung mittels BPMN, ja, dann ist das schon mal eine Hürde genommen, da wird es noch jede Menge weiterer Kommunikationsschwierigkeiten geben, aber ein bisschen Empathie, ein bisschen Verständnis, ein bisschen Offenheit, die Akzeptanz, dass die Ausbildung des anderen durchaus auch einen hohen Wert hat, das ist natürlich ohne Frage eine wichtige Eigenschaft. Aber ich fürchte, die werden wir nur durch Ausbildung alleine nicht hinkriegen. Das hat eine ganze Menge mehr Facetten.

Götz Müller: Gut. Jetzt haben wir relativ viel oder auch fast ausschließlich über Menschen gesprochen, eben die verschiedenen Bereiche, also Vertreter dieser verschiedenen Bereiche, die da zusammenarbeiten sollen. Jetzt gibt es natürlich noch so etwas wie das Unternehmen, die Organisation, auch wenn das selber vielleicht nicht diese Form von Bewusstsein wie ein Mensch hat, die Frage, die ich jetzt stellen will, ist, was muss aber eben diese abstrakte Entität Unternehmen, Organisationen mitbringen, damit ein Workflow Analyst überhaupt erfolgreich sein kann, damit er nicht scheitert im Extremfall.

Björn Richerzhagen: Das ist eine interessante Fragestellung. Man könnte die auch andersrum stellen: Was muss eigentlich der Workflow-Analyst tun, damit die Organisation erfolgreich ist? Sagen wir mal, ich würde vielleicht mal ein paar Merkmale aufzeigen, die ich erkenne, wo es schwer ist, diese Rolle des Workflow-Analysten zu leben. Das sind insbesondere solche Organisationen, die stark hierarchisch gegliedert sind, die aufgrund ihrer Kultur gut zementierte Abteilungsgrenzen pflegen. Es gibt Unternehmen, die haben schriftliche Vereinbarungen, wie die Schnittstelle zur Nachbarabteilung auszusehen hat. In diesen Organisationen wird das wahrscheinlich schwer, weil so ein Workflow-Analyst wahrscheinlich nicht an eine Stelle gehoben wird, wo er diese Strukturen aufbrechen darf. Die Fähigkeit dazu sollte er aber trotzdem haben. Also er sollte wissen, wie das geht, wenn er denn dann das Mandat dafür bekommt, dann sollte er das auch durchaus tun dürfen, denn das ist halt die Voraussetzungen dafür, dass man auch mal einen Prozess automatisiert, der über die Abteilungsgrenze hinweg geht. Der sollte auch eine Marktorientierung haben, also es gibt durchaus auch Organisationen, in denen einzelne Mitarbeiter nicht wissen, für welche Kunden sie arbeiten. Also mit anderen Worten, da, wo ein Workflow-Analyst tätig ist, sollte der natürlich auch immer irgendwie verstehen, für wen er da eigentlich arbeitet, welche Kundenbedürfnisse und Kundenanforderungen in den Prozessen und Workflows umzusetzen sind, ja, also lange Rede, wenig Sinn. Ich glaube die, die Eigenschaften eines Unternehmens, damit er besonders leicht arbeiten kann, sind eher flache Hierarchien, gute Kundenorientierung, wenig strukturelle Hemmnisse im Sinne von Abteilungsgrenzen. Dann funktioniert das, glaube ich, ganz gut, wenn diese Charaktereigenschaften des Unternehmens nicht da sind, dann braucht es aber jemanden, der da trotzdem mitarbeiten kann und das ist dann eben Methodik, die so ein Workflow Analyst eben in seinem Werkzeugkoffer haben muss.

Götz Müller: Mhm ja. Ich hatte in der Vorbereitung auch den Gedanken, im Grunde ist es so etwas wie ein System-Ingenieur, der natürlich eher auf nur so einer produkttechnischen Ebene unterwegs ist und hier ist halt das System die Organisation mit ihren Prozessen, aber ähnlich wie in ein System-Ingenieur, der zum Beispiel diese zwei, manchmal extremen Fraktionen, Hardware und Software unter einen Hut bringen muss, und vielleicht noch Konstruktion und Fertigung, wenn man von der horizontalen in eine vertikale Ebene geht und so weiter, so hatte ich mal den Gedanken, im Grunde ist es so etwas Ähnliches, und das gibt es jetzt auch noch nicht so lange, zumindest nicht so lange, wie es Ingenieure schon gibt, dass man dort eben erkannt hat, ja, ich brauche etwas, der sich in beiden, auf beiden Feldern ein bisschen zuhause fühlt und eben auch da Menschen zusammenbringen kann, ein Stück weit beide Sprachen sprechen kann und da hatte ich so das Gefühl, so ein Workflow-Analyst ist auf dieser organisatorischen Prozessebene etwas Vergleichbares.

Björn Richerzhagen: Das kann man, glaube ich, so sehen, ja. Also ein Verständnis für die diversen Lager und eine Orientierung auf eine bestimmte Anforderung, in unserem Fall ist das dann wahrscheinlich irgendwie eine Leistungsanforderung, die vom Kunden oder zumindest mal von Prozesskunden kommt, so ein Systemingenieur, der wird mit Sicherheit die Anforderungen an das Produkt irgendwie vor Augen haben und daraufhin eine Lösung bauen, ob die dann mechanisch umgesetzt wird oder elektrisch oder informationstechnisch ist dann vielleicht eine nachgelagerte Frage. Genau, also aufs gemeinsame Ziel ausrichten. Das ist sicherlich durchaus vergleichbar, ja.

Götz Müller: Dann hatte ich auch wieder so ein bisschen, vor dem Kontext, sagen wir mal meiner Erfahrung, es gibt ja Unternehmen in ganz verschiedenen Größen, vor allen Dingen als so einen Kriterium, wie man halt Dinge einordnen kann, und jetzt natürlich, in den großen Unternehmen kann man mit einem Thema eine Person Vollzeit auslassen oder sogar mehrere Personen mit dieser Tätigkeit. Wie können kleine Unternehmen damit umgehen, die einerseits diesen Bedarf an so einer Tätigkeit, an so einer Rolle mit all ihren Ausprägungen haben, aber den halt einfach nicht acht Stunden am Tag, fünf Tage die Woche auslasten können. Was ist da, weil wie gesagt ich, ich kenne das Problem natürlich jetzt im klassischen Lean Kontext, da ist es manchmal ähnlich, da geht es darum, Prozesse zu optimieren, aber jetzt habe ich als kleines Unternehmen gar nicht so viele Prozesse in ihrer Vielfalt, dass eine 40-Stunden-Woche oder auch eine 35-Stunden-Woche ausgefüllt wird.

Björn Richerzhagen: Es ist natürlich gar nicht so leicht zu beantworten, also ich glaube, es gibt kein Unternehmen auf der Welt, das sich nicht gerade mit Digitalisierungsfragen beschäftigt, Tschuldigung, das sich mit Digitalisierungsfragen beschäftigen sollte. Vielleicht muss man das so formulieren. Und Digitalisierung hat ja nicht zwangsläufig etwas nur mit Einsparungen und Effizienzgewinn und so zu tun, sondern hat ja auch durchaus damit zu tun, wie, also welchen Zusatznutzen kann ich für meinen Kunden schaffen. Und wenn man das jetzt mal invertiert, dann würde es ja heißen, kleine Unternehmen haben keine Zeit dafür, sich mit Effizienzfragen zu beschäftigen oder mit dem Nutzen für einen Kunden zu beschäftigen. Ich glaube, das ist nicht der Fall und insofern glaube ich, dass im Grunde genommen diese die grundsätzlichen Aufgaben schon immer in der Organisation irgendwie vorhanden waren. Es braucht jetzt einfach nur die Vernetzung, zu verstehen, wie da vielleicht die Zusammenhänge sind und die Werkzeuge und Möglichkeiten zu kennen, die das jeweils andere Lager vielleicht so bietet, wenn man es denn bislang nicht irgendwie zusammengebracht hat. Ich glaube, wenn ich ein kleineres Unternehmen wäre und ich würde mich jetzt einer Prozessautomatisierungsaufgabe stellen, dann ist, glaube ich, der Hauptnutzen oder der erste Schritt: Anfangen. Also das nicht irgendwie überzutheoretisieren, sondern einfach sich mit der Aufgaben- und Fragestellungen zu beschäftigen, vielleicht die Anspruchshaltung an irgendwelche Pläne vielleicht ein bisschen runterzuschrauben, aber den Leuten die Möglichkeit zu geben, diese beiden Welten kennenzulernen und dann daraus natürlich ihre Schlüsse zu ziehen, die gemeinsame Sprache zu entwickeln und ob der Mann dann oder ob die Frau dann Workflow-Analyst heißt oder ob die einfach nur Peter und Ursula heißen, ist an der Stelle egal, es braucht jemanden, der diese Welten oder diese Fäden irgendwie so zusammenführt und bei der Automatisierung eben nicht vergisst, dass der Prozess vielleicht vorher auch nochmal zu optimieren ist. Wenn schon mal ein Bewusstsein dafür da ist, ist ja schon mal viel gewonnen und wenn mit dem Bewusstsein man auch noch innerhalb der Organisation jemanden fragen kann, der einen dabei unterstützt, ist auch viel gewonnen, ob das dann Full Time ist vielleicht gar nicht so wichtig.

Götz Müller: Ja, was mir da halt durch den Kopf geht, ist, wenn es eben nicht Vollzeit ist, weil solche Fälle kenne ich dann, dann sind es so manchmal im Extremfall, und wie gesagt ich drück da jetzt Dinge vielleicht ein bisschen überspitzt aus, wer nicht schnell genug einen Schritt zurückgetreten ist, der hat das Thema an der Backe, ob er es wollte oder nicht, mal unabhängig davon, ob er dafür prädestiniert wäre, mit dem Thema umzugehen und manchmal kommen dann Dinge halt zu kurz, weil es ja noch das sogenannte Tagesgeschäft gibt, wenn sich jemand mit dem Thema eben nicht in Vollzeit beschäftigen kann, weil es ihn gar nicht Vollzeit beschäftigt.

Björn Richerzhagen: Na ja, also der Wirkungsgrad einer Vollzeitkraft, die gut ausgebildet ist, beide Lager vertreten kann und so weiter, die wird natürlich deutlich höher sein, aber das, was passiert, wenn ich mich gar nicht drum kümmere, wenn ich es gar nicht angehe, dann ist der Schaden natürlich viel grösser, insofern erstmal kleinschrittig anfangen und jetzt mal angenommen, es gäbe da einen Workflow-Analyst und der hat im ersten Projekt mal bewiesen, was da alles geht und so, der wird beim 2., 3., 4., 5. Projekt sicherlich eine gute Argumentationsgrundlage haben, warum man sich da eigentlich Full Time mit beschäftigen sollte und nicht irgendwie im Tagesgeschäft untergehen soll, wenn er nämlich bewiesen hat, dass dadurch mehr Nutzen für den Kunden entsteht und dadurch Kunden gewonnen wurde oder dass ein Kostenblock dadurch reduziert werden konnte und mehr Rendite dadurch entsteht. Ich glaube, man muss dann auch erstmal so ein bisschen beweisen, dass es funktioniert. Die Notwendigkeit, sich mit beiden Lagern zu beschäftigen, wird im ersten Projekt gleich auftauchen, da bin ich mir ziemlich sicher.

Götz Müller: Mhm ja. Jetzt vielleicht so als letzte Frage, du hast es schon angedeutet, ich möchte es zum Abschluss noch ein bisschen vertiefen und dann gerne auch einen kleinen Werbeblock nochmal für die Workflow Analytica, was können Unternehmen, egal welcher Größe, heute schon tun, wenn sie das Gefühl haben: Ja, wir stehen da vor einer gewissen Herausforderung, die uns in der Vergangenheit so nicht begegnet ist, wie gehen wir damit um? Du hast gesagt anfangen, aber manchmal ist dieses „Ja, wie fange ich denn an?“ schon die Frage.

Björn Richerzhagen: Also neben dem Anfangen ist auch immer ein Anruf bei mir eine gute Idee. Wir versuchen da ja zu unterstützen, wie es irgendwie nur geht. Wir haben so die Leitvision, dass wir eigentlich keine schlechten Prozesse mehr, weder den Mitarbeitern anbieten wollen noch, dass irgendwie Kunden durch schlechte Prozesse irgendwie leiden sollen. Also das ist so, da arbeiten wir dran bei unseren Kunden und, ja, wie gesagt auf viele Art und Weisen und der erste Schritt ist, wie du schon feststellst, nicht immer der leichteste. Das kommt natürlich ein bisschen auf die Gegebenheiten an. Bin ich groß, bin ich klein und so im Zweifel würden wir auch als Externe unterstützen oder wir qualifizieren jemanden, wie schon gesagt, wir haben ziemlich umfangreiches Schulungsangebot im Bereich des Prozessmanagements. Das wäre meine Startmöglichkeit, da vielleicht mal so eine Initialkompetenz einzupflanzen und von da aus, bin ich mir ziemlich sicher, werden sich Dinge einfach weiterentwickeln und dann muss man diese Entwicklung ein bisschen Raum geben.

Götz Müller: Ja, oder eben für diejenigen, die jetzt zuhören und das noch im Januar, Februar, jetzt muss ich aufpassen, dass ich nichts Falsches sage, aber das schreibe ich dann noch in die Notizen rein, die Workflow Analytica, auch wenn eine Podcast-Episode eher ein Evergreen ist, sag kurz, wann sie stattfindet, damit sich jemand gedanklich darauf einstellen kann und wenn er sagt: Hey, das war ein spannendes Thema, hat sich irgendwie wie der Berg angehört, vor dem ich gerade stehe, da könnte ich etwas erfahren.

Björn Richerzhagen: Ja, gerne. Also, wir werden uns im Jahr 2023 am 27. und 28. April in Berlin treffen zur Workflow Analytica. Die Domain workflow-analytica.eu gibt auch da Auskunft über weitere Informationen, was die Referenten angeht, was die Agenda angeht, was die eigentlich Location angeht. Das wird stattfinden im Amplifier in Berlin. Genau, das ist vielleicht so die 2023-Variante. Für diejenigen, die diese Podcast hören nach diesem Terminen. Wir werden auch im nächsten Jahr, wieder in Berlin, Ende April, Anfang Mai eine solche Veranstaltung durchführen, wenn es dieses Jahr nicht klappt, vielleicht im nächsten Jahr, aber ich glaube jeder, der erstens ein Bewusstsein dafür entwickeln möchte, welche Kompetenzen man da so zusammenbringen soll, ist gut aufgehoben bei uns auf der Veranstaltung. Und außerdem noch, wenn man mehr hören möchte, also irgendwie nur eine hübsche PowerPoint-Präsentationen sehen möchte, also wenn man Handfestes sofort anwendbares Knowhow einsammeln möchte, weil man ein konkretes Problem hat und einen Ansprechpartner dafür sucht oder so, der ist bei uns auch ganz gut aufgehoben. Die herzliche Einladung an alle Hörer. Ich freu mich, euch, Sie im April dann in Berlin zu sehen.

Götz Müller: Ich werde auf jeden Fall da noch ein paar Stichworte und Daten in die Notizen zur Episode reinnehmen, weil ja in der Regel, oder ganz oft man nicht in dem Augenblick, wo man das jetzt hört, nicht gleich alles aufschreiben kann und behalten kann. Björn, ich danke dir für deine Zeit, für das interessante Gespräch. Wie gesagt, diese Referenz zu dem Systemingenieur, wo ich jetzt gewisse Affinitäten habe, fand ich ganz treffend und du hast im Grunde, in meiner Wahrnehmung, ja auch bestätigt und eben eine Weiterentwicklung auch eines Berufsbildes.

Björn Richerzhagen: Ja. Genau. Ich freue mich, wenn Leute daran mitwirken wollen, das können sie auch auf der Workflow Analytica tun. Genau. Wir haben da so einen Kern gezündet oder so einen Initialfunken gesetzt. Und ja, alle, die den Bedarf erkennen und auch noch weitere Ideen haben, im Moment ist es erstmal nur eine Veranstaltung, vielleicht wird es ja tatsächlich mal ein richtig ausgebildetes Berufsbild mit IHK-Abschluss oder Uni-Abschluss oder so. Freue mich über jeden, der daran mitwirken will. Ansonsten, Götz, vielen Dank, dass ich da sein durfte.

Götz Müller: Das war die heutige Episode im Gespräch mit Björn Richerzhagen zum Thema Berufsbild Workflow-Analyst. Notizen und Links zur Episode finden Sie auf meiner Website unter dem Stichwort 306.

Wenn Ihnen die Folge gefallen hat, freue ich mich über Ihre Bewertung bei iTunes. Sie geben damit auch anderen Lean-Interessierten die Chance, den Podcast zu entdecken.

Ich bin Götz Müller und das war Kaizen to go. Vielen Dank fürs Zuhören und Ihr Interesse. Ich wünsche Ihnen eine gute Zeit bis zur nächsten Episode. Und denken Sie immer daran, bei allem was Sie tun oder lassen, das Leben ist viel zu kurz, um es mit Verschwendung zu verbringen.

Hinweis: Ich behalte mir vor, Kommentare zu löschen, die beleidigend sind oder nicht zum Thema gehören.