Die Projektdokumentation eines Automobil-Finanzdienstleisters basierte auf mehr als 100 Ergebnistypen, verteilt über mehr als zehn Projektrollen, mehrere Modellvarianten und unterschiedliche Projektphasen. Die
Die Projektdokumentation eines Automobil-Finanzdienstleisters basierte auf mehr als 100 Ergebnistypen, verteilt über mehr als zehn Projektrollen, mehrere Modellvarianten und unterschiedliche Projektphasen. Die benötigten Informationen lagen bereits in datenführenden Systemen vor – wurden jedoch manuell in Dokumente übertragen, dort mehrfach gepflegt und manuell geprüft. Das Ergebnis: Redundanzen, Inkonsistenzen und erheblicher Koordinations- und Nacharbeitsaufwand.
Ein modell- und datengetriebener Ansatz sollte das ändern. Auf Basis eines semantischen Informationsmodells und eines angepassten Dokumentengenerators wurden im Proof of Concept drei spezifische Ergebnistypen vollständig automatisiert erstellt. Ergebnis: Der manuelle Aufwand sank von rund zwei Wochen (ca. 4.800 Minuten) auf maximal 30 Minuten – eine Reduktion um 99,4 Prozent.
Ausgangssituation: Dokumente als Engpass der Projektdokumentation
Die Projektdokumentation des Kunden basierte auf definierten Ergebnistypen. Diese Ergebnistypen waren an Projektphasen gekoppelt und bildeten eine wesentliche Grundlage für Qualitätssicherung, Nachvollziehbarkeit und Freigabeentscheidungen.
In der Theorie war dieses Vorgehen nachvollziehbar: Ein vollständiges und korrektes Dokument sollte belegen, dass die geforderten Ergebnisse einer Projektphase erbracht wurden. In der Praxis zeigte sich jedoch, dass Dokumente für diese Aufgabe nur eingeschränkt geeignet waren, sobald Umfang, Variantenvielfalt und Änderungsdynamik zunahmen.
Mehrere Eigenschaften dokumentenzentrierter Arbeit erwiesen sich als problematisch:
- Aktualität: Dokumente bilden häufig nur den Stand zum Zeitpunkt ihrer Erstellung oder letzten Überarbeitung ab. Ändert sich das beschriebene System, ist das Dokument nicht automatisch aktuell.
- Konsistenz: Wenn sich während der Dokumentenerstellung fachliche Inhalte, Systemzustände oder Verantwortlichkeiten ändern, entstehen leicht Abweichungen zwischen Dokument und Realität.
- Änderungsmanagement: Änderungen an Systemen werden nicht automatisch in den zugehörigen Dokumenten sichtbar. Ebenso werden abhängige Dokumente oder betroffene Stakeholder nicht automatisch informiert.
- Redundanz: Viele Informationen existieren bereits in datenführenden Systemen oder werden in mehreren Dokumenten parallel gepflegt.
- Perspektive: Dokumente bilden Informationen meist in einer festen Struktur und Darstellung ab. Rollen-, phasen- oder kontextspezifische Sichten müssen häufig manuell abgeleitet werden.
- Automatisierbarkeit: In manuell erstellten Dokumenten liegen fachliche Informationen häufig unstrukturiert oder nur schwach strukturiert vor. Dadurch gehen Kontext, Bedeutung und maschinelle Prüfbarkeit weitgehend verloren.
- Prüfbarkeit: Die Qualität eines Dokuments lässt sich nur eingeschränkt automatisiert bewerten, wenn fachliche Aussagen nicht eindeutig mit Datenquellen, Regeln oder Modellinstanzen verknüpft sind.
- Vergleichbarkeit: Inhalte, Struktur und Darstellung sind nicht immer einheitlich definiert. Dadurch wird es schwierig, Ergebnisse projektübergreifend oder phasenübergreifend zu vergleichen.
- Verantwortung: Dokumente werden häufig von mehreren Personen in unterschiedlichen Rollen befüllt. Die Verantwortung für einzelne Inhalte ist dadurch nicht immer eindeutig nachvollziehbar.
- Skalierbarkeit: Änderungen an Dokumentstruktur, Pflichtinhalten oder Darstellungsformen führen schnell zu hohem Anpassungsaufwand in bestehenden und laufenden Projekten.
Diese Effekte verstärkten sich im laufenden Betrieb. Es gab mehrere Varianten des Projektmodells, darunter klassische und agile Ausprägungen, jeweils in unterschiedlichen Versionen. Pro Variante wurden über die Projektlaufzeit mehr als 100 Ergebnistypen beziehungsweise Dokumente erstellt, ergänzt und angepasst.
Hinzu kamen mehr als zehn verschiedene Projektrollen, darunter Fachbereichsverantwortliche, Projektmanager, Tester, Entwickler und weitere Spezialisten. Viele Personen arbeiteten parallel in mehreren Projekten und teilweise in unterschiedlichen Rollen. Dadurch mussten sie nicht nur ihre fachlichen Aufgaben erfüllen, sondern auch wissen, welche Informationen in welcher Rolle, in welcher Projektphase, in welchem Dokument, in welcher Modellvariante und in welcher Modellversion zu pflegen waren.
Die Herausforderung bestand somit nicht allein im Schreiben von Dokumenten. Das eigentliche Problem lag in der Koordination, Strukturierung, Prüfung und Wiederverwendung von Informationen über viele Rollen, Projektphasen und Werkzeuge hinweg.
Systemanalyse: Die eigentlichen Kernprobleme
Die zentrale Erkenntnis der Analyse war: Die meisten Informationen, die in der Dokumentation benötigt wurden, existierten bereits. Sie lagen jedoch verteilt über unterschiedliche Management-, Entwicklungs-, Test- und Organisationswerkzeuge vor.
Die manuelle Übertragung dieser Informationen in Dokumente erzeugte deshalb keinen zusätzlichen fachlichen Wert. Sie verursachte vielmehr Aufwand, Redundanz und potenzielle Fehler. Informationen wurden aus datenführenden Systemen entnommen, in Dokumente übertragen, dort anders dargestellt und anschließend manuell geprüft.
Ein weiteres Kernproblem war die falsche Zuordnung von Verantwortung. Projektrollen verantworten fachliche Aufgaben und Ergebnisse. Sie sollten nicht zusätzlich dafür verantwortlich sein müssen, die vollständige Dokumentstruktur, alle Compliance-Regeln und jede geforderte Darstellungsform im Detail zu kennen. Dieses Wissen war im dokumentenzentrierten Prozess jedoch faktisch bei den Projektrollen verortet. Dadurch entstand eine zusätzliche Belastung, ohne dass dies einen direkten Mehrwert für das Projekt erzeugte.
Auch die Qualitätssicherung war eingeschränkt. Die Prüfung konzentrierte sich häufig darauf, ob ein gefordertes Dokument vorhanden war und ob bestimmte Inhalte formal enthalten waren. Das ist jedoch nur eine minimale Prüfstufe. Entscheidend ist nicht allein, ob eine Information in einem Dokument steht, sondern ob das behauptete Ergebnis tatsächlich existiert, fachlich korrekt ist und mit dem aktuellen Zustand des Projekts übereinstimmt.
Die Projektdokumentation war außerdem nur eine von mehreren erforderlichen Perspektiven. Neben der Projektsicht gab es weitere Sichten, etwa aus Infrastruktur, Test, Entwicklung, Betrieb oder Governance. Diese Perspektiven nutzten teilweise dieselben Informationen, benötigten sie aber in unterschiedlicher Struktur, Granularität und Darstellung.
Damit wurde deutlich: Dokumente bleiben als Nachweis- und Kommunikationsmedium relevant. Als führendes System für aktuelle, konsistente und prüfbare Projektinformationen sind sie jedoch ungeeignet. Benötigt wurde ein Ansatz, bei dem die Information selbst in den Mittelpunkt rückt und Dokumente nur noch als abgeleitete Sicht auf diese Information verstanden werden.
Lösungskonzeption: Vom Dokument zur modellbasierten Informationsbasis
Der Lösungsansatz bestand darin, die relevanten Informationen aus unterschiedlichen Werkzeugen in einem semantischen Informationsmodell zusammenzuführen. Dieses Modell sollte beschreiben, welche fachlichen Objekte, Beziehungen, Rollen, Zustände und Nachweise für die Projektdokumentation erforderlich sind.
Damit wurde die Dokumentation grundlegend neu gedacht. Basierend auf dem Informationsmodell definiert ein Dokumentationsmodell, welche Informationen in welchem fachlichen Zusammenhang an welcher Stelle und in welcher Form in welchem Dokument stehen sollen.
Mit diesem Ansatz können beliebige Sichten erzeugt werden:
Mögliche Ausgabeformen aus dem Informationsmodell:
- klassische Dokumente für Compliance- und Freigabeprozesse,
- rollenbezogene Ansichten für Projektbeteiligte,
- prüfbare Nachweise für Qualitätssicherung und Governance,
- Reports zum Projektfortschritt,
- strukturierte Auswertungen zu Abhängigkeiten, Zuständen und Lücken.
Der wesentliche Vorteil liegt in der Entkopplung von Information und Dokument. Die Information musste nicht mehr mehrfach in verschiedenen Dokumenten gepflegt werden. Stattdessen wurde sie aus den datenführenden Systemen gelesen, semantisch eingeordnet, validiert und je nach Bedarf in unterschiedliche Ausgabeformate überführt.
Dadurch änderte sich auch die Qualitätsprüfung. Sie fand nicht mehr primär am Dokument statt, sondern am zugrunde liegenden Modell und an den referenzierten Datenquellen. Fehlende, unvollständige oder widersprüchliche Ergebnisse konnten dadurch wesentlich früher erkannt werden.
Dieser Ansatz eröffnete zusätzliche Möglichkeiten. Der aktuelle Zustand eines Projekts konnte nahezu in Echtzeit ausgewertet werden. Abweichungen zwischen Planung und Umsetzung wurden transparenter. Ergebnisse einer Rolle standen anderen Rollen schneller zur Verfügung. Auswertungen konnten wiederverwendet und unterschiedliche Dokumentationsvarianten automatisiert erzeugt werden.
Proof of Concept mit konkreten Ergebnistypen
Obwohl die Analyse abgeschlossen und das Lösungskonzept fachlich ausgearbeitet war, blieb der Kunde zunächst skeptisch. In der Vergangenheit waren bereits mehrere Initiativen zur Verbesserung der Dokumentation gescheitert. Deshalb wurde der Proof of Concept bewusst konkret, klein und überprüfbar aufgesetzt.
Zunächst wurden 3 spezifische Ergebnistypen aus dem Projektmodell ausgewählt. Anschließend wurde gemeinsam mit den relevanten Stakeholdern geklärt, welche fachlichen Informationen diese Ergebnistypen tatsächlich enthalten müssen. Dabei zeigte sich, dass die Inhalte nicht in allen Fällen ausreichend spezifiziert waren. Teilweise prüfte die Qualitätssicherung vor allem die Existenz von Dokumenten, nicht jedoch die fachliche Vollständigkeit oder Korrektheit der enthaltenen Ergebnisse.
Gemeinsam mit Bedarfsträgern, Prüfern und Projektbeteiligten wurde ein Informationsmodell entwickelt, das die relevanten Inhalte, Beziehungen und Darstellungsanforderungen abbildete. Dieses Modell konnte mit den bereits vorhandenen Datenquellen verknüpft werden. Die benötigten Informationen lagen in unterschiedlichen Anwendungen bereits vor und wurden dort von den jeweiligen Rollen gepflegt (oder sollten dort gepflegt werden).
Im nächsten Schritt wurde der Dokumentengenerator angepasst. Er musste auf Ebene des Dokumenten-Modells erkennen, welche Informationen für einen Ergebnistyp benötigt werden, diese im Kontext eines konkreten Projekts aus dem Informationsmodell erfragen und anschließend in der geforderten Form rendern.
Damit wurde es möglich, Informationen beliebig auf Ergebnistypen zu verteilen und Dokumente nach unterschiedlichen Varianten des Projektmodells zu erzeugen, sofern das Informationsmodell die geforderten Fragestellungen bedienen konnte. Auch laufende oder bereits abgeschlossene Projekte konnten dadurch nach einer neuen Dokumentationsstruktur ausgewertet werden, was die Vergleichbarkeit über alle Projekte ermöglichte.
Eine manuelle Aufgabe blieb im Proof of Concept bestehen: die Anordnung grafischer Elemente in komplexeren Sichten. Zwar existieren Layout-Algorithmen für grafische Modelle, die fachlich sinnvolle und gut lesbare Darstellung komplexer Beziehungen erfordert jedoch häufig manuelle Nachsteuerung. Für den Proof of Concept war dieses Vorgehen ausreichend, da der wesentliche Nachweis in der automatisierten Informationsbeschaffung, Modellierung, Validierung und Dokumentgenerierung lag.
Mehrwert der Dokumentationsdigitalisierung: 99,4 % weniger Aufwand
Für den bisherigen Aufwand lagen keine vollständig belastbaren Messdaten über alle Projekte hinweg vor. Projektmanager aus mehreren Projekten berichteten jedoch regelmäßig von Verzögerungen von zwei Wochen oder mehr. Ursachen waren unter anderem unklare Zuständigkeiten, Nacharbeiten nach Prüfungen und Unsicherheiten darüber, welche Informationen an welcher Stelle in welchen Ergebnistyp einzutragen waren.
Für die im Proof of Concept betrachteten Ergebnistypen war in Projekten typischerweise mindestens eine Person für die Dokumentation eingeplant. Der ursprünglich angesetzte Aufwand lag bei rund zwei Wochen (etwa 4.800 Minuten).
Aufwandsreduktion um 99,4 %
Durch den modell- und datengetriebenen Ansatz reduzierte sich dieser Aufwand auf maximal etwa 30 Minuten, sofern grafische Sichten mit vielen Elementen und Beziehungen manuell nachjustiert werden mussten, im Schnitt eher bei 15 Minuten.
Das entspricht einer Reduktion des manuellen Aufwands um rund 99,4 Prozent beziehungsweise einem Faktor von 160.
Nicht eingerechnet sind dabei weitere Effekte, die den Nutzen zusätzlich erhöhen:
- weniger Rückfragen an Fachrollen
- geringerer Abstimmungsaufwand zwischen Projektbeteiligten
- reduzierte Nacharbeiten nach Prüfungen
- schnellere Aktualisierung bei Änderungen
- bessere Wiederverwendung vorhandener Informationen
- höhere Konsistenz zwischen unterschiedlichen Dokumentationssichten
- bessere Grundlage für automatisierte Qualitätsprüfungen
- geringeres Risiko durch fehlende oder widersprüchliche Informationen
Der Mehrwert des Ansatzes ging damit deutlich über die reine Dokumentenerstellung hinaus. Die Transformation von Projektinformationen in Dokumente ist nur eine mögliche Ausgabeform. Wesentlich wertvoller war die entstandene Fähigkeit, Projektinformationen strukturiert, prüfbar, wiederverwendbar und rollenbezogen bereitzustellen.
Messbarer Projekterfolg
| Kennzahl | Vorher | Nachher |
|---|---|---|
| Dokumentationsaufwand (je Ergebnistyp) | ~2 Wochen (ca. 4.800 Min) | max. 30 Min (Ø ca. 15 Min) |
| Aufwandsreduktion | – | 99,4 % / Faktor 160 |
| Qualitätsprüfung | Nur Existenz des Dokuments geprüft | Fachliche Vollständigkeit modellbasiert prüfbar |
| Informationskonsistenz | Manuell, redundant, fehleranfällig | Modellbasiert, automatisch, einheitlich |
| Mehrfachpflege | Informationen in mehreren Dokumenten parallel | Single Source – beliebig viele Sichten generierbar |
Lessons Learned / Fazit
Klein anfangen – mit messbarem Nachweis starten.
Ein klar abgegrenzter Proof of Concept mit drei Ergebnistypen hat gereicht, um den Ansatz belastbar zu belegen. Wer auf einen großen Rollout wartet, verschenkt Zeit und Lernpotenzial. Der entscheidende Schritt ist nicht der perfekte Plan, sondern der erste konkrete Beweis.
Information führen – Dokument ableiten.
Der entscheidende Paradigmenwechsel liegt nicht im Tool, sondern im Denken: Informationen semantisch strukturieren, Dokumente daraus generieren – nicht umgekehrt. Wer Informationen dokumentenzentriert pflegt, erzeugt Redundanz, Inkonsistenz und unnötigen Pflegeaufwand.
Qualitätssicherung an der Quelle, nicht am Dokument.
Prüfungen, die nur das Vorhandensein eines Dokuments bestätigen, sind keine fachliche Qualitätssicherung. Wirksame QS setzt am Modell und an den Datenquellen an – ob das behauptete Ergebnis tatsächlich existiert, fachlich korrekt und aktuell ist.
Rollen entlasten: Strukturwissen gehört ins Modell, nicht in die Köpfe.
Projektrollen sollen fachliche Aufgaben erfüllen – nicht Dokumentstruktur, Compliance-Regeln und Darstellungsformen im Detail kennen. Dieses Wissen gehört ins Informations- und Dokumentationsmodell. Wer Rollen damit belastet, erzeugt Fehler und Frust.
Das Modell wächst mit der Nutzung.
Mit jeder weiteren angebundenen Datenquelle, jedem zusätzlichen Ergebnistyp und jeder neuen Auswertung steigt der Wert des Modells – ohne erneute Grundlagenarbeit. Digitalisierung der Dokumentation ist kein Einmalprojekt, sondern eine wachsende Fähigkeit.
Das Projekt zeigt, dass Digitalisierung nicht erst bei großen Plattformen oder unternehmensweiten Transformationsprogrammen beginnt. Auch ein klar abgegrenzter Prozess wie die Projektdokumentation kann erhebliche Potenziale freisetzen, wenn Informationen nicht länger dokumentenzentriert, sondern informations- und modellgetrieben organisiert werden.
Digitalisierung der Dokumentation bedeutet in diesem Kontext nicht, bestehende Dokumente lediglich elektronisch zu verwalten. Digitalisierung bedeutet, Informationen so zu strukturieren, dass sie aktuell, prüfbar, wiederverwendbar und automatisierbar werden.
Sprechen Sie uns an. Gemeinsam finden wir auch für Ihre Dokumentations-, Governance- oder Digitalisierungsherausforderung einen pragmatischen und wirksamen Lösungsansatz.
Sprechen Sie uns an!
Gerne erzählen wir Ihnen mehr dazu in einem persönlichen Kennenlerngespräch!
War dieser Beitrag hilfreich? Jetzt teilen!
