Das was da beschrieben wird deckt im Wesentlichen große Teile meiner Arbeit ab.
1) Workflowmanagement
2) Workflow Optimierung (Durchlaufzeiten, Latenzzeiten, Responsezeiten, Ergebnis Qualität, Dokumentation - Anbindung interner Schnittstellen)
soweit wie auch im Artikel angerissen -
aber
ohne
3)Arbeitsplatzworkflow Optimierung (Requirements engineering für die UI, Vertieftes Verständnis - aller Abläufe am Arbeitsplatz, lernen der vorhanden Skills und Vorlieben und Anpassung der Softwarelösungen auf die Gruppe von Menschen, die diesem Workflow betreiben)
ist die ganze Arbeit für die Katz!
(Ich hatte eine ERP Einführung (not my business!) in einer Filiale mitbekommen, da haben die Menschen vor Ort im Endeffekt nur den Labelworkflow für die Pakete genutzt - und den Rest als zu schwierig und umständlich abgelehnt.... 2 Jahre später war der Laden dicht.)
Immer, wenn mehr oder weniger analoge mit Office/Excel o.ä. Dreck "gestaltete" Workflows optimiert werden - dann müssen meiner Erfahrung nach mehrere Runden (idealerweise ohne Tooling Änderung) gefahren werden. Denn die Menschen können meist nur schrittweise mitgenommen werden - und der Workflowoptimierungsspezialist ist nicht Gott und hat immer alles auf Anhieb richtig verstanden und/oder richtig umgesetzt. Zudem lernen die Teams im Workflow nach und nach die Fähigkeiten Ihrer Werkzeuge kennen und hoffentlich auch schätzen - und kommen dann irgendwann von selbst auf den Gedanken, dass der Batchbegleitzettel für dessen Erhalt sie im Requirements engineering Prozess gekämpft haben im neuen System so wichtig ist, wie das 5te Rad am Wagen.... (Natürlich wird der zuerst implementiert - aber so parametrisiert, dass man Ihn abschalten kann. (Was dann erfahrungsgemäß auch die Menschen vor Ort irgendwann anfordern - oder noch besser - wo möglich - selbst umstellen.))
Natürlich ist die erste Version meist noch ausbaufähig - aber das Verständnis der Möglichkeiten der Werkzeuge ist es auch. Natürlich wird es mit einer Version 1.0 nicht alles besser und schneller und schöner. Aber, wenn es nach 1 Jahr Verbesserungen nicht flutscht, dann hat man (Management && Optimierer && Workflowbearbeiter) Scheiße gebaut!
Ich arbeite meist mit gut ausgebildeten Spezialisten, die spezielle Spezialworkflows mit teuren exotischen Geräten abarbeiten. Die verstehen viel mehr von Ihren (auch Kunden)Requirements als ich. Daher höre ich zu und arbeite gerne interaktiv agil mit denen (was die manchmal nervt.).
Wenn ich die jetzt wie im Artikel beschrieben nur formal geskillt - und offiziell eingebunden und mit Gefrierfleischorden zur angeblichen KI-Fähigkeit dekorierte Menschen ansprechen dürfte und denen zuhören könnte - dann wäre das imho mehr als kontraproduktiv - die Vorschläge aus dem Artikel grenzen in meinen Augen an Sabotage.
Meiner Erfahrung nach mit öffentlichen Dienst Workflows im öffentlichen Dienst werden - diese möglicherweise in ähnlicher Art und Weise erstellt und gepflegt, wie es der Artikel vorgibt. (Ich habe nirgendwo sonst so ineffiziente -, so Personalaufwändige -, so Personalskill verachtende -, so Kundenunfreundliche Workflows gesehen, die von dem anwesenden Personal mit unglaublicher Gleichmut mit Leben gefüllt werden, wie dort.)
Kurz Softwareentwicklung und Personalentwicklung entlang eines Workflows sind m.E. nach immer einheitlich zu betrachten (oder man baut grade mächtig Scheiße).