Direkt zum Hauptbereich

DMS- und ECM-Projekte zum Erfolg führen (Teil 4): Ein Beispiel für eine Projektablage

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.

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
In der Abbildung 1 sind beispielhaft drei Projektordner aufgeführt:
  • EMDEN.2013.011.9AT.BLOCK2
  • ILLER.2012.085.XA5.NEUBAU
  • ILLER.2013.040.XA5.ERW_BAU
Die Namen kommen aus dem Projektportfolio von CAAG und stellen für uns einfach willkürliche Bezeichnungen dar.

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)
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.

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“
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).

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

Kommentare

Beliebte Posts aus diesem Blog

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Den passenden Job finden

Hier teile ich, wie ich daran arbeite, endlich den richtigen Job zu finden. Kleingedrucktes: Dieser Artikel richtet sich (natürlich) an jene, die gerade in der luxuriösen Position sind, dass sie nicht jedes Angebot annehmen müssen. Anstatt von Engagement zu Engagement zu hetzen und frustriert zu sein über Konzernstrukturen, fehlende Ausrichtung und die Erkenntnis, dass in einem selbst beständig die Hintergrundfrage nagt, ob es das ist, womit man seine immer knapper werdende Lebenszeit wirklich verbringen möchte, gibt es manchmal auch die Möglichkeit, die nächste berufliche Station etwas nachhaltiger auszusuchen - auch, um tatsächlich (etwas) mehr beitragen zu können.

Die Microsoft Teams-Not-To-Do-Liste

Viele hoffen, dass es  für die Einrichtung von Microsoft Teams  den Königsweg gibt, den perfekten Plan – doch den gibt es leider (oder glücklicherweise?) nicht. Genauso wenig, wie es jemals einen Masterplan für die Organisation von Gruppenlaufwerken gab, gibt oder je geben wird. Was gut und vernünftig ist hängt von vielen Faktoren und ganz besonders den Unternehmensprozessen ab. Sicher ist nur eines: Von alleine entsteht keine vernünftige Struktur und schon gar keine Ordnung. Dafür braucht es klare Entscheidungen.

Agilität ist tot. Ausgerechnet jetzt?

Agilität wird zurückgefahren, Hierarchien kehren zurück. Doch ist das wirklich der richtige Weg in einer Welt, die immer unberechenbarer wird? Oder erleben wir gerade eine riskante Rolle rückwärts?

Wie beschreibt man einen Workshop für eine Konferenz?

Konferenzen bieten immer ein gutes Forum, um sein Wissen und seine Erfahrungen zu teilen. Was für die Vortragenden selbstverständlich scheint, ist für die Besucher:innen oft unverständlich. Wie können Vortragende ihren Workshop in 2-3 Sätzen beschreiben, damit die Besucher:innen schnell einschätzen können, er sich für sie lohnt?

Gemeinsam eine Anwenderdokumentation erstellen

Unternehmenssoftware ist ein wichtiges Bindeglied zwischen Anwenderinnen und Anwendern, den Unternehmensprozessen und den Ergebnissen. Normalerweise schreibt der Hersteller der Software die Dokumentation für diejenigen, die die Software benutzen. Wenn die Software allerdings stark angepasst wurde, muss die Dokumentation von denen kommen, die die Prozessmaschine am besten verstehen - den Anwenderinnen und Anwendern. Wie könnte man das praktisch machen?

Der Softwareeisberg, die Softwarepyramide - Wie sprechen wir über neue Software?

Software ist aus den Geschäftsprozessen vieler Unternehmen nicht mehr wegzudenken. Sie verwaltet Kunden- und Produktdaten. Sie automatisiert Abläufe und verhindert Fehler. Aber Software veraltet. Was machen wir, wenn wir Unternehmenssoftware erneuern müssen? Von den ersten Konzepten bis zum ersten Release ist es ein weiter Weg, mit vielen Entscheidungen. Wie sprechen wir über diese Entscheidungen?