Plone-Intranet für den Mittelstand: Warum 90% es nicht brauchen — und 10% nichts anderes nehmen sollten

Der Pharma-Mittelständler aus Freiburg hatte ein Problem: 800 Mitarbeiter, 5 Standorte, GxP-Compliance — und ein SharePoint-Intranet, das nach zwei Jahren Migration immer noch nicht richtig funktionierte. Die Dokumentenfreigabe dauerte Tage, die Audit-Trails waren lückenhaft, und bei jeder FDA-Inspektion brach Panik aus. Nach sechs Monaten Plone-Einführung? Freigabeprozesse in Stunden statt Tagen, lückenlose Compliance-Dokumentation, und die IT-Abteilung konnte endlich wieder durchschlafen. Kostenpunkt: 120.000 EUR Initial-Investment, Break-Even nach 18 Monaten durch eingesparte Compliance-Verstöße und effizientere Prozesse.

Klingt nach der perfekten Erfolgsgeschichte? Ist es auch — für genau diesen einen Fall. Für die anderen 90% der Mittelständler wäre Plone die falsche Wahl gewesen.

Die unbequeme Wahrheit über Plone

Lassen Sie uns Klartext reden: Plone ist ein Monster. Ein mächtiges, flexibles, Python-basiertes Monster, das seit 2001 existiert und für fast alles konfiguriert werden kann. Genau das ist das Problem.

Ein typisches Plone-Projekt startet mit großen Ambitionen. Man will nicht nur ein Intranet, sondern das Intranet. Mit Workflow-Engine, granularer Rechteverwaltung, Versionierung, Multi-Site-Fähigkeit, und natürlich soll alles hochgradig anpassbar sein. Nach drei Monaten Konzeption, sechs Monaten Entwicklung und einem sechsstelligen Budget haben Sie dann ein System, das theoretisch alles kann — praktisch aber von niemandem verstanden wird.

Die harte Realität: Für 90% der Intranet-Anforderungen reicht SharePoint, Confluence oder sogar Notion vollkommen aus. Sie brauchen News? Check. Dokumentenablage? Check. Mitarbeiterverzeichnis? Check. Das kriegen Sie mit SharePoint für 5 EUR pro User im Monat, Setup in zwei Wochen.

Plone-Entwickler sind rar und teuer. Ein Senior Plone-Developer kostet in Berlin 120-150 EUR pro Stunde. SharePoint-Experten? Die Hälfte. Und während Sie für SharePoint in jeder Stadt drei Agenturen finden, gibt es in ganz Deutschland vielleicht 20 wirklich gute Plone-Teams.

Die TCO-Rechnung sieht oft brutal aus:

SharePoint/Confluence: 50k EUR Einführung, 10k EUR jährlich
Plone: 120k EUR Einführung, 30k EUR jährlich für Wartung und Weiterentwicklung

Warum sollte irgendein vernünftiger Mittelständler das machen?

Die 10% Szenarien, wo Plone alternativlos ist

Szenario 1: Regulierte Industrien mit Audit-Trail-Anforderungen

Der Freiburger Pharma-Fall war kein Zufall. In der Pharmaindustrie, Medizintechnik oder Luftfahrt gelten Dokumentationsanforderungen, die Standard-Systeme an ihre Grenzen bringen. Jede Änderung muss nachvollziehbar sein, jeder Zugriff protokolliert, jede Version archiviert.

Plone bringt diese Features von Haus aus mit:

Komplette Versionshistorie für jedes Dokument
Audit-Trails auf Datenbankebene
Workflow-States mit erzwungenen Freigabeprozessen
Digitale Signaturen und Zeitstempel

Ein Medizintechnik-Hersteller aus Stuttgart hat sein QM-System komplett auf Plone aufgebaut. Resultat: Die Zeit für FDA-Audits reduzierte sich von drei Wochen auf drei Tage. Die Prüfer konnten jeden Prozessschritt, jede Änderung, jede Freigabe in Echtzeit nachvollziehen. ROI: Unbezahlbar, wenn man bedenkt, dass ein gescheitertes Audit den US-Marktzugang kosten kann.

Szenario 2: Dezentrale Organisationen mit lokaler Content-Hoheit

Stellen Sie sich vor: Ein Handelsunternehmen mit 50 Filialen. Jede Filiale soll eigene Inhalte pflegen können, aber nur ihre eigenen sehen. Gleichzeitig gibt es übergreifende Dokumente, manche nur für Filialleiter, andere für alle. Und natürlich soll die Zentrale alles im Blick haben.

