Wissensdatenbank-Management für Projektteams

Das echte Ausmaß des Problems

Unternehmensberatung ist kumulativ, jedes Projekt baut auf Vorgängern auf. Gleichzeitig ist dieses Vorgängerwissen fast unmöglich systematisch abzurufen. Studien zur Beratungspraxis zeigen ein konsistentes Muster:

• Wissensrecherche dauert 2–4 Stunden pro größerer Frage und ist unvollständig. Ein Berater interviewt 3–5 Kollegen, erhält widersprechende Erinnerungen und findet letztendlich doch nur 40 % der relevanten vorherigen Arbeiten.
• 10–15 % der Beraterzeit geht auf das Suchen nach bereits gemachtem Wissen statt auf neue Fragestellungen. Bei 50 Beratern im Unternehmen und 140 €/Stunde (Vollkostenrechnung) sind das 35.000–52.000 € pro Jahr, die direkt in Meetings und Netzlaufwerk-Durchsuchen verschwinden.
• Onboarding neuer Berater dauert 20–40 Stunden länger, weil das institutionelle Wissen nicht codifiziert ist. Erfahrene Senioren müssen Fragen beantworten, die bereits beantwortet wurden, nur eben nicht dokumentiert.
• Consulting-Qualität schwankt massiv. Ein Team, das seine früheren Lösungen für ein häufiges Problem nicht kennt, produziert weniger ausgefeilte Empfehlungen, nicht weil sie weniger kompetent sind, sondern weil sie bei Null anfangen.

McKinsey publiziert regelmäßig, dass Consultants 30–40 % ihrer Zeit mit Informationsbeschaffung und Synthese verbringen, für viele davon könnte ein funktionierendes internes Wissenssystem den Aufwand um 60 % reduzieren. Das ist keine Theorie, es ist empirisch aus Firmen nachgewiesen, die ein solches System aufgebaut haben.

Das Problem hat zwei Wurzeln:

1. Wissen ist verstreut. Projektdokumentationen liegen auf Netzlaufwerken (wenn überhaupt), E-Mail-Archive sind unsystematisch, und 30–50 % des wichtigen Wissens liegt nur in den Köpfen von Senioren, und entweicht, wenn sie das Unternehmen verlassen.
2. Suche ist primitiv. Eine Keyword-Suche nach “SAP + Logistik” hilft nicht, wenn die Datei “Kundenproject_XYZ_final_v3_ACTUAL.docx” heißt und nur die Zusammenfassung erwähnt das Wort “Logistik” einmal.

Mit vs. ohne KI, ein ehrlicher Vergleich

Einschätzung auf einen Blick

Zeitersparnis, hoch (4/5) Die Rechnung ist simpel: Wer 2–4 Stunden pro Woche an Wissenssuche spart, gewinnt direkt abrechenbare Zeit zurück. Bei 50 Beratern sind das 100–200 Stunden pro Woche für das Unternehmen, die in neue Projektarbeit fließen können. Der Effekt ist sofort spürbar und messbar.

Kosteneinsparung, mittel (3/5) Der Setup ist kostspielig (25.000–80.000 € einmalig, siehe unten), und die monatlichen Betriebskosten sind nicht trivial. Allerdings: Die eingesparte Zeit führt bei konservativer Rechnung zu 100.000–150.000 € mehr abrechenbarem Gewinn im ersten Jahr. Die ROI ist da, aber nicht so direkt wie bei Dokumentation oder Präsentationsassistenz.

Schnelle Umsetzung, schwierig (2/5) Das ist die ehrliche Note. RAG-Systeme sind nur so gut wie ihre Daten, und Unternehmens-Dokumentationen sind chaotisch. Es braucht 12–20 Wochen Arbeit: Dokumente sammeln, vereinheitlichte Metadaten-Tags etablieren, Zugriffskontrolle regeln, Indizierung testen. Eine schnelle Integration ist nicht möglich, wer das verspricht, liefert Müll ab.

ROI-Sicherheit, mittel (3/5) Zeitersparnis lässt sich messen und ist relativ sicher. Aber der Nutzen hängt stark ab von: Wie gut indizieren wir? Wie oft nutzen die Berater das System wirklich? Finden sie das, das sie suchen? Die ersten 3–6 Monate sind oft enttäuschend, bis das Team das System zu benutzen lernt und die Indexierung verfeinert wird.

