Kostenlose Lessons-Learned-Vorlage (Google Sheets, Excel, PDF)
Diese kostenlose Lessons-Learned-Vorlage bietet Ihnen ein strukturiertes Protokoll dafür, was gut lief, was verbessert werden muss, warum es so kam und was Sie anders machen werden, mit Verantwortlichem und Status für jede Empfehlung. Download für Google Sheets, Excel oder als druckbares PDF, in Einsteiger-, Fortgeschrittenen- oder Expertenversion.
Das Wichtigste in Kürze
- Jede Zeile erfasst eine Erkenntnis: die Phase, was passiert ist, ob es gut lief, die Grundursache, die Auswirkung, eine Empfehlung, einen Verantwortlichen und den Status der Maßnahme.
- Dropdowns halten die Einträge einheitlich, sodass Sie das Protokoll nach Phase, Auswirkung oder offenen Maßnahmen filtern können.
- Halten Sie Erkenntnisse während des gesamten Projekts fest, nicht erst beim Abschluss, solange die Details noch frisch sind.
- Eine Lektion ist erst gelernt, wenn ihre Empfehlung einen Verantwortlichen hat und umgesetzt wird; die Spalte „Maßnahmenstatus“ verfolgt das.
- Wählen Sie Einsteiger für ein schnelles Protokoll mit fünf Spalten, Fortgeschritten für das vollständige Protokoll mit Dropdowns oder Experte für ein Dashboard und eine Änderungshistorie.
Kostenloser Download · ohne Anmeldung
Lessons-Learned-Vorlage herunterladen
Wählen Sie Stufe und Format: Google Sheets, Excel oder ein druckfertiges PDF. Die Tabellen enthalten Dropdowns, Formeln und Beispielzeilen, die Sie überschreiben können.
Die vollständige Vorlage mit allen Tabs, Dropdowns und Formeln.
Was ist eine Lessons-Learned-Vorlage?
A Vorlage für Lessons Learned ist ein strukturiertes Protokoll, um festzuhalten, was ein Projektteam gelernt hat: was passiert ist, ob es gut lief oder verbessert werden muss, warum es so kam, wie wichtig es war und was beim nächsten Mal anders gemacht werden sollte. Jeder Eintrag endet mit einer Empfehlung und einem Verantwortlichen, damit das Wissen im selben Projekt und in künftigen Projekten wiederverwendet werden kann.
Es hilft, eine erkannten Erkenntnis von einer gelerntenLektion zu unterscheiden. „Tests begannen zu spät“ zu schreiben, identifiziert eine Erkenntnis. Gelernt ist sie erst, wenn eine spätere Phase oder ein späteres Projekt deswegen die Tests anders plant. Deshalb geht diese Vorlage über eine Liste von Beobachtungen hinaus und enthält für jede Zeile eine Empfehlung, einen Verantwortlichen und einen Maßnahmenstatus.
Die Idee ist in den wichtigsten Projektmanagement-Frameworks verbreitet. Der *PMBOK Guide* des PMI beschreibt ein Lessons-Learned-Register , das während des Projekts aktuell gehalten und am Ende in ein Repository der Organisation überführt wird, und PRINCE2 nutzt ein Erfahrungsprotokoll (Lessons Log) während des Projekts und einen Erfahrungsbericht (Lessons Report) , um Erkenntnisse weiterzugeben. Agile Teams halten ähnliche Erkenntnisse fest in jeder Sprint-Retrospektive. Diese Vorlage funktioniert als Register für jeden dieser Ansätze.
Den übergeordneten Prozess, einschließlich der Frage, wie Erkenntnisse die Praxis in einer Organisation verändern, finden Sie in unserem Leitfaden zu Lessons Learned im Projektmanagement.
Vorschau der Lessons-Learned-Vorlage
Hier der erste Tab mit den drei Beispielzeilen aus dem Download. Überschreiben Sie sie mit Ihren eigenen Erkenntnissen.
| # | Phase / Bereich | Was passiert ist | Lief gut oder muss verbessert werden? | Ursache | Auswirkung | Empfehlung | Verantwortlich | Status der Maßnahme |
|---|---|---|---|---|---|---|---|---|
| 1 | Planung | Anforderungen zwei Wochen früher abgenommen | Lief gut | Product Owner täglich verfügbar | Mittel | Zeit des Product Owners im Projektauftrag sichern | PMO | Erledigt |
| 2 | Entwicklung | Testumgebung 5 Tage lang nicht verfügbar | Muss verbessert werden | Kein Buchungsprozess für Umgebungen | Hoch | Umgebungen bei der Planung buchen; Zustandsprüfungen ergänzen | Betriebsleitung | In Arbeit |
| 3 | Kommunikation | Stakeholder im Unklaren über den Go-live-Termin | Muss verbessert werden | Termin ohne Benachrichtigung geändert | Mittel | Termine in einem einzigen Dashboard veröffentlichen | PM | Nicht begonnen |
Die Beispielzeilen sind nur Beispiele: Ersetzen Sie sie durch Ihre eigenen.
Was die Vorlage enthält
- Lessons Learned: #, Phase / Bereich, Was ist passiert, Lief gut oder muss verbessert werden?, Grundursache, Auswirkung, Empfehlung, Verantwortlicher, Maßnahmenstatus
Jede Spalte hat eine Aufgabe. Die folgende Tabelle erklärt, was in jede gehört und wie ein nützlicher Eintrag aussieht.
| Spalte | Was zu erfassen ist | So sieht ein guter Eintrag aus |
|---|---|---|
| Phase / Bereich | Wo im Projekt die Erkenntnis hingehört: eine Phase (Planung, Umsetzung, Test) oder ein Bereich (Kommunikation, Lieferanten) | Entwicklung |
| Was passiert ist | Eine kurze, sachliche Beschreibung des Ereignisses oder der Praxis | Testumgebung 5 Tage lang nicht verfügbar |
| Lief gut oder muss verbessert werden? | Dropdown: Lief gut oder Muss verbessert werden | Muss verbessert werden |
| Ursache | Der eigentliche Grund, nicht das Symptom | Kein Buchungsprozess für Umgebungen |
| Auswirkung | Dropdown: Niedrig, Mittel oder Hoch -Auswirkung auf Zeit, Kosten, Qualität oder Menschen | Hoch |
| Empfehlung | Eine konkrete Maßnahme, die jemand beim nächsten Mal ergreifen könnte | Umgebungen bei der Planung buchen; Zustandsprüfungen ergänzen |
| Verantwortlich | Eine namentlich benannte Person oder Rolle, die für die Umsetzung der Empfehlung verantwortlich ist | Betriebsleitung |
| Status der Maßnahme | Dropdown: Nicht begonnen, In Arbeit oder Erledigt | In Arbeit |
Einsteiger-, Fortgeschrittenen- und Expertenversion
- Einsteiger: ein Tab mit den fünf wesentlichen Spalten: Phase / Bereich, Was ist passiert, Lief gut oder muss verbessert werden?, Empfehlung und Verantwortlicher. Gut für eine erste Sitzung oder ein kleines Projekt.
- Advanced: das vollständige Protokoll mit allen neun Spalten, einschließlich Grundursache, Auswirkung und Maßnahmenstatus, sowie den oben beschriebenen Dropdowns. Diese Version nutzen die meisten Teams als laufendes Register.
- Experte: das fortgeschrittene Protokoll plus ein Anleitungs-Tab, ein Dashboard, das Erkenntnisse automatisch nach Verantwortlichem und Maßnahmenstatus zählt, Statusfarben in der Spalte „Maßnahmenstatus“ und ein Tab für die Änderungshistorie.
So füllen Sie die Lessons-Learned-Vorlage aus
- Richten Sie das Protokoll beim Kick-off ein. Speichern Sie eine Kopie in einem gemeinsamen Laufwerk, nehmen Sie den Projektnamen in den Dateinamen auf und sagen Sie dem Team, wo sie liegt. Das Festhalten von Erkenntnissen beginnt am ersten Tag, nicht beim Abschluss.
- Sammeln Sie Erkenntnisse, sobald sie auftreten. Ergänzen Sie Einträge nach jeder Phase, jedem Meilenstein, jedem Sprint oder größeren Vorfall. Innerhalb weniger Tage geschriebene Erkenntnisse sind weit genauer als solche, an die man sich Monate später erinnert.
- Beschreiben Sie in einem sachlichen Satz, was passiert ist. Benennen Sie das Ereignis, keine Meinung über eine Person: „Lieferant lieferte die Hardware drei Wochen zu spät“, nicht „Lieferant war nutzlos“.
- Ordnen Sie sie ein. Wählen Sie Lief gut oder Muss verbessert werden. Halten Sie Erfolge ebenso sorgfältig fest wie Probleme, denn sie sind die Praktiken, die Sie wiederholen wollen.
- Finden Sie die Grundursache. Fragen Sie so lange „Warum?“, bis Sie bei etwas ankommen, das Team oder Organisation ändern könnten. Eine Vorlage zur Ursachenanalyse (5 Whys) oder ein Fischgrätendiagramm hilft bei komplexen Problemen.
- Bewerten Sie die Auswirkung. Nutzen Sie Niedrig, Mittel oder Hoch, je nach Wirkung auf Terminplan, Budget, Qualität oder Team. Die Auswirkung hilft Ihnen zu entscheiden, welche Erkenntnisse Sie zuerst besprechen.
- Formulieren Sie eine Empfehlung und geben Sie ihr einen Verantwortlichen. Machen Sie sie so konkret, dass jemand außerhalb des Teams danach handeln könnte. Weisen Sie jeder Empfehlung einen Verantwortlichen zu, auch wenn mehrere Personen helfen.
- Verfolgen Sie den Maßnahmenstatus. Überprüfen Sie offene Empfehlungen in regelmäßigen Projektmeetings und setzen Sie sie von Nicht begonnen über In Bearbeitung auf Erledigt.
- Teilen und archivieren Sie das Protokoll. Gehen Sie beim Abschluss das vollständige Protokoll mit Team und Sponsor durch und übergeben Sie es dann an Ihr PMO oder Ihre Wissensdatenbank, damit künftige Projekte darin suchen können.
Fragen für Lessons Learned
Gute Fragen führen zu konkreten, nützlichen Erkenntnissen. Nutzen Sie diese Leitfragen in einer Sitzung oder versenden Sie sie vorab. Sie werden nicht alle brauchen; wählen Sie die Bereiche, die für Ihr Projekt wichtig sind.
Allgemein
- Was lief gut und sollte wiederholt werden?
- Was lief nicht wie geplant, und warum?
- Was hat uns überrascht?
- Wenn wir dieses Projekt morgen neu beginnen würden, was würden wir anders machen?
Planung, Umfang und Terminplan
- Waren Ziele und Umfang von Anfang an klar?
- Wie genau waren unsere Schätzungen, und wo lagen sie am weitesten daneben?
- Wie wurden Umfangsänderungen beantragt und genehmigt?
- Welche Risiken sind eingetreten, die nicht verzeichnet waren im Risikoregister?
Kommunikation und Stakeholder
- Haben die Stakeholder die Informationen erhalten, die sie brauchten, wann sie sie brauchten?
- Wurden Entscheidungen schnell genug und von den richtigen Personen getroffen?
- Welche Meetings oder Statusberichte waren nützlich, und welche könnten wir streichen?
Team, Ressourcen und Lieferanten
- Hatten wir zur richtigen Zeit die richtigen Personen und Fähigkeiten?
- Waren Rollen und Verantwortlichkeiten klar?
- Wie gut haben Lieferanten und andere Teams das Vereinbarte geliefert?
Qualität und Übergabe
- Haben die Liefergegenstände die Abnahmekriterien beim ersten Mal erfüllt?
- Wie reibungslos verlief die Übergabe an den Betrieb oder den Kunden?
- Was hätte den Personen geholfen, die das Ergebnis nun betreuen?
Lessons-Learned-Beispiel
Die folgende Tabelle zeigt ein ausgefülltes Protokoll für den Relaunch einer Website. Beachten Sie, dass jeder Eintrag eine Grundursache und eine Empfehlung hat, nach der jemand handeln könnte.
| Phase / Bereich | Was passiert ist | Lief gut? | Ursache | Auswirkung | Empfehlung | Verantwortlich | Status |
|---|---|---|---|---|---|---|---|
| Planung | Content-Inventur eine Woche früher fertig | Lief gut | Content-Leitung war ab dem Kick-off dabei | Mittel | Die Content-Leitung bei allen Webprojekten in den Projektauftrag aufnehmen | PMO | Erledigt |
| Entwicklung | Zwei Vorlagen nach der Designfreigabe neu aufgebaut | Muss verbessert werden | Designs ohne Prüfung durch Entwickler freigegeben | Hoch | Vor der Designfreigabe einen Prüfschritt durch Entwickler ergänzen | Design-Leitung | In Arbeit |
| Lieferanten | Hosting-Vertrag zwei Wochen zu spät unterzeichnet | Muss verbessert werden | Beschaffungsvorlaufzeit nicht im Terminplan | Mittel | Beschaffungsvorlaufzeiten als Aufgaben in den Terminplan aufnehmen | PM | Nicht begonnen |
| Kommunikation | Wöchentlicher 10-minütiger Status-Call hielt die Stakeholder auf einer Linie | Lief gut | Fester Termin und einseitiges Update | Mittel | Das einseitige Statusformat im nächsten Projekt wiederverwenden | PM | Erledigt |
Schwache und starke Einträge
Der Unterschied zwischen einer Erkenntnis, die niemand nutzt, und einer, die die Praxis verändert, liegt meist im Detaillierungsgrad.
| Schwacher Eintrag | Starker Eintrag |
|---|---|
| Die Kommunikation war schlecht. | Die Stakeholder wurden nicht informiert, dass sich der Go-live-Termin verschoben hatte, weil der Termin in drei Dokumenten stand. Wichtige Termine in einem gemeinsamen Dashboard veröffentlichen. |
| Die Tests liefen schlecht. | Die Tests verloren fünf Tage, weil die Testumgebung nicht verfügbar war und es keinen Buchungsprozess gab. Umgebungen während der Planung buchen und tägliche Zustandsprüfungen ergänzen. |
| Gute Teamarbeit. | Tägliche 15-minütige Stand-ups zwischen Design und Entwicklung reduzierten Nacharbeit. Bei ähnlichen Projekten gemeinsame Stand-ups ab Beginn der Umsetzung einplanen. |
Wenn mehrere Einträge dieselbe Folgemaßnahme brauchen, können Sie die Maßnahmen verfolgen in einem Vorlage für einen Maßnahmenplan und es aus dem Protokoll verlinken.
So führen Sie eine Lessons-Learned-Sitzung durch
Vor der Sitzung
- Teilen Sie die Vorlage einige Tage vorab und bitten Sie alle, zwei oder drei Erkenntnisse einzutragen.
- Laden Sie das Kernteam, wichtige Stakeholder und gegebenenfalls Lieferanten ein. Halten Sie die Gruppe klein genug, damit alle zu Wort kommen.
- Lassen Sie nach Möglichkeit jemand anderen als den Projektmanager moderieren, damit der PM offen beitragen kann.
- Bereiten Sie eine Agenda vor; unsere Vorlage für eine Besprechungsagenda funktioniert gut.
Während der Sitzung
- Beginnen Sie mit der Grundregel: Im Fokus stehen Prozesse und Entscheidungen, nicht die Schuldzuweisung an Einzelne.
- Gehen Sie das Projekt Phase für Phase durch und gruppieren Sie die Einträge über die Spalte „Phase / Bereich“.
- Verwenden Sie die meiste Zeit auf Erkenntnisse mit hoher Auswirkung und deren Grundursachen.
- Vereinbaren Sie für jede Erkenntnis eine Empfehlung und einen Verantwortlichen, bevor Sie weitergehen.
- Halten Sie neue Erkenntnisse direkt in der Vorlage auf dem Bildschirm fest, damit niemand sie später ausformulieren muss.
Nach der Sitzung
- Bereinigen Sie das Protokoll, prüfen Sie, dass jede Empfehlung einen Verantwortlichen hat, und teilen Sie es innerhalb weniger Tage mit den Teilnehmenden.
- Setzen Sie offene Empfehlungen auf die Agenda regelmäßiger Projektmeetings, bis sie erledigt sind.
- Machen Sie aus Erkenntnissen, die künftige Projekte betreffen, Änderungen an Vorlagen, Checklisten oder der Projektmethodik; wiederkehrende Risiken gehören in das nächste Projekt Vorlage für ein Risikoregister.
- Verschieben Sie jedes Problem, das in diesem Projekt noch behoben werden muss, in Ihr Problemprotokoll (Issue Log) , statt es im Erfahrungsprotokoll zu belassen.
- Legen Sie das finale Protokoll im Erfahrungsrepository der Organisation ab, als Teil des den Projektabschluss hinaus.
Tipps und häufige Fehler
- Bis zum Ende warten. Erst beim Abschluss festgehaltene Erkenntnisse sind vage und unvollständig. Ergänzen Sie Einträge am Ende jeder Phase oder jedes Sprints.
- Menschen die Schuld geben. Wenn die Sitzung zur Fehlersuche bei Personen wird, hören die Leute auf, offen zu berichten. Beschreiben Sie Ereignisse und Prozesse, nicht Einzelne.
- Nur Probleme festhalten. Erfolge sind genauso wertvoll. Sie sind die Praktiken, die Sie verbreiten wollen.
- Bei Symptomen stehen bleiben. „Die Deadline hat sich verschoben“ ist ein Symptom. Fragen Sie weiter nach dem Warum, bis Sie bei etwas ankommen, das Sie ändern können.
- Vage Empfehlungen. „Besser kommunizieren“ ist nicht umsetzbar. „Jede Woche ein einseitiges Status-Update an die Sponsoren senden“ schon.
- Kein Verantwortlicher, keine Nachverfolgung. Eine Empfehlung ohne Verantwortlichen wird selten umgesetzt. Nutzen Sie die Spalten „Verantwortlicher“ und „Maßnahmenstatus“ und überprüfen Sie sie regelmäßig.
- Frühere Erkenntnisse nie lesen. Machen Sie die Durchsicht des Erfahrungsrepositorys zu einem Schritt beim Start jedes neuen Projekts, zum Beispiel wenn Sie den folgenden Entwurf erstellen: Projektauftrag.
Lessons Learned vs. Retrospektive vs. Post-Mortem
Diese Begriffe überschneiden sich. Die Hauptunterschiede liegen in Zeitpunkt und Umfang.
| Lessons Learned | Sprint-Retrospektive | Post-Mortem | |
|---|---|---|---|
| Wann | Während des gesamten Projekts und beim Abschluss | Am Ende jedes Sprints | Nach einem Projekt, Release oder Vorfall |
| Umfang | Eine Phase oder das gesamte Projekt | Ein Sprint und die Arbeitsweise des Teams | Ein Ereignis oder das gesamte Projekt |
| Hauptergebnis | Ein Register von Erkenntnissen mit Empfehlungen und Verantwortlichen | Einige Verbesserungen für den nächsten Sprint | Ein Review-Bericht mit Ursachen und Maßnahmen |
| Zielgruppe | Team, Sponsor, PMO und künftige Projekte | Das Scrum Team | Team und Stakeholder |
Wenn Sie in Sprints arbeiten, nutzen Sie unsere Vorlage für Sprint-Retrospektiven in jedem Sprint und übertragen Sie die Erkenntnisse, die über das Team hinaus wichtig sind, in dieses Protokoll. Um offene Risiken und Probleme neben Ihren Erkenntnissen im Blick zu behalten, nutzen Sie ein RAID-Log-Vorlage.
Verwandte Vorlagen und Leitfäden
RAID-Log-VorlageKostenlose RAID-Log-Vorlage zur Verfolgung von Projektrisiken, Annahmen, Problemen und Abhängigkeiten mit…Einsteiger · Fortgeschritten · Experte
Sprint-Retrospektive-VorlageKostenlose Vorlage für Sprint-Retrospektiven: was gut lief, was verbessert werden soll, Ideen und Maßnahmen…Einsteiger · Fortgeschritten · Experte
Vorlage für BesprechungsprotokolleKostenlose Vorlage für Besprechungsprotokolle mit Teilnehmenden, Diskussion, Entscheidungen und Aufgaben mit…Einsteiger · Fortgeschritten · Experte
Vorlage für die Ursachenanalyse (5 Warum)Kostenlose Vorlage für die Ursachenanalyse mit der 5-Warum-Methode: Problembeschreibung, Warum-Kette, Grund…Einsteiger · Fortgeschritten · Experte
Projektplan-VorlageKostenlose Projektplan-Vorlage mit Zielen, Umfang, Lieferobjekten, Aufgaben, Verantwortlichen, Terminen und…Einsteiger · Fortgeschritten · Experte
Projektauftrag-VorlageKostenlose Projektauftrag-Vorlage mit Zweck, Zielen, Umfang, Meilensteinen, Budget,…Einsteiger · Fortgeschritten · Experte- Lessons Learned im Projektmanagement: Leitfaden und Beispiele
- Projektabschluss: Schritte, Checkliste und Abschlussbericht-Vorlage
- Sprint-Retrospektive: Ziel, Format und Moderationstipps
Wie sich Lessons Learned in das Ende eines Projekts einfügen, erfahren Sie in unserem Leitfaden zum Projektabschluss.
Häufig gestellte Fragen
Was ist eine Lessons-Learned-Vorlage?
Eine Lessons-Learned-Vorlage ist ein strukturiertes Protokoll, um festzuhalten, was in einem Projekt gut lief und was verbessert werden muss, die Grundursache jeder Erkenntnis, ihre Auswirkung sowie eine Empfehlung mit Verantwortlichem, damit künftige Arbeit davon profitiert.
Was sollte eine Lessons-Learned-Vorlage enthalten?
Mindestens: die Phase oder den Bereich, was passiert ist, ob es gut lief oder verbessert werden muss, die Grundursache, die Auswirkung, eine Empfehlung, einen Verantwortlichen und den Status der Folgemaßnahme. Diese Vorlage enthält all das.
Was sind die wichtigsten Lessons-Learned-Fragen?
Die Kernfragen lauten: Was lief gut, was lief nicht wie geplant, warum ist es passiert, und was werden wir beim nächsten Mal anders machen? Ergänzen Sie je nach Projekt konkrete Fragen zu Planung, Kommunikation, Ressourcen und Qualität.
Wie formulieren Sie eine gute Lesson Learned?
Beschreiben Sie ein konkretes Ereignis sachlich, erklären Sie seine Grundursache, nennen Sie seine Auswirkung und schließen Sie mit einer praktischen Empfehlung, die einen Verantwortlichen hat. Vermeiden Sie vage Aussagen wie „Die Kommunikation war schlecht“.
Wann sollte man Lessons Learned festhalten?
Während des gesamten Projekts: am Ende jeder Phase oder jedes Sprints, nach größeren Ereignissen und beim Abschluss. Wer bis zum Ende wartet, vergisst Details, und die Erkenntnisse können dem laufenden Projekt nicht mehr helfen.
Wer sollte eine Lessons-Learned-Sitzung moderieren?
Idealerweise eine neutrale Moderation, etwa ein PMO-Mitglied oder ein Projektmanager aus einem anderen Team, damit Projektmanager und Team frei beitragen können. Bei kleinen Projekten moderiert oft der Projektmanager.
Was ist ein Lessons-Learned-Register?
Ein Lessons-Learned-Register ist das laufende Protokoll der während eines Projekts gesammelten Erkenntnisse. Der PMBOK Guide des PMI verwendet diesen Begriff; PRINCE2 nennt es Erfahrungsprotokoll (Lessons Log). Diese Vorlage kann als beides verwendet werden.
Was ist der Unterschied zwischen Lessons Learned und einer Retrospektive?
Eine Sprint-Retrospektive betrachtet einen Sprint und die Arbeitsweise des Teams. Lessons Learned decken meist eine Phase oder das ganze Projekt ab und werden über das Team hinaus geteilt, damit andere Projekte sie nutzen können.
Ist diese Lessons-Learned-Vorlage kostenlos, und funktioniert sie in Google Sheets?
Ja. Alle drei Versionen stehen kostenlos und ohne Registrierung in den Formaten Google Sheets, Excel und PDF zum Download bereit. Die Dropdowns funktionieren sowohl in Google Sheets als auch in Excel.
Kann ich die Vorlage für positive Erkenntnisse nutzen?
Ja. Wählen Sie im Dropdown „Lief gut“. Erfolge festzuhalten ist genauso wichtig wie Probleme festzuhalten, denn sie sind die Praktiken, die andere Projekte wiederholen sollen.
Wo sollten abgeschlossene Erkenntnisse abgelegt werden?
An einem gemeinsamen, durchsuchbaren Ort, den das PMO oder eine Wissensdatenbank verantwortet, damit künftige Projektteams relevante Erkenntnisse prüfen können, wenn sie mit der Planung beginnen.
Was ist der Unterschied zwischen der Einsteiger-, Fortgeschrittenen- und Expertenversion?
Die Einsteigerversion hat fünf wesentliche Spalten auf einem Tab. Die Fortgeschrittenenversion ergänzt Grundursache, Auswirkung, Maßnahmenstatus und Dropdowns. Die Expertenversion ergänzt eine Anleitung, ein Dashboard, das Erkenntnisse nach Verantwortlichem und Status zusammenfasst, Statusfarben und eine Änderungshistorie.