Quelltext der Seite Gkc25/Wiki anstelle von Dokumenten - Confluence oder Open Source

'''Diese Session thematisiert den Einsatz von Wiki-Systemen in Organisationen und die damit verbundenen Herausforderungen. Im Mittelpunkt steht der Austausch über verschiedene Wiki-Lösungen, insbesondere Confluence und SharePoint, sowie die bevorstehende Zwangsmigration in Cloud-Lösungen bis 2029. Der Moderator argumentiert für einen grundlegenden Paradigmenwechsel von dokumentenzentriertem zu seitenbasiertem Arbeiten mit robusten URLs als Kernargument. Dabei werden technische, organisatorische und kulturelle Aspekte diskutiert, wobei die Teilnehmenden sowohl Chancen als auch erhebliche Bedenken hinsichtlich Kosten, Sicherheit und Qualitätsmanagement äußern.'''

'''Hauptthemen der Präsentation:'''

# Wiki-Systeme im Einsatz: Überblick und Erfahrungen
# Die Cloud-Migration bis 2029 als zentrale Herausforderung
# Robuste URLs als Schlüsselargument für Wiki-Systeme
# Dokumentenzentriertes vs. seitenbasiertes Arbeiten
# Qualitätssicherung und Wissensmanagement
# Rechtliche und sicherheitstechnische Anforderungen
# Organisatorische und kulturelle Barrieren

== Wiki-Systeme im Einsatz: Überblick und Erfahrungen ==

Die Teilnehmenden berichten von sehr unterschiedlichen Wiki-Implementierungen in ihren Organisationen. Die Bandbreite reicht von großen, offenen Systemen bis zu stark fragmentierten Lösungen mit erheblichen Herausforderungen.

Bei Siemens läuft seit 2008 eine große Confluence-Instanz mit einem sehr offenen Ansatz, der als Erfolgsfaktor identifiziert wird. Der Großteil der Seiten ist für alle zugänglich, was die Nutzung und den Wissensaustausch fördert. Eine Agentur nutzt SharePoint-Seiten in Vorbereitung auf Co-Piloten-Integration, berichtet aber von Kunden, die jahrelang Confluence aufgebaut haben und nun vor schwierigen strategischen Entscheidungen stehen.

Im öffentlichen Sektor zeigt sich ein differenziertes Bild. Eine Behörde führte 2016 ein Wiki ein, das zunächst nicht genutzt wurde. Erst nach einem zweijährigen Wissensmanagement-Projekt mit der Universität Regensburg wurde das System ab 2021 erfolgreich. Mit über einer Million Seitenaufrufen gilt dies als Erfolg, wobei das System geschlossen ist und nur Mitarbeitenden zugänglich.

Das Verteidigungsministerium betreibt seit 2008 Confluence mit 210.000 Nutzern und 1,8 Millionen Seiten, wovon 500.000 aktiv genutzt werden. Die Organisation beschreibt sich selbst als dokumentenzentriert mit Entscheidungsprozessen, die seit 1840 unverändert sind. Dies führt zu Herausforderungen, da Informationen auf drei Seiten zusammengefasst werden müssen, was die Qualität beeinträchtigt.

Eine IT-Agentur mit Wachstum von 300 auf 1.300 Mitarbeitende nutzt Confluence sowohl als internes Intranet als auch als Dokumentationsplattform für Kunden. Der Fokus lag in den letzten Jahren auf der Qualitätssicherung durch ein Qualitätsmanagementsystem, das auf jeder Seite anzeigt, wann der Inhalt zuletzt auf Aktualität geprüft wurde.

Ein Tech-Unternehmen mit 350 Mitarbeitenden wechselte vor etwa acht Jahren von DekiWiki zu Confluence. SharePoint wurde bewusst abgelehnt. Die Organisation nutzt eine Struktur mit Spaces pro Abteilung, Projekt und teils pro Produkt. Der Tech-Bereich ist weitgehend offen gestaltet, während Verwaltungsbereiche wie HR geschlossen bleiben.

== Die Cloud-Migration bis 2029 als zentrale Herausforderung ==

