Nur wenige Projekte zur Einführung von Dokumentenmanagement-Systemen bringen ihren Kunden den Nutzen, den diese sich davon erhoffen. Im vierten Teil unserer Serie beschäftigen wir uns mit der Unterstützung von Wissensprozessen durch ein DMS. Dabei orientieren wir uns an den Anforderungen, die ein Adaptive Case Management an die gemeinsame Dokumentenplattform eines Projektteams stellt.
In den beiden letzten Artikeln unserer Serie hatten wir uns mit den Beschränkungen beschäftigt, die die Workflow-Ideologie in ihren engstirnigen Varianten mit sich bringt. /1/ In unserem heutigen Artikel werden wir ganz positiv. Es geht um die Ablagestruktur in einem größeren Projekt. Und zwar sehen wir erst einmal von jeder Software-Unterstützung ab, sondern behandeln das Thema nur mit Bordmitten und auf Windows-Ebene. Denn es geht zuallererst um die notwendige Denkweise für das Projektteam. Und erst dann deren Abbildung in Programmstrukturen.
Die Calmann Anlagenbau AG (CAAG) ist auf den Bau von Kraftwerken auf dem Sektor Kohle und Gas spezialisiert. Weltweit wickelt sie ca. 25 Projekte jeweils gleichzeitig ab. Jedes Bauprojekt dauert vom Start bis zur Realisierung zwischen drei und fünf Jahren. Jedes Projektteam gliedert sich in mehrere Unterteams. Die wichtigsten davon sind das Bau-Team, das Team für Verfahrenstechnik und das Team für Anlagensteuerung. Die Projekte gehorchen einer gemeinsamen Grobstruktur, die aber sehr variabel auf die Projektgröße und das nationale Umfeld angepasst werden müssen.
Die Hauptrisiken des Projekts entstehen in der Umsetzungsphase. Hier müssen die Unterteams weitgehend parallel arbeiten, wobei aber jede Änderung in einer Teilaufgabe Auswirkungen auf die anderen Teilaufgabe und die anderen Unterteams zu Folge hat. Der worst case würde dann eintreten, wenn sich bei der Inbetriebnahme herausstellt, dass einige Teilprodukte nicht zusammen passen.
Dieses Risiko gilt es zu minimieren. Eine Projektablage, die einen tagesaktuellen Überblick während der gesamten Projektlaufzeit gewährleistet, ist ein unverzichtbares Erfolgskriterium.
Wichtig ist auch eine gute Dokumentation. Im Projekt entstehen viele Dokumente (eine hohe dreistellige bis vierstellige Zahl), die auch nach Projektabschluss noch benötigt werden.
In der Abbildung 1 sind beispielhaft drei Projektordner aufgeführt:
Wie soll die oberste Ordnerebene innerhalb eines Projekts aussehen? Die CAAG managt ihre Projekte mit PRINCE2 und der Begriff der „Projektprodukte“ ist den Beteiligten kein Fremdwort. Deshalb soll der Produktstrukturplan die Grundlage für die Projektplattform bilden.
Die Aufteilung des Gesamtproduktes in Teilprodukte geschieht nicht nach theoretischen Regeln, sondern nach Zweckmäßigkeit. Das Gesamtprodukt „neues Haus“ des Projekts „Hausbau“ könnte man nach Bestandteilen des Hauses gliedern (Fundament, Außenhülle, Innenausbau, Gebäudetechnik usw.) oder nach Gewerken. Was sinnvoller ist, entscheidet die Praxis.
Beispiel: Der Projektleiter der CAAG diskutiert in einem Workshop mit den Beteiligten eines großen Projekts, welche Produkte im Rahmen des Gesamtprojekts ILLER.2013.040.XA5.ERW_BAU sinnvoll unterschieden werden können.
Das ist gar nicht so einfach. Ist ein Leistungsverzeichnis (LV) ein sinnvolles Teilprodukt? Oder lautet das Teilprodukt besser „Ausschreibung Verfahrenstechnik“ und das LV ist nur ein Teil der Ausschreibung? Wenn man noch nie einen Produktstrukturplan erstellt hat, ist man schnell dabei, sich einige Stunden lang an solchen Fragen festzubeißen.
Am Ende aber sind alle Beteiligte ganz zufrieden. Sie haben sich auf einen sehr logischen Produktstrukturplan geeinigt (siehe Abbildungen 2 und 3).
Es stellt sich heraus, dass es fünf Produkte im Projekt gibt, die man gut funktional zuordnen kann: für jedes dieser Teilprodukte ist jeweils eine Abteilung eigenständig verantwortlich. (siehe Abbildung 6). Allerdings kann eine Änderung im „eigenen“ Teilprodukte erhebliche Konsequenzen für andere Projektbeteiligte aus anderen Abteilungen haben. Dazu aber weiter unten.
Daneben gibt es sechs übergreifende Produkte, für die die Abteilungen jeweils zusammenarbeiten (Abbildung 3). Zum Beispiel müssen am Antrag für die Betriebsgenehmigung die drei Abteilungen Bau, Stahlbau und Verfahrenstechnik Angaben liefern. Das gleiche gilt für die europaweite Ausschreibung für die Bauausführung.
Beispiel: Die Projektgruppe der CAAG einigt sich darauf, ein Produkt „Aufträge“ zu definieren (eigentlich sind es x Produkte, denn jeder Auftrag wäre in diesem Sinne ein Produkt). Dabei handelt es sich um alle Geräte und Dienstleistungen, die ohne Ausschreibung vergeben werden. Normalerweise sind diese Aufträge einem der anderen Produkte zuzuordnen, denn für die Erstellung dieses Produkts erbringen sie eine zusätzliche Leistung. Aber es gibt eben auch Ausnahmen, in denen z. B. ein Prüfauftrag mehrere andere Produkte betrifft. Außerdem ist hier der Überblick sehr wichtig: „Welche Leistungen haben wir denn gerade vergeben?“ Das ist ein gutes Beispiel für eine pragmatische Entscheidung.
Beim Thema „Aufträge“ hatten wir das schon am Beispiel gesehen. Bei einem größeren Bauprojekt kann es Dutzende von Aufträgen an externe Dienstleister geben. Aber auch ein Grundstückskauf kann mehrfach vorkommen: Zum einen, weil die benötigte Fläche sich aus mehreren Flurstücken mit mehreren Eigentümern zusammensetzt. Zum anderen, weil sich bisweilen im Verlauf des Projekts die Notwendigkeit ergibt, die Fläche zu erweitern und noch mitten in der Bauphase angrenzendes Gelände für einen größeren Parkplatz zu erwerben ist.
Das führt uns zum Begriff des Prozesses. Ein Prozess ist eine zusammenhängende Kette von Aktivitäten mit einem Auslöser und einem klar definiertem Produkt oder „Output“. Das Produkt muss einem Abnehmer („Kunden“) einen Nutzen stiften. Der Begriff des Prozesses ist in Abbildung 4 schematisch dargestellt.
Mithilfe des gleichen Prozesses können nun verschiedene Einzelprodukte
erzeugt werden. Zum Beispiel wird der Prozess „Aufträge vergeben“ mit
seiner Tätigkeitskette bei jedem zu erteilenden Auftrag wieder von neuem
durchlaufen. (siehe Abbildung 5).
Diese Überlegungen führen dazu, unterhalb des Projekts nicht gleich die Produkte anzusiedeln, sondern eine Hierarchiestufe „Prozesse“ dazwischenzuschalten. Abbildung 6 stellt das schematisch dar.
In den beiden letzten Artikeln unserer Serie hatten wir uns mit den Beschränkungen beschäftigt, die die Workflow-Ideologie in ihren engstirnigen Varianten mit sich bringt. /1/ In unserem heutigen Artikel werden wir ganz positiv. Es geht um die Ablagestruktur in einem größeren Projekt. Und zwar sehen wir erst einmal von jeder Software-Unterstützung ab, sondern behandeln das Thema nur mit Bordmitten und auf Windows-Ebene. Denn es geht zuallererst um die notwendige Denkweise für das Projektteam. Und erst dann deren Abbildung in Programmstrukturen.
Das Beispiel
Was wir unter einem Projekt verstehen und seinen Prozessen und Produkten, erläutern wir am besten an einem Beispiel:Die Calmann Anlagenbau AG (CAAG) ist auf den Bau von Kraftwerken auf dem Sektor Kohle und Gas spezialisiert. Weltweit wickelt sie ca. 25 Projekte jeweils gleichzeitig ab. Jedes Bauprojekt dauert vom Start bis zur Realisierung zwischen drei und fünf Jahren. Jedes Projektteam gliedert sich in mehrere Unterteams. Die wichtigsten davon sind das Bau-Team, das Team für Verfahrenstechnik und das Team für Anlagensteuerung. Die Projekte gehorchen einer gemeinsamen Grobstruktur, die aber sehr variabel auf die Projektgröße und das nationale Umfeld angepasst werden müssen.
Die Hauptrisiken des Projekts entstehen in der Umsetzungsphase. Hier müssen die Unterteams weitgehend parallel arbeiten, wobei aber jede Änderung in einer Teilaufgabe Auswirkungen auf die anderen Teilaufgabe und die anderen Unterteams zu Folge hat. Der worst case würde dann eintreten, wenn sich bei der Inbetriebnahme herausstellt, dass einige Teilprodukte nicht zusammen passen.
Dieses Risiko gilt es zu minimieren. Eine Projektablage, die einen tagesaktuellen Überblick während der gesamten Projektlaufzeit gewährleistet, ist ein unverzichtbares Erfolgskriterium.
Wichtig ist auch eine gute Dokumentation. Im Projekt entstehen viele Dokumente (eine hohe dreistellige bis vierstellige Zahl), die auch nach Projektabschluss noch benötigt werden.
Der Produktstrukturplan
Wie könnte eine Dokumentenordnung für ein solches Projekt aussehen? Als erstes gilt es, eine Projektplattform zu schaffen. Es gibt einen Ablageort für Projekte und dort wird für jedes Projekt ein Projektordner angelegt. Das heißt, die Oberflächenstruktur sieht dann folgendermaßen aus: |
| Abbildung 1 – Ordner mit Projektbezeichnungen |
- EMDEN.2013.011.9AT.BLOCK2
- ILLER.2012.085.XA5.NEUBAU
- ILLER.2013.040.XA5.ERW_BAU
Wie soll die oberste Ordnerebene innerhalb eines Projekts aussehen? Die CAAG managt ihre Projekte mit PRINCE2 und der Begriff der „Projektprodukte“ ist den Beteiligten kein Fremdwort. Deshalb soll der Produktstrukturplan die Grundlage für die Projektplattform bilden.
Was ist der Projektstrukturplan?
Jedes Projekt erzeugt ein nützliches Produkt. Dieses Produkt kann man in Teilprodukte aufteilen, um zum Beispiel Arbeitspakete besser zuordnen zu können und insgesamt um Komplexität zu reduzieren.Die Aufteilung des Gesamtproduktes in Teilprodukte geschieht nicht nach theoretischen Regeln, sondern nach Zweckmäßigkeit. Das Gesamtprodukt „neues Haus“ des Projekts „Hausbau“ könnte man nach Bestandteilen des Hauses gliedern (Fundament, Außenhülle, Innenausbau, Gebäudetechnik usw.) oder nach Gewerken. Was sinnvoller ist, entscheidet die Praxis.
Beispiel: Der Projektleiter der CAAG diskutiert in einem Workshop mit den Beteiligten eines großen Projekts, welche Produkte im Rahmen des Gesamtprojekts ILLER.2013.040.XA5.ERW_BAU sinnvoll unterschieden werden können.
Das ist gar nicht so einfach. Ist ein Leistungsverzeichnis (LV) ein sinnvolles Teilprodukt? Oder lautet das Teilprodukt besser „Ausschreibung Verfahrenstechnik“ und das LV ist nur ein Teil der Ausschreibung? Wenn man noch nie einen Produktstrukturplan erstellt hat, ist man schnell dabei, sich einige Stunden lang an solchen Fragen festzubeißen.
Am Ende aber sind alle Beteiligte ganz zufrieden. Sie haben sich auf einen sehr logischen Produktstrukturplan geeinigt (siehe Abbildungen 2 und 3).
 |