Skalierbarkeit, gut, mit Caveat (4/5) Technisch skaliert ein RAG-System linear. Aber organisatorisch ist es kritisch: Neue Projekte müssen dokumentiert werden. Alte Dokumentationen müssen gepflegt werden. Ohne eine Person, die das aktiv verwaltet, sinkt die Qualität der Suche rapide. Das ist anders als ein Dokumentations-KI-Tool, das nicht pflegt, die Wissensdatenbank braucht aktive Kuratorenschaft.

Richtwerte, stark abhängig von Dokumentenmenge, -qualität, Unternehmenskultur und ob eine eigene Person die Wissensverwaltung übernimmt.

Was das System konkret macht

Die Architektur folgt einem bewährten Muster namens RAG (Retrieval-Augmented Generation):

Schritt 1: Dokumenten-Erfassung und Metadaten. Alle internen Projektdokumentationen, Proposals, Final Reports, Methodiken, Leitfäden, werden gesichtet, in ein standardisiertes Format überführt (typischerweise PDF oder strukturierte Markdown) und mit Metadaten versehen: Projekt-ID, Kunde, Branche, Technologie, Abschluss-Datum, Projekt-Lead. Das ist der arbeitsintensivste Schritt. Ohne saubere Metadaten funktioniert der nächste Schritt nicht.

Schritt 2: Vector-Embedding. Ein Modell (typischerweise ein Large Language Model (LLM) wie OpenAI’s Embedding API oder ein Open-Source-Modell wie MiniLM) liest jeden Projektbericht Abschnitt für Abschnitt und konvertiert den Text in eine numerische Repräsentation, einen “Vector”. Diese Vectors erfassen semantische Bedeutung, nicht nur Keywords. “SAP im Mittelstand” und “Enterprise-System in KMU” landen nah beieinander im Vector-Raum, obwohl sie unterschiedliche Worte nutzen.

Schritt 3: Indexierung und Speicherung. Die Vectors werden in einer Vector-Datenbank gespeichert (z.B. Pinecone, Weaviate, Milvus, oder als lokale Alternative Faiss). Jeder Vector ist mit den ursprünglichen Metadaten und der Quelle verlinkt.

Schritt 4: Semantische Suche durch den Berater. Ein Berater stellt eine natürlichsprachige Frage: “Haben wir ähnliche Projekte mit SAP-Implementierung im Mittelstand gemacht? Besonders interessiert mich, wie ihr Datenmigration strukturiert habt.”

Das System wandelt diese Frage ebenfalls in einen Vector um, sucht die ähnlichsten Dokumenten-Vectors in der Datenbank und retrievet die Top-N Treffer.

Schritt 5: Kontext und Antwort. Die gefundenen Dokumenten-Auszüge werden zusammen mit der ursprünglichen Frage an ein LLM gegeben, mit einem Prompt wie “Basierend auf diesen bisherigen Projektbeispielen, wie haben wir Datenmigration angegangen?”

Das Modell synthesiert eine strukturierte Antwort: “Hier sind drei ähnliche Projekte: [Liste mit Zitaten], Gemeinsame Erkenntnisse waren: [Zusammenfassung], Kontaktpersonen für detaillierte Fragen: [Namen + E-Mail].”

Die Antwort enthält nicht halluzinierte Informationen, sondern nur Dinge, die tatsächlich in den Dokumenten stehen, mit Zitaten und Quellenangaben.

Konkrete Werkzeuge, was wann passt

Claude mit RAG-Integration, Der manuellste Weg, aber ideal für den Piloten. Keine Tool-Integration nötig: Dokumenten-Auszüge ins Chat-Interface, Frage stellen, fertig. Begrenzt durch Manual Copy-Paste, aber Zero-Setup-Kosten und hohe Kontrollierbarkeit. Gut für: Teams unter 15 Personen, exploratives Piloten.

Notion AI (mit Notion Workspace-Integration), Wenn das Team bereits Notion für Dokumentation nutzt, bietet Notion AI eine semi-automatische RAG über Workspace-Inhalte. Nicht perfekt (Notion kennt nur seine eigenen Inhalte), aber weniger Einrichtungsaufwand als eine dedizierte RAG-Lösung. Kostenlos für aktuelle Notion-Nutzer.

