Wissensmanagement mit Wiki und Content-Management-System
https://bildung.social/@oerinformatik/
https://oer-informatik.de/wiki-cms
Wissensmanagement, Wiki, Content-Management-System, CMS, implizites Wissen, explizites Wissen, Headless-CMS, statische Website, Versionsverwaltung, Datenschutz
tl/dr; (ca. 22 min Lesezeit): Wissen, das nur in Köpfen steckt, geht verloren, wenn Menschen gehen. Ein Wiki macht es für alle zugänglich: Jede*r kann Seiten im Browser anlegen und verbessern, jede Änderung bleibt nachvollziehbar. Ein Content-Management-System (CMS) trennt Inhalt und Gestaltung und organisiert, wer Inhalte schreibt, prüft und veröffentlicht. Der Artikel erklärt Begriffe, Funktionen, Vor- und Nachteile, die Auswahl zwischen Wiki, CMS und statischer Website und worauf es bei der Einführung ankommt [AI-Assisted]. (Zuletzt geändert am 28.10.2026)
Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast.
Als Wissensmanagement-Grundlagen kann ich nach Durchlesen des Artikels…
… erklären, warum Unternehmen Wissensmanagement betreiben, und implizites von explizitem Wissen unterscheiden.
… den Begriff Wiki erläutern und ein Wiki von einem Blog abgrenzen.
… Vorteile eines firmeninternen Wikis nennen und auf eine Situation beziehen.
… Nachteile und Risiken eines Wikis erläutern und passende Gegenmaßnahmen nennen.
… die Aufgabe eines Content-Management-Systems beschreiben und die Trennung von Inhalt und Gestaltung erklären.
… typische Funktionen eines CMS (Vorlagen, Rollen und Rechte, Versionsverwaltung, Freigabe-Workflow, Medienverwaltung, Erweiterungen) beschreiben.
… verbreitete CMS und Wiki-Programme nennen.
Darüber hinaus kann ich als Wissensmanagement-Expertenwissen…
… begründet entscheiden, ob für eine Aufgabe ein Wiki, ein CMS, ein Headless-CMS oder eine statische Website passt.
… die Einführung eines Wikis planen (Struktur, Vorlagen, Verantwortliche, Aktualität, Datenschutz).
… ein Wiki als Supportleistung neben FAQ und Hotline einordnen und die Auswahl begründen.
Warum Wissensmanagement?
In jeder Organisation steckt viel Wissen: Wie richtet man den Drucker im zweiten Stock ein? Welcher Kunde will Rechnungen nur per XRechnung? Welche Stolperfallen gab es beim letzten Server-Umzug? Ein großer Teil dieses Wissens liegt nur in den Köpfen einzelner Menschen, in privaten Notizen oder in E-Mail-Postfächern. Geht eine erfahrene Kollegin in den Ruhestand, wechselt ein Auszubildender nach der Ausbildung den Betrieb oder ist der einzige Experte krank, fehlt dieses Wissen plötzlich.
Wissensmanagement (knowledge management) ist der bewusste Umgang mit diesem Wissen: Es soll erkannt, festgehalten, verteilt, genutzt und aktuell gehalten werden. Ziele sind zum Beispiel:
Wissensverlust vermeiden, wenn Menschen das Unternehmen verlassen (Ruhestand, Fluktuation, Ende der Ausbildung).
Doppelarbeit vermeiden: Ein Problem wird nur einmal gelöst, die Lösung steht allen zur Verfügung.
Einarbeitung beschleunigen: Neue Kolleg*innen finden Abläufe und Ansprechpersonen selbst.
Abteilungsgrenzen überwinden: Die Werkstatt weiß, was der Vertrieb versprochen hat, und umgekehrt.
Aus Erfahrungen lernen: Erkenntnisse aus Projekten (Lessons Learned) fließen in das nächste Projekt ein.
Die Mindmap zeigt, welche Themen dieser Artikel behandelt: vom Wissen selbst über Wiki und CMS bis zu Auswahl, Einführung und IT-Support.
Daten, Information, Wissen
Im Wissensmanagement unterscheidet man oft drei Stufen:
Daten sind Zeichen mit einer Syntax, aber ohne Zusammenhang, z. B.
503.Information entsteht, wenn Daten eine Bedeutung im Zusammenhang erhalten: „Der Webserver liefert den Statuscode 503.“
Wissen ist vernetzte Information, mit der jemand handeln kann: „503 heißt bei uns fast immer, dass der Anwendungsserver nach dem nächtlichen Update nicht neu gestartet ist – dann hilft ein Neustart des Dienstes.“
Implizites und explizites Wissen
Explizites Wissen lässt sich in Worte, Tabellen, Diagramme oder Anleitungen fassen und damit dokumentieren: eine Checkliste für die Serverwartung, eine Netzwerkdokumentation, eine Schritt-für-Schritt-Anleitung.
Implizites Wissen (auch stilles Wissen, tacit knowledge) steckt in Erfahrung und Können und ist schwer aufzuschreiben: das Gespür, welcher Kunde bei einer Rückfrage ungeduldig wird, oder die Routine, ein Netzwerkproblem am Blinkmuster eines Switches zu erkennen.
Ein Wiki oder CMS kann nur explizites Wissen speichern. Implizites Wissen wird eher weitergegeben, indem Menschen zusammenarbeiten: Einarbeitung im Tandem, Pair Programming, Hospitation, Erfahrungsaustausch. Gute Wiki-Seiten machen aber einen Teil davon sichtbar, etwa als Abschnitt „Typische Fehler“ oder „Darauf achten wir“ – oder sie nennen die Person, die man fragen kann.
Was ist ein Wiki?
Ein Wiki ist eine Sammlung von Webseiten, die die Nutzenden direkt im Browser lesen und selbst anlegen und ändern können. Der Name kommt vom hawaiianischen Wort „wiki“ für „schnell“. Das erste Wiki, das WikiWikiWeb, stellte Ward Cunningham 1995 online; das bekannteste Wiki ist heute die Wikipedia.
Das Grundprinzip: Nicht eine Redaktion schreibt für viele Lesende, sondern die Lesenden schreiben selbst. Wer einen Fehler sieht, korrigiert ihn; wer etwas weiß, ergänzt es. Damit dabei nichts verloren geht, speichert das Wiki jede Änderung als neue Version.
Zur Abgrenzung:
Ein Blog ist eine chronologisch sortierte Folge von Beiträgen einer oder weniger Personen; Lesende können meist nur kommentieren, aber die Beiträge nicht ändern.
Ein Forum sammelt Diskussionen in Form von Fragen und Antworten; das Ergebnis ist ein Gesprächsverlauf, kein gepflegtes Nachschlagewerk.
Eine FAQ (Frequently Asked Questions) ist eine von wenigen Personen gepflegte Liste häufiger Fragen mit Antworten.
Ein Wiki ist ein gemeinsam gepflegtes, verlinktes Nachschlagewerk, das immer den aktuellen Stand zeigen soll.
Typische Funktionen eines Wikis
| Funktion | Beschreibung |
|---|---|
| Seiten im Browser bearbeiten | Seiten werden mit einer einfachen Auszeichnungssprache (Wikitext, Markdown) oder einem grafischen Editor (WYSIWYG) bearbeitet; HTML-Kenntnisse sind nicht nötig. |
| Versionsgeschichte | Jede Änderung wird mit Zeitpunkt, Autor*in und Kommentar gespeichert. Zwei Versionen lassen sich vergleichen (Diff), eine fehlerhafte Änderung lässt sich mit einem Klick zurücksetzen. |
| Interne Verlinkung | Seiten werden über ihren Titel verlinkt. Ein Link auf eine noch nicht vorhandene Seite wird markiert (in MediaWiki rot) und lädt dazu ein, die Seite anzulegen. |
| Suche, Kategorien, Tags | Volltextsuche über alle Seiten; Kategorien, Namensräume oder Bereiche ordnen die Seiten. |
| Diskussionsseiten, Kommentare | Fragen und Einwände werden neben dem Inhalt geklärt, ohne den Text selbst zu verändern. |
| Beobachten und Benachrichtigen | Wer eine Seite beobachtet, wird über Änderungen informiert. |
| Vorlagen | Wiederkehrende Seitentypen (Anleitung, Protokoll, Checkliste) starten mit einer festen Gliederung. |
| Rechteverwaltung | Lese- und Schreibrechte je Bereich und Gruppe, Anmeldung oft über das zentrale Benutzerkonto (Single Sign-on). |
Vorteile eines firmeninternen Wikis
Aufgaben fragen gern nach den Vorteilen eines Wikis, das ein Unternehmen intern einsetzt. Wichtig ist, sie auf die Situation zu beziehen:
Offenes System: Alle Beschäftigten können Wissen beitragen, nicht nur eine kleine Redaktion. Das Wissen der Fachleute vor Ort fließt direkt ein.
Ergänzungen und Berichtigungen sind jederzeit möglich: Wer einen Fehler oder eine veraltete Angabe entdeckt, korrigiert sie sofort. Das Wiki bleibt dadurch aktueller als ein gedrucktes Handbuch.
Historie nachvollziehbar: Die Versionsgeschichte zeigt, wer wann was geändert hat. Fehlerhafte oder mutwillige Änderungen lassen sich rückgängig machen.
Abteilungsübergreifende Nutzung: Alle greifen auf denselben Wissensstand zu, egal in welcher Abteilung oder an welchem Standort sie arbeiten.
Zentral, durchsuchbar und verlinkt: Statt Wissen in Postfächern und verstreuten Dateien zu suchen, gibt es eine Anlaufstelle mit Volltextsuche.
Ortsunabhängig: Der Zugriff funktioniert im Browser, auch vom Smartphone, ohne zusätzliche Software.
Geringe Einstiegskosten: Viele Wiki-Programme sind Open Source und ohne Lizenzkosten nutzbar; einfache Bedienung braucht wenig Schulung.
Unabhängigkeit von Personen: Das Wissen bleibt im Unternehmen, auch wenn Menschen gehen.
Nachteile und Risiken – und was dagegen hilft
Ein Wiki ist kein Selbstläufer. Typische Probleme und Gegenmaßnahmen:
| Risiko | Gegenmaßnahme |
|---|---|
| Veraltete oder falsche Inhalte, weil niemand sich zuständig fühlt | Verantwortliche je Bereich (oft „Wiki-Gärtner*innen“ genannt), Prüfdatum auf jeder Seite, regelmäßige Durchsicht |
| Wildwuchs: doppelte Seiten, uneinheitliche Struktur, nichts wird gefunden | vorgegebene Startseite und Gliederung, Vorlagen für Seitentypen, Namenskonventionen, Kategorien |
| Geringe Beteiligung: Viele lesen, wenige schreiben | Schulung, Zeit für die Pflege einplanen, Vorbilder in der Leitung, Wiki in Abläufe einbinden (z. B. „Ticket erst schließen, wenn die Lösung im Wiki steht“) |
| Aufwand für Betrieb und Pflege | Server, Updates, Datensicherung und Pflege einplanen; ggf. gehostete Lösung |
| Datenschutz und Vertraulichkeit: personenbezogene oder geheime Daten landen auf Seiten, die viele lesen; gelöschte Angaben bleiben in der Versionsgeschichte | Regeln, was ins Wiki darf; Rechte je Bereich; Zugangsdaten nie ins Wiki, sondern in einen Passwortmanager; endgültiges Löschen von Versionen durch Administrator*innen |
| Leistungskontrolle: Die Versionsgeschichte zeigt, wer wie viel schreibt | Regelung mit der Interessenvertretung (Betriebs- bzw. Personalrat), keine Auswertung einzelner Personen |
| Ungeprüfte Inhalte: Jede*r kann schreiben, niemand prüft | für kritische Seiten (Sicherheitsanweisungen, Notfallpläne) Freigabe durch eine verantwortliche Person |
Der letzte Punkt zeigt die Grenze des reinen Wiki-Prinzips: Wo Inhalte verbindlich oder öffentlich sind, braucht man eine Prüfung vor der Veröffentlichung – und damit Funktionen, die ein Content-Management-System mitbringt.
Was ist ein Content-Management-System?
Ein Content-Management-System (CMS, deutsch auch Redaktionssystem) ist eine Software, mit der man digitale Inhalte erstellen, verwalten und veröffentlichen kann – meist die Seiten einer Website. Inhalte (content) sind Texte, Bilder, Videos, Audiodateien, Downloads, Termine oder Produktdaten. Das Besondere: Die Redakteur*innen brauchen keine Programmier- oder HTML-Kenntnisse. Sie schreiben in einem Editor im Browser, das CMS erzeugt daraus die fertige Webseite.
Ein Wiki ist damit eine besondere, sehr offene Form eines CMS: Bei einem Wiki darf jede*r ändern, bei einem klassischen CMS bestimmen Rollen und Freigaben, wer was darf.
Trennung von Inhalt, Struktur und Gestaltung
Der Kern jedes CMS ist die Trennung von
Inhalt: der eigentliche Text, die Bilder, die Metadaten (Autor*in, Datum, Schlagworte) – meist in einer Datenbank gespeichert,
Struktur: wo ein Inhalt erscheint (Menü, Seitenbaum, Kategorie, Startseite),
Gestaltung (Layout): wie er aussieht – festgelegt in Vorlagen (Templates, Themes) mit HTML und CSS.
Ändert sich das Design der Website, tauscht man das Theme aus; die Inhalte bleiben unverändert. Umgekehrt muss eine Redakteurin beim Schreiben nicht auf Schriftarten und Farben achten – das Erscheinungsbild bleibt einheitlich (Corporate Design).
Zwei Teile: Bearbeitung und Auslieferung
Ein CMS besteht grob aus zwei Teilen:
Die Bearbeitungsanwendung (Content Management Application, CMA, oft „Backend“ genannt) ist die Oberfläche für die Redaktion: Inhalte anlegen, ändern, löschen, Bilder hochladen, Freigaben erteilen – ohne dass ein Webmaster eingreifen muss.
Die Auslieferungsanwendung (Content Delivery Application, CDA, „Frontend“) organisiert und speichert die Inhalte und erzeugt daraus die Seiten, die Besucher*innen sehen.
Klassische CMS erzeugen die Seiten dynamisch bei jedem Abruf: Ein Skript (z. B. in PHP) holt den Inhalt aus der Datenbank, setzt ihn in das Template ein und schickt das HTML an den Browser. Caches sorgen dafür, dass das nicht bei jedem Aufruf neu passieren muss.
Eine neuere Variante ist das Headless-CMS: Es hat nur die Bearbeitungsanwendung und liefert die Inhalte über eine Schnittstelle (REST oder GraphQL, meist JSON) aus. Eine Website, eine App oder ein Infomonitor holen sich die Inhalte und stellen sie selbst dar – derselbe Inhalt erscheint so auf vielen Kanälen.
Das Schema stellt beide Bauarten gegenüber: Links setzt die Auslieferungsanwendung Inhalt und Vorlage zur fertigen Seite zusammen, rechts holen sich verschiedene Kanäle die Inhalte über die Schnittstelle.
Funktionen eines CMS
Wird nach den Funktionen eines CMS gefragt, solltest Du sie beschreiben, also sagen, was die Funktion leistet und wozu sie dient:
Vorlagen für Seitentypen: Das CMS stellt Vorlagen für unterschiedliche Arten von Seiten bereit (Startseite, Artikel, Veranstaltung, Personenprofil, Bildergalerie). Wer einen neuen Inhalt anlegt, füllt nur die Felder aus; Aufbau und Gestaltung sind einheitlich.
Benutzer-, Rollen- und Rechteverwaltung: Das CMS bildet eine redaktionelle Hierarchie ab. Typische Rollen sind Autor*in (erstellt Inhalte), Lektorat bzw. Redaktion (korrigiert und prüft), Herausgeber*in bzw. Chefredaktion (gibt frei und veröffentlicht) und Administrator*in (verwaltet Benutzer, Themes, Erweiterungen). Jede Rolle darf nur, was sie für ihre Aufgabe braucht.
Versionsverwaltung: Jede gespeicherte Änderung wird als Version abgelegt. Änderungen lassen sich vergleichen, nachvollziehen und rückgängig machen; bei mehreren Bearbeitenden verhindern Sperren, dass sich Änderungen gegenseitig überschreiben.
Workflow und Veröffentlichungsprozess (Publishing): Ein Inhalt durchläuft festgelegte Stationen, an denen verschiedene Personen beteiligt sind, z. B. Entwurf → Prüfung → Freigabe → veröffentlicht → archiviert. Veröffentlichungen lassen sich zeitlich planen („erscheint am 01.03. um 8:00 Uhr“) und mit einem Ablaufdatum versehen.
Medienverwaltung: Bilder, Videos und Dokumente werden zentral abgelegt, mit Metadaten (Bildrechte, Alternativtext) versehen und mehrfach verwendet; das CMS erzeugt passende Bildgrößen automatisch.
Navigation und Struktur: Menüs, Seitenbaum, Kategorien und Schlagworte entstehen aus den Inhalten; Links werden beim Verschieben einer Seite angepasst.
Suche: Eine Volltextsuche über alle veröffentlichten Inhalte.
Mehrsprachigkeit: Inhalte werden in mehreren Sprachfassungen gepflegt und einander zugeordnet.
Erweiterungen (Plugins, Module): Zusatzfunktionen wie Formulare, Veranstaltungskalender, Newsletter oder ein Webshop lassen sich nachrüsten, ohne das CMS selbst zu programmieren.
Suchmaschinenoptimierung und Barrierefreiheit: sprechende URLs, Metadaten, Pflichtfeld für Alternativtexte, Überschriftenstruktur. Öffentliche Stellen müssen ihre Websites barrierefrei gestalten (EU-Richtlinie 2016/2102, in Deutschland umgesetzt durch Bund und Länder, z. B. BITV 2.0 und BITV NRW). Für Schulen gibt es Ausnahmen – in NRW gilt die Pflicht für Schulwebsites nur bei wesentlichen Online-Verwaltungsfunktionen (§ 10 Abs. 5 BGG NRW) –, barrierefrei gestaltete Seiten sind aber auch dort sinnvoll.
Kommentare und Interaktion: Rückmeldungen von Lesenden, die vor der Anzeige freigegeben werden.
Wie ein Inhalt den Workflow durchläuft, zeigt das UML-Zustandsdiagramm. Findet die Redaktion Mängel, gibt sie den Inhalt zur Überarbeitung in den Entwurf zurück.
Verbreitete Systeme
| Art | Beispiele |
|---|---|
| Web-CMS (Open Source) | WordPress (mit Abstand am weitesten verbreitet: rund 40 % aller Websites, W3Techs, Oktober 2026), Joomla, Drupal, TYPO3 (vor allem im deutschsprachigen Raum bei Behörden, Hochschulen und Unternehmen) |
| Baukasten-Systeme (gehostet) | Wix, Squarespace, Jimdo |
| Shopsysteme mit CMS-Funktionen | Shopify, Shopware, WooCommerce (Plugin für WordPress) |
| Headless-CMS | Strapi, Directus, Contentful |
| Wiki-Programme | MediaWiki (die Software der Wikipedia), DokuWiki (speichert Seiten als Textdateien, keine Datenbank nötig), BookStack, Wiki.js, XWiki, Confluence (kommerziell) |
Wiki, CMS oder statische Website?
Nicht jede Aufgabe braucht dasselbe Werkzeug:
| Merkmal | Wiki | Web-CMS | Statische Website |
|---|---|---|---|
| Wer schreibt? | viele, oft alle Beschäftigten | eine Redaktion mit Rollen | wenige Personen mit Technikkenntnissen |
| Freigabe vor Veröffentlichung | meist nein (Kontrolle danach über die Versionsgeschichte) | ja, über Workflow | ja, über den Erstellungsprozess (z. B. Git) |
| Zielgruppe | intern, Nachschlagewerk | meist öffentlich, Außendarstellung | öffentlich |
| Gestaltung | einheitlich, schlicht | frei über Themes | frei, aber Handarbeit |
| Änderungshäufigkeit | ständig | regelmäßig | selten |
| Betrieb | Server mit Wiki-Software | Server mit Datenbank und Skriptsprache, regelmäßige Sicherheitsupdates | einfacher Webserver, kaum Angriffsfläche |
Daraus ergeben sich typische Entscheidungen:
Internes Nachschlagewerk, das viele pflegen: Wiki.
Öffentlicher Auftritt mit regelmäßig neuen Inhalten, an dem mehrere Personen mit unterschiedlichen Rechten mitwirken und bei dem Inhalte vor der Veröffentlichung geprüft werden müssen: CMS.
Wenige Seiten, die sich selten ändern (z. B. ein Impressum, eine Projektseite, die einmal erstellt wird): Ein CMS lohnt sich dann oft nicht – Installation, Updates und Absicherung kosten mehr Aufwand, als die Redaktion spart. Eine statische Website ist schneller, günstiger und sicherer. Moderne statische Seitengeneratoren (z. B. Hugo, Jekyll) oder Konverter wie pandoc erzeugen aus Markdown-Dateien fertige HTML-Seiten. Auch oer-informatik.de entsteht so: Die Artikel werden als Markdown in GitLab gepflegt, eine Pipeline erzeugt mit pandoc daraus HTML, das WordPress einbindet.
Inhalte für viele Kanäle (Website, App, Infomonitor): Headless-CMS.
Soll ein vorhandener Auftritt um eine Funktion ergänzt werden (z. B. einen Webshop), ist oft eine Erweiterung des vorhandenen CMS günstig: Sie fügt sich in Gestaltung und Navigation ein und wird im gewohnten Backend gepflegt. Eine getrennte Cloud-Lösung kann dagegen leistungsfähiger und sicherer betrieben sein.
Wiki als Supportleistung
Auch im IT-Support spielt das Wiki eine Rolle. Ein internes Wiki (bzw. die Wissensdatenbank eines Ticketsystems) hilft den Supportmitarbeitenden, bekannte Lösungen schnell zu finden, und sichert das Wissen über Störungen und ihre Behebung. Ein öffentliches FAQ oder ein Self-Service-Portal hilft dagegen den Anwendenden direkt, und eine Hotline ist nötig, wenn schnelle persönliche Hilfe gefragt ist. Mehr dazu im Artikel Ticketsystem und IT-Service.
Ein Wiki einführen – so klappt es
Damit ein Wiki tatsächlich genutzt wird, helfen folgende Schritte:
Ziel und Zielgruppe klären: Welches Wissen soll hinein, wer liest, wer schreibt? Ein Wiki „für alles“ wird schnell unübersichtlich.
Software auswählen: Anforderungen wie Anmeldung über das vorhandene Benutzerkonto, Rechte je Bereich, Suche, Bedienbarkeit am Smartphone, Barrierefreiheit, Datensicherung, Betrieb im eigenen Rechenzentrum oder als Cloud-Dienst (Datenschutz, Auftragsverarbeitung) mit einer Nutzwertanalyse vergleichen.
Grundstruktur und Vorlagen vorgeben: Startseite, Bereiche, Namenskonventionen und Vorlagen für die häufigsten Seitentypen (Anleitung, Checkliste, Protokoll, Lessons Learned) anlegen, bevor alle loslegen.
Startinhalte einpflegen: Ein leeres Wiki lädt niemanden ein. Die wichtigsten Anleitungen sollten schon da sein.
Regeln festlegen: Was gehört ins Wiki und was nicht (keine Passwörter, keine unnötigen personenbezogenen Daten)? Wer ist für welchen Bereich verantwortlich? Wie oft wird geprüft?
Schulen und einbinden: kurze Einführung, Zeit für Pflege im Arbeitsalltag einplanen, Wiki in Abläufe einbauen (Einarbeitung neuer Kolleg*innen, Projektabschluss, Ticket-Lösungen).
Pflegen und messen: Seiten mit abgelaufenem Prüfdatum nachfassen, verwaiste Seiten aufräumen, Suchbegriffe ohne Treffer auswerten.
Datenschutz und Rechte
Wiki und CMS enthalten oft personenbezogene Daten: Namen und Kontaktdaten in Protokollen, Fotos auf der Website, Autorenangaben in der Versionsgeschichte. Es gelten die Grundsätze der DSGVO, insbesondere Zweckbindung, Datenminimierung und Speicherbegrenzung (Art. 5 DSGVO). Praktisch heißt das:
Fotos von Personen nur mit Einwilligung bzw. passender Rechtsgrundlage veröffentlichen; bei fehlender Einwilligung Bild weglassen oder Person unkenntlich machen.
Zugriffsrechte nach dem Prinzip der minimalen Rechte vergeben; interne Bereiche nicht öffentlich erreichbar machen.
Daran denken, dass „gelöschte“ Inhalte in der Versionsgeschichte weiter stehen – bei Bedarf endgültig entfernen.
Bei Cloud-Diensten einen Vertrag zur Auftragsverarbeitung abschließen.
Für die Website die Pflichtangaben beachten (Impressum nach § 5 DDG, Datenschutzerklärung).
Mehr zu Schutzzielen und Rechtekonzepten findest Du in den Artikeln Schutzziele und Sicherheitsrisiken und Authentifizierung.
Typische Fehler in Antworten
Schlagwort statt Beschreibung: „Versionierung“ ist genannt, nicht beschrieben. Beschrieben ist: „Das CMS speichert jede Änderung als eigene Version, sodass man Änderungen nachvollziehen und eine frühere Fassung wiederherstellen kann.“
Kein Bezug zur Situation: „Ein Wiki ist kostengünstig“ überzeugt weniger als „Die Wiki-Software ist Open Source; das Krankenhaus zahlt keine Lizenzgebühren, sondern nur den Betrieb auf dem vorhandenen Server.“
Zweimal derselbe Vorteil: „schnell aktuell“ und „Fehler können korrigiert werden“ meinen im Kern dasselbe.
Wiki und CMS gleichsetzen: Ein Wiki ist eine offene Form eines CMS; ein klassisches CMS hat dagegen eine Redaktionshierarchie mit Freigabe.
Nachteile vergessen: Ein Wiki pflegt sich nicht von selbst. Wer nach Vor- und Nachteilen gefragt wird, sollte Pflegeaufwand und Aktualität erwähnen.
Leitfragen
- Warum betreiben Unternehmen Wissensmanagement, und worin unterscheiden sich implizites und explizites Wissen?
Unternehmen betreiben Wissensmanagement, um Wissensverlust beim Ausscheiden von Menschen und Doppelarbeit zu vermeiden, die Einarbeitung zu beschleunigen, Abteilungsgrenzen zu überwinden und aus Erfahrungen zu lernen. Explizites Wissen lässt sich in Worte, Tabellen oder Anleitungen fassen und dokumentieren; implizites Wissen steckt in Erfahrung und Können und wird eher durch Zusammenarbeit (Tandem, Pair Programming, Hospitation) weitergegeben. Siehe Abschnitt „Warum Wissensmanagement?“ und Abschnitt „Implizites und explizites Wissen“
- Was ist ein Wiki, und wie unterscheidet es sich von einem Blog, einem Forum und einer FAQ?
Ein Wiki ist eine Sammlung von Webseiten, die die Nutzenden direkt im Browser lesen, anlegen und ändern können; jede Änderung wird als Version gespeichert, und es soll als gemeinsam gepflegtes, verlinktes Nachschlagewerk immer den aktuellen Stand zeigen. Ein Blog ist dagegen eine chronologische Folge von Beiträgen weniger Personen, ein Forum ein Gesprächsverlauf aus Fragen und Antworten und eine FAQ eine von wenigen gepflegte Liste häufiger Fragen. Siehe Abschnitt „Was ist ein Wiki?“
- Welche Vorteile hat ein firmeninternes Wiki, und mit welchen Maßnahmen begegnest Du seinen Nachteilen?
Vorteile sind ein offenes System, in das alle Wissen einbringen, jederzeit mögliche Korrekturen, eine nachvollziehbare Historie, abteilungsübergreifende, zentrale und durchsuchbare Nutzung, ortsunabhängiger Zugriff, geringe Einstiegskosten und Unabhängigkeit von Personen. Gegen Nachteile helfen Verantwortliche je Bereich mit Prüfdatum, vorgegebene Struktur und Vorlagen, Schulung und Einbindung in Abläufe, Regeln und Rechte für vertrauliche Daten, eine Regelung mit dem Betriebsrat und Freigaben für kritische Seiten. Siehe Abschnitt „Vorteile eines firmeninternen Wikis“ und Abschnitt „Nachteile und Risiken – und was dagegen hilft“
- Welche Aufgabe hat ein Content-Management-System, und was bedeutet die Trennung von Inhalt und Gestaltung?
Ein CMS ist eine Software, mit der Redakteur*innen ohne Programmier- oder HTML-Kenntnisse digitale Inhalte erstellen, verwalten und veröffentlichen. Die Trennung bedeutet: Inhalte liegen meist in einer Datenbank, die Gestaltung ist in Vorlagen (Themes) mit HTML und CSS festgelegt – so lässt sich das Design austauschen, ohne die Inhalte zu ändern, und das Erscheinungsbild bleibt einheitlich. Siehe Abschnitt „Was ist ein Content-Management-System?“ und Abschnitt „Trennung von Inhalt, Struktur und Gestaltung“
- Welche Funktionen eines CMS kannst Du beschreiben (Vorlagen, Rollen, Versionen, Workflow …)?
Vorlagen geben Seitentypen einen einheitlichen Aufbau vor; die Rollen- und Rechteverwaltung bildet eine redaktionelle Hierarchie (Autor*in, Redaktion, Herausgeber*in, Administrator*in) ab; die Versionsverwaltung speichert jede Änderung, sodass man sie nachvollziehen und rückgängig machen kann; der Workflow führt Inhalte über Entwurf, Prüfung und Freigabe zur (auch zeitgesteuerten) Veröffentlichung. Dazu kommen Medienverwaltung, Navigation, Suche, Mehrsprachigkeit, Erweiterungen, SEO und Barrierefreiheit. Siehe Abschnitt „Funktionen eines CMS“
- Wann ist ein Wiki, wann ein CMS, wann eine statische Website die bessere Wahl?
Ein Wiki passt für ein internes Nachschlagewerk, das viele pflegen; ein CMS für einen öffentlichen Auftritt mit regelmäßig neuen Inhalten, mehreren Rollen und Prüfung vor der Veröffentlichung; eine statische Website für wenige, selten geänderte Seiten, weil sie schneller, günstiger und sicherer ist. Für Inhalte auf vielen Kanälen eignet sich ein Headless-CMS. Siehe Abschnitt „Wiki, CMS oder statische Website?“
- Welche Schritte gehören zur Einführung eines Wikis, und was ist beim Datenschutz zu beachten?
Zur Einführung gehören: Ziel und Zielgruppe klären, Software auswählen (z. B. per Nutzwertanalyse), Grundstruktur und Vorlagen vorgeben, Startinhalte einpflegen, Regeln und Verantwortliche festlegen, schulen und in Abläufe einbinden sowie pflegen und messen. Beim Datenschutz gelten Zweckbindung, Datenminimierung und Speicherbegrenzung: Fotos nur mit Einwilligung, minimale Rechte, gelöschte Inhalte auch aus der Versionsgeschichte entfernen, bei Cloud-Diensten Auftragsverarbeitungsvertrag. Siehe Abschnitt „Ein Wiki einführen – so klappt es“ und Abschnitt „Datenschutz und Rechte“
Links und weitere Informationen
Ticketsystem und IT-Service (Wissensdatenbank, Support-Ebenen)
Projektorganisation (Lessons Learned am Projektende)
für den Einstieg: Wikipedia: Wiki und Wikipedia: Content-Management-System
zur Verbreitung von CMS: W3Techs: Usage statistics of content management systems
zum Wiki-Prinzip: MediaWiki: Handbuch für Benutzer*innen
zur Barrierefreiheit öffentlicher Websites: Bundesfachstelle Barrierefreiheit
Hinweis zur Nachnutzung als Open Educational Resource (OER)
Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Wissensmanagement mit Wiki und Content-Management-System” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/wiki-cms veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/it-systeme/it-service. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