| Abbildung 2 – Der Produktstrukturplan eines Projekts der CAAG (Teil 1) |
 |
| Abbildung 3 – Der Produktstrukturplan eines Projekts der CAAG (Teil 2) |
Daneben gibt es sechs übergreifende Produkte, für die die Abteilungen jeweils zusammenarbeiten (Abbildung 3). Zum Beispiel müssen am Antrag für die Betriebsgenehmigung die drei Abteilungen Bau, Stahlbau und Verfahrenstechnik Angaben liefern. Das gleiche gilt für die europaweite Ausschreibung für die Bauausführung.
Beispiel: Die Projektgruppe der CAAG einigt sich darauf, ein Produkt „Aufträge“ zu definieren (eigentlich sind es x Produkte, denn jeder Auftrag wäre in diesem Sinne ein Produkt). Dabei handelt es sich um alle Geräte und Dienstleistungen, die ohne Ausschreibung vergeben werden. Normalerweise sind diese Aufträge einem der anderen Produkte zuzuordnen, denn für die Erstellung dieses Produkts erbringen sie eine zusätzliche Leistung. Aber es gibt eben auch Ausnahmen, in denen z. B. ein Prüfauftrag mehrere andere Produkte betrifft. Außerdem ist hier der Überblick sehr wichtig: „Welche Leistungen haben wir denn gerade vergeben?“ Das ist ein gutes Beispiel für eine pragmatische Entscheidung.
Ablage nach Prozessen und Produkten
Man könnte jetzt einfach unterhalb des Projekts nach Produkten ablegen, aber dem steht eine weitere Überlegung entgegen. Auch hier kommt es vor, dass es zu „Schleifenbildungen“ kommt und dass bestimmte Produkte mehrfach erzeugt werden.Beim Thema „Aufträge“ hatten wir das schon am Beispiel gesehen. Bei einem größeren Bauprojekt kann es Dutzende von Aufträgen an externe Dienstleister geben. Aber auch ein Grundstückskauf kann mehrfach vorkommen: Zum einen, weil die benötigte Fläche sich aus mehreren Flurstücken mit mehreren Eigentümern zusammensetzt. Zum anderen, weil sich bisweilen im Verlauf des Projekts die Notwendigkeit ergibt, die Fläche zu erweitern und noch mitten in der Bauphase angrenzendes Gelände für einen größeren Parkplatz zu erwerben ist.
Das führt uns zum Begriff des Prozesses. Ein Prozess ist eine zusammenhängende Kette von Aktivitäten mit einem Auslöser und einem klar definiertem Produkt oder „Output“. Das Produkt muss einem Abnehmer („Kunden“) einen Nutzen stiften. Der Begriff des Prozesses ist in Abbildung 4 schematisch dargestellt.
 |