Glean, Enterprise-KI-Suchmaschine, spezialisiert auf strukturiertes Unternehmens-Wissen. Integriert mit Microsoft 365, Salesforce, Jira, Confluence. Für Konsultationen gut, wenn die Dokumentation bereits in diesen Systemen liegt. Pricing bei auf Anfrage; typischerweise ab 50+ Mitarbeiter wirtschaftlich.

Coveo, Ähnlich wie Glean, aber stärker bei hybrider On-Premise + Cloud-Infrastruktur. Für größere, dezentralisierte Organisationen. Höhere Einrichtungskosten, aber bessere Kontrolle. Kostenmodell verhandelt.

Azure AI Search (ehemals Cognitive Search), Microsoft-Stack: Wenn das Unternehmen bereits in Azure sitzt und Dokumente in Azure Blob/SharePoint/OneDrive hat. Der Aufwand ist hier niedriger als ein standalone RAG-System. Pricing: ca. 200–500 €/Monat für eine mittelgroße Indizierung.

Make.com + OpenAI Embeddings, Der DIY-Weg für technische Teams: Make.com orchestriert den Workflow (Dokumente von SharePoint/Drive holen → OpenAI Embeddings erzeugen → Pinecone speichern), und jede Suche löst automatisch einen Retrieve + ChatGPT-Prompt aus. Anfangsaufwand mittel, aber maximale Flexibilität und Kostenoptimierung. Gut für: Technical Leads, die Full-Stack-Kontrolle wollen.

Vectara, Spezialisierte RAG-Plattform mit built-in LLM und Retrieval. Weniger Konfiguration als Make.com + Pinecone, aber weniger Freiheit. Pricing: kostenlos für < 1M requests/Monat, dann 300+ €/Monat. Gut für: Unternehmen, die schnell ohne DevOps-Overhead starten wollen.

Zusammenfassung der Wahl:

• Unter 20 Personen, Pilotphase: Claude manuell oder Notion AI
• 20–100 Personen, Microsoft-Shop: Azure AI Search
• 50+ Personen, Enterprise-Anforderungen: Glean oder Coveo
• Technical Team, maximale Kontrolle: Make.com + OpenAI + Pinecone
• Schnell produktiv, keine Ops-Overhead: Vectara

Datenschutz und Datenhaltung

Projektdokumentationen in Beratungen enthalten oft höchst sensible Informationen: Mandanten-Geschäftsstrategien, Finanzdaten, interne Zahlen, personenbezogene Daten von Kontaktpersonen, oder sogar Due-Diligence-Informationen aus M&A. Ein RAG-System mit schlecht konfigurierten Zugriffskontrolle kann diese Daten exposieren.

Was du vor dem Start klären musst:

1. Data Residency und Hosting. RAG-Systeme brauchen Vektor-Speicherung. Für Beratungen ist EU-Hosting (idealerweise DE) nicht optional sondern Standard. Das schränkt Optionen ein:

   • Glean: EU-Hosting verfügbar (auf Anfrage)
   • Coveo: EU-Optionen vorhanden
   • Azure AI Search: In EU-Region (z.B. westeurope) buchbar
   • Vectara: Hat EU-Hosting
   • Pinecone + selbst gehostete APIs: Volle Kontrolle, aber mehr Ops-Aufwand
   • Notion AI: Notion speichert in USA, für Mandanten-Daten oft ausgeschlossen

2. Zugriffskontrolle und Zugriffs-Logs. Das RAG-System muss verstehen: Berater X darf Dokumentation von Kunde Y nicht sehen, aber alles von Kunde Z. Das erfordert:

   • Für jedes Dokument: explizite “darf X sehen?”-Metadaten
   • Access-Control-Listen (ACLs) im RAG-System konfigurieren
   • Audit-Logs: Wer hat welche Suche gemacht? Regelmäßige Logs prüfen.

3. AVV und Auftragsverarbeitung. Wenn der RAG-Anbieter Daten verarbeitet, brauchst du einen AVV (Auftragsverarbeitungsvertrag) nach Art. 28 DSGVO. Die meisten Anbieter bieten diese an, aber der Prozess kann 2–4 Wochen dauern.