Die bevorstehende Zwangsmigration von Atlassian-Produkten in die Cloud bis 2029 stellt für nahezu alle Teilnehmenden die größte aktuelle Herausforderung dar. Atlassian zwingt seine Kunden in die Cloud-Lösung ähnlich wie Microsoft, was erhebliche Auswirkungen hat.

Die zentrale Frage ist, ob und wie sich offene Wiki-Setups in Cloud-Umgebungen übertragen lassen. Dabei geht es nicht nur um technische Machbarkeit, sondern auch um neue Abhängigkeiten und Kostenstrukturen. Viele Organisationen fragen sich grundsätzlich, ob sie diese Cloud-Migration überhaupt wollen und ob sie die damit verbundenen Kosten tragen können oder wollen.

Besonders problematisch ist die Situation für Organisationen mit stark angepassten Systemen. Ein Tech-Unternehmen berichtet, dass ihr Confluence-System stark kustomisiert ist und es schlichtweg keinen Migrationspfad gibt. Die Integration mit Jira als Gesamtpaket ist sehr attraktiv, aber die fehlende Migrationsmöglichkeit führt zu einem Lock-in-Effekt.

Für den öffentlichen Sektor und sicherheitskritische Bereiche ist die Cloud-Thematik besonders heikel. Eine Behörde des Bundesinnenministeriums arbeitet sowohl im Intranet als auch behördenübergreifend im Extranet mit Confluence und SharePoint. Die Cloud-Lösung ist momentan keine Option, was die Hoffnung weckt, dass durch gemeinsames Vorgehen aller Behörden eine nicht-fragmentierte Lösung gefunden werden kann.

Das Verteidigungsministerium betont, dass die aktuelle amerikanische Administration sie zwingt, auf alle KI-Lösungen zu verzichten, die nicht selbst entwickelt, aufgesetzt und in eigenen roten Netzen betrieben werden. Dies macht das Cloud-Thema besonders komplex, da viele Vorteile moderner Systeme nicht genutzt werden können.

Die Kostenfrage spielt eine erhebliche Rolle. Viele Organisationen betreiben sowohl Confluence als auch SharePoint parallel, was kostenintensiv ist. Die Frage nach alternativen Lösungen wird gestellt, aber bislang gibt es keine klare Best-Practice-Lösung mit funktionierenden Migrationspfaden für gängige Plugins.

== Robuste URLs als Schlüsselargument für Wiki-Systeme ==

Der Moderator präsentiert robuste URLs als zentrales Argument für den Einsatz von Wiki-Systemen gegenüber dokumentenbasierten Lösungen. Eine robuste URL ist eine stabile Webadresse, die dauerhaft auf dieselbe Information verweist, auch wenn sich deren Darstellung oder Titel ändern.

Das Hauptproblem bei Dokumenten ist das Fehlen stabiler, robuster URLs. Man kann nicht dauerhaft auf eine spezifische Stelle in einem Dokument verweisen, besonders wenn dieses Dokument weiterentwickelt wird. Im 21. Jahrhundert sollten robuste URLs zur digitalen Grundbildung gehören - das Verständnis, dass ein Link auch morgen noch dorthin führt, wo die gewünschte Information zu finden ist.

Dieses Argument gewinnt durch die KI-Welle zusätzlich an Bedeutung. Chatbots und Sprachmodelle können Informationen zusammenfassen, aber die entscheidende Frage bleibt: Woher kommt das Wissen? Spätestens hier werden URLs wieder zentral, denn Nutzer wollen oder müssen nachvollziehen können, was die Quelle der Information ist und was in deren Kontext steht.

Mit Dokumenten ist dies nicht leistbar. Auch ein PDF-Verweis auf Seite 30 ist keine praktikable Lösung. Die Mediengeschichte zeigt, dass verschiedene Ansätze gescheitert sind. Dokumentenmanagementsysteme mit eindeutigen IDs wurden nie wirklich erfolgreich, da Dokumente ständig umbenannt und verschoben wurden, wodurch stabile Referenzen verloren gingen.

Auch das Semantic Web von Tim Berners-Lee aus dem Jahr 2001 verfolgte ähnliche Ziele mit autonomen Agenten und stabilen semantischen URLs. Die Idee war, dass Informationen semantisch verknüpft und dauerhaft referenzierbar sind. Dies funktionierte jedoch nicht, teilweise weil die Konzepte zu verkopft waren und selbst Fachleuten nicht klar war, dass URLs klickbar sein sollten.

