Seminar Magnolia CMS – Einführung, Auswahl und Projektplanung

Das Seminar unterstützt die strukturierte Bewertung von Magnolia, die Abgrenzung geeigneter Anwendungsfälle und die Planung eines realistischen Einführungs- oder Modernisierungsvorhabens. Der Schwerpunkt liegt auf einer reproduzierbaren Vorgehensweise mit klaren Ausgangswerten, kontrollierten Änderungen, Negativtests und dokumentierten Abnahmekriterien. Produktive Änderungen werden nicht vorausgesetzt; alle Arbeitsschritte lassen sich in einer Labor- oder Projektumgebung nachvollziehen.

Inhaltsübersicht

1. Ziele, Kanäle und Anwendungsfälle
2. Plattform- und Architekturentscheidung
3. Fit-Gap und Proof of Concept
4. Roadmap, Team und Governance
5. Zielgruppe und Voraussetzungen
6. Didaktik und Arbeitsweise

Ziele, Kanäle und Anwendungsfälle

Inhaltsverzeichnis

• Geschäftsziele und Nutzergruppen
• Websites, Portale, Apps und Omnichannel
• redaktionelle, technische und betriebliche Anforderungen
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Geschäftsziele und Nutzergruppen, Websites, Portale, Apps und Omnichannel und redaktionelle, technische und betriebliche Anforderungen zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Geschäftsziele und Nutzergruppen werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Websites, Portale, Apps und Omnichannel wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: redaktionelle, technische und betriebliche Anforderungen werden schrittweise konfiguriert oder implementiert. Ein Anforderungskatalog wird nach Nutzen, Kritikalität und Differenzierungsbedarf priorisiert. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Priorisierte Use-Case-Landkarte.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Plattform- und Architekturentscheidung

Inhaltsverzeichnis

• klassisches, hybrides und Headless-CMS
• Integrationen, Datenquellen und Frontends
• Betriebsmodell, Skalierung und Sicherheitsniveau
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet klassisches, hybrides und Headless-CMS, Integrationen, Datenquellen und Frontends und Betriebsmodell, Skalierung und Sicherheitsniveau zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: klassisches, hybrides und Headless-CMS werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Integrationen, Datenquellen und Frontends wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Betriebsmodell, Skalierung und Sicherheitsniveau werden schrittweise konfiguriert oder implementiert. Mehrere Zielarchitekturen werden gegen feste Entscheidungskriterien verglichen. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Bewertungsmatrix für Plattform- und Betriebsoptionen.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Fit-Gap und Proof of Concept

Inhaltsverzeichnis

• Must-have- und Soll-Anforderungen
• Risiken, Annahmen und offene Punkte
• PoC-Schnitt, Abnahmekriterien und Aufwand
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Must-have- und Soll-Anforderungen, Risiken, Annahmen und offene Punkte und PoC-Schnitt, Abnahmekriterien und Aufwand zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Must-have- und Soll-Anforderungen werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Risiken, Annahmen und offene Punkte wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: PoC-Schnitt, Abnahmekriterien und Aufwand werden schrittweise konfiguriert oder implementiert. Ein fokussierter PoC wird so zugeschnitten, dass die risikoreichsten Annahmen zuerst geprüft werden. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: PoC-Steckbrief mit messbaren Abnahmekriterien.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Roadmap, Team und Governance

Inhaltsverzeichnis

• Rollen und Lieferorganisation
• Migrations-, Rollout- und Schulungswellen
• Budgetrahmen, Entscheidungen und Qualitätsgates
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Rollen und Lieferorganisation, Migrations-, Rollout- und Schulungswellen und Budgetrahmen, Entscheidungen und Qualitätsgates zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Rollen und Lieferorganisation werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Migrations-, Rollout- und Schulungswellen wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Budgetrahmen, Entscheidungen und Qualitätsgates werden schrittweise konfiguriert oder implementiert. Eine stufenweise Roadmap mit Verantwortungen und Entscheidungspunkten wird erstellt. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Einführungsfahrplan mit Rollen- und Meilensteinplan.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Zielgruppe und Voraussetzungen

Inhaltsverzeichnis

• Adressierte Rollen
• Fachliche und technische Vorkenntnisse
• Labor- und Arbeitsmittel

Zielgruppe: Geschäftsführung, IT-Leitung, Enterprise Architecture, Digitalverantwortung, Product Owner, Projektleitung, Einkauf und Fachbereichsvertretung.

Voraussetzungen: Kenntnis der eigenen digitalen Kanäle und organisatorischen Ziele; technische Magnolia-Vorkenntnisse sind nicht erforderlich.

Für die Praxisanteile wird eine getrennte Magnolia-Umgebung mit Beispieldaten verwendet. Administrations- und Entwicklungsübungen werden mit nicht produktiven Konten durchgeführt. Vor jedem Eingriff werden Ausgangszustand, erwartete Wirkung und Rückfallmöglichkeit festgehalten.

Didaktik und Arbeitsweise

Inhaltsverzeichnis

• Fachimpuls und Demonstration
• Geführte Umsetzung
• Kontrollierte Fehlerfälle
• Abnahme und Dokumentation

Kurze Fachimpulse werden unmittelbar durch Demonstrationen und geführte Arbeitsschritte vertieft. Jede Übung enthält einen definierten Ausgangszustand, konkrete Prüfpunkte, mindestens einen Negativfall und eine schriftliche Abnahme. Wiederholbare Checklisten und Runbooks stehen im Mittelpunkt; reine Funktionsvorführungen ohne Prüfung sind nicht Bestandteil des Vorgehens.