Plone Dienstleister in Berlin: Warum das 'alte' CMS für KI-Integration unterschätzt wird
Der Anruf kam von einer Berliner Landesbehörde: "Unser Plone-Intranet läuft seit 2014 stabil, jetzt will die Führungsebene KI-Suche. Der neue Berater sagt, wir müssen alles auf SharePoint migrieren. 1,2 Millionen Euro Budget, 18 Monate Projektlaufzeit. Gibt's keine andere Lösung?"
Diese Frage höre ich als Python-Agentur in Berlin mindestens einmal im Monat. Die Antwort überrascht viele: In 80% der Fälle lässt sich das bestehende Plone-System für einen Bruchteil der Kosten KI-ready machen. Nicht trotz, sondern wegen seiner Python-Basis.
Plone in 2024: Tot oder unterschätzt?
Seien wir ehrlich: Plone hat ein Image-Problem. Die meisten kennen es als das CMS aus den 2000ern, das mal hip war und jetzt in verstaubten Behörden-Kellern vor sich hin läuft. "Legacy", "monolithisch", "schwer zu warten" – die üblichen Verdächtigen.
Die Realität? Von den 50 größten deutschen Behörden nutzen 12 immer noch Plone. Die Bundesagentur für Arbeit verwaltet damit 400.000 Dokumente. Das Umweltbundesamt koordiniert darüber die Kommunikation von 1.200 Mitarbeitern in 13 Standorten. Nicht weil sie zu träge für einen Wechsel sind, sondern weil es funktioniert.
Die Python-Basis als unterschätzter Vorteil
Hier kommt der Twist: Plone basiert auf Python. Demselben Python, das heute 90% aller KI-Projekte antreibt. LangChain, Hugging Face, scikit-learn – alles Python. Während WordPress-Nutzer PHP-Python-Bridges basteln und Drupal-Teams mit Node.js-Workarounds kämpfen, haben Plone-Systeme direkten Zugriff auf das gesamte KI-Ökosystem.
Ein Beispiel aus unserem letzten Projekt: RAG-System (Retrieval Augmented Generation) für 200.000 Verwaltungsdokumente. Integration in Plone: 3 Wochen. Geschätzte Zeit für Migration zu SharePoint plus KI-Integration: 6 Monate.
Volto als modernes React-Frontend
"Aber die Oberfläche!" – der häufigste Einwand. Stimmt, Classic Plone UI sieht aus wie 2010. Aber seit Version 6 gibt's Volto, ein komplett neues React-basiertes Frontend. Headless-Architektur, REST-API, moderne Developer Experience. Die wenigsten wissen das.
Konkretes Projekt: KI-Integration in Legacy-Plone
Lassen Sie mich das Behörden-Projekt von oben konkretisieren. Die Ausgangslage:
- Plone 5.2 Intranet, 8 Jahre alt
- 200.000 Dokumente (PDFs, Word, interne Wikis)
- 1.200 Nutzer, davon 300 täglich aktiv
- Hauptproblem: "Keiner findet mehr was"
Die SharePoint-Migration hätte bedeutet:
- Alle Workflows neu aufbauen (Plone hatte 47 custom Workflows)
- 1.200 Nutzer schulen
- Integrationshölle mit 12 Altsystemen
- DSGVO-Prüfung für Microsoft Cloud
Unser Ansatz: Plone behalten, KI draufsetzen.
Code-Snippet: LangChain-Integration in Plone
So sieht die Integration konkret aus:
# plone_ki/indexing.py
from plone import api
from langchain.embeddings import HuggingFaceEmbeddings
from langchain.vectorstores import FAISS
from langchain.text_splitter import RecursiveCharacterTextSplitter
class PloneKIIndexer:
def __init__(self):
# Deutsche Embeddings, on-premise
self.embeddings = HuggingFaceEmbeddings(
model_name="deutsche-telekom/gbert-large-paraphrase-cosine",
model_kwargs={'device': 'cpu'},
encode_kwargs={'normalize_embeddings': True}
)
def index_content(self, brain):
"""Indiziert Plone-Content für KI-Suche"""
obj = brain.getObject()
# Text aus verschiedenen Plone-Feldern sammeln
text_parts = []
if hasattr(obj, 'text'):
text_parts.append(obj.text.output if hasattr(obj.text, 'output') else str(obj.text))
if hasattr(obj, 'description'):
text_parts.append(obj.description)
# PDFs und Office-Dokumente verarbeiten
if obj.portal_type == 'File':
text_parts.append(self.extract_file_content(obj))
full_text = "\n\n".join(text_parts)
# Chunking für bessere Suchergebnisse
splitter = RecursiveCharacterTextSplitter(
chunk_size=1000,
chunk_overlap=200,
separators=["\n\n", "\n", ".", " "]
)
chunks = splitter.split_text(full_text)
# Metadaten für Kontext
metadata = {
'uid': obj.UID(),
'title': obj.Title(),
'portal_type': obj.portal_type,
'modified': obj.modified().ISO8601(),
'creator': obj.Creator(),
'subjects': list(obj.Subject()),
'url': obj.absolute_url()
}
return chunks, metadataDas ist Production-Code aus dem Projekt. Läuft seit 6 Monaten, verarbeitet täglich 500 Suchanfragen. On-Premise, DSGVO-konform, keine Daten verlassen das Behördennetzwerk.
ROI-Berechnung: Migration vs. Modernisierung
Die Zahlen sprechen für sich:
Aber Kosten sind nur eine Seite. Time-to-Value:
- SharePoint-Migration: Erste nutzbare Version nach 8 Monaten
- Plone-KI-Integration: MVP nach 6 Wochen, Vollausbau nach 3 Monaten
Wann Plone (immer noch) die richtige Wahl ist
Nach 15 Jahren Python-Entwicklung kann ich klar sagen: Plone ist nicht für jeden. Aber für bestimmte Szenarien gibt's kaum Besseres.
DSGVO/Compliance-Anforderungen
Plone läuft on-premise. Punkt. Keine US-Cloud, keine Datenschutz-Diskussionen, keine Privacy-Shield-Nachfolger-Problematik. Für Behörden, Krankenhäuser und Finanzdienstleister oft das K.O.-Kriterium.
Ein Kunde (Versicherung, 5.000 Mitarbeiter) wollte ursprünglich zu Microsoft 365 wechseln. Nach der DSGVO-Prüfung: "Geht nicht, zu viele offene Fragen bei der Auftragsdatenverarbeitung." Lösung: Plone-Upgrade mit modernem UI. Kostenpunkt: 20% der geplanten Migration.
On-Premise-Zwang
"Aber Cloud ist doch moderner!" – Nicht wenn Ihre Sicherheitsrichtlinie es verbietet. Bundesbehörden, kritische Infrastruktur, Rüstungszulieferer – alle brauchen on-premise. Plone läuft auf einem Raspberry Pi, wenn es sein muss.
Komplexe Workflows und Rechteverwaltung
Plone's Workflow-Engine ist ein Monster. Im positiven Sinne. 50-stufige Genehmigungsprozesse? Verschiedene Sichtbarkeiten je nach Abteilung, Standort und Mondphase? Plone kann das seit 20 Jahren.
Ein Beispiel: Großer Pharmakonzern, Clinical-Trial-Dokumentation. 17 verschiedene Rollen, 23 Workflow-States, Audit-Trail für jeden Mausklick. In Plone: Konfiguration. In modernen Headless-CMS: Monate Custom-Entwicklung.
Mehrsprachigkeit mit 20+ Sprachen
Die EU-Kommission nutzt Plone. Warum? 24 Amtssprachen, jedes Dokument in jeder Sprache, mit Übersetzungs-Workflow und Versionierung. Plone's LinguaPlone macht das out-of-the-box.
WordPress Multisite? Drupal mit Entity Translation? Funktioniert, aber haben Sie mal versucht, einen Übersetzungs-Workflow für 24 Sprachen zu bauen? Ich schon. Nehmen Sie Plone.
Wann Sie von Plone wegmigrieren sollten
Jetzt kommt der Teil, den Plone-Evangelisten hassen werden: Es gibt gute Gründe, von Plone wegzugehen. Ich rate aktiv davon ab, wenn:
Marketing-Websites → Headless CMS
Ihre Marketing-Abteilung will A/B-Tests, Personalisierung, schnelle Landing-Pages? Vergessen Sie Plone. Nehmen Sie Strapi, Contentful oder Sanity. Plone ist für Dokument-Management gebaut, nicht für Campaign-Management.
Ein E-Commerce-Kunde kam mit Plone als CMS für seinen Shop. Nach 2 Wochen Analyse: "Nehmt Shopify und ein Headless-CMS." Haben sie gemacht, sind glücklich. Plone wäre die falsche Wahl gewesen.
Startups → Django + React
Sie bauen das nächste große Ding? 3 Entwickler, viel Custom-Logic, schnelle Iterationen? Django plus React. Plone's Overhead lohnt sich erst ab einer gewissen Komplexität.
Faustregel: Unter 10.000 Content-Items und 100 Usern ist Plone overkill. Darüber fängt es an, Sinn zu machen. Ab 100.000 Items und 1.000 Usern spielt es seine Stärken aus.
Wenn niemand mehr Plone kann
Der ehrlichste Grund: Wenn Ihr einziger Plone-Entwickler in Rente geht und Sie in Berlin keinen Ersatz finden, wird's schwierig. Der Plone-Talent-Pool ist klein. Python-Entwickler gibt's viele, aber Plone-spezifisches Wissen ist rar.
Plone-Dienstleister finden: Worauf achten
Sie haben sich entschieden, Plone zu behalten und zu modernisieren? Gut. Jetzt brauchen Sie den richtigen Partner. Nach 50+ Plone-Projekten meine Kriterien:
Nicht nur Plone-Erfahrung, sondern Python-Tiefe
"Wir machen Plone seit 15 Jahren" reicht nicht. Die Frage ist: Können sie auch Python jenseits von Plone? Moderne KI-Integration braucht tiefes Python-Verständnis. Fragen Sie nach:
- Erfahrung mit FastAPI/Django neben Plone
- Data-Science-Projekten mit pandas/scikit-learn
- Deployment jenseits von Zope (Kubernetes? Docker?)
Ein Test: Bitten Sie um Code-Beispiele ihrer letzten Python-Projekte. Wenn nur Plone-Boilerplate kommt, Finger weg.
KI-Kompetenz nachweisen lassen
"Wir machen auch KI" sagt jeder. Konkreter werden:
- Welche LLMs haben sie integriert?
- Kennen sie den Unterschied zwischen Embedding-Modellen?
- Haben sie RAG-Systeme gebaut?
- Wie lösen sie Halluzination-Probleme?
Wer bei "Embeddings" nachfragen muss, sollte nicht Ihre KI-Integration bauen.
Wartung vs. Weiterentwicklung
Es gibt zwei Arten von Plone-Dienstleistern:
- Die Verwalter: Halten Ihr System am Laufen, machen Security-Updates
- Die Entwickler: Bauen neue Features, integrieren moderne Tools
Für KI-Projekte brauchen Sie Typ 2. Fragen Sie nach dem Verhältnis Wartung/Entwicklung in ihren Projekten. Über 70% Wartung? Das ist eine Wartungsfirma, keine Entwicklungsagentur.
So würden wir ein Plone-KI-Projekt aufsetzen
Genug Theorie. So würde ich als Softwareagentur ein Plone-KI-Projekt konkret angehen:
Phase 1: Pilot mit messbarem ROI (6-8 Wochen)
Wir fangen klein an. Ein Use-Case, messbare Metrik, schneller Erfolg:
Woche 1-2: Use-Case-Definition- Workshop mit Power-Usern: Was nervt am meisten?
- Typischer Gewinner: Dokumentensuche
- Metrik definieren: "Zeit bis zum Finden des richtigen Dokuments"
- Baseline messen: Aktuell durchschnittlich 12 Minuten
- Embedding-Modell auswählen (deutsch, on-premise)
- 10.000 Dokumente indizieren
- Einfache Suchmaske bauen
- Integration in Plone-Intranet
- A/B-Test: Alte Suche vs. KI-Suche
- Täglich Feedback sammeln
- Messung: Zeit bis zum Dokument
- Ergebnis typischerweise: 70% Zeitersparnis
- ROI-Berechnung: Bei 1.000 Usern = 2h/Woche gespart
- Go/No-Go für Vollausbau
Phase 2: Vollintegration (3-4 Monate)
Nach erfolgreichem Pilot der Vollausbau:
- Plone 6.0 (oder Upgrade von 5.2)
- Volto Frontend mit React-Komponenten für KI-Features
- PostgreSQL mit pgvector für Embeddings
- FastAPI für KI-Service-Layer
- Qdrant oder Weaviate als Vector-Store
- Prometheus + Grafana für Monitoring
- Semantische Suche über alle Inhalte
- Q&A-System für Dokumente ("Was sagt die Richtlinie X zu Thema Y?")
- Auto-Tagging neuer Inhalte
- Duplikaterkennung beim Upload
- Verwandte-Inhalte-Vorschläge
Phase 3: Kontinuierliche Optimierung
KI-Systeme werden mit Nutzung besser. Unser Wartungskonzept:
Monatlich:- Analyse der Suchbegriffe ohne Treffer
- Nachjustierung der Embeddings
- User-Feedback einarbeiten
- Neue Modelle evaluieren
- Performance-Optimierung
- Feature-Requests priorisieren
- Grundlegende Architektur-Review
- Update auf neue Plone/Python-Versionen
- Sicherheits-Audit
Der unbequeme Rat zum Schluss
Die meisten Artikel würden jetzt mit "Plone ist super für KI" enden. Die Realität ist differenzierter:
Wenn Sie ein bestehendes Plone-System haben, das funktioniert, und KI-Features brauchen: Modernisieren statt migrieren. Die Python-Basis macht es zum idealen Kandidaten für Python für KI und Machine Learning.
Wenn Sie neu starten und zwischen CMS-Systemen wählen: Nehmen Sie Plone nur, wenn Sie die spezifischen Stärken brauchen. Für 80% der Projekte gibt es schlankere Alternativen.
Und der wichtigste Punkt: KI macht aus einem schlechten CMS kein gutes. Wenn Ihre User das System hassen, hilft auch die beste Semantic Search nicht. Erst die Basics fixen, dann KI draufsetzen.
Sie haben ein Plone-System und wollen wissen, ob KI-Integration Sinn macht? Lassen Sie uns reden. Keine Powerpoints, keine Buzzword-Schlachten. Wir schauen uns Ihr System an, definieren einen Pilot und rechnen den ROI aus. In 2 Stunden wissen Sie, ob es sich lohnt.
Kontaktieren Sie uns für eine kostenlose Ersteinschätzung Ihres Plone-Systems.