Confluence macht hier einen besonders guten Job, indem es Links konsistent hält. Selbst wenn eine Seite umbenannt wird - was sinnvoll ist, da sich Wissen weiterentwickelt - bleiben die URLs robust. In vielen anderen Wiki-Systemen entstehen bei Umbenennungen Weiterleitungen, also Links zweiter oder dritter Klasse, was zwar besser als nichts ist, aber nicht optimal.

Für das Thema Sicherheit und Phishing bei E-Mails sind URLs von allgemeinem Interesse. Nutzer lernen zunehmend, URLs vor dem Klicken zu prüfen. Die Vernetzung von Informationen ist fundamental, und wenn diese ständig kaputt geht, ist das extrem ineffizient. Dies ist das zentrale Argument, das auch gegenüber Management und Vorstand kommuniziert werden sollte.

== Dokumentenzentriertes vs. seitenbasiertes Arbeiten ==

Der Moderator argumentiert entschieden dafür, dass Dokumente ein “Dead End” sind und dass ein Paradigmenwechsel zu seitenbasiertem Arbeiten notwendig ist. Diese Position wird kontrovers diskutiert.

Dokumentenmanagementsysteme mit Versionsmanagement sollten theoretisch funktionieren - mit Check-in-Verfahren und einzelnen Pointern auf die aktuelle Version. In der Praxis geschieht dies jedoch kaum. Stattdessen sieht man überall “Final_Draft”, “Final_Draft_2”, “Final_Draft_kommentiert” und “Final_Draft_präsentiert”. Diese Praxis ist seit 20 Jahren in der Breite zu beobachten.

Auch E-Mail-Betreffszeilen, die anfangs vielleicht strukturiert waren, sind mittlerweile problematisch. Die Mediengeschichte zeigt, dass dokumentenzentrierte Ansätze einfach nicht funktioniert haben. Selbst Social Tagging als Strukturierungsversuch ist teilweise wieder verschwunden.

Der Übergang von Dokumenten zu Wiki-Seiten bedeutet, dass Informationseinheiten kleiner und granularer werden. Wiki-Seiten haben einen bestimmungsgemäßen Gebrauch mit einer typischen Länge, aber es gibt sowohl sehr kurze als auch Seiten mit 50 Druckseiten. Letzteres widerspricht eigentlich dem Wiki-Konzept, da man granularer auf Informationen zugreifen möchte.

Ideal wäre die Möglichkeit, nicht nur auf Seiten, sondern auch auf Absätze zu verweisen. Wenn jemand eine sehr lange Wiki-Seite erstellt hat, sollte man aus Effizienzgründen auf Absatz 23 verweisen können. Es geht immer um möglichst robuste Referenzen auf spezifische Informationen.

Ein Teilnehmender berichtet von der Beobachtung, dass zunehmend in “Containern” gearbeitet wird - weg von klassischen Dokumenten hin zu Projekt-Kanban-Boards, Textfiles, Microsoft Loop. Diese Container haben zwar URLs, aber niemand weiß, wo sie liegen, und niemand kann die URLs richtig interpretieren. Die Dokumentationslastigkeit geht zurück, aber zu welchem Preis?

Die ISO 9001:2015 hat den Begriff von “Dokumenten” zu “dokumentierter Information” gewechselt, was zeigt, dass selbst Normengeber erkannt haben, dass sich das Konstrukt “Dokument” in den letzten Jahrzehnten verändert hat. Das Dokument als Konstrukt wird als “eher von gestern” charakterisiert.

== Qualitätssicherung und Wissensmanagement ==

Die Qualitätssicherung von Wiki-Inhalten stellt eine zentrale Herausforderung dar, die von mehreren Teilnehmenden thematisiert wird. Die Wikipedia-Assoziation, dass “alle mitmachen und alles von allein passiert”, trifft in der Realität nicht zu.

