Business Brain — Field Notes (interne Swisscom-Fassung)

🔒 Intern – nicht für externe Veröffentlichung. Diese Fassung beschreibt unser konkretes Setup (Tooling, Working Model) und ist als Learning / Field Notes für interne Swisscom-Zielgruppen gedacht. Die öffentliche LinkedIn-Fassung liegt separat (V4). Vor Weitergabe: Sensitivität prüfen – Vault-Inhalte sind vertraulich, die hier beschriebene Methode ist teilbar. Zahlen (McKinsey, Deloitte, Accenture) vor breiter Streuung gegenprüfen.

Worum es geht (kurz, für alle, die die öffentliche Version schon kennen)

«We know more than we can tell.» – Michael Polanyi, 1966. Das meiste Wissen, das eine Organisation ausmacht, ist implizit: Es lebt in Köpfen, Chats und Meetings, nicht in Dokumenten. Genau dieses Wissen brauchen unsere KI-Agenten am dringendsten – und genau dieses fehlt ihnen.

Unsere These in einem Satz: Der Engpass aktueller Enterprise-KI ist nicht das Modell, sondern das Fundament darunter. Wir nennen dieses fehlende Substrat den «Business Brain». Accenture zeigte am Swiss MarTech Summit (Lavazza «Brand Brain») dieselbe Aufteilung, die wir im Alltag sehen: ~20 % einer Marke sind explizit dokumentiert, ~80 % bleiben implizit.

Soweit die Theorie. Dieses Dokument geht auf das Wie ein – und ehrlich auch auf das, was wir dabei gelernt (und vermasselt) haben.

Warum als „Learning" und nicht als „Blueprint"

Wir haben keinen fertigen Bauplan gefunden, den wir abarbeiten konnten. Wir haben angefangen, sind in Sackgassen gelaufen, haben umgebaut. Was hier steht, ist deshalb bewusst als Field Notes formuliert: Stand heute, mit allen offenen Punkten. Wer es nachbauen will, soll von unseren Umwegen profitieren – nicht so tun, als gäbe es keine.

Das Setup – konkret

Single Source of Truth: ein versionierter Markdown-Vault

Unser Business Brain ist im Kern ein Obsidian-Vault aus Markdown-Dateien, versioniert in GitLab (intern, code.swisscom.com). Bewusst schlicht – und bewusst nicht ein neues Tool, das erst gekauft, integriert und gepflegt werden muss.

Warum diese Wahl, nicht Confluence/SharePoint:

• Markdown ist menschen- und maschinenlesbar. Dieselbe Datei, die ein Mensch in Obsidian liest, ist der Kontext, den ein Agent bekommt. Kein Export, kein Format-Bruch.
• Git bringt Versionierung, Historie und Konfliktbehandlung von Haus aus mit – die drei Eigenschaften, auf die es ankommt (siehe unten), sind eingebaut statt nachgerüstet.
• Kostenfrei & portabel. Plain-Text in Git läuft überall, kein Vendor-Lock-in, volle Datenhoheit – die Dateien liegen in unserer GitLab-Instanz, nicht in einer fremden Cloud.
• Obsidian als Editor: schnelles Verlinken, Graph-Sicht, lokal. Das Git-Plugin synct die Arbeit fast unsichtbar im Hintergrund.

Drei-Vault-Struktur

Wir trennen nach Zweck, verlinkt über obsidian://-URIs:

• knowledge-vault – das Herzstück: Use Cases, Methodik, Research, Strategie-Threads.
• mta.strategy – Strategie-Artefakte für breitere Audienzen.
• mta.dataeng – Data-Engineering-naher Content.

Learning: Die Trennung kam nach dem ersten Wildwuchs. Anfangs war alles in einem Vault – das wurde schnell unübersichtlich. Wenn wir nochmal starten würden, würden wir die Schnitte früher setzen, aber nicht überfrüh: zu viele Vaults zu Beginn hätten genauso gebremst.

Die drei Prinzipien – wie sie konkret umgesetzt sind

1. Nachvollziehbarkeit (Provenienz). Jede Information soll wissen, woher sie kommt. In der Praxis: Quelle und Stand laufen im Dokument mit, und die Git-Historie protokolliert lückenlos, wer wann was geändert hat – das Commit-Autorenfeld ist unser eingebauter Provenienz-Layer. Learning: Das funktioniert nur, wenn die Disziplin sitzt. „Unbestätigt, Stand März" ist wertvoller als eine glatte Behauptung ohne Herkunft – aber es muss auch wirklich so erfasst werden.