| Abbildung 4 – Definition des Begriffs „Prozess“ |
 |
| Abbildung 5 – Vermittels des gleichen Prozesses können mehrere Exemplare des gleichen Produkts erzeugt werden |
Diese Überlegungen führen dazu, unterhalb des Projekts nicht gleich die Produkte anzusiedeln, sondern eine Hierarchiestufe „Prozesse“ dazwischenzuschalten. Abbildung 6 stellt das schematisch dar.
 |
| Abbildung 6 – Unterhalb des Projekts wird eine zweistufige Ordnerhierarchie angelegt |
Diese Ordnung ist eigentlich nichts anderes als ein in „Windows-Strukturen“ gegossenes Adaptive Case Management. Eine Ansammlung von Bausteinen auf 2 Hierarchiestufen (die man auch als Konkretisierungsebenen bezeichnen kann), wobei jeder Baustein sich gegenüber jedem anderen in der zeitlichen Abfolge verschieben kann. Er kann auch wiederholt oder in einem anderen Produkt noch einmal durchlaufen werden oder in manchen Fällen auch ganz übersprungen. Trotzdem liegt eine Normierung vor: das kommt schon in den festen Prozessbezeichnungen zum Ausdruck.
Diesen Überlegungen werden wir im nächsten Artikel genauer nachgehen.
Sie wollen mehr über die gemeinsame Ablage lernen? Dazu gibt es eine Überblicksseite, die wichtige Artikel aus diesem Blog in eine Reihenfolge bringt.
Anmerkungen
- /1/ Wolf Steinbrecher: DMS- und ECM-Projekte zum Erfolg führen (Teil 1): Gründe für das Scheitern von Projekten, Teamworkblog, erschienen am 01. April 2013, abrufbar unter http://www.teamworkblog.de/2013/04/dms-und-ecm-projekte-zum-erfolg-fuhren.html und Wolf Steinbrecher: DMS- und ECM-Projekte zum Erfolg führen (Teil 2): Der Belegworkflow, Teamworkblog, erschienen am 29. April 2013, abrufbar unter http://www.teamworkblog.de/2013/04/dms-und-ecm-projekte-zum-erfolg-fuhren_29.html
Kommentare
Kommentar veröffentlichen