Ein Sechs-Mann-Team kann für ein Unternehmen wie Siemens nicht das komplette Wiki-Gardening übernehmen. Die Idee des Wikis ist eigentlich, dass die Leute, die am Content arbeiten, ihn selbst pflegen. Der Wikipedia-Vergleich ist nur zu 50 Prozent richtig - er hilft zwar, das Konzept bekannt zu machen, entspricht aber nicht der organisatorischen Realität.

Eine Organisation aus dem öffentlichen Sektor berichtet von einem fundamentalen Problem: Es ist nicht klar erkennbar, welche Inhalte Weisungswissen sind (wo es nichts zu diskutieren gibt) und welche Inhalte Erfahrungswissen darstellen (wo unterschiedliche Praktiken legitim sind). Diese Differenzierung zwischen top-down-Weisungen und bottom-up-Wissen ist nicht gelöst.

Ein Tech-Unternehmen hat ein Qualitätsmanagementsystem eingeführt, das auf jeder Seite anzeigt, wann der Inhalt zuletzt auf Gültigkeit geprüft wurde. Dies ist besonders wichtig bei Wachstum von 300 auf 1.300 Mitarbeitende. Es gibt zuständige Personen, die regelmäßig prüfen, was neu ist, was zusammengeführt werden sollte, aber in arbeitsintensiven Phasen geht vieles unter.

Ein anderes Unternehmen berichtet von “Regulierungslust von oben” mit Fragen wie “Wie aktuell sind die Informationen?” und “Steht auch wirklich alles drin?”. Der dort vertretene Ansatz ist pragmatischer: Dokumentieren an sich ist schon wertvoll, und was irgendwann nicht mehr sinnvoll ist, wird irgendwann wieder gelöscht.

Die Frage der Community-Aktivität ist zentral. Im öffentlichen Sektor wurde festgestellt, dass die Community nicht so aktiv ist wie bei Wikipedia, sodass Qualitätsdefizite nicht automatisch durch die Gemeinschaft gelöst werden. Es fehlt die Masse an engagierten Nutzern, die bei Wikipedia zur Selbstregulierung führt.

Das Thema berührt grundsätzliche Wissensmanagement-Prinzipien: Mensch, Organisation, Technik. Das Wiki ist nur die technische Grundlage für Kollaboration. Die Herausforderung ist, Mitarbeiter von Befehlsempfängern zu Wissensbeitragenden zu entwickeln. In bundesweiten Organisationen ist schwer erkennbar, wie qualitätsgesichert Wiki-Inhalte sind, wenn man keinen zentralen Freigabe-Button haben möchte.

== Rechtliche und sicherheitstechnische Anforderungen ==

Für viele Organisationen, insbesondere im öffentlichen Sektor und in regulierten Branchen, stellen rechtliche und sicherheitstechnische Anforderungen massive Herausforderungen dar, die mit Wiki-Systemen schwer zu vereinbaren sind.

Das E-Government-Gesetz verpflichtet zur aktenmäßigen Führung und Umsetzung in elektronische Akten. Die E-Akte ist verpflichtend, was zu SharePoint-Adaptionen mit Rollen- und Rechtekonzepten führt, die wiederum Silos schaffen und Dokumente für andere unsichtbar machen. Dies ist eine fundamentale Kopfbarriere für die Entwicklung hin zu Wiki-basierten Lösungen.

Die Bundeswehr hat aktuell 3.800 aktive Vorschriften und Regelungen sowie etwa 8.000 technische Vorschriften, die theoretisch jeder Soldat kennen sollte. Diese sind als PDF-Dokumente gespeichert und werden aktuell gehalten. Es wird mit RAG-basierten KI-Lösungen experimentiert, um Soldaten Zugang zu den für ihren Dienst relevanten Informationen zu geben, da niemand 3.800 Regelungen lesen kann.

Die Frage nach einer Alternative mit hoher Authentizität und Integrität im Wiki-Gedanken, die regelungskonform ist und gesetzliche Auflagen erfüllt, bleibt unbeantwortet. Atlassian erfüllt diese Anforderungen im momentanen Zustand nicht. Google wird als mögliche Alternative erwähnt, ist aber für die Bundeswehr mit eigenen Rechenzentren und roten Netzen keine Option.