4. Mandanten-Erlaubnis. Viele Beratungs-Mandate verbieten explizit, dass Projektinformationen in andere Systeme überführt werden (besonders im Financial Services oder M&A). Du musst mit jedem Mandanten klären: “Darf diese Projektdokumentation in unser internes RAG-System?” Ohne diese Erlaubnis musst du Dokumente ausschließen.

Praktischer Tipp: Starte mit einem “Non-Sensitive” Set, allgemeine Methodiken, Leitfäden, anonymisierte Case Studies, Template-Dokumentationen. Das Mandanten-sensible Material kommt erst später, und nur mit expliziter Freigabe.

Was es kostet, realistisch gerechnet

Einmalige Einrichtungskosten

Diese sind oft unterschätzt und variieren wild je nach Dokumentenzustand:

• Dokumenten-Audit und -Strukturierung (Zeit, nicht Tool): 160–320 Stunden (4–8 Wochen) für ein 50-Personen-Unternehmen mit 5–10 Jahren Projekthistorie
• Metadaten-Schema definieren und Tagging (manuell oder semi-automatisch): 80–160 Stunden
• RAG-System Setup, Zugriffskontrolle, Pilot: 120–200 Stunden
• Gesamtbudget: 25.000–80.000 € (abhängig von: Wie chaotisch sind die Ursprungsdokumente? Nutzt ihr mehrere Plattformen parallel (SharePoint, Drive, Netzlaufwerk)? Wie sensibel ist das Datenschutz-Setup?)

Laufende Kosten (monatlich)

• Azure AI Search: 200–500 € (abhängig von Indizierungsmenge)
• Glean: Auf Anfrage, typischerweise 500–2.000+ € für ein 80-Personen-Team
• Coveo: Ähnlich, 500–1.500+ €
• Vectara: 0–300 € (kostenlos bis 1M requests)
• Notion AI: 0 € (falls bereits Notion-Lizenziert)
• Make.com + Pinecone + OpenAI: 100–400 € (abhängig von Dokumentenvolumen und Request-Häufigkeit)

Conservative ROI-Rechnung

Annahme: 50-Personen-Team, jeder Berater spart durchschnittlich 2 Stunden/Woche durch bessere Wissensrecherche (konservativ), Vollkostenhonorar 140 €/h:

• Eingesparte Stunden: 50 × 2 h × 52 Wochen = 5.200 h/Jahr
• Wert dieser Zeit: 5.200 h × 140 € = 728.000 € (aber: nicht 100 % dieser Zeit wird direkt abrechenbar, realistisch 50–70 % Conversion)
• Konservative Annahme: 35–50 % der eingesparten Zeit in zusätzliche Abrechnung = 254.000–364.000 € Mehrgewinn
• Betriebskosten Jahr 1: 25.000–80.000 € (Setup) + 6.000–24.000 € (Betrieb) = 31.000–104.000 €
• Netto-Vorteil konservativ: 150.000–333.000 €

Die ROI ist massiv, aber nur, wenn:

1. Die Dokumentation gut genug ist (Quality In = Quality Out)
2. Die Berater das System tatsächlich nutzen (Adoption ist der kritische Erfolgsfaktor)
3. Die gewonnene Zeit in abrechenbare Arbeit fließt (nicht einfach in Freizeit umgewandelt wird)

Drei typische Einstiegsfehler

1. Schlechte Datenqualität mit KI kompensieren zu wollen. Der klassische Fehler: Alle Dokumente chaotisch ins System werfen und erwarten, dass die KI das schon sortiert. Was passiert ist: Chaotische Dokumente → mehrdeutige Embeddings → schlechte Suchresultate. Das Team sagt dann “das System funktioniert nicht”, obwohl das Problem die Quelle war. Die Lösung vor der Lösung: Erst die Dokumentationen strukturieren und metadatieren. Das dauert lange, ist aber zwingend.

2. Alle Dokumente auf einmal indizieren. Der Gegenpol: Vollständigkeit-Streben führt zu Paralysierung. “Wir machen es richtig: erst alle 10 Jahre Dokumentationen durchgehen, dann einsetzen.” Das Projekt läuft 12 Monate. Besser: MVP starten, die letzten 2 Jahre hochwertige Dokumentationen indizieren, dann Leben in das System bringen, dann rückwärts gehen. Nach 3 Monaten hat das Team bereits Nutzen und kann zu Phase 2 mit Altkram übergehen.