Mit SharePoint wird das zur Hölle. Sie jonglieren mit Berechtigungsgruppen, Sub-Sites und Inheritance-Breaks, bis niemand mehr durchblickt. Mit Plone definieren Sie lokale Arbeitsbereiche mit eigenen Workflows. Die Hamburger Filiale sieht nur Hamburg, außer bei Dokumenten, die explizit geteilt werden.

Ein Großhändler aus dem Ruhrgebiet hat genau das umgesetzt. 2.000 Mitarbeiter, 30 Standorte, eine Plone-Instanz. Jeder Standort verwaltet seine Dokumente selbst, die Zentrale hat trotzdem den Überblick. Setup-Zeit: 4 Monate. Alternative mit SharePoint wurde nach 6 Monaten Konzeption verworfen — zu komplex.

Szenario 3: KI-Integration mit strengen Datenschutz-Anforderungen

Hier wird es spannend für eine Python-Agentur wie uns. Plone ist Python. Ihre KI-Modelle? Auch Python. Die Integration? Ein Kinderspiel im Vergleich zu proprietären Systemen.

Ein Beispiel aus unserer Praxis: Ein Maschinenbauer wollte seine technische Dokumentation (10.000+ Dokumente) per KI durchsuchbar machen. Die Anforderung: Alles on-premise, keine Cloud, DSGVO-konform. Mit Plone als Basis und einem lokal gehosteten LLM haben wir eine Lösung gebaut, die Ingenieure in natürlicher Sprache fragen lässt: "Wie wechsle ich das Lager bei Modell X?" und präzise Antworten mit Quellenangaben liefert.

Plone als KI-Enabler

Die Python-Basis macht Plone zum idealen KI-Enabler für sicherheitskritische Anwendungen. Während SharePoint-Admins noch überlegen, wie sie ihre REST-API zum Laufen kriegen, bauen wir bereits RAG-Systeme direkt ins Intranet.

Ein konkretes Beispiel aus unserem Code:

from plone import api
from fastapi import FastAPI
import httpx

app = FastAPI()

@app.post("/api/ki/document-search")
async def search_documents(query: str, context: str = None):
    # Plone REST-API für Dokumentenzugriff
    portal = api.portal.get()
    catalog = api.portal.get_tool('portal_catalog')
    
    # Relevante Dokumente basierend auf Kontext filtern
    brains = catalog(
        portal_type='Document',
        review_state='published',
        SearchableText=context
    )
    
    # Dokumente an lokales LLM senden
    documents = [brain.getObject().text for brain in brains[:10]]
    
    async with httpx.AsyncClient() as client:
        response = await client.post(
            "http://localhost:8080/v1/completions",
            json={
                "prompt": f"Context: {' '.join(documents)}\n\nFrage: {query}",
                "max_tokens": 500,
                "temperature": 0.3
            }
        )
    
    return {
        "answer": response.json()['choices'][0]['text'],
        "sources": [brain.getURL() for brain in brains[:3]]
    }

Das Besondere: Die Daten verlassen nie das Unternehmensnetzwerk. Das LLM läuft lokal, Plone verwaltet die Zugriffsrechte, und die Mitarbeiter bekommen KI-gestützte Antworten auf ihre Fragen — DSGVO-konform und ohne Cloud-Abhängigkeit.

Ein Automobilzulieferer aus Baden-Württemberg nutzt genau diesen Ansatz für sein Qualitätsmanagement. Statt stundenlang in PDF-Dokumenten zu suchen, fragen Mitarbeiter das System: "Welche Prüfschritte gelten für Bauteil 4711?" Die KI liefert die Antwort in Sekunden, inklusive Verweis auf die relevanten Dokumente. Zeitersparnis: 2 Stunden pro Mitarbeiter pro Woche.

Der technische Deep-Dive

Plone 6 mit Volto Frontend vs. Classic UI

Die Entscheidung zwischen Volto (React-basiert) und Classic UI (serverseitiges Rendering) ist keine technische Spielerei, sondern hat massive Auswirkungen auf Ihr Projekt.

Volto ist modern, schnell, und bietet eine User Experience, die mit kommerziellen Lösungen mithalten kann. Der Haken: Sie brauchen Frontend-Entwickler mit React-Expertise zusätzlich zu Ihren Python-Entwicklern. Für ein mittelständisches Intranet mit 500 Usern often Overkill.

Classic UI ist "langsamer", aber bewährt. Ihre Python-Entwickler können Frontend und Backend aus einer Hand liefern. Für interne Systeme, wo Funktionalität über Hochglanz-UI geht, oft die bessere Wahl.

Integration mit bestehenden Django/Python-Systemen

Hier spielt Plone seine Stärken aus. Beide Systeme sprechen Python, beide nutzen ZODB oder PostgreSQL, beide verstehen REST.

Ein Logistik-Unternehmen hatte bereits eine Django-basierte Auftragsverwaltung. Die Plone-Integration dauerte zwei Wochen:

# Django View
from django.http import JsonResponse
from django.views import View
import requests

class PloneDocumentSync(View):
    def post(self, request):
        # Auftragsdaten aus Django
        order_data = Order.objects.get(id=request.POST['order_id'])
        
        # Dokument in Plone erstellen
        plone_response = requests.post(
            'https://intranet.firma.de/@types/Document',
            headers={'Accept': 'application/json'},
            auth=('sync-user', 'secret'),
            json={
                'title': f'Auftrag {order_data.number}',
                'description': order_data.description,
                'text': self.generate_order_html(order_data)
            }
        )
        
        return JsonResponse({'plone_url': plone_response.json()['@id']})

Performance-Optimierung für 1000+ User

Standard-Plone skaliert bis etwa 100 gleichzeitige User. Darüber braucht es Optimierung:

Varnish Cache: Statische Inhalte ausliefern ohne Python-Overhead
Redis für Sessions: Entlastet die ZODB
Horizontal Scaling: Mehrere Plone-Instanzen hinter HAProxy
Asynchrone Tasks: Celery für aufwändige Operationen

Ein Energieversorger mit 1.500 Mitarbeitern läuft mit dieser Architektur seit drei Jahren stabil. Load-Tests zeigen: Das System verkraftet 500 gleichzeitige User ohne Performance-Einbußen.

ROI-Rechnung mit echten Zahlen

Reden wir über Geld. Ein typisches Plone-Intranet für 500-1000 Mitarbeiter:

Initiale Kosten:

Konzeption & Workshops: 15.000 EUR
Basis-Setup & Anpassungen: 40.000 EUR
Inhalts-Migration: 20.000 EUR
Spezial-Features (Workflows, Integration): 30.000 EUR
Testing & Go-Live: 15.000 EUR
Gesamt: 120.000 EUR

Laufende Kosten pro Jahr:

Hosting (on-premise oder Private Cloud): 6.000 EUR
Wartung & Updates: 12.000 EUR
Weiterentwicklung: 15.000 EUR
Gesamt: 33.000 EUR

Zum Vergleich SharePoint Online:

Lizenzen (500 User): 30.000 EUR/Jahr
Einrichtung: 40.000 EUR
Anpassungen: stark limitiert

Der Break-Even? Bei Standard-Anforderungen nie. Bei Compliance-Szenarien nach 2-3 Jahren. Bei vermiedenen Audit-Problemen schon nach dem ersten verhinderten Vorfall.

So geht's jetzt weiter

Der 3-Fragen-Test: Brauchen Sie wirklich Plone?

Haben Sie spezielle Compliance-Anforderungen? (GxP, ISO, FDA)

Ja → Plone könnte passen

Nein → Weiter zu Frage 2

Brauchen Sie komplexe, standortspezifische Berechtigungen?

Ja → Plone in Betracht ziehen

Nein → Weiter zu Frage 3

Planen Sie tiefe Integration mit Python-basierten Systemen oder KI?

Ja → Plone evaluieren

Nein → Nehmen Sie SharePoint oder Confluence

Haben Sie dreimal "Nein" geantwortet? Vergessen Sie Plone. Im Ernst. Die Komplexität lohnt sich für Sie nicht.

Pilot-Projekt-Ansatz

Falls Plone für Sie infrage kommt, starten Sie klein:

Ein Fachbereich, 50 User, ein konkreter Use-Case
3 Monate Laufzeit, fixes Budget (30-40k EUR)
Klare Erfolgskriterien definieren
Nach 3 Monaten: Ausrollen oder Abbrechen

Konkrete nächste Schritte

Wenn Sie bis hier gelesen haben und immer noch interessiert sind:

Dokumentieren Sie Ihre Spezial-Anforderungen — nicht die Standard-Features, sondern das, was SharePoint nicht kann
Sprechen Sie mit Referenz-Kunden — nicht mit Agenturen, mit echten Anwendern
Kalkulieren Sie realistisch — Plone wird teurer als gedacht, die Frage ist, ob es sich trotzdem lohnt

Unsere Python Agentur Berlin hat schon mehrere Plone-Projekte begleitet. Die erfolgreichen hatten alle eins gemeinsam: klare Anforderungen, die nur Plone erfüllen konnte. Die gescheiterten wollten "einfach mal Plone ausprobieren".

Die Botschaft ist klar: Plone ist kein Tool für jeden. Es ist ein Spezialwerkzeug für spezielle Anforderungen. Eingesetzt am richtigen Ort, ist es unschlagbar. Am falschen Ort ist es eine teure Fehlentscheidung. Die Kunst liegt darin, den Unterschied zu erkennen — bevor Sie sechsstellige Summen investieren.