Liebe Leserinnen und Leser,

ich habe den Open Processes Blog bereits Mitte 2012 eingestellt, als ich andere Aufgaben im Konzern übernommen habe. Auch wenn´s etwas spät ist – der Vollständigkeit halber ein letztes Update.

Das Open Processes Projekt, das wir damals gestartet haben und das im November 2011 im Konzern live ging, ist nach wie vor in Betrieb. Und nicht nur das – es wurde Ende 2014 erneut als „Enterprise 2.0 Lighthouse“ ausgezeichnet! Dabei hat sich das Projekt seither zwar von der Reichweite und Nutzungsintensität sehr gut entwickelt, ist konzeptionell aber noch immer auf dem Stand von 2011.

Ich glaube, sowas nennt man „Avantgarde“ 🙂

VG

Andreas Apeldorn


Das Agile Manifest ( http://de.wikipedia.org/wiki/Agiles_Manifest#Werte ) bringt die dahinter stehende Philosophie gut auf den Punkt. Allerdings ist es auf Softwareentwicklung zugeschnitten. Wie könnte ein allgemeineres „Manifest“ aussehen, das auf andere Bereiche übertragbar wäre? Ein Vorschlag.

1.Individuen und Interaktionen sind wichtiger mehr als Hierarchien und Formalismen. Hierarchien und formale Verhaltensregeln sind zwar etabliert, wesentlicher sind jedoch die Qualifikation der Mitarbeitenden und eine effiziente Kommunikation zwischen ihnen.

2.Klare Abnahmekriterien und Zielsetzungen sind wichtiger als umfassende Ablaufdokumentation. Eine gut geschriebene Prozessdokumentation kann zwar hilfreich sein, das eigentliche Ziel ist, dass das Arbeitsergebnis die Erwartungen erfüllt.

3.Zusammenarbeit ist wichtiger als Rollenmodelle Statt sich an ursprünglich formulierten und mittlerweile veralteten Ablauf- oder Rollenbeschreibungen in Prozessdokumentationen festzuhalten, steht vielmehr die fortwährende konstruktive und vertrauensvolle Abstimmung der Beteiligten im Mittelpunkt.

4.Reagieren auf Veränderung mehr als das Befolgen eines Plans. Im Verlauf eines Prozesses ändern sich viele Anforderungen und Randbedingungen ebenso wie das Verständnis des Problemfeldes. Die Beteiligten müssen darauf schnell reagieren können.

Ist das stimmig? Ich bin gespannt auf Ihre Meinung.

… und übrigends:

unsere XING Gruppe: https://www.xing.com/net/pri7ef6a8x/openprocesses/

und der ganze Artikel zu Open Processes: http://www.open-processes.org/index.php/Open_Processes


Unser Pilotprojekt, das Supplier Management, ist in den geregelten Betrieb übergegangen und entwickelt sich sehr gut. Und unsere Open Processes Methode für e 2.0 basiertes Prozessmanagement ist vom Telekom Center of Excellence als Leuchtturmprojekt ausgezeichnet worden, und damit Vorbild für E 2.0 Anwendungen im Telekom Konzern.

Es zeigt sich: Open Processes hat als Methode zum Design und Management von organisations- und unternehmensübergreifenden, wissensbasierten Prozessen erhebliches Potential. Aus diesem Grund werden wir den Open Processes Ansatz weiterentwickeln – gerne auch mit Ihnen gemeinsam.

Wir haben dazu im ersten Schritt eine XING Gruppe eröffnet: http://www.xing.com/net/openprocesses. Die Gruppe richtet sich an alle die wissen, dass Selbstorganisation effektiver ist als Delegation, Knowledge Sharing besser als Information Hiding – und dass moderne Unternehmen moderne Formen der Zusammenarbeit brauchen.

In der Gruppe soll es um
– Hinweise und Diskussion zu aktuellen Beiträgen und Artikeln
– Austausch zu Good Practices aus Basis von Praxisbeispielen und Anwendungsfällen
– Austausch und Diskussion zu offenen Fragen
– Weiterentwicklung der Methodik
– Organisation von Meetups und Events

gehen.

Sie interessieren sich für den Open Processes Ansatz, oder haben selbst Erfahrungen mit dem Einsatz von e 2.0 Ansätzen im Prozessmanagement gemacht? Dann sind Sie herzlich eingeladen, in unsere Gruppe einzutreten. Ich freue mich auf Sie!

Außerdem könnten wir uns gut vorstellen, demnächst ein Meet up zu organisieren, um uns
– erstmal gegenseitig kennenzulernen
– mit einen Good Practice Austausch zu e 2.0 und Prozessmanagement zu beginnen.

Themen könnten z.B.
– Prozessdesign und -management mit E 2.0
– Community buidling
– Praxisbeispiele für den Einsatz von WIKIs, Social Networks etc.

Was meinen Sie? Ich freue mich auf Ihr Feedback!

Ihr

Andreas Apeldorn


Selten hat jemand etwas so schön auf den Punkt gebracht wie Stefan Ehrlich von der T-Systems MMS in Dresden. Nach der Vorstellung unseres „Open Processes“ Vorgehensmodells sah er uns nachdenklich an und meinte dann „…unsere Prozesse sind Open Source. Das ist gut!“. Fanden wir auch.

Schön. Aber was heißt das jetzt konkret? Und betrifft Sie das überhaupt? Eine Art „Management Summary“…

Letztlich geht es doch immer wieder um dieselben Fragen. Darum, wie wir besser zusammenarbeiten können. Wie wir Transparenz schaffen. Wie wir unser Know how optimal nutzen und Synergien entwickeln können, damit nicht ständig alles neu erfunden werden muss. Wie wir uns weiter verbessern können.

Antworten darauf gab es  schon viele – Prozessmanagement ist eine davon. Die auch durchaus Sinn macht. Trotzdem sind wir da jetzt mal anders ran gegangen.

open processes – eigentlich wie Fussball

Die Idee war, das ganze agiler, direkter und zielorientierter anzugehen. So wie im Fussball, zum Beispiel. Da kennt jeder sein Team und ein paar Regeln (…der Ball ist rund, ein Spiel dauert 90 Minuten…). Aber wie genau der Ball ins Eckige kommt – das entscheidet sich im Spiel. Und ein gutes Team gewinnt mit Kreativität, Technik, Teamspirit, Schnelligkeit…. Mit einer Prozesstapete in der Hand würden sich die Spieler wohl eher schwer tun.

Damit sowas wie Fussball auch im Prozessmanagement funktioniert, haben wir ein paar neue Schwerpunkte gesetzt. Eingeflossen sind darin z.B. Gedanken aus der Open Source Community und Ansätze aus dem Wissensmanagement. Außerdem haben wir dabei konsequent die uns zur Verfügung stehenden Enterprise 2.0 Tools verwendet – hauptsächlich das konzernweite WIKI. Was dabei herausgekommen ist, hat mein Kollege Lars Guillium auf eine einfache Formel gebracht:

WIKI + Community – Hierarchie – Formalismus = open processes

Das ist immer noch recht abstrakt. Eine kurze Übersicht über die zentralen Eckpunkte hilft vielleicht weiter:

Collaboratives Prozessdesign und -management
  • Interaktive Meeting Agenden, Action Items, Protokolle
  • Weiterentwicklung der Inhalte durch alle Stakeholder in real-time
Knowledge Management nach GPoWM Prinzipien
  • Good & Best Practices, Arbeitsmittel, Rollen und Ansprechpartner – „roter Faden“ ist der Prozessablauf
Fokus auf Praxiseinsatz
  • Integration von unternehmensrelevanten Social Objects mit Key Informationen und Ansprechpartnern
  • Einfachste Usability (i.e. Tag Clouds, druckbare Checklisten)
Optimierung nach Open Source Prinzipien
  • Freie Editierbarkeit – konzernweit. Bis auf wenige Kernbereiche ist die Dokumentation sind frei editierbar – direktes Feedback ist überall möglich.
  • Meritokratische Strukturen – wer Kompetenz nachweist, bekommt volle Rechte.
Steuerung über KPI
  • Zielvorgaben und Erfolgskontrolle über Key Performance Indikatoren.

Ein Beispiel für die praktische Umsetzung unseres Modells ist die Knowledge Base Supplier Management, die z.B. die Prozessbeschreibung, aber auch „Social Objects“ wie Supplier Dossiers enthält, die konzernweit abrufbar – und auch bearbeitbar sind.

Wir könnten uns vorstellen, das ganze Modell einmal in einer größeren Runde vorzustellen, zu diskutieren und weiterzuentwickeln.

Wie seht es aus? Hätten Sie Interesse? Und welche Fragen sollten wir dann in den Vordergrund stellen? Bin gespannt auf Ihr Feedback!


Nach drei Monaten ist es endlich da! Es heißt Knowledge Base, hat E20 Gene, ist ca. 100 Artikel groß und hat viele Mamies und Papies. Und viele finden, dass es wirklich hübsch geworden ist (Update am 7.2.2011):

Soviel vorne weg: es war keine besonders schwere Geburt… Nur wie ziehen wir es jetzt zusammen groß?

Zur Erinnerung: es ging um ein Experiment. Es ging um das Re-Design eines Know how intensiven Prozesses – Supplier Management. Außerdem, ob E20 Methoden und Techniken dabei helfen können, Prozessmanagement effizienter zu machen. Und ob E20 Ansätze tatsächlich besser als traditionelle Methoden und Tools geeignet sind, Know how im Sinne eines geschäftsprozessorientierten Wissensmanagements (GPoWM) unternehmensübergreifend zu erarbeiten, transparent und anwendbar zu machen (vgl. dazu http://www.dfki.de/web/forschung/km/kompetenz/forschung/geschaftsprozessorientiertes-wissensmanagement. Im Scope lagen WIKIs, Social Networks und Blogs. Zeit, ein erstes Fazit zu ziehen.

The Winner is: WIKI!

Was die berufliche Zukunft angeht, scheint unser WIKI Baby schon mal gut gerüstet zu sein. Das Deutsche Institut für Künstliche Intelligenz wünscht sich für „Wissensarbeitsprozesse“ beispielsweise

  • persönliche Aufgabenlisten, die um jeweils für eine Aufgabe individuell als nützlich empfundene Informationen und Dokumente angereichert werden können
  • Möglichkeiten zum Austausch von relevanten Informationen, die von anderen Mitarbeitern als nützlich für ähnliche Aufgaben angesehen wurden
  • hin zu dem inkrementellen Aufbau einer unternehmensweiten „best practices“-Bibliothek, die Bausteine für etablierte oder empfohlene Vorgehensweisen liefert.

(vgl. http://www.dfki.de/web/forschung/km/kompetenz/forschung/agile-prozesse-fur-wissensarbeit). Haben wir alles drin. – und das war nicht einmal besonders aufwendig, da das WIKI genau für solche Anwendungen wie gemacht ist. Und sonst? Was hat uns der WIKI Einsatz noch gebracht? Ein paar Benefits:

Zunächst prozessual: definitiv Zeitersparnis durch effizientere Abstimmung: Trotz neuer, anfänglich allen Teilnehmern unbekannter Technik und zusätzlichem Aufwand bei der Konzeption und dem Aufbau des WIKIs sind wir auf den Tag genau im Zeitplan geblieben – das ist doch was.

Möglicherweise auch monetär: Zumindest in unserem Fall ist das WIKI deutlich kostengünstiger als die „klassischen“ Tools zur Prozessdarstellung (z.B. ARIS, ADONIS, etc). Wir haben zwar eines zur Modellierung und zur Erstellung von Grafiken verwendet. Aber eigentlich hätte es ein simples Grafikprogramm getan.

Organisatorisch: Unser WIKI hat eine effiziente Berechtigungsverwaltung, dadurch werden neue Möglichkeiten zur Steuerung des Zugriffs und Weiterentwicklung der Inhalte geschaffen. Wir haben das WIKI erstmal für alle WIKI User freigeschaltet – jeder kann es sehen, kommentieren, und sogar neue Seiten erstellen. Einige wenige Funktionen sind dem Kernteam vorbehalten – z.B. Seiten zu beschränken oder zu löschen. Die konzernweite Verfügbarkeit des WIKIs bringt zudem Vorteile beim Roll-out und der übergreifenden Vernetzung zum Thema

Qualitativ: das WIKI führt zu einer vereinfachten Darstellung und Suche – dazu gab es ein durchweg positives Feedback von allen Seiten. Zusätzlich erwarten wir – basierend auf den Erfahrungen aus dem Re-Design Projekt – eine dauerhaft höhere Konsistenz und Qualität der Inhalte durch das WIKI Prinzip.

Und es gibt nichts Negatives? Keinen Nachgeschmack? Ehrlich gesagt: doch. Die aktive Beteiligung des Teams beim Aufbau der Knowledge Base hätte etwas höher sein können. Letztlich haben nur wenige Kollegen (4 von 15) aktiv Inhalte erstellt. Die übrigen haben zwar gelesen und ihre Inputs in den Workshops eingebracht. Das könnte aber noch besser werden. Eine Ursache waren fehlendes Know how über die Bedienung / Benefits des WIKIs. Es war ja auch noch alles recht neu. Jetzt haben wir aber Erfahrungswerte und praktische Beispiele. Beim nächsten Mal werden wir deswegen gleich zu Anfang des Projektes eine E20 / WIKI Schulung durchführen. Was die anderen E20 Techniken angeht (Blogs, Social Networks), haben sie bisher eher ein Schattendasein geführt. Das könnte sich jetzt aber ändern.

Fazit: Alle Ziele erfüllt? Zunächst ja…

Aber wie geht es jetzt weiter? Unser Baby lebt, aber wird es auch wachsen und irgendwann selbstständig laufen lernen? Das ist jetzt noch längst nicht sichergestellt.

Und jetzt? Community Building!

Ich gehe davon aus, dass Know how ist nur dann wirklich attraktiv ist, wenn man sieht, was man daraus machen kann – und außerdem die Möglichkeit hat, die Köpfe hinter den Kulissen kennenzulernen und seinen eigenen Input dazuzugeben. Dazu überlegen wir aktuell verschiedene Ansätze.

Ein wesentlicher Trigger wird die „Operationalisierung“ unserer Knowledge Base sein. Dazu werden wir im WIKI beispielsweise „Supplier Dossiers“ entwerfen, in denen Informationen zu den Suppliern, deren Historie im Konzern, laufenden Projekten, SLA und QLA sowie Ansprechpartnern enthalten sein können. Die Pages werden natürlich frei editierbar sein, sodass alle Kollegen, die mit dem Supplier in Kontakt stehen, die Inhalte ergänzen und diskutieren können. Da sie durch ihre Beiträge auch für andere sichtbar werden, entsteht auf diese Weise auch eine Möglichkeit, diese Kollegen untereinander zu vernetzen – unterstützt durch Social Networks. Könnte spannend werden.

Als weiterer Trigger kommen beispielsweise Formate in Frage, in denen Kollegen Good Practices vorstellen und diskutieren können. Dazu ist die WIKI Plattform selbst schon mal gut geeignet – wir haben wie bereits erwähnt allen Nutzern Schreibberechtigung gegeben. Ergänzend dazu werden wir in der Kommunikation auch verstärkt auf Blogs setzen. Zusätzlich denken wir auch darüber nach, weitere, reale „Event“-Formate für das Community Building zu verwenden – i.e. Barcamps, Vorträge, Fishbowls etc. Denn rein virtuell klappt eine echte Vernetzung selten.

Dazu aber demnächst mehr. Nach der Abnahme unseres „Re-Design Projektes“ haben wir erstmal den Auftrag, einen Projektauftrag für die Implementierung zu erstellen. Danach sehen wir weiter.

Ich glaube, es bleibt spannend. So ein Baby ist halt doch was Nettes 🙂


Das Grobkonzept für unseren Prozess ist entwickelt und in unserer WIKI-basierten Process Knowledge Base dokumentiert. Wir haben jetzt dem Feinkonzept begonnen. Das Projektende naht also, und immer deutlicher zeichnet sich ab, wie unsere WIKI basierte Knowledge Base tatsächlich aussehen wird. Wir befinden uns damit im Landeanflug – und ich möchte Ihnen einen ersten Blick auf unser Ziel nicht vorenthalten. Natürlich bin ich auch gespannt auf Ihr Feedback!  

Die Herausforderung ist jetzt, unserer Knowledge Base „Leben“ einzuhauchen. Ziel ist, die Knowledge Base zu einem echten SPOI (Single Point of Information) auszubauen, die sowohl Fragen nach dem „was soll ich jetzt eigentlich machen?“ auch „… und wie komme ich dahin?“ oder „und was bringts?“ Fragen beantworten kann. Neben der „reinen“ Prozessdokumentation, über die alle prozessrelevanten Themen dokumentiert und interaktiv verlinkt sind (vgl. dazu No Thrills! Unsere Prozessdokumentation im WIKI) werden wir deswegen auch Links zu Arbeitsmitteln (Systemen, Templates, Guidelines, Rankings), konkreten Ansprechpartnern und den Prozessergebnissen (i.e. aktuelle KPI Reports) einbauen.

WIKI Artikel zu Prozessen

Zunächst ein Beispiel für einen Artikel, wie wir ihn für unserer Prozessbeschreibung verwenden. Vieles dürfte dabei Standard sein. Ich werde deswegen nur auf die „aus WIKI Sicht“ oder „aus User Sicht“ wichtigen Bestandteile eingehen.

Beispiel für einen WIKI Artikel über einen Prozess
Beispiel für einen WIKI Artikel über einen Prozess

Die „Einleitung“

Wie alle WIKI – Artikel beginnt auch dieser mit einer kurzen Einleitung, die den Inhalt des Artikels umreisst. Einleitungen sind natürlich generell sinnvoll, bei uns hat sie aber noch eine besondere Bedeutung. Da die Suchfunktion unseres WIKI neben dem Artikelnamen auch immer die ersten Textzeilen anzeigt, ist eine kurze und knappe Einleitung eine sehr gute Orientierungshilfe. 

Die „Story“ 

Die Story soll auf den Punkt bringen, warum der Prozess aus Sicht des Unternehmens wichtig ist. Vorbild sind die User Stories aus der Agilen Software Entwicklung, konkret SCRUM, wo sie für Anforderungsdefinitionen verwendet werden und aufgrund ihrer kurzen, knappen Art „traditionellen“, umfassenden Anforderungsspezifikationen den Rang ablaufen.

Im Prozessmanagement wirken User Stories wie ein Elevator Pitch – in einem Satz kann dargestellt werden, warum der Prozess oder die Tätigkeit für das Unternehmen sinnvoll sind. Wir erwarten dadurch eine höhere Akzeptanz im Management und bei den Mitarbeitern.

User Stories sind grundsätzlich nach folgendem Muster aufgebaut: „As a , I want so that “ (vgl. i.e. http://en.wikipedia.org/wiki/User_story).

Bei Prozessen setzen wir für die Rolle den Process Owner, der – stellvertretend für „das Unternehmen“ – der ja für die Zielerreichung des Prozesses verantwortlich ist. Alle Stories müssen die Prozessziele direkt unterstützen.

In unserem Beispiel sieht eine Story für den Teilprozess „Qualification“ das dann z.B. so aus: Als Process Owner für den Supplier Management Prozess möchte ich sicherstellen, dass alle Requests mit Supplier Bezug erfasst und für diese aus Unternehmenssicht geeignete Supplier identifiziert werden.“ Damit zahlt der Prozess auf das Oberziel „Steigerung des Kosten- Nutzen Verhältnisses“ ein, das über die KPI „Entwicklung Kommerzielle Lieferantenbeurteilung Soll/ Ist“ bzw. „Lieferantenbeurteilung Innovation/ Strategie“ gemessen wird. 

Die „Vorteile“

Die Vorteile sind aus Sicht der Anwender beschrieben. Im Gegensatz zu den Stories, die die Notwendigkeit aus Sicht des Unternehmens beschreiben, sollen die „Vorteile“ noch einmal die Benefits für die tägliche Arbeit der unterschiedlichen Beteiligten transparent machen.

Im Fall unseres Beispiels „Supplier Qualification“ sind das z.B. Transparenz über Anzahl und Art der geeigneten Lieferanten, Transparenz über Anzahl, Art, Umfang der Requests, oder die Vorauswahl von Suppliern in Abstimmung mit den Konzernvorgaben.

WIKI Artikel über Tätigkeiten

Die Artikel zu den einzelnen Tätigkeiten sind ein zentraler Bestandteil der Knowledge Base. Während die Prozessbeschreibungen – trotz Stories, Vorteilen etc. – eher Übersicht und Orientierung bringen, beinhalten die Artikel zu den Tätigkeiten eine Art Guideline, die über Tags leicht gefunden und bei Bedarf über die Druckfunktionen als One-Pager (oder Two-Pager) ausgedruckt und auf den Schreibtisch gelegt werden kann. Tätigkeitsartikel enthalten das vollständige Know how, das zur Planung und Durchführung der Aufgabe notwendig ist – oder sind zumindest damit verlinkt. Anbei ein kurzes, selbsterklärendes Beispiel:

Beispiel für einen WIKI Artikel über eine Tätigkeit

Nach wie vor befinden wir uns im Entwicklungsstadium. An einigen Stellen wirkt das WIKI noch etwas unbeholfen. Da in z.B: keine interaktiven Grafiken möglich sind, behelfen wir uns mit etwas unübersichtlichen Link Listen… 

Es ist also durchaus möglich, dass sich noch das eine oder andere ändert. Trotzdem – unser Ziel kommt langsam in Sicht. 

Gerade deswegen bin ich auch gespannt auf Ihre Einschätzung: könnten Sie sich vorstellen, eine ähnliche Vorgehensweise zu verwenden? Und wenn ja – für welche Themen? Wenn nein – wo und warum nicht? 

Ich freue mich auf Ihr Feedback!

PS: Sorry für das „Ausgrauen“ der Grafiken. Bei aller E20 Euphorie möchte ich aber nicht in Teufels Küche kommen…