90-Tage-Plan für den Aufbau einer kuratierten Knowledge Library für Bid-Teams. Owner-Matrix, Content-Audit, Versionierung und Erfolgsmessung.
Eine brauchbare Knowledge Library führt pro Baustein Quelle, Owner, Reviewstatus und Nutzung. Der folgende 90-Tage-Ablauf ist ein Planungsbeispiel, das an Datenmenge, Team und Qualitätszustand angepasst werden muss. Alle Mengen, Zeitbudgets, Frequenzen und Prozentwerte sind interne Startwerte, keine Branchenbenchmarks oder Leistungszusagen.
In den ersten 30 Tagen geht es um Struktur, nicht um Inhalt. Zwei Outputs am Tag 30:
**Woche 1: Stakeholder-Workshop und Taxonomie-Entscheidung**. Library-Owner moderiert einen halbtägigen Workshop mit Bid Manager, drei bis fünf Subject-Matter-Experts und idealerweise einem Sales-Lead. Output: Liste der 8 bis 12 Domänenblöcke, in denen die Library aufgebaut wird. Beispiele: Sicherheit, revDSG-Compliance, Methodologie, Referenzen, Service-Level, Pricing-Argumentation, Migration, Onboarding, Quality Assurance, Innovationsargumentation, Branchenspezifisches Wissen, Kommerzielle Klauseln.
**Woche 2: Owner-Matrix**. Jeder Domänenblock bekommt einen Owner aus dem Subject-Matter-Expert-Pool. Owner verantwortet: Erstinhalt, Reviewzyklus, Aktualitätspflege. Wichtig: kein Block ohne Owner. Wenn niemand Owner sein kann, gehört der Block nicht in die initiale Library.
**Woche 3: Eintrag-Schema**. Jeder Library-Eintrag bekommt das gleiche Schema:
**Woche 4: Tooling-Entscheidung und Pilot-Eintrag**. Die Library landet entweder in einer Bid-Plattform (Tendaro, Loopio, Responsive) oder in einer kuratierten Confluence-Struktur. Erster Pilot-Eintrag wird gemeinsam erstellt, um das Schema zu validieren.
In den nächsten 30 Tagen wird die Library mit Inhalten gefüllt. Im Planungsbeispiel lautet das Ziel am Tag 60: 60 bis 100 Einträge in den drei wichtigsten Domänenblöcken.
**Beispielhafte Auswahl für die ersten Inhalte**:
**Drei-Stationen-Workflow pro Eintrag mit illustrativen Zeitbudgets**:
1. **Subject-Matter-Expert** schreibt fachlich korrekte Erstversion (in 30 bis 90 Minuten pro Eintrag). 2. **Lektor** prüft Tonalität, Konsistenz, sprachliche Präzision (in 10 bis 20 Minuten pro Eintrag). 3. **Library-Owner** gibt frei, taggt, datiert, definiert Reviewzyklus (in 5 bis 10 Minuten pro Eintrag).
Die Kapazität wird vor dem Pilot berechnet: geplante Einträge mal Zeitbudget je Rolle, ergänzt um Workshop-, Korrektur- und Koordinationszeit. Teilen Sie das Ergebnis durch die tatsächlich verfügbaren Arbeitstage und Personen. So wird sichtbar, ob der gewünschte Umfang mit dem bestätigten Team erreichbar ist.
**Risiken, die im Pilot vermieden werden sollten**:
In den letzten 30 Tagen wird die Library produktiv und es werden die Lebenszyklus-Routinen eingeführt.
**Woche 9: Erste produktive Verwendung**. Der nächste echte Tender wird mit Library-Unterstützung bearbeitet. Bid Manager dokumentiert, welcher Anteil der Antworten aus der Library kam, welche Einträge gefehlt haben, welche unbrauchbar waren.
**Woche 10: Library-Refresh basierend auf erster Verwendung**. Lessons learned aus dem ersten produktiven Tender werden in die Library eingearbeitet. Fehlende Einträge ergänzt, unbrauchbare überarbeitet.
**Woche 11: Reviewzyklen aktivieren**. Jeder Eintrag bekommt einen risikobasierten Reviewzyklus. Ein sechsmonatiger Zyklus kann für stabile Inhalte als interner Startwert dienen. Rechtliche, sicherheitsrelevante oder häufig geänderte Aussagen können eine ereignisbezogene oder kürzere Prüfung benötigen.
**Woche 12: Erfolgsmessung**. Drei KPIs werden gegen die vor dem Pilot erfasste Ausgangslage geprüft:
Eine Owner-Matrix legt für jeden Domänenblock fest:
Beispiel-Matrix für ein Schweizer IT-Unternehmen:
Bevor ein Eintrag in die Library aufgenommen wird, durchläuft er einen Audit gegen sieben Kriterien:
Einträge, die einen oder mehrere dieser Audits nicht bestehen, kommen entweder zurück zum SME oder werden nicht aufgenommen.
Wenn ein Eintrag aktualisiert wird (Zertifikat verlängert, Compliance-Aussage angepasst, Methodologie verfeinert), bleibt die Vorgängerversion erhalten. Drei Vorteile:
Das gewählte Werkzeug sollte eine nachvollziehbare Versionshistorie mit Autor, Zeitpunkt und Änderung ermöglichen. Reine File-Naming-Konventionen wie "Antwort_v3_final_FINAL.docx" sind fehleranfällig und erschweren die Prüfung.
Library-Governance ist die Sammlung der Regeln, die festlegen, wer wann was darf. Drei Felder:
**Editier-Rechte**: Wer darf neue Einträge schreiben? Typische Antwort: Subject-Matter-Experts ihrer eigenen Domänenblöcke, plus Library-Owner als Universal-Editor.
**Freigabe-Rechte**: Wer darf einen Eintrag in den produktiven Status setzen? Typische Antwort: nur der Library-Owner, oder ein 4-Augen-Prinzip mit Reviewer.
**Löschung und Archivierung**: Wer darf Einträge löschen oder archivieren? Typische Antwort: nur der Library-Owner, mit dokumentierter Begründung.
Klare Governance reduziert widersprüchliche Änderungen und macht den Freigabestatus nachvollziehbar. Fehlen Rollen und Rechte, sollte das Team diese Lücke vor einer breiten Nutzung schliessen.
Erfassen Sie vor dem Start eine Ausgangslage und vergleichen Sie nach dem vereinbarten Pilotzeitraum:
Dokumentieren Sie Datenmenge, Qualitätskriterien und Messzeitraum. Abweichungen können auf fehlende Owner, unpassende Taxonomie oder einen ungeklärten Arbeitsablauf hinweisen.
Nach dem Aufbau braucht jeder Baustein weiterhin einen Owner, ein Reviewdatum und eine Regel für Nutzung oder Archivierung. Prüfen Sie diese Felder regelmässig und passen Sie Umfang sowie Reviewzyklus an die gemessene Nutzung an.
Leiten Sie das Budget aus Inventar, Qualitätszustand, Anzahl Domänen und verfügbarem Reviewpersonal ab. Als Planungsinput kann ein Team beispielsweise einen festen Anteil für den Library-Owner und wiederkehrende Reviewfenster für Fachpersonen reservieren. Diese Kapazitäten sind intern zu bestätigen und keine Branchenbenchmark.
Definieren Sie einen Pilotumfang, der im nächsten echten Tender genutzt und geprüft werden kann. 60 bis 100 kuratierte Einträge in priorisierten Domänen sind ein mögliches Planungsbeispiel, keine allgemeine Zielvorgabe. Owner, Quelle und Reviewstatus sind wichtiger als die reine Anzahl.
Reduzieren Sie den Umfang auf die Bausteine, die einen Owner, eine Quelle und einen Reviewstatus haben. Dokumentieren Sie offene Inhalte und planen Sie die nächste Iteration aus der gemessenen Nutzung.
Das hängt von Umfang, Rollen, Freigaben, Versionierung und Reporting ab. Eine gepflegte Tabelle oder ein Wiki kann für einen begrenzten Pilot genügen. Prüfen Sie bei wachsendem Bestand, ob Owner-Zuweisung, Reviewstatus, Suche und Nutzungsauswertung zuverlässig unterstützt werden.
Sichten Sie alte Antworten selektiv und übernehmen Sie nur fachlich geprüfte, wiederverwendbare Bausteine mit Quelle und Owner. Eine kleine Stichprobe aus relevanten gewonnenen und verlorenen Tendern ist ein möglicher Start. Der Umfang richtet sich nach Qualität und Aktualität, nicht nach einem festen Prozentsatz.
Legen Sie ab dem Übergang in den Regelbetrieb Owner, risikobasierte Reviewzyklen, Aktualisierung bei Verwendung und eine Archivierungsregel fest. Die passende Kadenz hängt von Änderungsrisiko und Nutzung des jeweiligen Inhalts ab.
Messen Sie Library-Anteil pro Tender, Wiederverwendung pro Eintrag, Reviewstatus und Zeit bis zum prüfbaren Erstentwurf. Zielwerte werden aus der dokumentierten Ausgangslage des Teams abgeleitet.