Aus dem Automotive-Bereich wird die IATF 16949 eingebracht, die Qualitätssicherung und Dokumentenlenkung regelt. Kleine wie große Unternehmen haben Herausforderungen mit den GoBD-Vorgaben der Finanzämter zur Aufbewahrung aller ein- und ausgehenden Informationen in unveränderlicher Form. Google bietet hier mit Google Vault Lösungen, aber nicht für Organisationen, die eigene Rechenzentren betreiben müssen.

Es wird die grundsätzliche Frage aufgeworfen, ob Wiki-Systeme überhaupt für Dokumentenlenkung geeignet sind, die auch die Aufgabe hat, Dokumente zu vernichten, Nachweisführung zu betreiben und Unveränderlichkeit herzustellen. Hier werden Grenzen von Wiki-Systemen deutlich, die zwar gut durchsuchbar und für bestimmte Zwecke geeignet sind, aber möglicherweise nicht alle regulatorischen Anforderungen erfüllen können.

Interessanterweise wird argumentiert, dass gerade der Nachweis von Änderungen im Wiki viel besser funktioniert, da ein komplettes Tracking aller Änderungen vorhanden ist. Dies wird in der Praxis bei hochgeladenen Dokumenten oft nicht erreicht. Die ISO 9001:2015 spricht nicht mehr von “Dokumenten”, sondern von “dokumentierter Information”, was eine gewisse Anerkennung der Veränderung darstellt.

== Organisatorische und kulturelle Barrieren ==

Neben technischen und rechtlichen Herausforderungen erweisen sich organisatorische und kulturelle Aspekte als ebenso bedeutsam, wenn nicht sogar schwerwiegender für den erfolgreichen Wiki-Einsatz.

Die dokumentenzentrierte Arbeitsweise ist tief in Organisationen verankert. Das Verteidigungsministerium beschreibt sich als dokumentenzentrierte Organisation mit Entscheidungsprozessen aus dem Jahr 1840. Entscheidungen werden auf drei Seiten zusammengefasst, was die Informationsqualität so eindampft, dass keine adäquate Entscheidungskompetenz mehr aufgebaut werden kann. Dies ist eine bewusste Kritik an traditionellen Prozessen.

Der Versuch, auf SharePoint umzusteigen, scheiterte daran, dass das System “amputiert, ohne Arme, ohne Beine, bitte nur mit einem Auge, auch keine Ohren” genutzt werden sollte. Das Ergebnis ist, dass die Leute arbeiten wie mit “Word im Star Office Format” - nicht gut, vorsichtig formuliert.

Im öffentlichen Sektor wurde ein Wiki 2016 eingeführt, weil es “on vogue” war, aber keiner nutzte es. Erst nach einem zweijährigen Projekt mit Universitätsunterstützung wurde es ab 2021 erfolgreich. Dies zeigt, dass technische Einführung allein nicht ausreicht - es braucht Change-Management und Unterstützung.

Die Frage der Organisationskultur ist zentral: Wie verwandelt man Mitarbeiter von Befehlsempfängern, die top-down Informationen erhalten, in aktive Wissensbeitragende? Der Wunsch ist, nicht niedergeschriebenes Wissen zu teilen und bottom-up-Feedback zu ermöglichen, wenn Weisungen nicht praktikabel sind. Dies ist ein fundamentaler kultureller Wandel.

In einer Agentur wurde berichtet, dass SharePoint ein “Wildwuchs sondergleichen” ist mit 12.000 Datensilos, Berechtigungsproblematiken und schwachen Verlinkungen. Dies zeigt, dass selbst mit Systemen, die technisch Besseres ermöglichen würden, organisatorische Probleme zu chaotischen Strukturen führen.

Ein Online-Teilnehmender berichtete, dass SharePoint-Pläne an Chefetagen scheiterten. Das Konstrukt sollte für die ganze Verwaltung offen sein, wurde aber letztlich nicht für alle freigegeben. Nun “dümpelt alles in Intranet-Zeilen rum, in Dokumenten, in Clouds und wilden SharePoint-Sachen”. Es fehlt jemand von oben, der sagt: “Wissensmanagement heißt ein Wiki und nicht Tausende.”

