Kultureinrichtungen haben meistens kein IT-Problem. Sie haben ein Einkaufsproblem.
Das Muster wiederholt sich. Ein Museum, eine Kunstschule, ein Theater: zu wenig Personal, zu wenig Budget, gewachsene Strukturen die niemand mehr ganz überblickt. Irgendwann ist der Leidensdruck groß genug für eine Entscheidung. Also wird eingekauft. Eine Agentur wird beauftragt. Ein Softwarepaket lizenziert. Ein CMS eingeführt das eigentlich für Konzerne gedacht ist. Sechs Monate später läuft es — irgendwie. Zwei Jahre später traut sich niemand mehr, etwas anzufassen.
Was hier schiefläuft ist keine Frage von Kompetenz. Die Leute die solche Entscheidungen treffen wissen sehr viel über Kunst, über Vermittlung, über Betrieb. Was sie nicht wissen — und auch nicht wissen müssen — ist, was Software in fünf Jahren noch kann, wenn niemand mehr an ihr arbeitet. Diese Frage wird beim Einkauf meistens gar nicht gestellt.
Das liegt am Markt. Agenturen verkaufen Lösungen, keine Infrastruktur. Softwarehersteller verkaufen Features, keine Langzeitverantwortung. Beide haben Interesse daran, dass in drei Jahren wieder eingekauft wird. Die Kultureinrichtung hat das gegenteilige Interesse — sie möchte ein System das läuft, nicht eines das gepflegt werden muss wie ein krankes Tier.
Was Kultureinrichtungen tatsächlich brauchen ist selten spektakulär. Meistens ist es das: eine Website die schnell lädt und sich ohne Agentur aktualisieren lässt. Eine Möglichkeit, Anmeldungen zu verwalten ohne Excel. Ein Weg, Honorare abzurechnen ohne dass jemand drei Stunden sucht. Kommunikation mit Kursteilnehmern die nicht über vier verschiedene Tools geht. Das klingt bescheiden. Es ist in der Praxis für viele Einrichtungen nicht gelöst.
Stattdessen bekommt man: WordPress mit zwanzig Plugins. Ein Buchungssystem das eigentlich für Fitnessstudios gebaut wurde. Eine CRM-Lizenz die im dritten Monat zu teuer wird und dann doch nicht genutzt wird. Und irgendwo im Hintergrund läuft weiterhin die Excel-Datei, weil die zuverlässiger ist als alles andere zusammen.
Das Problem mit Plugins ist nicht, dass sie funktionieren. Das Problem ist, dass sie alle einzeln aktualisiert werden wollen, alle einzeln brechen können, und keiner von ihnen für die spezifische Kombination aus Anforderungen gebaut wurde, die eine Kunstschule mit drei Standorten und zwei Dutzend freien Dozenten hat. Jedes Plugin löst ein abstraktes Problem. Das konkrete Problem bleibt.
Niemand würde ein Plugin-Update im Cockpit-HUD eines Flugzeugs akzeptieren. Die Höhenanzeige bekommt kein neues Feature, sie zeigt die Höhe an — seit Jahrzehnten, zuverlässig, ohne Überraschungen. Dass dieselbe Logik nicht für Verwaltungssoftware gilt, ist eine kulturelle Entscheidung, keine technische Notwendigkeit. COBOL läuft heute noch in einem Großteil der weltweiten Bankeninfrastruktur. Nicht weil niemand Bescheid weiß, sondern weil es funktioniert — und weil die Kosten eines Fehlers jeden Modernisierungswunsch sofort relativieren.
Was besser funktioniert: weniger. Ein System das genau das kann, was gebraucht wird — und nichts sonst. Kein Überbau, keine Lizenzkosten, keine Black Box. Langweilige Software ist gute Software. Das ist in der Regel nicht das was eine Agentur anbietet, weil es sich schlechter verkauft als ein vollständiges Paket. Es ist das was entsteht, wenn jemand zuerst versteht wie eine Einrichtung tatsächlich arbeitet — und dann baut.
Die gute Nachricht: der Aufwand für so ein System ist heute erheblich kleiner als noch vor ein paar Jahren. KI hat die Entwicklungszeit für maßgeschneiderte Lösungen drastisch verkürzt. Was früher ein halbes Jahr Agenturprojekt war, ist heute in Wochen machbar — ohne dass dabei Qualität verloren geht, eher im Gegenteil. Das macht Dinge möglich, die früher am Budget gescheitert wären.
Die schlechte Nachricht: man muss trotzdem zuerst die richtigen Fragen stellen. Software die schnell gebaut wird aber das falsche Problem löst, ist nur schneller falsch.