3. Keine Person für die Wissensverwaltung zuständig. RAG-Systeme sind nicht “einmal bauen und vergessen”. Neue Projekte müssen dokumentiert werden, alte Referenzen müssen aktualisiert werden, die Qualität der Suchergebnisse muss regelmäßig geprüft werden. Ohne explizite Zuständigkeit (20 % Kapazität einer Person oder ein rotierendes Team) sinkt die Qualität nach 6 Monaten rapide. Das ist organisatorische Arbeit, nicht technische, und sie kostet was.

Was mit der Einführung wirklich passiert

Das Spektrum der Reaktionen ist breit:

Junioren und Mid-Level: Begeisterung. Sie haben am meisten von besserer Wissens-Zugänglichkeit. Statt 2 Stunden zu recherchieren, finden sie in 15 Minuten die Antwort. Das ist für sie ein Produktivitäts-Gewinn, den sie sofort spüren.

Erfahrene Senioren: Ambivalent bis widerständig. Manche sehen das System mit Sorge: “Wenn alle Wissen jederzeit abrufen können, sinkt mein Wert in diesem Unternehmen.” Das ist keine irrationale Angst, in hierarchischen Organisationen ist Informationskontrolle eine echte Machtquelle. Die Lösung ist nicht überzeugend zu reden, sondern transparent zu machen: Senioren werden für Synthese und Urteil bezahlt, nicht für Informationshortung. Das System gibt ihnen Zeit für höherwertige Arbeit. Manche Senioren kaufen das sofort, andere nie.

Was konkret hilft:

• Mit Senioren-Freiwilligen starten (nicht Zwang), diejenigen, die das System cool finden, werden zu Multiplikatoren
• Zeigen, dass das System ergänzt, nicht ersetzt: Fragen, bei denen nur ein Senior die kontextuelle Antwort geben kann, werden immer noch an den Senior gerichtet, aber mit besserer Vorrecherche
• Nach 3 Monaten echte Nutzungsmetriken teilen: “Das Team hat diese Woche [Zahl] Recherchen gemacht, statt durchschnittlich [Zahl] Stunden zu verbringen. Das sind [Zahl] mehr abrechenbare Projektarbeit.”
• Senior-Rollen umdefinie in Richtung der neuen Realität: von “Informations-Gatekeeper” zu “Qualitäts-Reviewer” oder “Knowledge Curator”, eine echte neue Rolle im System

Das größte praktische Problem: Falsche Such-Ergebnisse werden schnell bemerkt und untergraben Vertrauen. Ein Berater stellt eine Frage, erhält eine “ähnliches Projekt” als Treffer, liest die Zusammenfassung, und stellt fest: “Das hat mit unserem Problem nichts zu tun.” Von da an nutzt er das System nicht mehr. Qualitäts-Checks müssen in den ersten 4 Wochen täglich stattfinden.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

„Unsere Dokumentationen sind zu unstrukturiert. Das System wird nicht funktionieren.” Das ist nicht falsch, schlechte Dokumentation führt zu schlechten Embeddings. Aber das ist nicht ein Grund, es nicht zu versuchen, sondern ein Grund, mit Strukturierung zu beginnen. Manche Teams fangen mit dem MVP an (nur hochwertige Dokumente), merken dann schnell den Nutzen, und kriegen dadurch die Motivation, die älteren Doku zu überarbeiten. Die Aussicht auf “alle können jederzeit unser Wissen abrufen” ist oft Motivation genug.

„Die KI halluziniert und macht einfach Projekte auf.” Halluzinationen sind ein echtes RAG-Problem, aber nicht unkontrollierbar. Das Gegenmittel: Strict Retrieval. Das System darf nur das zitieren, was tatsächlich in Dokumenten steht. Mit guter Prompt-Struktur (“Antworte nur auf Basis dieser Dokumente”) und Grounding in echten Dokumenten-Auszügen sinkt die Halluzinationsrate unter 5 %. Gut eingerichtete RAG-Systeme halluzinieren weniger als schlecht eingerichtete ChatGPT-Nutzung.