Der Moderator verweist auf Nonaka (1994) und das Konzept der “Hypertext-Organisation”, wo Informationen vernetzt werden und die Pyramide auf den Kopf gestellt wird mit “High Accessibility to Knowledge Base by Individual Members” - so offen wie möglich. Dies ist ein 30 Jahre altes Konzept, das beschreibt, wie Technik und robuste Verknüpfungen die Organisation verändern.

Die Erwartungen an mobilen Konsum und zeitgemäßes Nutzerverhalten sind gestiegen. Kaum jemand hat noch Zeit, Dokumente umfassend zu lesen und Dinge mit drei Klicks zu downloaden, anzugucken und hochzuladen. KI-Thematiken könnten hier helfen, sind aber in Sicherheitsbereichen eine ganz andere Herausforderung.

== Fazit und Ausblick ==

Die Session zeigt deutlich, dass Organisationen vor komplexen, vielschichtigen Herausforderungen beim Einsatz von Wiki-Systemen stehen. Das zentrale technische Argument für Wiki-Systeme - robuste URLs als Grundlage für vernetzte, konsistente Information - trifft auf eine Realität aus rechtlichen Anforderungen, Sicherheitsbedenken, Kostenüberlegungen und tief verwurzelten organisatorischen Kulturen.

Die bevorstehende Zwangsmigration in Cloud-Lösungen bis 2029 verschärft die Situation erheblich. Organisationen müssen grundsätzliche strategische Entscheidungen treffen zwischen Cloud-Migration mit ihren Abhängigkeiten und Kosten, dem Aufbau eigener Lösungen oder dem Verbleib in fragmentierten, suboptimalen Strukturen. Besonders problematisch ist das Fehlen klarer Migrationspfade für stark kustomisierte Systeme.

Der Gegensatz zwischen dokumentenzentriertem und seitenbasiertem Arbeiten ist nicht nur eine technische, sondern eine fundamentale kulturelle Frage. Während die Argumente für robuste URLs und vernetzte Information überzeugend sind, stehen dem regulatorische Anforderungen zur Dokumentenlenkung, Nachweisführung und Unveränderlichkeit gegenüber. Nicht alle Anwendungsfälle lassen sich gleichermaßen gut mit Wiki-Systemen abbilden.

'''Offene Fragen:'''

* Wie können offene Wiki-Strukturen mit rechtlichen Anforderungen an Dokumentenlenkung und E-Akten vereinbart werden?
* Welche Alternativen zu Confluence bieten funktionierende Migrationspfade für kustomisierte Systeme und gängige Plugins?
* Wie lässt sich die Qualitätssicherung von Wiki-Inhalten skalierbar organisieren, wenn die Wikipedia-Community-Dynamik fehlt?
* Wie kann die Unterscheidung zwischen Weisungswissen und Erfahrungswissen im Wiki-System abgebildet werden?
* Welche Lösung eignet sich für den öffentlichen Sektor und sicherheitskritische Bereiche, wenn Cloud-Lösungen keine Option sind?

'''Handlungsempfehlungen:'''

* Entwickle ein klares Verständnis für den Wert robuster URLs und kommuniziere dies als digitale Grundkompetenz bis in Führungsebenen
* Prüfe frühzeitig Migrationspfade und -optionen, um nicht in technische Lock-in-Situationen zu geraten
* Investiere in Change-Management und Organisationsentwicklung, nicht nur in Technologie - ein Wiki ohne kulturellen Wandel wird nicht genutzt
* Implementiere Qualitätsmanagementsysteme mit klaren Verantwortlichkeiten und regelmäßigen Prüfzyklen für Wiki-Inhalte
* Evaluiere systematisch, welche Inhalte tatsächlich als Dokumente mit Unveränderlichkeit und Nachweisführung geführt werden müssen und welche als lebende Wiki-Seiten besser aufgehoben sind
* Suche den Austausch mit anderen Organisationen in ähnlichen Situationen, insbesondere im öffentlichen Sektor, um gemeinsame Lösungen zu entwickeln
* Berücksichtige bei Strategieentscheidungen nicht nur aktuelle Kosten, sondern auch langfristige Abhängigkeiten und Flexibilität
* Experimentiere mit hybriden Ansätzen, die die Stärken verschiedener Systeme kombinieren, statt auf monolithische Lösungen zu setzen

[[Kategorie:gkc25]]