„Wir wollen jetzt agile Prozesse – starre Prozesse hatten wir lange genug!“ Solche oder so ähnliche Bemerkungen höre ich in meinen Kundengesprächen.
Alle größeren Unternehmen haben sich schon mit ihren Prozessen beschäftigt. Doch wurden die Erwartungen an das, was durch die Prozessaufnahme verändert wird, oft nicht erfüllt.
In diesem Artikel geht es um die Frage: „Agile Prozesse – starre Prozesse: Was ist besser?“ Du wirst nicht nur eine Antwort bekommen, sondern auch viele Infos zur Gestaltung von Prozessen und zum Zweck des Prozessmanagements selbst mitnehmen.
More...
Zunächst lass uns zusammen die Begriffe anschauen, damit wir ein gleiches Bild davon haben, worüber wir reden.
Die meisten Definitionen sprechen im Kern davon, dass ein Prozess aus Eingaben (Inputs), einer Reihe von Aktivitäten und den daraus resultierenden Ergebnissen (Outputs) besteht.
Dem kann ich grundsätzlich zustimmen. Ich denke jedoch, dass wir Prozesse spezifischer betrachten müssen. Beschrieben habe ich das im Artikel ‚Was ist ein Geschäftsprozess‘. (Link am Ende des Artikels)
Starre Prozesse
Um unserer Thematik näher zu kommen, wenden wir uns von den Definitionen ab und schauen uns an, wie sich das Prozessverständnis überhaupt entwickelt hat. Ich schildere Dir nun, wie das bei mir war:
Ich habe schon während meines BWL-Studiums in den frühen 90er-Jahren in der Organisationsberatung gearbeitet und Abläufe optimiert. Am Ende eines Beratungsprojektes wurde ein mindestens 10-seitiger, eng beschriebener Bericht übergeben. Prozessbeschreibungen kannte man so nicht.
Meine ersten Prozessbeschreibungen habe ich im Rahmen der Einführung von Qualitätsmanagement für eine Zertifizierung nach ISO 9001 erstellt.
QM-Prozesse
Die ISO 9001 wurde 1987 durch die International Organization for Standardization (ISO) veröffentlicht. Im Jahr 1994 gab es die erste Revision, 2000 wurde die Norm grundlegend überarbeitet. Sie trug dann den Zusatz „prozessorientiert“.
Ab 1993 wurden etwa 46.000 ISO 9001-Zertifikate vergeben, bis Ende 2000 waren es dann weltweit über 400.000 und heute über 1 Million. Genau konnte ich diese Zahlen nicht recherchieren, für einen Eindruck jedoch scheinen sie mir gut genug. Sie verdeutlichen, ab wann wir uns aus Sicht des Qualitätsmanagements mit Prozessen und deren Beschreibung beschäftigt haben.
Wie Du weißt, benötigen Firmen die Zertifizierung, um an Ausschreibungen teilnehmen zu können, weil ihre Kunden es verlangen oder es Voraussetzung für weitere technische Zulassungen ist.
Und genauso extrinsisch motiviert wurden die Prozesse auch damals aufgenommen und beschrieben. Eine bestandene Zertifizierung reichte aus. Ein weiterer Mehrwert wurde nicht angestrebt oder zumeist nur auf dem Papier formuliert und nicht in der Praxis gelebt.
Durch die Prozessbeschreibungen wurden erstmals Vorgaben für Abläufe gemacht, mehr oder weniger kleinteilig. Diese Vorgaben wurden mittels Audits auf Beachtung kontrolliert. Wie hilfreich oder sinnvoll diese Regelungen waren, stand nicht so im Fokus. Viel wichtiger war, die Zertifizierung zu erhalten.
So entstand oft Frust bei den Mitarbeiter:innen. Die Prozessbeschreibungen waren eine neue Art der Bevormundung, die zudem noch mehr Verwaltungsarbeit mit sich brachte und Zeit durch unangenehme Audits stahl.
Der auferlegte und oft übergenau erfüllte Mechanismus erschwerte Veränderungen in den Prozessbeschreibungen, so dass sie eher auf dem „kleinen Dienstweg“ gelebt wurden.
Für das Management waren Zertifizierungen meist von vornherein eine Pflichtübung. Doch selbst engagierte Unternehmer:innen konnte selten einen über die Zertifizierung hinaus gehenden Nutzen für die Effizienz und Effektivität des Betriebes erkennen.
Das Urteil war gefällt: Prozesse sind etwas Starres.
Wenden wir uns einem anderen Schwerpunkt der Prozessbetrachtung zu.
IT-Prozesse
„Auch ein flexibler Ablauf, wie in agilen Prozessen, bleibt ein Prozess, solange ein strukturelles Grundgerüst und ein gemeinsames Ziel vorhanden sind“, gibt mir ChatGPT auf Nachfrage aus.
Abläufe kann man über Informationstechnologie abbilden und teils automatisch laufen lassen. Ablaufdiagramme gibt es seit den 1920-iger Jahren, doch erst um die 90-iger Jahre setzte sich mit UML (Unified Modeling Language) und EPK (Ereignisgesteuerte Prozessketten) diese Art der Beschreibung von Abläufen durch.
Der Durchbruch konnte mit BPMN (Business Process Model and Notation) erzielt werden. Heute ist BPMN ein weltweit akzeptierter Standard für die Prozessmodellierung und verbindet Fachanwender mit IT-Experten, indem sie sowohl verständlich als auch technisch präzise ist.
Es ist jedoch immer noch so, dass der Fachanwender (der Mitarbeitende in einer Abteilung) den Kollegen aus der IT nicht versteht.
Prozesse, die für die Abarbeitung in einem informationstechnischen System vorgesehen sind, werden sehr kleinteilig beschrieben. Die Maschinen konnten nur das umsetzen, was programmiert wurde.
Insofern sind auch IT-Prozesse starre Prozesse, da sie nicht so einfach zu ändern sind und aus kleinteiligen, definierten Abfolgen bestehen.
AUF DEN PUNKT GEBRACHT
Mit starren Prozessen sind streng strukturierte, sequenzielle Abläufe gemeint, die einen engen, kleinteiligen Handlungsrahmen vorgeben.
Geschäftsprozesse
Doch was ist mit den Abläufen, die den Tagesalltag der Mitarbeitenden ausmachen? Das sind auch Prozesse. Ich nenne sie Geschäftsprozesse.
Diese Geschäftsprozesse haben nie die gleiche Aufmerksamkeit erlangt. Sie waren weder durch eine Zertifizierung gefordert noch für die Programmierung eines IT-Systems notwendig.
Das ist ein bisschen verrückt, denn genau die Geschäftsprozesse machen Unternehmen überhaupt lebensfähig.
Geschäftsprozesse sind die Basis, auf der die IT-Prozesse aufgesetzt werden. Sie sind das, worauf ein Qualitätsmanagement-System basiert. Sie sind das, was als Prozessliste für die DGSVO vorzuhalten sind, oder die Abläufe, die für den Datenschutz, Nachhaltigkeit, Arbeitsschutz usw. zu begutachten sind.
AUF DEN PUNKT GEBRACHT
Prozesse sind ein Synonym für die Gesamtheit aller Arbeitsabläufe. Sie lassen sich unter bestimmten Aspekten wie IT oder QM, aber auch in unterschiedlichen Detaillierungsgraden von ganz kleinteilig bis hin zur Übersicht über die Prozesslandschaft betrachten.
Diesen Fakt der unterschiedlichen Detaillierungsgrade sollten wir uns zusammen genauer anschauen. Hier finden wir die Antwort auf die Frage: „Wie erhalten wir agile Prozesse?“
Agile Prozesse
Zunächst möchte ich die Frage untersuchen, was agile Prozesse sind.
Die Antwort von ChatGPT: „Agile Prozesse sind flexibel und iterativ aufgebaut“. Es geht auch hier darum, dass in mehreren Prozessschritten ein Output erarbeitet wird.
Als Beispiel für agile Prozesse wird die Projektplanungsmethode SCRUM genannt. Bei diesem Vorgehen geht es um kurze Zyklen, die Sprints, die flexibel und iterativ aufgebaut sind und eine Anpassung an die Anforderungen enthalten.
Die Vorgaben für die Prozessausführung sind nicht so eng gefasst. Sie enthalten lediglich den Rahmen für die Arbeit: Sprint Planning, Daily, Sprint Review und Sprint Retrospective. Wie dieser Rahmen gefüllt wird, ist von der Aufgabenstellung und der Entscheidung, wie diese abgearbeitet wird, abhängig.
Wenn wir genauer hinschauen, kennen wir agile Prozesse nicht erst seit dem agilen Manifest und dem Aufstieg von SCRUM.
Wir kennen agile Prozesse einfach unter einem anderen Namen: Projektmanagement.
Dies enthält seit jeher schwach strukturierte Prozesse. Bauprojekte sind hierfür ein gutes Beispiel. Nach HOAI (Honorarordnung für Architekten und Ingenieure) sind sieben Phasen von der Grundlagenermittlung über die Entwurfsplanung bis hin zur Objektbetreuung und Dokumentation vorgegeben. Egal, wie was gebaut werden soll, egal wie die Anforderungen sind, alle Projektphasen sind zu durchlaufen.
Starre Prozesse wären insofern nur möglich, wenn die Anforderungen genau gleich wären. Was aber für Bauprojekte kaum realistisch ist, im Gegensatz zur Produktion eines Autos.
AUF DEN PUNKT GEBRACHT
Mit agilen Prozessen sind schwach strukturierte Prozesse gemeint, die nur einen groben Handlungsrahmen vorgeben.
Agile Prozesse oder starre Prozesse?
Einen Teil der Antwort hierauf finden wir in den unterschiedlichen Detaillierungsgraden, mit denen wir Prozesse betrachten können. Um diese genauer zu beschreiben, verwende ich das Giersberg®-Prozessmodell.
Sehr kleinteilige Prozesse mit engen Vorgaben liegen hier auf der Ebene 4. Diese kann bei Bedarf bzw. Notwendigkeit genutzt werden. Auf der Ebene 3 – dem eigentlichen Geschäftsprozess – jedoch gibt es diese engen Vorgaben nicht. Es gibt lediglich eine Betrachtung der Prozessschritte, die mal stärker strukturiert sind wie beispielsweise ‚Rechnungen erstellen‘ oder schwächer strukturiert sind wie ‚Marketingkampagne entwickeln‘.
Insofern ist nicht die Frage: „Was ist besser – agile Prozesse oder starre Prozesse?“. Es muss beides geben, je nach Gegebenheit.
FAZIT
Machen wir uns frei von dem Gedanken "agile Prozesse – starre Prozesse". Es sind eher stark oder schwach strukturierte Prozesse. Je nach Anforderung ist mal das eine und mal das andere gut.
Ich denke, die bessere Frage ist: „Wie gestalten wir Prozesse?“. Genau dies scheint mit dem Wunsch nach agilen Prozessen verbunden zu sein.
Wir können verbessern:
- wie wir Prozesse darstellen,
- wie kleinteilig Vorgaben gemacht und
- wie und von wem Prozesse verändert werden.
Hier sollten wir in eine agile Arbeitsweise im Sinne einer iterativen, immerwährenden Verbesserungsschleife kommen.
