90-Tage-Plan für den Aufbau einer kuratierten Knowledge Library für Bid-Teams. Owner-Matrix, Content-Audit, Versionierung und Erfolgsmessung.
Eine Knowledge Library ist kein Dokumentenspeicher, sondern ein lebendes System mit Owner, Versionierung und Verwendungs-Tracking. Dieser Leitfaden beschreibt einen pragmatischen 90-Tage-Plan, mit dem ein Bid-Team von einer Mottenkiste alter Tender-Antworten zu einer strukturierten, produktiven Library kommt. Das Ziel ist Reifegrad 1 in 90 Tagen, nicht Vollständigkeit.
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 halbtaegigen 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, Innovations-Argumentation, Branchen-spezifisches 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. Ziel am Tag 60: 60 bis 100 Einträge in den drei wichtigsten Domänenblöcken.
**Quellen für die ersten Inhalte**:
**Drei-Stationen-Workflow pro Eintrag**:
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).
Bei 60 bis 100 Einträgen über 30 Tage entspricht das 2 bis 3 Einträgen pro Werktag pro SME, mit 0.5 FTE Library-Owner-Zeit für Koordination und Freigabe.
**Was nicht passieren darf**:
In den letzten 30 Tagen wird die Library produktiv und es werden die Lebenszyklus-Routinen eingefuehrt.
**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 seinen ersten Reviewzyklus aktiviert. Bei 100 Einträgen mit 6-monatigem Default-Zyklus bedeutet das, die ersten Reviews stehen ab Tag 180 an, mit gleichmaessiger Verteilung.
**Woche 12: Erfolgsmessung**. Drei KPIs werden erfasst:
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 Vorgaengerversion erhalten. Drei Vorteile:
Versionierung muss strukturell unterstützt sein, nicht über File-Naming-Konventionen ("Antwort_v3_final_FINAL.docx") improvisiert werden. Ohne strukturelle Versionierung gibt es de facto keine Versionierung.
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 verhindert Chaos und macht Library-Inhalte verlässlich. Ohne Governance werden Einträge parallel von mehreren Personen überschrieben, Versionsschuften entsteht, niemand vertraut den Inhalten mehr.
Drei Metriken nach Tag 90, mit Zielwerten für Tag 180 und Tag 365:
**Library-Anteil pro Tender**: Anteil der Antworten in einer neuen Submission, die aus der Library stammen.
**Wiederverwendungs-Rate pro Eintrag**: Wie oft wird ein Eintrag pro Jahr verwendet?
**Erstentwurf-Zeit-Reduktion**: Wie viel schneller ist der Erstentwurf eines neuen Tenders mit Library?
Wer diese Werte erreicht, hat eine produktive Library. Wer sie deutlich verfehlt, hat entweder Owner-Probleme, Tooling-Probleme oder Disziplin-Probleme. In allen drei Fällen lohnt sich eine Diagnose-Runde.
**Eine Library ist nicht "fertig" am Tag 90, sondern produktiv.** Der Aufwand verschiebt sich vom Aufbau zum Lebenszyklus: weniger Schreiben, mehr Pflegen. Wer den Lebenszyklus diszipliniert führt, hat in 12 Monaten eine Library, die das Bid-Team strukturell schneller macht. Wer den Lebenszyklus vernachlässigt, hat in 12 Monaten eine veraltete Sammlung, die niemand mehr nutzt. Der Unterschied ist nicht Software oder Inhalt, sondern Disziplin.
Library-Owner: 50 Prozent der Zeit (etwa 800 Stunden über 90 Tage). Subject-Matter-Experts: jeweils 4 bis 8 Stunden pro Woche. Lektor: 6 bis 10 Stunden pro Woche. Total etwa 1'200 bis 1'500 Personenstunden über das Quartal.
100 bis 200 kuratierte Einträge in den drei wichtigsten Domänenblöcken (Sicherheit, Methodologie, Referenzen), produktiv im nächsten Tender, mit etablierter Owner-Struktur und definierten Reviewzyklen.
Pragmatisch reagieren: Scope nicht aufbauschen, sondern reduzieren. 80 Einträge mit Owner und Reviewzyklus sind besser als 200 ohne Pflege. Lieber Reifegrad 1 mit weniger Inhalten erreichen als Reifegrad 1.5 mit aufgeblaehter, instabiler Library.
Theoretisch nein, praktisch ja ab 100 Einträgen. Ohne strukturierte Tooling-Unterstützung wird Owner-Zuweisung, Reviewzyklen-Tracking und Wiederverwendungs-Statistik unverhältnismässig aufwändig. Tendaro bringt diese Funktionen out-of-the-box.
Nicht migrieren, sondern selektiv kuratieren. 90 Prozent davon sind veraltet, schlecht formatiert oder kontextspezifisch. Aus den letzten 3 gewonnenen Tendern die wertvollsten 30 bis 50 Antworten extrahieren und in die neue Struktur überfuehren ist effektiver als Massenmigration.
Drei Mechanismen ab Tag 91: monatliches Review-Standup mit Library-Owner, automatische Aktualitätspruefung bei Tender-Verwendung, Quartalsaudit auf Karteileichen. Ohne diese drei zerfällt die Library binnen 12 Monaten.
Drei Metriken: Library-Anteil pro Tender (Anteil der Antworten aus der Library, Zielwert 50 bis 70 Prozent ab Monat 6), Wiederverwendungs-Rate pro Eintrag (Zielwert mindestens 3 Verwendungen pro Eintrag pro Jahr), Erstentwurf-Zeit-Reduktion (Zielwert 40 bis 60 Prozent gegenüber Status quo).
Tendaro is a Swiss B2B SaaS platform for AI-powered tender and bid management. It helps companies in Switzerland manage public tenders, private RFQs, buyer-portal packages and uploaded tender documents from intake to submission-ready proposals, in a single workspace.
Tendaro consolidates public tenders (SIMAP publications across all 26 Swiss cantons supported), private customer RFQs, invitation-based tenders from buyer portals, and tender documents uploaded directly as PDF, Word, Excel or ZIP archives. Scanned PDFs are processed too. Swiss filename conventions like Pflichtenheft, Lastenheft, Eignungskriterien and AGB are recognised natively.
Tendaro turns tender documents and company knowledge into structured requirements, risks, deadlines, ownership, fit insights and proposal-ready answers. Muss, Kann and Soll criteria are distinguished. Eligibility, evaluation and technical criteria are classified separately. Each requirement carries a source citation back to the original document, sheet, row or page.
Company Memory stores past proposals, won tenders, references, certifications, CVs, datasheets and curated answer blocks. Knowledge Matching maps these assets to current requirements with a fit score, so teams can answer new RFQs faster and more consistently.
Bid Desk enables collaborative bid/no-bid decisions where team members vote with comments and Tendaro provides an AI recommendation with confidence score. Bid Pulse is a strategic intelligence hub that analyses a company's entire tender history to reveal win/loss patterns, recurring weaknesses, market demand trends, and prioritised recommendations. AI Tender Chat allows natural-language conversations about any tender, with full context awareness of documents, requirements, and company knowledge. Tender Discovery covers SIMAP imports and parallel intake of private RFQs and uploaded packages. Deadline Calendar provides visual tracking of all extracted deadlines colour-coded by urgency.
Tendaro is built for bid teams, presales teams, and companies that regularly respond to tenders in Switzerland and the DACH region: IT service providers, engineering firms, consultancies, and professional services.
All data is hosted exclusively in Swiss data centres. Customer data is never used for AI model training. Tendaro features role-based access control, immutable audit trails, and Human Approval before every submission.