Organisationsgestalter.de: 2013

1. Prozessmanagement

1.1 Problemstellung im Prozessmanagement

Prozessmanagement als Werkzeug in der Gestaltung und Optimierung der Unternehmensabläufe ist schwierig und herausfordernd. Daran wird eine neue Methodik wenig ändern. Denn das Wesen des Prozessmanagements ist ein bewusster Umgang mit Menschen in Organisationen, Innovation und Kreativität. Oft scheitern aber derartige Projekte oder liefern Ergebnisse, die weder die eigenen Mitarbeiter zufrieden stellen noch die angestrebten wirtschaftlichen Ziele erreichen lassen, da sie dabei oftmals einen Kreislauf selbstverstärkender (amplifierender) Rückkopplungen in Gang setzen (vgl. Senge, 2003, S. 120).

Der Automatisierungsgrad im innerbetrieblichen wie im zwischenbetrieblichen Geschäftsprozessmanagement lässt - speziell in KMU-Betrieben - immer noch zu wünschen übrig. Das Kernproblem liegt dabei oft in heterogenen Darstellungen von verschiedenen Perspektiven und von verschiedenen Phasen im Lebenszyklus von Geschäftsprozessen. Typische Beispiele sind oftmals inkompatible Repräsentationen der Intra-Perspektiven zwischen Mitarbeitern und Entscheidungsträgern und Inter-Perspektiven zwischen dem Unternehmen und seinen Anspruchsgruppen (Kunden, Lieferanten, Anrainern) oder der Lücke zwischen normativer Modellierung für Compliance-Zwecke einerseits und realen Prozessausführungen andererseits (vgl. Brandstätter/Gölzner/Siems, 2006, S. 25).

Derartige Projekte zur Einführung von Prozess- aber auch Qualitätsmanagement sowie die Gestaltung einer prozessorientierten Unternehmung führen grundsätzlich zu einer Änderung in der Unternehmensorganisation, sind also ein stückweit auch Organisationsveränderungsprojekte. Sie sind auch oftmals mit einer hohen Misserfolgsrate ausgezeichnet. Die Begründung liegt lt. Aussage von Becker/Kugeler/Rosemann (vgl. 2005, S. 35) neben:

überzogenen Erwartungshaltungen der Zielsetzung,
in den aufwändigen und dadurch oftmals mangelhaft durchgeführten Methoden für die Implementierung und laufenden Anpassung von Prozessmanagement in den Unternehmensorganisationen,
dem erhöhten Dokumentationsbedarf zur Sicherstellung der Methode
und der dadurch ständig notwendigen, aber leider oftmals nicht erfolgten Unterweisung der Mitarbeiter.

Auch die generelle Beharrung bei Veränderungen in Form von Ablehnung und Angst schwingen in derartigen Vorhaben mit (Boos/Heitger, 2004).

1.2 Nutzen von agilen Methoden im Prozessmanagement

Projekte im Bereich des Prozessmanagements weisen in Bezug auf die langjährige Erfahrung des Autors deswegen eine suboptimale Arbeitsorganisation auf, da oftmals frühzeitig versucht wird alle Eventualitäten und Arbeitsdetails zu definieren, als fixe Größe zu betrachten und als unumstößlichen Plan auszuführen. Gleichzeitig erhält ein Projektteam in derartigen Projekten erst spät die Rückmeldung über den tatsächlichen Fortschritt, wenn der Prozess fertig in der Organisation implementiert wird. Ein Idealzustand könnte daher sein, alle Arbeiten von der Konzeption bis zur Implementierung in die Organisation innerhalb mehrerer iterativer Schleifen auszuführen. So könnte das Prozessteam bereits nach Wochen Rückmeldungen über Fortschritt oder etwaige Probleme und Hindernisse bekommen. Die Planung könnte daher auf dem tatsächlichen Fortschritt des Prozessprojektes basieren. Eine mögliche Vorgehensweise ist in Abb. 1 dargestellt.

2. Die Methode Scribble im Überblick

2.1 Grundsätzlich

Scribble ist im Moment noch eine von wenigen existierenden Methoden des agilen Prozessmanagements und stellt in ihrer Form ein organisatorisches Rahmenwerk für die Implementierung und die lfd. Adaptierung von Prozessmanagement in Unternehmen dar. Sie basiert auf einer iterativen Vorgehensweise und ist mit einfachen Regeln, Rollen und Artefakten ausgestattet.

Scribble wurde in den Jahren 2008 und 2009 am Salzburger Institut für Management (IfM) in Zusammanarbeit mit dem Studiengang Betriebswirtschaft an der Fachhochschule in Salzburg entwickelt. Der Name "Scribble" weist einerseits auf die Visualisierungsform dieser Methode hin, die in ihrer Darstellungsform und Gestaltungsart der eines Skizzenblocks ähnelt und beschreibt andererseits auch ein stückweit die iterative Vorgehehensweise (vom Groben zum Detaillierten), die dieser Methode zugrunde liegt. Das Ziel der Methodenentwickler war es, ein simples Modell für die Implementierung und die lfd. Adaptierung von Unternehmensprozessen bzw. des gesamten Prozessmanagements zu entwerfen. Es sollte darüber hinaus einen hohen Mehrwert für alle Beteiligte, frei von jeglicher Verschwendung durch unproduktive Tätigkeiten (z.B. aufwändige Dokumentationen in der Initialpahse sowie bei Änderungen in der Betriebsphase) schaffen (Womack/Jones, 1996).

2.2 Das Phasenmodell von Scribble