2. Widersprüche werden gehalten, nicht weggemittelt. Wo fünf Leute einen Account oder Entscheid unterschiedlich sehen, ist diese Uneinigkeit die Information. Git ist dafür gemacht: konkurrierende Stände stehen nebeneinander, mit Urheber und Zeitpunkt. Zusätzlich flaggen wir Tentatives explizit („half-baked", „draft", „exploring"), damit work-in-progress nicht als gesicherte Position missverstanden wird – weder von Menschen noch von Agenten.

3. Abgleich mit der Realität. Was wir über Marketing oder Kunden zu wissen glauben, wird gegen tatsächliche Ergebnisse geprüft. Was sich bestätigt, gewinnt Gewicht; was widerlegt wird, wird korrigiert oder als unsicher markiert. Learning: Das ist der am schwersten durchzuhaltende Teil – der bequeme Default ist, Inhalte einmal abzulegen und nie wieder gegen die Realität zu halten.

Governance: Menschen entscheiden, Agenten schlagen vor

Unsere wichtigste Leitplanke: Nur Menschen editieren den Vault. Ein Agent darf vorschlagen – die Integration in den Wissensstand ist eine bewusste menschliche Entscheidung. Das klingt nach Reibung, ist aber genau der Punkt: Es hält das Substrat sauber und verhindert, dass sich KI-Output unkontrolliert selbst verstärkt. Für ein Enterprise-Setting ist das auch die Antwort auf die Governance-Frage, die sonst gern „später" kommt.

Implizites Wissen herausholen: Interview-Agents

Der eigentliche Hebel sitzt nicht im Tool, sondern im Gespräch. Wir holen implizites Wissen dort ab, wo es lebt – bei den Menschen – mit strukturierten Interviews. Transkripte dieser Gespräche fließen aufbereitet in den Vault und speisen genau jenen Modus, der sich bisher nicht skalieren liess (die menschlichen Modi aus Nonaka/Takeuchis SECI-Modell). Learning: Qualität der Fragen schlägt Quantität der Dokumente. Ein gutes 30-Minuten-Interview liefert mehr nutzbares Substrat als ein halber Confluence-Space.

Was wir gelernt haben (die ehrliche Liste)

• Disziplin > Technologie. Das Setup ist erstaunlich schlicht. Die Schwierigkeit liegt nicht im Tooling, sondern im Durchhalten: Provenienz erfassen, Widersprüche stehen lassen, gegen Realität prüfen – jeden Tag.
• Klein anfangen, aber richtig. Eine einzige Domäne, die schmerzt oder sich anbietet – ein Brand-Thema, ein Schlüssel-Account, ein zentrales Angebot. Nicht das Gesamtunternehmen auf einmal.
• Tempo vs. Tragfähigkeit. Der schnelle Prototyp ist verlockend. Tragfähig wird er erst auf einem Fundament nach den drei Prinzipien. Diese Abwägung kommt immer wieder – wir treffen sie inzwischen bewusst.
• Grösser als gedacht. Wir haben den Aufwand am Anfang unterschätzt. Das ist kein Argument dagegen, sondern dafür, es seriös statt nebenbei zu tun.

Warum das gerade intern relevant ist

Die Tools sind plötzlich in jeder Hand. Jede und jeder will etwas bauen – einen Agenten hier, einen Assistenten dort. Foundation, Governance, Datenbasis? Kommt später, wenn überhaupt. Das erzeugt einen Hype-getriebenen Groove, der sich grossartig anfühlt – bis die Erwartung auf die Realität trifft. Genau hier öffnet sich die Lücke zwischen dem, was alle erwarten, und dem, was sich auf einem ungeklärten Fundament liefern lässt. Ein beeindruckender Prototyp ist schnell gebaut; ihn verlässlich, governance-konform und auf belastbaren Daten in Produktion zu bringen, ist eine andere Liga.

Unser Vorschlag ist keine fertige Lösung, sondern eine Haltung: erst das Fundament, dann skalieren. Wir teilen unsere Field Notes, weil wir glauben, dass andere Teams bei Swisscom denselben Weg vor sich haben – und nicht jede:r dieselben Umwege gehen muss.

Anschluss / Austausch

Wenn euer Team an einem ähnlichen Fundament arbeitet (oder darin feststeckt): Lasst uns reden. Genau dieser Austausch – was bei euch funktioniert, was nicht – ist der schnellste Weg, die kollektiven Umwege zu verkürzen.

Verwandt: «We know more than we can tell» – V4 (öffentliche LinkedIn-Fassung). · Quellen: Polanyi (1966); Nonaka & Takeuchi (1995, SECI); Anthropic (Context Engineering); Accenture/Lavazza „Brand Brain", Swiss MarTech Summit 2026, Winterthur.