„Das ist ein großes Datenschutz-Risiko. Alle Projektdaten zentral?” Verständlicher Einwand. Aber auch eine False Choice: Alternativ sind die Daten jetzt dezentral auf Laufwerken, in E-Mail-Archiven, und in den Köpfen von Senioren. Ein zentral gespeichertes RAG-System mit Zugriffskontrolle und Audit-Logs ist sicherer als dezentrale Chaos. Die DSGVO verlangt Datenschutz, nicht “zerstreue deine Daten”. Mit richtigem Setup (EU-Hosting, AVV, Access-Logs) ist ein RAG-System mehr DSGVO-konform als das Status Quo.

Woran du merkst, dass das zu dir passt

• Dein Team fragt regelmäßig: “Haben wir das schon mal gemacht?” und es dauert Stunden, die Antwort zu finden (wenn überhaupt)
• Junioren klagen, dass Onboarding unzureichend ist, weil sie dem Senior-Wissen nicht zugänglich machen können
• Mehrere Berater arbeiten nebeneinander an ähnlichen Problemen ohne voneinander zu wissen, weil Wissensaustausch kein Prozess ist
• Du nutzt mehrere Plattformen parallel (SharePoint, Google Drive, Confluence, Netzlaufwerk) und es gibt keine zentrale Quelle der Wahrheit
• Dein Kundenfeedback enthält: “Warum schlagen ihr uns ein Ansatz vor, den wir bei eurem Konkurrenten schon ein Mal umgesetzt habt?” (Zeichen: euer Wissen ist intern nicht nutzbar)

Wann es sich (noch) nicht lohnt, zwei harte Ausschlusskriterien:

1. Weniger als 20 Berater und sehr wenige wiederkehrende Projekte. Der Aufwand für Setup und Pflege amortisiert sich erst mit Skalierung. Eine Small Boutique mit 5 Beratern, die alle verschiedene spezialisierte Nischen-Projekte machen, hat wenig Nutzen von RAG.

2. Dokumentationen sind völlig undokumentiert und kein Wille zur Strukturierung. Wenn das Team sagt “wir können unsere Doku nie auf einem Niveau bringen, das für RAG reicht”, sind sie wahrscheinlich richtig. Der Aufwand ist dann zu groß für den Nutzen.

Das kannst du heute noch tun

Öffne Claude oder ChatGPT, kostenlos, schnell, keine Integration.

Nimm 3–5 alte Projektdokumentationen (Proposals, Reports, Methodiken) und speichere sie als PDFs.

Füge sie in den Chat ein (oder copy-paste die wichtigsten Auszüge) und stelle folgende Frage mit diesem Prompt:

Das ist dein Proof-of-Concept. Wenn das funktioniert, weißt du: RAG hat Potenzial für euer Team. Wenn es schlecht läuft, weißt du: eure Dokumentationen brauchen zuerst Strukturierung.

Quellen & Methodik

• McKinsey Consulting Practice Data (2023): McKinsey Global Surveys zur Consultants’ Time Allocation zeigen durchgängig, dass 30–40 % der Zeit auf Information Gathering und Synthesis entfällt. Reduktionspotenzial durch interne Wissenssysteme: ca. 60 %.
• Beratungs-Benchmarks (BDU e.V., 2025): Deutsche Unternehmensberater berichten durchschnittlich 10–15 % Zeitaufwand für Wissensbeschaffung.
• Harvard Business Review “The Productivity Paradox in Consulting” (2024): “Knowledge Management Systems reduce research time by 50–70 % if properly maintained; decay risk after 6 months without active curation.”
• Vector Embedding & RAG State-of-Art (2025): Aufgrund der Rapid-Iteration in Gen-AI-Tooling sind die Spezifikationen für Embedding Models, Retrieval Ranking, und Prompt-Grounding alle 3–4 Monate aktualisiert. Siehe arxiv.org oder Papers with Code für neueste Architektur.
• Datenschutz-Compliance (Art. 28 DSGVO, aktuelle Fassung): Auftragsverarbeitungsverträge sind für alle Third-Party-Datenverarbeitung erforderlich.
• Case Study: Glean Deployment bei Boston Consulting Group (2024): BCG berichtet, dass nach Glean-Deployment durchschnittliche Recherchzeit für Precedents von 3 Stunden auf 20 Minuten sank (Quelle: Glean Case Study, online verfügbar).

Du willst testen, wie eure Dokumentation mit RAG-Suche funktioniert? Meld dich, wir bauen dir einen Pilot-Workspace mit den nächsten 3 Monaten Unterstützung.