In der zeitlichen Betrachtung der Projektabwicklung, orientiert sich Scribble an der agilen Projektmanagementmethode Scrum, mit seiner iterativen Vorgehensweise und seiner Notwendigkeit, nach jedem Sprint schon fertig auslieferbare Teilergebnisse (in Scribble, funktionierende Teilprozesse) auszuliefern. Als Visualiserungsform der Prozesse, sowohl im Überblick einer Prozesslandkarte, wie auch in jener zur Ausgestaltung der Prozesse werden die Tätigkeiten, ähnlich in Form eines Storyboards skizzenhaft gezeichnet. Sie können aber pro Tätigkeitsschritt auch nur fotografiert und kurz beschrieben werden. Diese einfache und grafische Ausgestaltung der Prozesse dient in der Gestaltungsphase von Scribble zur Schaffung eines gemeinsamen Prozessverständnisses, sowie als Vorlage für die Simulation und das Training der jeweilgen Prozesschritte (Szenen des Storyboards. In der Betriebsphase von Scribble dienen diese Storyboards als Arbeits- bzw. Verfahrensanweisungen und erfüllen damit die Minimalanforderungen an eine Dokumentation im Rahmen eines modernen Prozessmanagements.

Wenn man nun ein Vorhaben in Scribble in seiner zeitlichen Abfolge betrachtet, so durchläuft es grundsätzlich drei definierte Phasen:

Die Initialphase - ist die Phase, ausgehend vom Bedarf eines derartigen Vorhabens über die Zusammenstellung des Projektteams und Prozessauswahl bis hin zur Entwicklung der Prozessvision.
Gestaltungsphase - eine projektbezogene Prozessgestaltung, inklusive Training der fertigen Abläufe mittels Simulationen. Die Visualisierungsform, die der Methode auch den Namen gegeben hat, lehnt sich an der Gestaltung von Filmproduktionen mittels Storyboards an. Genauso wie in der Filmproduktion, wo die einzelnen Szenen eines Spielfilms in Szenen skizzenhaft abgebildet werden, werden in Scribble die Tätigkeiten eines Prozesses als „Szenenausschnitte“ visualisiert. Notwendige Verfahrensanweisungen pro Prozesschritt (zB Anweisung für die Patientendatenerfassung im IT-System für die Patientenaufnahme) werden in der „Tonsspur“ zur jeweilgen „Szene“ beschrieben.
Betriebsphase - Start des Prozesses (der Prozesse) im Echtbetrieb. Der in Scribble visualisierte Prozess in Form eines Storyboards, wird in der Betriebsphase als eine „Bedienungsanleitung“ (Arbeits- und Verfahrensanweisung) sowie als Nachschlagwerk für den Prozess im Tagesgeschäft verwendet und kann im Bedarfsfall simpel adaptiert werden. Die Anpassung eines Prozesses geht in Form einer einfachen Einfügung oder Änderung von „Szenen“ im Storyboard des Prozessses vonstatten.

In der Gestaltungsphase eines Vorhaben in Scribble, werden sogenannte Sprints durchlaufen. Diese impliziten wiederkehrenden, simplen Abläufe können im Unternehmen grundsätzlich schnell und einfach angewendet werden. Die Arbeitsweise und das Ergebnis eines Sprints werden regelmäßig begutachtet und angepasst (neu priorisiert und allfällig ergänzt). Am Ende jedes einzelnen Sprints, steht ein grafisch fertig ausformulierter und mit allen Beteiligten tranierter Teilprozess (mitsamt der allfällig verwendeten Anwendungssoftware, Ressourcen und Werkzeuge) zur Verfügung. Die Sprintergebnisse begutachtet der Process Manager und bestimmt damit den Fertigstellungsgrad der erzielten Ergebnisse (nur 100% fertige ausformulierte und tranierte Teilprozesse werden dabei akzeptiert). Das Team reflektiert über seine Zusammenarbeit und Anwendung der Regeln. So lernt das Projektteam eines Vorhabens von Sprint zu Sprint dazu und kann sich kontinuierlich verbessern. Ein weiterer Aspekt dieser Methode liegt in der zeitlichen Kontinuität des Sprints mit der darin ausgeprägten Termintreue (timeboxing) begründet.

Scribble schreibt nicht detailliert fest, was wann zu tun ist, gibt auch keine Anweisung wie die zu gestaltende Auf- und Ablauforganisation im Unternehmen auszusehen hat und welche Software als Unterstützung der gestalteten Prozesse zu verwenden ist. Daher beinhaltet die Methode auch keine diesbezüglichen Verfahrensanweisungen oder Prozessschablonen.

Die Träger des Prozesswissens in der Methode des agilen Prozessmanagements sind kollektiv die Personen der Projektteams, die in der Gestaltungsphase die Prozesse entwickeln und testen. Nur ein geringer Anteil des Prozesswissens wird zusätzlich in Form einer Minimaldokumentation stichwortartig erfasst. Daher kann die vorliegende Methode als Vertreter einer modernen personenorientierten Methode im Vergleich zur dokumentenorientierten Methode des traditionellen Prozessmanagements bezeichnet werden. Ein Überblick über die Methode des agilen Prozessmanagements verschafft die Abbildung 1.

Abb. 1: Agiles Prozessmanagement, angelehnt an Wirdemann (2009), Gloger, (2008) und Pichler (2008)

2.3 Die Rollen

2.3.1 Grundsätzlich

In Anlehnung an die Aussagen von Pichler (2008, S. 9ff.) und Gloger (2008, S. 71ff.) wo für Entwicklungsprojekte in der Methodik Scrum eine Trennung zwischen den Rollen des Produkt- und des Projektmanagements (Product Owner und Scrum Master) herbeigeführt wird, ist auch in Scribble eine Trennung zwischen der operativ verantwortlichen Person eines Prozess- und/oder Qualitätsmanagers und die eines Change Agents (vgl. Robbins, 2001, S. 631) zu unterscheiden.

Im agilen Prozessmanagement sind - in enger Anlehnung an Scrum - drei Rollen definiert: Process Manager, Team und Change Master. Alle drei Rollen sollten adäquat besetzt sein und eng zusammenarbeiten um ein Prozessprojekt in kuzer Zeit erfolgreich umzusetzen. In Anlehnung an das Agile Manifest (vgl. Beck et al., 2001), indem die Wichtigkeit der Individuen und Interaktionen höher als Prozesse, Werkzeuge und Dokumentationen verankert sind, soll daher im agilen Prozessmanagement wieder mehr dem Menschen ein neuer Freiraum gegeben werden. Die drei Rollen weisen nun folgende Verantwortlichkeiten auf:

Der Process Manager entscheidet, welche Anforderungen eines oder mehrerer Prozesse umgesetzt und in der Organisation verankert und/oder optimiert werden soll. Er definiert gemeinsam mit dem Topmanagement die Vision der nachfolgenden Aufgabenstellung. Er erstellt eine Anforderungsliste in Form eines Process Backlogs. Darin werden die Anforderungen grob beschrieben und anschliessend priorisiert.
Das Team - bestehend, in Anlehnung an die Aussagen von Witte (vgl. 1973, S. 17f.), Witte/Hauschildt/Grün (vgl. 1989, S. 142ff.), Hauschildt/Chakrabarti (vgl. 1988, S. 379ff.), Hauschildt/Gemünden/Witte (vgl. 1999) und Kostka/Mönch (vgl. 2001, S. 16ff.) - sollte daher aus einer Kombination von Machtpromotoren, Fach- bzw. Prozesspromotoren und Machtdestruktoren bestehen, organisiert seine Arbeiten selbstständig, entscheidet selbsttätig wie viele Anforderungen des Process Backlogs es innerhalb eines Zeitabschnitts (Sprint) verlässlich in ein Prozessinkrement umsetzen kann und führt die Arbeiten aus.
Der Change Master hilft allen Beteiligten, agiles Prozessmanagement richtig anzuwenden und unterstützt das Team dabei, seine Produktivität kontinuierlich zu verbessern. Die Bezeichnung Change Master ist eine Kombination aus den Bezeichnungen Change Agent und Scrum Master, leitet sich einerseits aus der Rolle eines Change Agents für Organisationsänderungsprojekte und andererseits aus der Rolle des abgeleiteten „Zeremonienmeisters“ in agilen Projekten in Form des Scrum Masters ab.

2.3.2 Der Process Manager

Der agile Process Manager repräsentiert die Stakeholder des Unternehmens und somit auch deren Bedürfnisse. Er steuert das Prozessprojekt indem er fachliche Vorgaben grob in einem Process Backlog definiert und mit dem Team über den gesamten Projektverlauf eng zusammenarbeitet. Die Rolle soll weit mehr als die eines traditionellen Prozessmanagers sein. Der Prozess Manager nimmt im agilen Prozessmanagement eine zentrale Stellung ein. Er beeinflusst den Erfolg eines Prozessprojektes entscheidend und ist für diesen verantwortlich. Der Unterschied zu den traditionellen Arbeitspraktiken ist dabei:

Es werden keine Analysen der bestehenden Prozessorganisation vorgenommen.
Die Anforderungen an eine neue oder optimierte Prozessorganisation werden nicht mehr komplett aufgeschrieben, eingefroren und an die Umsetzung übergeben, sondern nur mehr grob umrissen und priorisiert. Die dabei wichtigsten Anforderungen an die neue Prozessorganisation (Priorität 1 Anforderungen) werden detaillierter in einem Process Backlog definiert.
Die Projektumsetzung in Form der Prozessimplementierung wird, wie aus Sicht des Autors selbst mehrfach erlebt, nicht mehr an einen eigenen Projektleiter delegiert.
Prozessverantwortliche im Sinne des traditionellen Prozessmanagements werden in Scribble nicht besetzt, da die Verantwortung und die Umsetzung der Prozessaufgabe in der Gestaltungsphase als auch in der Betriebsphase (von dem dafür gesondert nominierten Team gesamtheitlich wahrgenommen werden soll.

Der Process Manager in Scribble ist für das Erfassen der Anforderungen an den Prozess (die Prozesse) verantwortlich. Dies beinhaltet das Erstellen der Process Vision gemeinsam mit dem Topmanagement und des eigenständigen Verfassens des Process Backlogs. Der Process Manager bearbeitet das Process Backlog kontinuierlich. Er fügt neue Anforderungen in Form von Process Stories ein, verfeinert und priorisiert Anforderungen. Damit der Process Manager in Scribble die Bedürfnisse der betroffenen Mitarbeiter (Mitarbeiter der neuen bzw. optimierten Prozessorganisation) beschreiben und dem Team kommunizieren kann, muss er diese genau kennen. Eine enge und regelmässige Abstimmung zwischen Mitarbeitern und dem Team sowie anderen Interessensvertretern ist hierzu notwendig. Diese kann z.B. in Form gemeinsamer Workshops und regelmässiger Meetings (Daily Process Meetings) realisiert werden.

Die strategische Zielsetzung des Process Managers ist das erfolgreiche Erreichen des Projektergebnisses. Damit ist er für den Erfolg dieses Vorhabens, mit dem Ziel einer Verbesserung der Ablauforganisation eines Unternehmens, gesamtverantwortlich. Anders als in traditionellen Prozessorganisationen delegiert er die Leistung nicht an einen eigenen Projektmanager, Prozessverantwortlichen oder Abteilungsleiter. Er führt die Projektmanagementaufgaben selbst aus indem er die Entwicklung, die Formulierung von Anforderungen und deren Priorisierung im Process Backlog bestimmt. Er hilft in enger Abstimmung mit dem Team, die Anforderungen der betroffenen Mitarbeiter zu verstehen und diese in Prozessinkrementen umzusetzen, indem er die Beteiligten nicht nur mit detaillierten Anforderungen versorgt, sondern auch die entstanden Arbeitsergebnisse (fertig getestete oder simulierte Teilprozesse) überprüft. Der Process Manager in agilen Prozessprojekten übt daher eine Brückenfunktion zwischen betroffenen Mitarbeitern in der Prozessorganisation und des im Prozessprojekt arbeitenden Teams aus.

Zu den operativen Aufgaben des Process Managers zählen die Detaillierung und Verfeinerung der im nächsten Sprint umzusetzenden Anforderungen, in Form von Process Stories formuliert, die Teilnahme an allen Daily Process Meetings sowie die Überprüfung und Abnahme der in einem Sprint erzielten Arbeitsergebnisse. Der Process Manager sollte ausreichend Zeit mit dem Team verbringen und zu festen Zeiten jeden Tag mindestens eine Stunde Zeit mit dem Team zusammenarbeiten, beispielhaft im Anschluss an die Daily Process Meetings. So können Fragen schnell geklärt und Feedback zu Arbeitsergebnissen im laufenden Sprint geben werden (vgl. Schwaber/Beedle, 2001).

Wenn es schwierig sein sollte die explizite Rolle des Process Managers festzulegen, kann sie durchaus vom Leiter des Qualitätsmanagements, eines bestehenden Prozessverantwortlichen oder durch eine sonstige Person in Leitungsfunktion - auch als Teilzeitfunktion - ausgeübt werden.

2.3.3 Das Team

Ein Prozessteam führt alle Aufgaben zur Umsetzung der Prozessanforderungen in fertige Prozessinkremente aus. Das Team ist dabei interdisziplinär aufgebaut und sollte grundsätzlich aus den betroffenen Mitarbeitern der jeweiligen Abteilungen, allfällig Kunden und Lieferanten bestehen. Alle arbeiten eng zusammen und erstellen die Arbeitsergebnisse gemeinschaftlich.

Entscheidend für den Erfolg ist dabei sicherlich die Zusammensetzung des Teams. Angelehnt an die Aussagen von Witte (vgl. 1973, S. 17f.), Witte/Hauschildt/Grün (vgl. 1989, S. 142ff.), Hauschildt/Chakrabarti (vgl. 1988, S. 379ff.), Hauschildt/Gemünden/Witte (vgl. 1999) und Kostka/Mönch (vgl. 2001, S. 16ff.), ist dabei auf die sorgfältige Auswahl der Schlüsselpersonen Wert zulegen. Bei Veränderungsprojekten sollten daher auch für die Auswahl von Schlüsselpersonen in Projekten des agilen Prozessmanagements im Vorfeld folgende Personengruppen identifiziert werden:

Machtpromotoren - Wo sind die „Opinion Leaders“, die für die Idee der weiteren Veränderungsschritte gewonnen werden müssen, wenn die Mehrheit der Belegschaft mitziehen soll?
Fach- und Prozesspromotoren - Wer hat das Zeug dazu, den Veränderungsprozess - oder wichtige Arbeitsschritte in diesem Prozess - zu leiten?
Machtdestruktoren - Wo sind die „Opinion Leaders“, die für die Idee der weiteren Veränderungsschritte hinderlich werden können?
Fach- und Prozessdestruktoren - Wer hat das Zeug dazu, den Veränderungsprozess - oder wichtige Arbeitsschritte in diesem Prozess - zu blockieren?

Um sicherzustellen dass die richtigen Mitarbeiter Teil des Teams sind, kann es sinnvoll sein, die Mitarbeiter mitbestimmen zu lassen (vgl. Schwaber, 2007). In Anlehnung an Scrum ermutigte beispielweise die Firma Google Inc. in einem Softwareprojekt die Software-Entwickler, sich für interessante Projekte selbst zu nominieren (vgl. Poppendieck/Poppendieck, 2006). Dies ist eine mögliche Variante von Selbstselektion: Mitarbeiter können beeinflussen, an welchen Projekten sie mitarbeiten, anstelle der traditionellen Ressourcen-basierten Projektzuweisung.

Ein Team das nach der Methode des agilen Prozessmanagements Scribble agiert, soll bevollmächtigt sein. Das bedeutet, dass das Team alleine entscheidet, wie viele Anforderungen es innerhalb des nächsten Sprints von den Anforderungen zu einem fertigen Prozessinkrement umsetzen wird. Zudem entscheidet es, welche Arbeitschritte notwendig sind um die Anforderungen umzusetzen und wie es seine Arbeit organisiert. Ein bevollmächtigtes Team muss in der Lage sein, auch nein zu verschiedenen Anforderungen sagen zu können. Diese Bevollmächtigung erfordert das Vertrauen sowohl vom Topmanagement als auch vom Process Manager in die eigenen Fähigkeiten des Teams.

Traditionelles Management trennt die Übernahme von Verantwortung und die Ausführung der Arbeit (vgl. Ward, 2007). Wäre in Projekten des agilen Prozesssmanagements beispielhaft mit Scribble ausgeführt, dieser Umstand in der Rolle des Process Managers manifestiert, würde das die Isolierung des Process Managers vom eigentlichen Prozessgeschehen bedeuten. In dieser Situation wären die Vorgesetzten gezwungen, durch Lesen der Berichte zu den relevanten Informationen zu gelangen und dabei gefilterte Entscheidungsgrundlagen für die weitere Vorgehensweisen zu erlangen. Resultierend aus der traditionellen Vorgehensweise würden dabei die Mitarbeiter oftmals nicht die volle Verantwortung für diese Handlungen und Konsequenzen übernehmen.

Bevollmächtigung im Sinne des agilen Prozessmanagements wie zB in Scribble, hingegen vereint Ursache und Wirkung. Das Team wählt die umzusetzenden Anforderungen aus dem Process Backlog selbsttätig für die Umsetzung des nachfolgenden Sprints aus und steht somit in der Pflicht, diese Auswahl zuverlässig (in Funktion und Zeit) in ein Prozessinkrement umzusetzen. Durch das Zusammenwirken von kurzen Arbeitszyklen und regelmässigem Feedback des Process Managers, lernt das Team seine Verpflichtungen immer besser zu erfüllen. Selbstorganisierte bzw. autonome Prozessteams benötigen somit keinen Teamleader oder Manager. Folgende Artefakte bilden dabei die Basis für diese Selbstorganisation: Sprint Backlog, Sprint Burndown Chart und die Daily Process Meetings. Prozessteams in agilen Prozessprojekten sollten neben einem gemeinsamen Arbeitsplatz, der eine enge Kommunikation und Zusammenarbeit ermöglicht, die Möglichkeit gegeben werden, alle wichtigen Informationen in Form von Artefakten sichtbar für alle Beteiligten zu verwalten.

2.3.4 Change Master

Die Aufgaben des Change Masters lassen sich in fünf Teilbereiche zerlegen:

Implementieren des agilen Prozessmanagements in Form von Scribble in die Unternehmensorganisation.
Die Arbeit mit dem Team.
Das Abarbeiten von Hindernissen, die in der täglichen Arbeit des Teams entstehen.
Die Arbeit mit dem Process Manager.
Die Steigerung der Teamproduktivität.

In der Aufgabe des Implementierens agiert er wie von Robbins (2001, S. 631ff.) in herkömmlichen Organisationsänderungsprojekten beschrieben, für das gesamte Projekt in der Rolle des Change Agents. Dadurch bereitet er in der Organisation den „Boden für Änderungen“ vor.

In der Aufgabe des Teamplayers agiert er als Coach des Teams. Er hat die Aufgabe, dem Team in seinen Aufgaben zu helfen und die Methode von Scribble anzuwenden. Er sollte auch dafür verantwortlich sein, dass das Prozessteam und der Process Manager die Regeln des agilen Prozessmanagements einhalten - sozusagen als Zeremonienmeister. Für folgende Einhaltung, der aus dem agilen Projektmanagement Scrum abgeleiteten Regeln für Scribble, ist der Change Master verantwortlich:

Abwicklung der Sprint Planungs Meetings
Moderation der Daily Process Meetings (maximal 15-minütiger Erfahrungsaustausch zwischen dem Prozessteam),
Abwicklung von Sprint Retrospective Meetings.

In der Aufgabe zur Beseitigung von Hindernissen liefert das Team in seinen täglichen Daily Process Meetings Antworten auf die „Hindernissfrage“: Was hat das Team am Vortag behindert oder könnte es am aktuellen Tag behindern? Der Change Master erstellt daraus ein täglich aktualisiertes „Impediment Chart“ und arbeitet dieses kontinuierlich ab.

In der Zusammenarbeit kümmert er sich darum, dass nicht nur das Team, sondern auch der Process Manager die Besonderheiten von Scribble versteht. Er hilft ihm dabei zusätzlich in der Gestaltung des Process Backlogs.

Grundsätzlich steht der Change Master in Anlehnung an Scrum ausserhalb der Vorgabe: „Der Scrum Master ist nur seinem Team und der Produktivität verpflichtet“ (vgl. Gloger, 2008, S. 111f.). Er sollte verändern indem er mit Scribble die Art und Weise einführt, wie in einer agilen Prozessorganisation gearbeitet werden soll und kann sich damit nicht immer an die geschriebenen und ungeschriebenen Regeln seiner Organisation halten. Er nimmt seine Berechtigung für seine Handlung aus dem höheren, von allen anerkannten Zweck: Die Produktivsteigerung des Teams und die Verbesserung der Qualität im Arbeiten (vgl. Gloger, 2008, S. 111). Er sollte sein Team nicht deshalb für ein agiles Prozessmanagement gewinnen, weil er es neuartig und interessant findet, sondern weil die Produktivität seines Teams und die Qualität der Unternehmensorganisation und seiner Produkte bzw. Dienstleistungen erhöhen will. Daraus kann aus Sicht des Autors für den Change Master das legitime Recht abgeleitet werden, unbequeme Massnahmen einzuleiten, Regeln zu verletzten und Konflikte mit anderen Organisationseinheiten auszulösen. Wobei auch hier nicht gelten sollte: „Der Zweck heiligt die Mittel“.

In Anlehnung an Scrum darf die Produktivität anderseits auch nicht auf Kosten des Teams erzielt werden. Die Steigerung wird am Einsatz von agilem Projektmanagement ... [vergleichbar für agiles Prozessmanagement] (Anm. d. Verf.) ... ein natürliches Resultat sein, wenn die Abläufe innerhalb des Teams klarer und effektiver werden. Die Steigerung der Produktivität darf nicht durch ständige Mehrarbeit, Druck oder gar Anweisungen von oben erzielt werden. (vgl. Gloger, 2008, S. 112; Pichler, 2008, S. 19ff.; Oesterreich/Weiss, 2008, S. 42ff.).

In den meisten Fällen wird der Change Master aus den Reihen des Teams gebildet werden. Die Rolle des Change Masters wandelt sich im Laufe eines Prozessprojektes. In der ersten Phase eines agilen Prozessprojektes sollte der Change Master eine Vollzeittätigkeit sein. Die Wahrnehmung seiner Aufgaben ist dabei zeitintensiv. Er agiert dabei als Change Agent, dessen Aufgaben im Heranführen des gesamten Teams an die notwendige Veränderung liegt. Ist die Methodik im gesamten Team etabliert, wird die Rolle des Change Masters zum Teilzeitjob. Er kann dann auch Aufgaben zur Erreichung der Sprintziele übernehmen. Trotzdem ist er als Change Master bis zum Abschluss des Projektes für die Einhaltung der Regeln zuständig.

2.4 Die Artefakte

In der nachfolgenden Anwendungsbeschreibung von Scribble, werden in Ableitung der Projektmanagementmethode Scrum, eingeführte Begriffe für idente Artefakte beibehalten oder wenn, dann nur geringfügig geändert. Daher werden die einzelnen Umsetzungsschritte von Erstellung des Process Backlogs, über die Sprintplanung und Sprintumsetzung bis hin zu Process Review und Retrospective in diesem Abschnitt nur mehr grob beschrieben.

Folgenden Artefakte werden in der Methode Scribble verwendet:

Process Backlog,
Sprint,
Sprint Backlog,
Burndown Charts,
Impediment List.

Der Process Backlog analog zum Product Backlog in Scrum, beschreibt das Anforderungsprofil des gesamten Prozessprojektes mit seinen Detailanforderungen (Items) in einer Kurzform. Diese - als priorisierte Tabelle von einzelnen Process Stories ausgeführt - wird ständig vom Process Owner, in Abstimmung mit den Beteiligten adaptiert. Jede Anforderung wird in Form von Process Stories beschrieben und mit jeweils einem Abnahmekriterium versehen. Der generische Syntax einer Process Story lautet:

In der Rolle (eines Prozesskunden, zB als Produktionsleiter)
benötige ich folgende Funktionalität (zB einen validen Produktionsauftrag)
damit ich folgende Zielsetzung (zeitgerechte und einhetiliche Herstellung eines Produktes nach folgenden Qualitätskriterien) erreiche.

So wie in Scrum werden auch im agilen Prozessmanagement alle Aktivitäten in Form von Sprints umgesetzt. Unter Sprints werden dabei Arbeitszyklen mit einer fixen Dauer (z.B. 30 Tage) verstanden, in denen das Team ungestört von Einflüssen aus dem Projektumfeld, aus den Anforderungen fertige Prozesse formt, trainiert, simuliert sowie dokumentiert.

Der Sprint Backlog repräsentiert analog zum Sprint Backlog in Scrum, das Anforderungsprofil eines aktuellen Sprints fixer Dauer (z.B. 30 Tagen), zumeist in Tabellenform verwaltet. In der Sprintplanung werden dabei die hochpriorisierten Proces Backlog Items (Process Stories) in den Sprint Backlog übernommen und weiter in einzelnen Tätigkeiten (Tasks) unterteilt. Die dann folgende Aufgabenzuordnung durch die beteiligten Personen wird von ihnen autonom vorgenommen. Es gibt dabei keine verordneten Anweisungen.

Das Burndown Chart bietet einen Überblick über die noch offenen Aktivitäten (Tasks), die täglich geschätzt und entsprechend in diesem Diagramm abgetragen werden. Am Ende eines Sprints sollten laut der Planung alle Aktivitäten zu 100% fertig und damit keines noch offen sein.

Das Impediment Chart ist als Hindernisliste analog zu Scrum eine Auflistung mit Problemen, die während eines Sprints anfallen, vom Change Master geführt und abgearbeitet werden. Dem Change Master dient sie einerseits als Überblick auf alle offenen und das Team behindernden Aspekte sowie als Arbeitsliste für ihn zum Beseitigen dieser Hindernisse.

3. Anwendung von Scribble in der Gestaltungsphase

3. 1 Allgemein

Die Gestaltungsphase beschreibt den Hauptteil der agilen Prozessmethode Scribble. Sie beinhaltet die Tätigkeiten von der Konzeption eines Process Backlogs als Arbeitsgrundlage für die Entwicklung oder Überarbeitung der Teilprozesse in der Ausformulierung auf einem sogenannten Storyboard, das Trainieren und Simulieren der Teilprozesse sowie das Abschließen der Teilprozesse bis zum Übergang in die Betriebsphase.

3.2 Die Prozessanforderung im Process Backlog

Der erste Teil der Gestaltungsphase beginnt mit dem Erstellen des Process Backlogs. Der Process Backlog ist eine Sammlung der Anforderungen in Form von einfach gehaltenen Process Stories. Im Process Backlog beschreibt der Process Manager eigenständig die Zielsetzung des Prozesses, auf Basis der Prozessvision. Der Process Backlog sollte dabei möglichst einfach gehalten sein und zugleich aber sicherstellen, dass alle wichtigen Anforderungen schon von Beginn an darin festgehalten werden. Das Process Backlog sollte in jedem Fall aber genügend Anforderungen für mindestens zwei bis drei Sprints beinhalten. Anforderungen im Process Backlog werden mit unterschiedlichem Detaillierungsgrad beschrieben. Dadurch ist gewährleistet, dass der Informationsbestand möglichst gering gehalten wird. Aufgrund von Priorisierung der Anforderungen erhält man die Vorgabe des Detaillierungsgrades. D.h. höhere priorisierte Anforderungen werden detaillierter dargestellt als nieder priorisierte Anforderungen. Letztere werden in Anlehnung an Cohn (2004) zu Beginn des Projektes nur grob skizziert und als sogenannte Process Stories in der Betrachtungsweise des Prozesskunden beschrieben. Dies setzt voraus, dass das Bedürfnis aller Prozessbeteiligten, im Speziellen des Prozesskunden verstanden wird. Es erfordert zudem, dass der Process Manager und das Team über den gesamten Verlauf des Prozessprojektes eng zusammenarbeiten und die Anforderungen gemeinsam verfeinern.

Alle Anforderungen an den Prozess und Teile daraus sollten aus der Betrachtungsweise des Prozesskunden beschrieben werden. Diese Benutzergeschichten (Process Stories) bestehen aus einem Namen (z.B. Passagierliste), einer kurzen Beschreibung der Anforderung aus Sicht des Prozesskunden (z.B. Die Fluggäste müssen am Check-in Schalter namentlich für das weiterführende Boarding erfasst werden) und einer Reihe von Akzeptanzkriterien. Aufgrund dieser Akzeptanzkriterien kann nach der Fertigstellung sicher geprüft werden, ob die vorher definierten Anforderungen als erfolgreich realisiert gelten. Die Benutzergeschichten werden auf Metaplankarten geschrieben, wobei Name und Text auf der Vorderseite und die Akzeptanzkriterien auf der Rückseite geschrieben werden. Für die Benutzergeschichten gelten die sogenannten 3 C Kriterien nach Cohn (2004). Diese beschreibt die 3 Cs mit „Card“, „Communication“ und „Confirmation“. Card: Die Prozessbeschreibung muss in ihrer Kurzform auf einer Metaplankarte Platz finden und aus Sicht des Prozesskunden formuliert sein. Communication: Diese Prozessbeschreibung muss allen Beteiligten kommuniziert werden. Confirmation: Die Akzeptanzkriterien - ebenfalls kurz formuliert - sind dafür notwendig, um damit das jeweilige Ergebnis und die Qualität des jeweiligen Prozessschrittes überprüfen zu können (z.B. im Teilprozess „Kundenauftrag anlegen in einem Produktionsbetrieb“: Der Kundenauftrag muss innerhalb von 8 Std. nach Einlangen des Kundenauftrages als Produktionsauftrag vollständig erfasst werden). Die Reihenfolge der Teilprozesse muss in der Aufstellung der einzelnen Teilprozesse zusätzlich ersichtlich sein.

3.3 Der Anforderungsworkshop

Nach der fertigen Erstellung des Process Backlogs durch den Process Owner, wird von ihm im Rahmen eines Anforderungsworkshops allen Beteiligten das Prozessziel und die priorisierten Prozessbeschreibungen in Form von Process Stories kommuniziert. Diese können in der Diskussion auch gemeinsam verfeinert werden. Im Rahmen des Anforderungsworkshops wird jede der einzelnen Process Story vom gesamten Team in ihrem Umfang (Grösse und Komplexität der Aufgabe) geschätzt. Als Ergebnis liegt nach dem Anforderungsworkshop ein priorisierter „Selected Process Backlog“ vor, indem zusätzlich jede Process Story in der Metrik „Story Points“ vom gesamten Team geschätzt wurde (Cohn, 2004). Vom zeitlichen Ablauf her betrachtet sollte der Anforderungsworkshop kurz gehalten sein und maximal einen halben Tag (bezogen auf eine Neudefinition einer kompletten Prozesslandkarte mit allen unternehmensrelevanten Kernprozessen) nicht übersteigen.

3.4 Sprints im Überblick

In der agilen Prozessmanagementmethode Scribble finden - so wie in Scrum - alle Aktivitäten zur Umsetzung von Anforderungen in sogenannten Sprints statt. Als Sprints werden Arbeitszyklen beschrieben, die jeweils ein Prozessinkrement erzeugen. Manchmal werden Sprints auch als Iteration bezeichnet. (vgl. Pichler, 2008, S. 81ff.). Sprints kann man auch als sogenannte Miniprojekte bezeichnen. Wie der Begriff Sprint andeutet, sind die Arbeitszyklen kurz. Sie dauern maximal 30 Tage, können aber wenn sinnvoll 10 oder 20 Tage-Sprints umfassen. Die Sprint-Dauer ist jedoch im Rahmen eines agilen Prozessmanagement Projektes mit einer fixen Sprintlänge fixiert. Jeder Sprint wandelt Anforderungen in ein Prozessinkrement um. Die Abbildung 2 gibt einen kurzen Überblick über die wichtigsten Elemente, die dazu notwendig sind.

Jeder Sprint beginnt mit einer zweistufigen Sprintplanung. Das Team legt dabei fest, welche und wie viele Anforderungen (Process Items) innerhalb des Sprints in ein Prozessinkrement umgewandelt werden können. Anschließend führt das Team die hierzu notwendigen Aktivitäten aus. Im Rahmen der Umsetzung findet zu jedem Tag zur selben Zeit und am selben Ort ein kurzes Daily Process Meeting (max. 15 Minuten) statt. Das Sprint Review und die Sprint Retrospective schließen den Sprint ab. Das Sprint Review erlaubt dem Process Manager, die erbrachten Prozessergebnisse in Form fertig ausformulierter und getesteter (simulierter) Prozesse zu überprüfen. In der anschließenden Sprint Retrospective reflektiert das Team gemeinsam mit dem Change Master über seine Zusammenarbeit und leitet daraus eventuelle Verbesserungen für den kommenden Sprint ab. Diese allfälligen Verbesserungen werden in der nächsten Sprintplanung eingebracht.

In Bezug auf wissensbasiertes Arbeiten handelt es sich bei Sprints (sowohl in Scrum als auch agilem Prozessmanagement) um Rituale mit einfachen Feedbackschleifen. Sprint Review und -Retrospective fungieren dabei als Feedbackmechanismen (vgl. Pichler, 2008, S. 82). Die einzelnen Sprints finden unmittelbar aufeinander statt. Sprints wandeln daher Anforderungen aus dem Process Backlog in getestete (simulierte) und dokumentierte Prozesse oder Teilprozesse um. Am Ende eines Sprints muss der Process Manager die entstandenen Prozesse begutachten können. Damit dies möglich ist, muss das Team innerhalb eines Sprints ein Prozessinkrement erzeugen (Schwaber, 2004).

3.5 Die Sprintplanung

Die Sprint-Planungssitzungen sind ein verpflichtungsbasierter (commitment driven) Planungsansatz, bei dem das Team selbsttätig festlegt, welche und wie viele der vom Process Manager vorbereiteten Anforderungen bis zum nächsten Sprint umgesetzt werden können (vgl. Pichler, 2008, S. 93).

Nach dem Anforderungsworkshop findet nun der erste Teil des Sprint Planning Meetings statt. Teilnehmer sind dabei Process Manager, das Team und der Change Master. Im ersten Teil dieses Sprint Planning Meetings bespricht der Process Manager den gesamten Process Backlog mit dem Team. Er legt weiters für den kommenden Sprint, das individuelle Sprintziel fest. Das Sprintziel sollte das Prozessprojekt seinem Ziel einen Schritt näherbringen. Es sollte allen Beteiligten ein klares Verständnis davon erzeugen, was in Summe das Ergebnis des Sprints ist. Es sollte realistisch, prägnant und gut verständlich sein. Ein Sprintziel könnte z.B. in einem Vertriebsprozess sein: „Beschleunigung des Teilprozesses Angebotslegung um 50%“. Das Formulieren des Sprintzieles sollte daher eine einheitliche Ausrichtung aller Beteiligten gewährleisten. Es werden anschließend vom Team selbsttätig für den kommenden Sprint, jene Prozessanforderungen (Process Stories oder auch Process Items bezeichnet) mit der höchsten Priorität (und die dem Sprintziel gerecht werden) aus dem Process Backlog entnommen zu einem Sprint Backlog zusammengefasst. Der Sprint Backlog beinhaltet nun alle Aktivitäten (in Form von Process Stories), die zur Unterstützung der Prozessanforderungen notwendig sind. Es legt fest, wie das Sprintziel erreicht werden kann und fungiert sozusagen als kollektives Zeitmanagementsystem des Teams (vgl. Pichler, 2008, S. 102ff.).

Haben nun das Team und der Process Manager ein gemeinsames Verständnis der ausgewählten Anforderungen erzielt, so ermittelt das Team alle Aktivitäten, die zur vollständigen Umsetzung in fertige Prozesse (Teilprozesse) notwendig sind. Im zweiten Teil dieses Sprint Planning Meetings moderiert der Change Master das Meeting, das nun gemeinsam mit dem Team weitergeführt wird. Der Process Manager nimmt in diesem Teil des Meetings ausschließlich eine Beobachterrolle ein.

In diesem zweiten Teil des Sprint Planning Meetings werden die Items (Process Stories) des aktuellen Sprint Backlogs nun in sogenannte Tätigkeiten (Tasks) unterteilt und dabei wieder der Umfang pro Task geschätzt. Zumeist wird durch die Schätzung der einzelnen Tasks der Umfang pro Sprint Backlog Item konkreter gehalten. Die oben angeführten Tasks beinhalten typischerweise Design-, Test- und Simulations- sowie Dokumentationsaufgaben. Die Art, Anzahl und Reihenfolge der Aktivitäten hängt vom Sprintziel, den Rahmenbedingungen des Prozessprojektes und der Arbeitsweise des Teams ab. Allfällige Anpassungen in der Ablauf- und Aufbauorganisation, entsprechende Schulungen, Änderungen der relevanten Anwendungssoftware oder eventuell von Räumlichkeiten sind Bestandteil eines Sprints. Ein Sprint Backlog ist sozusagen eine Arbeitsliste die als Hilfestellung dient, aus den Prozessanforderungen der einzelnen Backlog Items einen funktionierenden, getesteten und dokumentierten Teilprozess zu gestalten. Das Sprint Backlog sollte also dem Team zur Organisation der Sprint-Zielerreichung dienen. Das Sprint Backlog kann auf einem Blatt einer Tabellenkalkulation oder auf Karteikarten an einer Metaplanstellwand aufbereitet sein. Im Nachfolgenden wird die vom Autor bevorzugte Version beschrieben:

Die erste Spalte „Priorität“ zeigt die Wichtigkeit des in dem rechts davon aufgelisteten Spalteneintrag „Item“ bezogen auf den aktuellen Sprint an. Die Spalte „Item“ ist der aus dem Process Backlog übernommene Item-Eintrag einer Prozess- oder Teilprozessanforderung. In der Spalte „Zu erledigen“ sind die dafür notwendigen Tasks (Aktivitäten), die gemeinsam mit dem Team erstellt worden sind. Da im Rahmen des Sprint Planning Meetings (zweiter Teil des Sprint Plannng Meetings) jeder Task zeitlich geschätzt wird, wird dieser Schätzbetrag in Personenstunden auf dem jeweiligen Task-Kärtchen notiert. Jenes Teammitglied, das einen Task von der Spalte „Zu erledigen“ in die „In Arbeit“ hängt, versieht diesen mit seinem Namenskürzel. Sobald diese Aktivität fertig abgearbeitet, getestet (simuliert) und dokumentiert ist, wird diese in die Spalte „Erledigt“ umgehängt und der verbleibende Restaufwand dafür auf null gesetzt. Aktivitäten, die während des Sprints identifiziert werden und noch „Zu erledigen“ oder “In Arbeit“ sind, werden vom Restaufwand her betrachtet täglich vor dem Daily Process Meeting geschätzt und auf dem Task-Kärtchen notiert. Der Fortschritt des Sprints wird so für alle Beteiligte greifbar. Weiters wandern immer mehr Kärtchen von links der Stellwand nach rechts. visualisierte Struktur kann nach Bedarf angepasst und erweitert werden, wie z.B. mit den Spalten „Test ready“ und „To verify“ (vgl. Cohn, 2005; Pichler, 2008, S. 104f.).

Zusammenfassend kann in der Verwendung von Scribble mittels Pinwänden festgestellt werden:

Vorteile - die Stellwand schafft einerseits Transparenz. Im Arbeitsraum aufgestellt, ist sie für alle Beteiligten sichtbar. Sie verschafft und fördert andererseits Verantwortungsbewusstsein und Flexibilität. Die Teammitglieder können ohne Probleme den Plan aktualisieren.
Struktur - eine Unterteilung der Stellwand in verschiedene Spalten hilft, den Fortschritt des Prozessprojektes leichter zu erkennen.

3.6 Der allgemeine Ablauf von Sprints

Sprints sind nun Arbeitszyklen, die ein fertiges Prozessinkrement erzeugen. D.h. dass nach jedem abgeschlossenen Sprint die Anforderungen an einen Prozess oder an einen Teilprozess fertig ausformuliert und mit allen Beteiligten simuliert wurden. Eine ähnliche Herangehensweise in Richtung einer Konzeption mit nachfolgender Simulation der Teilabläufe beschreiben Osterloh/Frost (vgl. 2006, S. 46ff.) in ihrem Werk zum Thema Probeläufe mit möglichen Flow-Line Varianten.

In jedem Sprint werden daher Anforderungen (Items) aus dem Process Backlog in die Realität umgesetzt und auf Funktionsfähigkeit geprüft. Für Sprints gilt die absolute Termintreue (timeboxing). Sprints starten und enden zum geplanten Zeitpunkt. Dies ist unabhängig davon, ob das Team das Sprint-Ziel erreicht hat oder nicht. Ist der Fortschritt des Sprints langsamer als gedacht, so werden die Anforderungen vom Process Manager entweder im kommenden Sprint abgeschlossen oder in einem Falle der Umpriorisierung der Anforderungen eventuell auch nicht mehr fertig gestellt.

Das oben beschriebene Daily Process Meeting ist eine auf 15 Minuten beschränkte Besprechung, die täglich (Werktage) am selben Ort und zur selben Zeit stattfinden sollte (Schwaber, 2004). Die vom Autor bevorzugte Zeit ist morgens um 09:00 und in der Nähe der Sprint Process Backlog Pinnwand. Somit kann das Team am Vorabend die diesbezüglichen Planungen vornehmen und den Arbeitstag gemeinsam danach beginnen. Die Zielsetzung des Daily Process Meetings soll dazu dienen, die Selbstorganisation des Teams zu unterstützen und Hindernisse systematisch zu ermitteln. Alle Teammitglieder inkl. Change Master müssen an diesem Daily Process Meeting teilnehmen. Ebenfalls können der Process Manager und sonstige Interessenten an dem Prozessprojekt - jedoch nur als Zuhörer - anwesend sein. Der Change Master moderiert die Veranstaltung und befragt alle Teilnehmer über den Fortgang des Projektes. Da die Maximaldauer des Daily Process Meetings auf 15 Minuten begrenzt ist, müssen die Teammitglieder kurz und knapp antworten. Der Change Master ist für den geregelten und straffen Ablauf des Meetings verantwortlich. Das Meeting soll nicht dazu dienen Probleme zu lösen, sondern maximal diese aufzuzeigen und alle Beteiligten über den Projektverlauf zu informieren. Zur Lösung von Problemen sollte ein separates Meeting anberaumt werden. Dazu können sich (nur) die beteiligten Mitarbeiter des Teams direkt im Anschluss an das Daily Process Meeting zusammenfinden.

3.7 Der Ablauf eines Sprints in Form der Visualisierung und der Simulation von Prozessen

3.7.1 Grundsätzlich

Das Ziel eines jeden Sprints in der Methode Scribble ist die Ergebnislieferung von fertig gestalteten Teilprozessen, in folgender Reihenfolge:

Grafische Erstgestaltung eines Storyboards und eventuelle Ausgestaltung aller Abläufe in Form einer Prozesslandkarte
Detaillierte Gestaltung des Storyboards mit Ergänzung der Detailinformationen
Physikalischer Aufbau der Prozesslandschaft
Simulation der gestalteten Szenen.
Allfällige Ergänzung und Überarbeitung des Storyboards

3.7.2 Prozesslandkarte

Wird Scribble nun als Methode zur Einführung von Prozessmanagement verwendet, ist es notwendig, zu Beginn des Vorhabens die gesamte Prozesslandkarte in einfacher Art und Weise grafisch abzubilden.

Unter einer Prozesslandkarte versteht man grundsätzlich eine simple und einfache Übersichtsdarstellung der gesamten Ablauforganisation. Dabei werden die einzelnen Prozesse, eingeteilt in die Prozesskategorien: Kern-, Support- und Managementprozesse mit allen darin involvierten Personengruppen grafisch dargstellt (Robbins, 2001; Rosenkranz, 2002; Schmelzer/Sesselmann, 2002).

Unter Kernprozess versteht man jene Tätigkeiten einer Unternehmung, die das Kerngeschäft einer Organisation betrifft. Oder in anderen Worten ausgedrückt, beschreibt es die Tätigkeiten, die dem Kunden dieser Organisation, Nutzen schafft.

Unter Supportprozess werden jene Abläufe beschrieben, die diese Kernprozesse unterstützen. Dazu gehören zB Tätigkeiten zur Aufrechterhaltung der eigenen Infratruktur (IT oder Haustechnik).

Als Managementprozesse werden alle Tätigkeiten zur Steuerung von Kern- und Supportprozessen bezeichnet. Für die Gestaltung einer Prozesslandkarte bietet es sich an, auf einer Pinwand jede aktuelle Abteilung (oder Personengruppe) als Grafik (zB mittels eines Metaplankärtchens pro Abteilung) abzubilden und die einzelnen Prozesse (Kern-, Support- und Managementprozesse) als gerichtete Verbindungslinien (Pfeil weist von auslösender Personengruppe in Richtung des Prozesskunden) zwischen diesen zu markieren. Dabei wird der Informationsfluss eines Prozesses, jeweils mit einer gestrichelten Linie und ein möglicher Warenfluss, mit einer durchgezogenen Linie abgebildet.

Die einzelnen Prozesskategorien (Kern-, Support- und Managementprozesse) sind darüber hinaus noch farblich zu unterscheiden.Das Gesamtbild der Prozesslandkarte einer Unternehmensorganisation ist somit auf der Pinwand mit den jeweiligen Abteilungen grafisch abgebildet. Dazwischen spannen sich die Informationslinien (mit Pfeilen gestrichelt dargestellt) und die Warenflusslinien (mit Pfeilen durchgezogen dargstellt) jedes einzelnen Prozesses.

Die Detaillierung der Prozesslandkarte in Form der Beschreibung der einzelnen Prozesse wird in Form von Storyboarding durchgeführt und nachfolgend beschrieben.

Abb. 2 Beispiel einer Prozesslandkarte

3.7.3 Storyboarding

Der Begriff Storyboarding wurde aus dem dem Bereich der Kreativwirtschaft, konkret aus der Filmproduktion entliehen. Die Gestaltung und das Zeichnen eines Storyboards in der Filmbranche entspricht dem grafischen Skizzieren eines Drehbuches, wobei jede Szene grafisch als Bild ausgestaltet wird und die dazu notwendigen Zusatzinformationen (zB Sprechtext, Gestik, Mimik, Kameraführung, Beleuchtung) direkt darunter als Text angefügt werden.

In diesem Kontext bedeutet das Storyboarding in Scribble ein grafisches Skizzieren von „Schlüsselszenen“ eines Geschäftsprozesses mitsamt der jeweils darunter angeführten Kurzbeschreibung, der dazu notwendigen Rollen, Informationen mitsamt der erforderlichen Infrastruktur.

Die Visualisierungsform des Storyboardings in Scribble ist demnach eine einfach in Bild und Wort gestaltete Szenerie, ähnlich einem Cartoon dargestellt. Scribble bedarf keiner eigenständigen Metasprache wie sie in Form von Ablaufdiagrammen, inklusive abstrakter Symbolik im traditionellen Prozessmanagement Anwendung findet.

Der Ablauf des Storyboardings ist nachfolgend beschrieben und gehorcht folgender Reihenfolge (siehe dazu auch Abb. 3):

Grafische Erstgestaltung eines oder mehrerer Prozesse in Form des Grobentwurfs eines Storyboards. Ist die Aufgabe des aktuellen Vorhabens jedoch die gesamte Ausgestaltung der Ablauforganisation oder besteht auch nur die Notwendigkeit mehrere zusammenhängende Prozesse in der Methode Scribble abzubilden, bietet sich die vorherige Ausgestaltung aller Abläufe in Form einer Prozesslandkarte an.
Detaillierte Gestaltung des Storyboards mit Ergänzung der Grafik und Erstellung der Kurzbeschreibung, Angabe der Rollen, notwendige Informationen und Materialen als Input, erstellte Prozessergebnisse als Output, notwendige Infrastruktur (IT-Systeme, Raumgestaltung, Werkzeuge, Maschinen und Material) sowie Schnittstellen zu anderen Prozessen (siehe dazu Abb. 2).
Das somit pro Teilprozess entwickelte Storyboard (inklusive einer möglichen Prozesslandkarte als Gesamtüberblick), dient in weiterer Folge als Vorlage für den:

Physischen Aufbau der Prozesslandschaft,

Simulation und Training der Prozesse,

Abnahme dieser Prozesses im Sprintreview und

anschliessende Betriebsphase des laufenden Tagesgeschäfts.

Abb. 3 Überblick über den Verlauf in der Gestaltungsphase mit der Umsetzung der Prozessideen am Prozess Backlog (PBL ) über den Sprint Backlog (SPL) als Vorlage der Einzeltätigkeiten des aktuellen Sprints, in der Überführung der einzelnen Teilprozesse auf ein Storyboard bis hin zum Ausprobieren, Trainieren in Form der Simulation

3.7.4 Simulation und Training

Im Anschluss an die Ausgestaltung eines detaillierten Storyboards werden in den selben oder in eigens dafür zur Verfügung gestellten Räumlichkeiten die Prozesse nachgestellt und dabei simuliert, allfällige Änderungen inhaltlich sofort am Storyboard ergänzt und mit allen notwendigen Rollen inklusive der dafür erforderlichen Infratruktur trainiert. Der Ablauf dabei gehorcht folgender Reihenfolge:

physikalischer Aufbau der Prozesslandschaft für die einzelnen Tätigkeitsschritte (Szenen des Storyboards) mitsamt allen dazu notwendigen Details (IT-Systeme, Tische, Material). Dazu wird die Örtlichkeit und die Räume, in den der Prozess nachgestellt, simuliert und trainiert wird, entweder mit den Originalteilen aufgebaut oder sonst mit einfachen Mitteln (Karton, Legobausteine, Plastilin, Papier) nachgebaut,
Simulation der gestalteten Szenen (Tätigkeitsschritte) und Training der Tätigkeiten mit allen dazu notwendigen Rollen und Infratruktur,
allfällige Ergänzung und Überarbeitung des Storyboards, das anschliessend als Vorlage für die Abnahme in der aktuellen Sprintreview und der abschliessenden Betriebsphase dient (siehe dazu auch Abb. 4).

Abb. 4: Der Prozess wird in Form eines Storyboards skizziert und anschliessend mit allen dazu notwendigen Werkzeugen und Infrastruktur aufgebaut und simuliert

3.8 Sprint Review

Am Ende jedes Sprints findet das Sprint Review statt. Je nach Art des Prozesses kann diese Sitzung in einem Büro, einem Besprechungsraum, oder in einer eigens dafür aufgebauten Prozesslandschaft stattfinden. Die Zielsetzung des Sprint Reviews ist es, die im Sprint erarbeiteten Prozessergebnisse zu begutachten. Der Process Manager überprüft, ob das Team alle Anforderungen, zu denen es sich in den Sprint Planning Meetings verpflichtet hat, erfolgreich umgesetzt hat. Dies sollte vollständig, fehlerfrei und mit allen in der Organisation hinkünftig Beteiligten getestet (simuliert) vorliegen. Das Sprint Review ermöglicht dem Process Manager, das Ergebnis zu inspizieren und ggf. das Ziel des nächsten Sprints zu adaptieren. Teilnehmer des Sprint Reviews sind das Team, der Process Manager, der Change Master sowie optional Interessensvertreter, wie z.B. Kunden oder Lieferanten bzw. Mitarbeiter anderer Abteilungen. Es ist sicherlich eine ungewöhnliche Vorgehensweise, die erweiterten Stakeholder von Prozessen einzuladen, jedoch liefern insbesonders Kunden oder Lieferanten oft hilfreiche Rückmeldungen über die entstandenen Prozessergebnisse.

Im Sprint Review Meeting führt das Team die im Sprint entstandenen Ergebnisse vor und zeigt den Prozessablauf in Form einer Live-Demonstration und/oder Simulation der Abläufe mit allen Beteiligten vor. Als Vorlage dafür dient dem Team grafisch gestaltete Prozesslandkarte im Überblick und die detaillierte Prozessbeschreibungen in Form des Storyboards. Der Process Manager überprüft die Ergebnisse anhand der Akzeptanzkriterien pro User Story die für jeden Backlog ursprünglich Item - spätestens im Anforderungsworkshop - erstellt wurden. Der Process Manager nimmt daraufhin den jeweiligen Item entweder zu 100% oder gar nicht ab. Eine Teilabnahme pro Item ist nicht zulässig. Partiell oder fehlerhaft umgesetzte Items können stets im nächsten Sprint fertig umgesetzt werden. Die ausgeprägte Teamverantwortung in der Verwendung von Scribble manifistiert sich auch im Review Meeting, indem alle Teammitglieder sich beim Sprint Review kollektiv für das Ergebnis verantwortlich fühlen, unabhängig davon, welches Teammitglied an welchen Arbeitsergebnissen mitgearbeitet hat.

3.9 Sprint Retrospective

Die Sprint Retrospective findet unmittelbar im Anschluss an das Sprint Review statt und schliesst den Sprint ab. Die Zielsetzung der Sprint Retrospective ist es, die Zusammenarbeit innerhalb des Teams zu verbessern (vgl. Schwaber, 2004; Derby/Larsen, 2006; Pichler, 2008, S. 110f.). Retrospectiven unterstützen dadurch einen kontinuierlichen Verbesserungsprozess. Eine wichtige Annahme ist hierbei, dass stets Verbesserungspotential besteht, auch dann, wenn ein Projekt sehr erfolgreich ist und ein Team gut zusammengearbeitet hat. Regelmäßige Reflexion und kontinuierliche Verbesserungen hat die Methode Scribble, genauso wie die Methode Scrum, aus der agilen Produktionsmethode der Leanproduktion im Allgemeinen und des Toyota Produktionssystems (TPS) im Speziellen entnommen Diese kontinuierliche Verbesserung spielt in der schlanken Produktentwicklung eine wesentliche Rolle. Dieser Umstand, ein Hauptbestandteil des Toyota Produktionssystems (japanisch als „hansei“ bezeichnet) und die damit verbundene Kultur des stetigen Lernens und Verbesserns ist vermutlich eine der grossen Stärken des Unternehmens Toyota (Ohno, 1988; Womack/Jones, 1996; Morgan/Liker, 2006). Die Teilnehmer der Sprint Retrospective sind das Team und der Change Master. Die Aufgabe des Change Masters ist es dabei, die Sprint Retrospective vorzubereiten und zu moderieren.

Nach dem letzten Sprint wird das gesamte Prozessprojekt im selben Kontext wie Sprints (Projekt Review, Projekt Retrospective) mit dem Unterschied abgeschlossen, dass einerseits bei erfolgreichem Abschluss der gesamte Prozess in die Betriebsphase geht und andererseits das gesammelte Wissen im Rahmen des abgeschlossenen Projektes reflektiert und dokumentiert werden sollte.

4. Übergang in die Betriebsphase

4.1 Allgemein

Nach der Abnahmeprüfung des fertig gestellten und simulierten Prozesses oder Teilprozesses durch das Projekt Review, geht dieser in die Phase des Tagesbetriebes über. Das Team, das in der Gestaltungsphase involviert war, übernimmt somit den Regelbetrieb und ist für die Einhaltung der selbst erstellten Verfahrensanweisungen zuständig. Der Process Manager nimmt im Rahmen seines Tagesgeschäftes (entweder in der Rolle des CIO , Qualitätsmanagers, oder des Prozessgesamtverantwortlichen innerhalb des Unternehmens) wieder seinen geregelten Arbeitsablauf auf. Der Change Master schließt nach erfolgreichem Projekt seine Tätigkeit ab, zieht sich in sein Team als Mitarbeiter zurück oder wird als externer Mitarbeiter, seine Tätigkeit beenden. Ziel der Methode des agilen Prozessmanagements ist es, nach kurzer Gestaltungszeit einen schnellen Betriebszustand zu erzeugen und den neuen Zustand nach dem Wandel langfristig erfolgreich „einfrieren“ zu können (Lewin, 1951).

Das Ergebnis der vorbereitenden Gestaltungsphase innerhalb eines agilen Prozessmanagementprojektes ist ein fertig konzipierter Prozess mitsamt der iterativen Implementierung in die Unternehmensorganisation. Dies wird grossteils in Form von Simulationen der Abläufe mit allen darin beinhalteten Personen und Ressourcen erreicht.

4.2 Vorgehensweise in der Betriebsphase

Der Process Manager koordiniert eine laufende Adaptierung und Verbesserung der Prozesse. Die Verbesserungen von Prozessen oder Teilprozessen gehen grundsätzlich vom Team aus, werden dabei aber vom Process Manager geführt. Im Falle von anfallenden Adaptierungsmaßnahmen innerhalb des Prozesses (z.B. wenn der Bedarf einer neuen Bildschirmmaske im IT-System für die erweiterte Erfassungsmöglichkeit von Kundendaten notwendig geworden ist) ist das verantwortliche Team dafür zuständig, dies mit dem Process Manager zu besprechen. Dieser entscheidet, ob ein neues Scribble Projekt nach dem vorher beschriebenen Prozedere (Initial-, Gestaltungs-, Betriebsphase) gestartet werden sollte, oder ob dies auf „kurzem“ Weg in direkter Abstimmung z.B. mit der IT-Abteilung des Unternehmens abzuarbeiten ist. Änderungen im Rahmen des agilen Prozessmanagements, sind daher „Anlass-getrieben“, erfordern keine regelmäßigen Meetings oder sonstigen Artefakte (Protokolle, digitale Workflows). Die Erfordernisse für eine zeitnahe Adaptierung von Prozessen im Änderungsfall sind einerseits eine hohe Sensorik für Änderungen im jeweilig verantwortlichen Team und die Konsequenz (Disziplin) diese Änderungen gemeinsam durch vorherige Meldungen an den Process Manager mit diesem gemeinsam umzusetzen.

Einen wichtigen Bestandteil des agilen Prozessmanagements stellt eine „lebendige“, d.h. ständig adaptierte Prozessdokumentation dar. Dazu ist die Notwendigkeit einer Minimaldokumentation der abgebildeten Prozesse gegeben.

4.3 Die Minimalkriterien einer Prozessdokumentation

Entlang der einzelnen Phasen innerhalb eines agilen Prozessmanagement Projektes mit Scribble kann auf ein Mindestmaß einer Dokumentation nicht verzichtet werden. Die Kriterien dafür orientieren sich an den im Moment gängigen Standards im Bereich des Prozessmanagements (Wächter/Vedder, 2001; Pfitzinger, 2002; Brauer, 2004). Diese Minimalkriterien für eine Prozessdokumentation sind entweder als Gesamtbeschreibung des Storyboards oder unter jeder einzelnen Abbildung pro Prozessschritt am Storyboard ausgeführt und beinhalten:

Prozessinhalt - Kurzfassung des Inhaltes und Zwecks des entsprechenden Prozesses (Teilprozesses), angeführt in der Übersichtsbeschreibung des jeweiligen Storyboards. Aus Sicht der Übersichtlichkeit sollte die verwendete Granularität der Beschreibung gering und von der Formulierung her betrachtet aus der Perspektive des Prozesskunden sein. Sinnvoll kann es dabei sein, die 3-C Methode von Cohn (vgl. 2004, S. 25ff.) anzuwenden. Diese beschreibt die 3 Cs mit „Card“, „Communication“ und „Confirmation“. Card: Die Prozessbeschreibung muss in ihrer Kurzform auf einer Metaplankarte Platz finden und aus Sicht des Prozesskunden formuliert sein. Communication: Diese Prozessbeschreibung muss allen Beteiligten kommuniziert werden. Confirmation: Die Akzeptanzkriterien - ebenfalls kurz formuliert - sind dafür notwendig, um damit das jeweilige Ergebnis und die Qualität des jeweiligen Prozessschrittes überprüfen zu können (z.B. im Teilprozess „Kundenauftrag anlegen in einem Produktionsbetrieb“: Der Kundenauftrag muss innerhalb von 8 Std. nach Einlangen des Kundenauftrages als Produktionsauftrag vollständig erfasst werden). Die Reihenfolge der Teilprozesse muss in der Aufstellung der einzelnen Teilprozesse zusätzlich ersichtlich sein.
Erfolgskriterien - Was sind die wichtigsten Voraussetzungen, damit der Prozess zu voller Zufriedenheit abläuft? Ein bis maximal drei 3 Faktoren (z.B. eine Minimalbetreuungszeit für Tätigkeit und Kommunikation mit dem Patienten), angeführt in der Übersichtsbeschreibung des jeweiligen Storyboards.
Prozessinput - der Impuls, der diesen Prozess (Teilprozess) auslöst. Der Input kann auch das Ergebnis eines anderen Prozesses sein (z.B. löst in einem Industriebetrieb der Kundenauftrag als Ergebnis des Vertriebsprozesses den Produktionsprozess aus).
Prozessoutput - das Ergebnis des Prozesses (z.B. das Ergebnis des Vertriebsprozesses ist der Kundenauftrag)
Prozessschnittstellen - Schnittstellen zu anderen Prozessen (Teilprozessen).
Prozesskunde - jene Person oder Personengruppen, die im fertig definierten Prozess mit dem Ergebnis des Prozesses arbeiten.
Prozesslieferant - jene Person oder Personengruppe, die im fertig definierten Prozess diesen jeweiligen Prozessschritt erstellt oder bearbeitet.
Prozessressourcen - jene Ressourcen, die im Rahmen des Prozesses verwendet werden, eingeteilt in:

Mensch - jene Mitarbeiter, die im Prozess tätig sind, und jene Personen, die für die Prozessdurchführung unbedingt erforderlich sind (z.B. Pflegekräfte und Hilfspflegekräfte in einem Spital).
Material - Arbeitsumgebung, Betriebsmittel, Infrastruktur. In welcher Arbeitsumgebung findet der Prozess statt und welche Betriebsmittel, Infrastruktur etc. werden benötigt? (z.B. Medikamente in einem Pflegeprozess oder PC-System inkl. der dafür notwendigen Software zur Erfassung von Patientendaten).
Medien (Informationen, Unterlagen und Know-how) - jene Informationen und Unterlagen, welche standardmäßig für die Durchführung des Prozesses benötigt werden (z.B. Patientendaten für die Zusammenstellung der Medikamentation während der täglichen Frühvisitation durch das Pflegepersonal inkl. der dafür notwendigen Checklisten bzw. die Ausbildung zur medizinischen Pflege in einem österreichischen Spital).

4.4 Die Voraussetzungen

Die nachfolgenden Aufstellungen resultieren einerseits aus den Analogien von Scrum, wie in den Werken von Gloger (vgl. 2008, S. 71ff.) und Pichler (vgl. 2008; S. 10ff.) beschrieben und andererseits aus den Ergebnissen von der Anwendungen der Methode Scribble in der Praxis.

Grundsätzlich kann man die vorliegende Methode Scribble, so wie auch die des agilen Projektmanagements Scrum als „voraussetzungsreich“ bezeichnen. Folgende Grundvoraussetzungen sind für die agile Prozessmanagementmethode notwendig:

Fokus auf eine iterative Zielerreichung.
Vertrauen - das Management vertraut dem Team, denn das Team ist für das Selbstmanagement “selbst” verantwortlich. Ohne Unterstützung durch die Geschäftsleitung ist eine unternehmensweite Einführung und Etablierung von agilem Prozessmanagement schwer möglich.
Respekt - Akzeptanz von Stärken und Schwächen der Teammitglieder.
Offenheit - in allen Belangen der täglichen Prozessarbeit. Dies spiegelt sich sowohl in der Kommunikation der Daily Process Meetings täglich wider, sowie in den laufenden Review- und Retrospective Meetings.
Verbindlichkeit zu selbst-organisierenden Teams durch eine Zielerreichung in Form von Iterationen, die keinen zusätzlichen externen Einfluss auf diese Iterationen zulassen.
Disziplin - bei allen Beteiligten. Beim Process Manager wird aufgrund seiner Rolle eine hohe inhaltliche Disziplin in Form der intensiven und ständigen Arbeit am Process Backlog und bei den kontinuierlichen Reviews nach den abgeschlossenen Sprints erwartet. Beim Team wird eine hohe terminliche Disziplin für die zeitnahe Abwicklung der einzelnen Aktivitäten innerhalb des Sprints verlangt. Beim Change Master wird eine notwendige hohe zeitliche Disziplin in der Moderation der unterschiedlichen Meetings (Planning, Daily Process, Review, Retrospective) vorausgesetzt.
Multidisziplinarität der Prozessteams. Die Zusammensetzung des Prozessteams soll so beschaffen sein, dass möglichst alle Qualifikationen, die der zukünftige Prozess in seiner Betriebsphase erfordert, vorhanden sind.
Während die oben genannten Voraussetzungen eine allgemeine Betrachtung dessen darstellen, besitzt die Methode folgende spezielle Anforderungen bzw. Voraussetzungen:

Prototyping-fähige Software - speziell in Projekten mit einer hohen Komponente an IT-gestützten Abläufen, sowohl in bestehenden, wie in zukünftigen Abläufen, wird eine Softwareplattform benötigt, die ohne hohen Konzeptionsaufwand an die Abläufe oder Ablaufänderungen einfach angepasst werden kann.
Freie Dokumentationsart der Abläufe - die oben beschriebene Methode eignet sich nur bedingt für Projekte mit gezielten Verfahrensanweisungen und Dokumentationsvorschriften als Vorgabe bzw. bedingt für Projekte, die in der beschriebenen Minimaldokumentation nicht das Auslangen finden.
Effektive Change Master - der Change Master muss erreichen, dass sich das Team jeden Tag 15 Minuten zusammenfindet, er muss die geforderten Sprint-Artefakte erzeugen lassen (z.B. Sprint Planning, Sprint Backlogs, u.v.a.m.), er muss das Daily Process Meeting gut moderieren, ständig neu auftretende Impediments lösen und hinter der „Bühne des Prozessprojektes die Fäden so ziehen“, dass das Team möglichst ungestört arbeiten kann.

Ein Change Master sollte seinen Fokus auch in Richtung der Organisation ausrichten, um seine Kollegen und sein Management von der Methode des agilen Prozessmanagements zu überzeugen. Vielleicht hält er interne Vorträge darüber, was diese Methode in Unternehmen bewirken kann. Es kann durchaus sein, dass er sich gegen seine Vorgesetzten mit seinen Ideen durchsetzen muss. Denn die traditionelle „dokumentenorientierte“ Methode des Prozessmanagements bestimmt die momentane offizielle Lehre in der Betriebswirtschaftslehre (Wächter/Vedder, 2001; Pfitzinger, 2002; Brauer, 2004). Das sind alles Aspekte, die nicht jeder Person liegen und oftmals erst im Laufe der Zeit gelernt werden müssen. Aus diesem Grund liegt in der Auswahl des Change Masters eine hohe Bedeutung und sollte daher wohlüberlegt sein.

4.5 Vorteile und Grenzen in der Verwendung der Methode Scribble

Folgende Vorteile in der Anwendung von Scribble konnten aus den Praxiserfahrungen ermittelt werden:

Scribble ist eine Methode für sehr schnelle Prozessentwicklung und Umsetzung. Das iterative Vorgehen und die Lieferung von optimierten und feritg simmulierten Teilprozessen in kurzer Zeit ist eines der Stärken in der Verwendung der Methode. Neben einer schnelleren Implementierung von fertigen Prozessen, kann Scribble als Implementierung des gesamten Prozessmanagements verwendet werden. Derartige Projekte in der Methode Scribble eignen sich daher gut für die Einführung von Prozessmanagement in die Unternehmensorganisation, sowie auch für Projekte mit dem Ziel der Optimierung von bestehenden Prozessorganisationen. Die Methode ist ebenso als organisatorischer Rahmen für sämtliche Qualitätsmanagementprojekte geeignet.
Scribble macht die Prozesse schon in der Gestaltungsphase sichtbar.
Scribble optimiert am „lebenden“ Prozess und kann daher Erkenntnisse aus Gestaltung und Simulation mit den aktuellen Prozesskunden und -lieferanten frühzeitig erkennen und umsetzen.
Scribble kann erfahrungsgemäss ein „Flow-Gefühl“ in der Umsetzung erzeugen und macht durchaus auch Spass in der Anwendung (Csikszentmihalyi, 2010).
Nachdem Scribble eine von vielen agilen Arbeitmethoden ist, kann agiles Arbeiten für alle Beteiligten dadurch im Ansatz auch erstmals erlebbar gemacht werden.
Oftmalige und gezielte Kommunikation kann als einer der Schlüsselerfolgsfaktoren dieser Methode betrachtet werden.
Die minimale und einfach adaptierbare Dokumentation in Form von Cartoons oder Storyboards ist ein weiterer Vorteil der Methode.

Folgende Grenzen in der Anwendung von Scribble wurden aus konkreten Praxisfällen berichtet :

Ohne Unterstützung durch die Geschäftsleitung, ist eine unternehmensweite Einführung und Etablierung von agilem Prozessmanagement nicht möglich. Der dadurch bewirkte Wandel ist meistens so tiefgreifend, dass es dieser Unterstützung von Beginn an bedarf. Je nach Situation kann es sinnvoll sein, Scribble vorerst nur in einer Geschäftseinheit und mit Unterstützung des Mittelmanagements zu pilotieren. Haben sich erste positive Ergebnisse eingestellt, ist es leichter die Geschäftsführung als Sponsor für diese Methode zu gewinnen.
Die Einführung von Daily Process Meetings bedingt anfangs einen hohen Koordinationsaufwand. Daily Process Meetings mit einer durchgängigen Kontinuität sind überwiegend nur in Projekten anwendbar, wo der Anteil an dafür eingebrachter Projektleistung mindestens 50% beträgt. Ansonsten ist der terminliche Abstimmungsaufwand der Beteiligten zu hoch.
In einer bestehenden traditionellen Prozessorganisation ist die Methode erfahrungsgemäss nur erschwert anwendbar, da sowohl die generelle Herangehensweise zum Prozessmanagement, als auch die mit der agilen Methode erstellte Mindestdokumentation dem Anspruch der Vollständigkeit nur bedingt genügt.
Wurde in einem Unternehmen ein Prozessmanagement nach der vorliegenden Methode erfolgreich „pilotiert“, wird sich in diesem Unternehmen wahrscheinlich die Frage der Etablierung der Methode auf breiter Basis stellen. Dies könnte beispielhaft folgende Maßnahmen beinhalten (vgl. Pichler, 2008, S. 163f.):

Anpassung der Stellenprofile an das Arbeiten in interdisziplinären Teams;
Anpassen der Einstellungskriterien für neue Mitarbeiter;
Anpassen der Fortbildungsprogramme der Mitarbeiter;
Anpassen von Karrierepfaden von Change Master, Process Manager;
Anpassung der Auswahlkriterien für Zulieferer, ihre Organisation ebenfalls agil zu gestalten;
Anpassen von Räumlichkeiten, Infrastruktur und Tools. Hierzu zählt vor allem das Schaffen von geeigneten Gruppenarbeitsräumen für die Anwendung des agilen Prozessmanagements.

Nimmt man nun Scrum als Vorlage für eine weiterführende Diskussion in der unternehmensweiten Anwendung von Scribble, dann sind keine speziellen Voraussetzungen für Branchen oder Unternehmensgrößen beschrieben. Das bedeutet, dass für eine Anwendung der Methode Scribble auch keine Beschränkung für Branche oder Unternehmensgröße existieren sollte.

Für weiterführende Fragen stehe ich Ihnen gerne zur Verfügung und freue mich über Ihre Kommentare zu diesem Artikel.

Weiterführende Literaturverzeichnis

Bea, F./Schnaitmann, H. (1995): Begriff und Struktur betriebswirtschaftlicher Prozesse, in: WiSt, (1995] 6, S. 278-282, Wiesbaden.

Beck, K. et al. (2001): The Agile Maifesto, http://www.agilemanifesto.org, (Abfrage: 18.03.2009).

Becker, J./Kugeler M./Rosemann, M. (2005): Prozessmanagement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung, Wiesbaden.

Binner, H., F. (1997): Integriertes Organisations- und Prozeßmanagement. Die Umsetzung der General Management Strategie durch Integrierte Managementsysteme, München.

Brandstätter, M./ Gölzner, H./Siems, F. (2006): Diversifizierte Kommunikation auf Basis des Event Life Cycle. Eine interdisziplinäre Betrachtung für die Stakeholder Netzwerkpartner, Mitarbeiter und Kunden. In: Proceedings of VI. Interdisziplinäres Symposium „Europäische Kulturen in der Wirtschaftskommunikation (EUKO 2006)”, S. 24-25, Turku.

Cohn, M. (2004): User Stories Applied. For Agile Software Development, Boston.

Csikszentmihalyi, M. (2010): Das flow-Erlebnis. Jenseits von Angst und Langweile: im Tun aufgehen, Stuttgart.

Derby, E./Larsen, D. (2006): Agile Retrospectives. Making Good Teams Great, Boston.

Drucker, P. (1988): The Coming of the New Organization, in: Harvard

Business Review, Vol. 66 (1988), No. l, S. 45-53, Boston.

Drucker, P. (2007): The coming of the new Organization. In: Harvard Business Review on Knowledgement, S. 1-19, Boston.

Fuhrmann, B. (1998): Prozessmanagement in kleinen und mittleren Unternehmen, Wiesbaden.

Frese, E. (1971): Ziele als Führungsinstrumente. Kritische Anmerkungen zum Management by Objectives. In: zfo - Zeitschrift für Führung und Organisation, 1971, S. 227-238, Stuttgart.

Gloger, B. (2008): Scrum. Produkte zuverlässig und schnell entwickeln, München.

Goldman, S., L./Nagel, R., N./Preiss, K. (1995): Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer. New York.

Grasl, O. (2004): Prozessorientiertes Projektmanagement. Steuerung von IT-Projekten mit integrierten Projektinformationssystemen, Wiesbaden.

Hall, R. (1987): Organizations: Structures, Processes and Outcomes, 4. Aufl., New York.

Hauschildt, J./Chakrabarti, A. (1988): Arbeitsteilung im Innovationsmanagement - Forschungsergebnisse, Kriterien, Modelle. In: zfo - Zeitschrift für Führung und Organisation, 57. Jg., S. 378-388, Stuttgart.

Hauschildt, J./Gemünden, H., G./Witte, E. (1999): Promotoren: Champions der Innovation, Wiesbaden.

Boos, F./Heitger, B. (2004): Veränderung – systemisch. Management des wandels – Praxis, Konzepte und Zuknft, Stuttgart.

Hinkelmann, K. et al. (2002): Geschäftsprozessorientiertes Wissensmanagement: Effektive Wissensnutzung bei der Planung und Umsetzung von Geschäftsprozessen, Wiesbaden.

Kosiol, E. (1972): Organisation der Unternehmung, Wiesbaden.

Kosko, B. (1993): Fuzzy Thinking: The New Science of Fuzzy Logic, New York.

Kugeler, M. (2000): Informationsmodellbasierte Organisationsgestaltung, Berlin.

Lewin K. (1951): Field Theory in Social Science, New York.

Morgan, G. (2002): Bilder der Organisation, 3. Aufl., Stuttgart.

Morgan, J., M./Liker, J., K. (2006): The Toyota Product Development System. Integrating

Peole, Process and Technology, New York.

Nonaka, I./Takeuchi, H. (1998): The Knowledge-Creativing Company. How Japanese Companies Create The Dynamics Of Innovation, New York.

Oesterreich, B./Weiss, C. (2008): APM - Agiles Projektmanagement. Erfolgreiches Timeboxing für IT-Projekte, Heidelberg.

Ohno, T. (1988): Toyota Production System. Beyond Large Scale Production, Cambridge.

Osterloh, M./Frost, J. (2006): Prozessmanagememt als Kernkompetenz. Wie Sie Business Reengineering strategisch nutzen können, 5. Auflage, Wiesbaden.

Pichler, R. (2008): Scrum. Agiles Projektmanagement erfolgreich einsetzen, Heidelberg.

Pfitzinger, E. (2002): Der Weg von DIN EN ISO 9000 FF zu total Quality Management, Berlin.

Porter, M. (1998): On Competition, New York.

Robbins, P. (2001): Organisation der Unternehmung, 9. Aufl., München.

Rosenkranz, F. (2002): Geschäftsprozesse. Modell- und computergestützte Planung, Heidelberg.

Schmelzer, H./Sesselmann, W. (2002): Geschäftsprozessmangement in der Praxis, München.

Scholl, W. (2004): Grundkonzepte der Organisation. In H. Schuler (Hrsg.), Lehrbuch der Organisationspsychologie, 3. Aufl., S. 515-556, Bern.

Schwaber, K./Beedle, M. (2001): Agile Software Development with Scrum, New York.

Schwaber, K. (2004): Agile Project Management with Scrum, Redmond.

Schwaber, K. (2007): The Enterprise and Scrum, Redmond.

Senge, P., M. (2003): Die fünfte Disziplin, 9. Auflage, Stuttgart, New York.

Stolzenberg, K./Heberle, K. (2006): Change Management. Veränderungsprozesse erfolgreich gestalten - Mitarbeiter mobilisieren, Heidelberg.

Takeuchi, H./Nonaka, I. (1986): The New Product Development Game. Stop Running The Race And Start Rugby. In: Harvard Business Review. Jan-Feb 1986, S. 137-146, Boston.

von Rosenstiel, L. (2000): Grundlagen der Organisationspsychologie, Stuttgart.

von Rosenstiel, L. (2003): Grundlagen der Führung. In: Rosenstiel, L.v./Domsch, M., E. (Hrsg.), Führung von Mitarbeitern. Handbuch für erfolgreiches Personalmanagement, S. 3-15, Stuttgart.

Wächter, H./Vedder, G. (2001): Qualitätsmanagement in Organisationen. DIN ISO 9000 und TQM auf dem Prüfstand, Wiesbaden.

Ward, A., C. (2007): Lean Product and Process Development. Lean Enterprise Institute, Cambridge.

Weick, K. (1995): Der Prozess des Organisierens, Frankfurt a. Main.

Wirdemann, R. (2009): Scrum mit User Stories, München, Wien.

Witte, E. (1973): Organisation für Innovationsentscheidungen. Das Promotorenmodell. Schriften der Kommission für wirtschaftlichen und sozialen Wandel, Band 2, Göttingen.

Witte, E./Hauschildt, J./Grün, O. (1989): Innovative Entscheidungsprozesse: die Ergebnisse des Projektes "Columbus", Tübingen.

Wojda, F. (2000): Innovative Organisationsformen. Neue Entwicklungen in der Unternehmensorganisation, Stuttgart.

Womack, J., P./Jones, D., T. (1996): Lean Thinking, Auf dem Weg zum perfekten Unternehmen, 1. Aufl., München.

Organisationsgestalter.de

Seiten

Montag, 30. Dezember 2013

Denkanstösse zum Jahreswechsel

Die Führung unserer Unternehmen liegt großteils in den Händen schon längst verstorbener Personen

Montag, 9. Dezember 2013

Scribble - eine agile Methode zur Einführung und Umsetzung von Prozessmanagement in der Unternehmensorganisation