Heranführung an CiviCRM durch Unterscheidung von Anwendungsebene, Orchestrierungsebene, Use Cases und Trampelpfade

CiviCRM zu verstehen und anzuwenden wird deutlich erleichtert, wenn man zwischen zwei unterschiedlichen, aber aufeinander bezogenen Ebenen unterscheidet: der Anwendungsebene und der Orchestrierungsebene. Beide Ebenen strukturieren den Umgang mit dem System. Zwei weitere Perspektiven kommen hinzu: Erstens die Beschreibung konkreter Aufgabenstellungen (Use Cases), die mit CiviCRM bewältigt werden. Zweitens die Beobachtung tatsächlich entstandener Nutzungsmuster, die sich als Trampelpfade (Desire Paths) beschreiben lassen. Zusammengenommen bilden diese vier Perspektiven – Anwendungsebene, Orchestrierungsebene, Use Cases und Trampelpfade – ein Schichtenmodell, das es ermöglicht, die Struktur und Nutzung von CiviCRM verständlich zu machen. Die Anwendungsebene beantwortet dabei die Frage: „Was will ich tun?“ Zum Beispiel „Kontakte verwalten“ oder „ein Rundschreiben versenden“ oder „Zuwendungsbestätigungen erstellen“. Die Orchestrierungsebene beantwortet die Frage: „Wie kann ich das Zusammenspiel zwischen Daten und Funktionen der Anwendungsebene gestalten?“ Use Cases und Trampelpfade ergänzen diese Perspektiven um die Frage: „Wie wird es tatsächlich gemacht?“. Jede Heranführung an das System muss sich außerdem der Frage stellen, wie dauerhaft die auf diese Weise identifizierten Pfade in einem sich verändernden System sind, welche Rolle KI bei ihrer Erkennung, Vermittlung und möglichen Re-Proprietarisierung der Software spielt und wer die Kosten trägt, die kollektive Wissensinfrastruktur bereitzustellen, um das Wissen um erprobte Lösungen bereitzustellen, die Anwender*innen als auch KI als Referenz dient.

Inhaltsverzeichnis

1. Anwendungsebene und Orchestrierungsebene: Was will ich tun? Wie soll es ablaufen?

Die Anwendungsebene und die Orchestrierungsebene sind zwei unterschiedliche Denk- und Nutzungsebenen in CiviCRM.

Die Anwendungsebene besteht aus Ausprägungen realer sozialer Praxis: Kontakte und Adressen, Aktivitäten bezogen auf Kontakte, Beziehungen zwischen Kontakten oder die Zuordnung von Kontakten zu Gruppen – auch im Sinne von Nachrichten-Verteilern. Hinzu kommen Bereiche wie die Verwaltung von Zuwendungen, die Organisation von Veranstaltungen, die Verwaltung von Mitgliedschaften oder die Fall- bzw. Vorgangsverwaltung. Technisch handelt es sich um voneinander unabhängige Datensätze, die als „Entitäten“ zueinander in Beziehung stehen. Ein Beispiel: Ein Kontakt hat eine Adresse, aber die Adresse könnte auch einem anderen Kontakt „gehören“. Eine Zuwendung ist dokumentiert, aber man könnte feststellen, dass sie von einem anderen Kontakt stammt. Und so weiter.

Die Anwendungsebene erschließt sich über typische Handlungen, die sich auf diese Entitäten beziehen: Kontakte erfassen, Aktivitäten notieren, Beziehungen pflegen, E-Mails an Kontakte senden, Zuwendungen erfassen und bescheinigen, Veranstaltungen anlegen und Teilnahmen verwalten, Mitgliedschaften verwalten oder Fälle bearbeiten. Der Zugang fällt hier leicht, weil die Benennung des jeweiligen Bereichs auf die Frage antwortet: „Was will ich tun?“ und damit beschreibt, wofür das System benutzt wird.

CiviCRM besitzt zusätzlich Funktionsbereiche, die nicht Teil der Anwendungsebene sind, sondern als darüber liegende „Orchestrierungsebene“ verstanden werden können. Der Zugang zu dieser Ebene fällt weniger leicht, weil diese Werkzeuge der Beantwortung der Frage „Wie soll es ablaufen?“ dienen, jedoch weder ihre Benennung noch ihre Oberflächen unmittelbar erkennen lassen, wie sie zu diesem Zweck benutzt werden können.

Es handelt sich um Werkzeuge, die auf die Entitäten der Anwendungsebene und ihre Datenarten – etwa Name, Adresse, Status, Beziehung oder Vorgangsdaten – zugreifen und es ermöglichen, mit ihnen zu arbeiten. Zu dieser Ebene zählen „SearchKit“, „FormBuilder“, „FormProcessor“, „CiviRules“, „Search Action Designer“ und auch die Programmierschnittstelle „APIv4“ von CiviCRM. Mit diesen Werkzeugen entwirft man Suchmasken und Listendarstellungen, Eingabeformulare und Abläufe bis hin zu Automatisierungen, etwa dem Anlegen von Entitäten oder dem Versand von Benachrichtigungs-E-Mails abhängig davon, ob bestimmte Voraussetzungen erfüllt sind.

2. Geschichte als Schlüssel: Warum ist das System gerade so aufgebaut?

Den meisten Menschen dürfte die Orchestrierungsebene unverständlich bleiben, solange sie bloß die isolierten Funktionen der Werkzeuge betrachten. Werkzeuge wie SearchKit, FormBuilder, FormProcessor, CiviRules, Search Action Designer und APIv4 sind in ihrer gegenwärtigen Form kaum selbsterklärend und wirken häufig uneinheitlich oder funktional überlappend. Diese Unübersichtlichkeit ist das Ergebnis einer Entwicklungsgeschichte, in der einzelne Funktionsbereiche – teils von unterschiedlichen Softwareentwicklern – jeweils zur Lösung zunächst eng umrissener Probleme entwickelt wurden und erst im Laufe der Zeit miteinander in Beziehung getreten sind.

Die Entstehungsgeschichte erleichtert das Verständnis. Das ist auch deshalb der richtige Ansatz, weil die Entwicklungsgeschichte das Erfahrungswissen derjenigen plausibel erklärt, die CiviCRM-Instanzen konfigurieren, betreiben und Konfiguration und Betrieb als Dienstleistung anbieten.

So lässt sich erkennen, dass unterschiedliche Werkzeuge der Orchestrierungsebene aus konkreten Problemstellungen hervorgegangen sind. Der FormBuilder entstand in Folge der funktionalen Grenzen des älteren „Profile“-Konzepts der Eingabemasken als flexiblerer Ansatz zur Gestaltung von Datenerfassungsprozessen durch externe Nutzer*innen.

Der FormProcessor wurde als Abstraktion für die serverseitige Verarbeitung von Formulardaten entwickelt, also für die Frage, was mit von außen eingegebenen Daten im System geschehen soll.

CiviRules implementiert ein ereignisgetriebenes Modell, bei dem auf bestimmte Zustandsänderungen im System automatisiert reagiert wird: Ereignis → Bedingung → Aktion.

Der Search Action Designer hat seinen Ursprung in der Möglichkeit, auf Basis von Suchergebnissen Massenaktionen auszuführen.

Die Rekonstruktion der Entstehungslogiken ist eine geeignete Strategie, die Orchestrierungsebene verstehbar zu machen. Sie ermöglicht es, das für Laien schwer erkennbare Zusammenspiel der unterschiedlichen Werkzeuge als Effekt einer jahrelangen inkrementellen Entwicklung nur lose miteinander verbundener Entwicklerteams zu begreifen, deren Designentscheidungen nachzuvollziehen und funktionale Überschneidungen nicht als Widerspruch, sondern als Hinweis auf alternative Lösungswege zu interpretieren.

Dies gilt in abgeschwächter Form auch für die Anwendungsebene selbst. Auch ihre Funktionsbereiche sind historisch aus konkreten Anwendungsfällen hervorgegangen und tragen ihre Herkunft sowie deren blinde Flecken in ihrer Struktur fort. Die Anwendungsebene erscheint daher nur auf den ersten Blick als selbstverständlich gegeben; tatsächlich ist auch sie das Resultat einer Verdichtung häufig wiederkehrender sozialer Praktiken.

Neben den Fragen „Was will ich tun?“ und „Wie soll es ablaufen?“ tritt damit die Frage: „Warum ist das System gerade so aufgebaut?“ Erst im Zusammenspiel dieser drei Perspektiven wird es möglich, sich die Struktur von CiviCRM nicht nur anzueignen, sondern sie auch eigenständig weiterzudenken.

3. Use Cases und Trampelpfade

Die Unterscheidung zwischen Anwendungsebene und Orchestrierungsebene macht sichtbar, welche Elemente im System vorhanden sind und wie mit ihnen gearbeitet werden kann. Sie beantwortet jedoch noch nicht die Frage, wie sich aus diesen Möglichkeiten konkrete, in der Praxis bewährte Vorgehensweisen ergeben. Hier setzen Anwendungsfälle (Use Cases), und Trampelpfade an.

Ein Use Case beschreibt eine typische Aufgabe, die eine Nutzer*in mit CiviCRM bewältigen möchte, zusammen mit einem möglichen Weg, diese Aufgabe mit Hilfe des Systems zu lösen. Ein Use Case lässt sich als eine Art Arbeitsrezept verstehen: Er beantwortet nicht nur die Frage, was getan werden soll, sondern zeigt, wie dies mit den vorhandenen Möglichkeiten des Systems erreicht werden kann.

Ein Use Case beschreibt die Arbeit auf der Anwendungsebene – also, mit welchen Entitäten und Daten gearbeitet wird – und verbindet dies optional mit der Orchestrierungsebene, auf der Hilfsmittel und Automatisierungen modelliert werden können.

Typische Use Cases sind etwa: eine Veranstaltung veröffentlichen und Anmeldungen entgegennehmen, eine Anmeldung zu einem Nachrichtenverteiler ermöglichen, eingehende Anfragen erfassen und nachverfolgen oder Spenden dokumentieren und am Jahresende Bescheinigungen erstellen.

Eine Use-Case-Bibliothek beschreibt typische Aufgaben, die bewältigt werden sollen, und Wege, wie sie sich durch die Kombination von Anwendungsebene und Orchestrierungsebene lösen lassen.

Trampelpfade bezeichnen dabei Wege, die sich in der Nutzung von CiviCRM herausgebildet und etabliert haben, weil viele Anwender*innen immer wieder vor ähnlichen Aufgaben stehen und ähnliche Wege zur Lösung der Aufgaben beschreiten. Sie entstehen ohne zentrale Planung durch wiederholte Praxis. In ihnen verdichtet sich Erfahrung zu wiederkehrenden Mustern.

Während Use Cases mögliche Vorgehensweisen beschreiben, zeigen Trampelpfade tatsächlich gegangene Wege.

Zwischen beiden besteht ein Verhältnis der Auswahl und Verdichtung: Use Cases lassen sich am Reißbrett entwerfen, aber Trampelpfade liefern das Material aus der Praxis, aus dem eine Use-Case-Bibliothek entsteht.

Der Übergang von Trampelpfaden zu dokumentierten Use Cases markiert einen Schritt der Institutionalisierung. Implizites Wissen wird explizit und übertragbar. Eine erprobte Praxis wird dadurch zu kollektiv nutzbarer Orientierung. Eine Use-Case-Bibliothek, die sich an Trampelpfaden orientiert, ist daher mehr als eine Sammlung von Beispielen. Sie stabilisiert bestimmte Wege und macht sie zu Referenzen.

Diese Stabilisierung beruht nicht auf der Dauerhaftigkeit konkreter Werkzeuge, sondern auf der Reproduktion zugrunde liegender Strukturen. Die in Trampelpfaden sichtbaren Muster beziehen sich auf wiederkehrende Grundlogiken organisatorischer Abläufe: Kontakte werden angelegt, Handlungen dokumentiert, Zustände verändert und Folgehandlungen ausgelöst. Diese Struktur bleibt vergleichsweise konstant, während sich ihre technische Umsetzung verändert.

Die Orientierung an Trampelpfaden führt damit zu einer Entkopplung von Kompetenz und konkreter Technik. Entscheidend ist nicht, mit welchem Werkzeug ein Prozess umgesetzt wird, sondern wie er modelliert ist.

Ein zusätzlicher Schritt ergibt sich, wenn man Trampelpfade nicht nur beschreibt, sondern systematisch als Ausgangspunkt von Dokumentation, Schulung und Entwicklungsentscheidungen verwendet.

Jeder konkrete Use Case ist wahlweise kongruent mit einem historisch etablierten Trampelpfad oder stellt diesen durch Neuheit in Frage. Die etablierten Trampelpfade sind aus unterschiedlichen Problemstellungen hervorgegangen und tragen jeweils implizite Annahmen, Stärken und Grenzen in sich. Die Aufgabe einer an Trampelpfaden orientierten Dokumentation besteht daher nicht darin, einen vermeintlich „richtigen“ Weg zu behaupten – wie dies ein probalistisch operierendes Large Language Model tun wird – , sondern darin, konkurrierende Wege sichtbar zu machen, ihren Entstehungskontext zu rekonstruieren und sie im Hinblick auf einen konkreten Anwendungsfall zu bewerten.

Erst auf dieser Grundlage wird ein kuratierter Hauptpfad formulierbar, der als begründetermaßen als bevorzugte Lösung dient. Schulung bedeutet in diesem Sinne nicht nur, die Umsetzung eines Use Cases zu vermitteln, sondern die Entscheidung für einen bestimmten Weg gegenüber alternativen Trampelpfaden nachvollziehbar zu machen.

Damit verschiebt sich die Perspektive: CiviCRM erscheint nicht mehr als konsistent entworfenes System, sondern als Überlagerung von Nutzungspfaden unterschiedlicher Akteure. Die Leistung von Dokumentation besteht darin, diese Pfade zu kartieren, zu bewerten und in verlässliche, anschlussfähige Wege zu überführen.

Offene Systeme wie CiviCRM legen die Versuchung nahe zu behaupten, dass Anwender*innen sich ihre Lösungen nach Bedarf selbst zusammenstellen können, da ja alle notwendigen Komponenten vorhanden sind. Technisch ist dies zutreffend, praktisch jedoch nur für einen kleinen Teil derAnwender*innen realistisch. CiviCRM ist ein Paradebeispiel dafür, dass die bloße Verfügbarkeit technischer Bausteine noch überhaupt nicht die Fähigkeit zu ihrer sinnvollen Nutzung beinhaltet.

Die Erwartung, dass Anwender*innen ihre Lösungen eigenständig konstruieren, führt bei mächtigen Systemen wie CiviCRM zu struktureller Überforderung. Zudem begünstigt sie durch das unverbundene Nebeneinander der Nutzung Über-Individualisierungen, in der ähnliche Probleme immer wieder neu gelöst werden, während implizites Erfahrungswissen der nebeneinander mit CiviCRM Arbeitenden nicht systematisch zugänglich wird.

Eine entgegengesetzte Strategie – die vollständige Vorstrukturierung aller Nutzungspfade – wäre jedoch ebenso problematisch. Sie würde die Offenheit des Systems einschränken und den Eindruck erwecken, dass es für jede Aufgabe genau einen richtigen Weg gibt.

Der Ansatz der Trampelpfade lässt sich daher als rechtes Maß zwischen diesen Extremen verstehen: Nicht alle Nutzer*innen müssen Wege selbst bauen können, aber alle sollten in der Lage sein, bewährte Wege zu gehen. Gleichzeitig muss verständlich bleiben, warum diese Wege funktionieren, um Abweichungen und eigene Lösungen zu ermöglichen.

Daraus folgt eine doppelte Aufgabe der Dokumentation: Sie muss häufig gegangene Nutzungspfade identifizieren, stabilisieren und zugänglich machen. Zugleich muss sie die zugrunde liegenden Strukturen dieser Pfade sichtbar machen, um Nutzer*innen zu befähigen, bei Bedarf von ihnen abzuweichen und eigene Lösungen zu entwickeln.

4. Trampelpfade sind veränderlich

Trampelpfade haben eine Eigenschaft, die sich metaphorisch auf Software übertragen lässt: Sie verändern sich, wenn sich Bedingungen im Gelände ändern. Ein umgestürzter Baum oder eine Pfütze reichen aus, damit Menschen beginnen, eine Stelle zu umgehen. Der Trampelpfad verlagert sich.

Auf Software übertragen stellt sich die Frage, wie dauerhaft die Dokumentation eines Systems in Form einer Use-Case-Bibliothek sein kann, wenn sich die technischen Komponenten des Systems fortlaufend verändern. Dies beginnt mit geringfügigen Veränderungen in der Benennung von Funktionen, setzt sich in Veränderungen der Benutzerführung fort und reicht bis zu Situationen, in denen Systemkomponenten entfallen, nicht mehr funktionieren oder durch andere Systemteile ersetzt werden.

Es ist eine verbreitete Erfahrung, dass Software-Dokumentation nicht nur lückenhaft ist, sondern durch Weiterentwicklung schnell veraltet. Tutorials funktionieren nicht mehr, Forenbeiträge werden zu historischen Artefakten, und konkrete Kochrezepte verlieren ihre Gültigkeit, sobald sich die zugrunde liegenden Werkzeuge verändern.

Dieses Phänomen ist strukturell: Die konkreten Lösungspfade verändern sich, weil sich die technischen Bausteine verändern. Soll die Möglichkeit der Aneignung durch den Lernenden nachhaltig angelegt sein, muss das zugrunde liegende Denk- und Strukturmodell des Lösungsansatzes höher priorisiert werden. In diesem Sinne zielt eine an Trampelpfaden orientierte Dokumentation zuerst darauf ab, das wiederkehrende Strukturmuster sichtbar zu machen. Erst danach wird der jeweils aktuelle Pfad als Möglichkeit unter den zum Zeitpunkt der Darstellung gegebenen technischen Voraussetzungen erörtert. Und es wird beschreibbar, wie und wann sich der Pfad geändert hat, weil sich die Umwelt verändert hat, in der dieser Pfad verläuft.

5. Die Rolle von KI

Angesichts lückenhafter Dokumentation und des ständigen Veraltens verfügbarer Anleitungen stellt sich die Frage, welche Rolle KI-Systeme spielen werden. Auf den ersten Blick scheint KI fehlende Dokumentation ersetzen, kontextbezogene Anleitungen zu generieren und implizit in der Software enthaltenes Wissen in verständliche Schritte übersetzen zu können. Tatsächlich wirkt sie bereits heute in vielen Fällen als funktionaler Ersatz für unzureichende Dokumentation.

Es ist möglich, dass KI die individuellen Kosten der Aneignung senkt. Die strukturelle Unterversorgung mit kuratiertem, kollektiv zugänglichem Wissen dürfte jedoch bestehen bleiben. KI mag im Einzelfall hilfreiche Hinweise geben; sie ermöglicht Anwender*innen aber nicht ohne Weiteres zu erkennen, ob ihre Aufgabenstellung allgemein bekannt ist und wie ein allgemein erprobter Lösungsansatz aussieht. Es fehlt die Referenz, mit der der Ratschlag der KI verglichen werden könnte.

Ohne eine Dokumentation der Trampelpfade fehlen zudem genau jene expliziten Wissensbestände, an denen KI sich orientieren könnte, um verbreitete und bewährte Muster typischer Aufgaben zuverlässig abzubilden.

Das Verfügbarwerden von KI kann paradoxe Effekte haben. Indem sie Nutzer*innen ermöglicht, sich situativ zu behelfen, verringert sie womöglich den Druck zur Verbesserung der zugrunde liegenden Wissensinfrastruktur.

Gleichzeitig eröffnet KI neue Möglichkeiten auf Seiten der Implementierungsagenturen. Diese können ihre eigenen Datenbestände – Ticketsysteme, Projektdokumentationen und maschinell auslesbare Konfigurationen von CiviCRM-Instanzen – systematisch auswerten, um ihnen bekannte Use Cases und Trampelpfade zu identifizieren. Gerade Implementierungsagenturen könnte es dadurch gelingen, Trampelpfade in größerem Umfang maschinell zu extrahieren.

Diese Entwicklung führt jedoch nicht automatisch zu einer besseren Versorgung mit Aneignungsfähigkeit im Sinne eines öffentlichen Gutes. Vielmehr besteht die Möglichkeit, dass Wissen um Use Cases und Trampelpfade als strategisches Kapital einzelner Akteure gebunden bleibt. Das Wissen um Lösungswege wäre dann ein proprietär gehaltenes Clubgut, der Einsatz von KI geriete zu einem Baustein von Reproprieisierunsstrategien der ansonsten FOSS-lizensierten Software.

Eine öffentlich kuratierte Use-Case-Bibliothek, die sich an Trampelpfaden orientiert, wird damit zu einer Form von Wissensinfrastruktur, die der Privatisierung dieser Erkenntnisse entgegenwirkt.

Es ergibt sich ein komplementäres Verhältnis: KI kann als Zugang dienen, der individuelle Aneignung erleichtert und punktuell Probleme zu lösen hilft. Eine kuratierte Dokumentation von Trampelpfaden stellt dagegen die strukturellen Referenzpunkte bereit, an denen sich KI-gestützte Aneignung orientieren kann. KI hilft, sich im Gelände zu bewegen; Trampelpfade markieren die Wege, die sich als tragfähig erwiesen haben.

6. Dokumentierte Trampelpfade als implizite Governance

Die im vorangehenden Abschnitt beschriebene Entwicklung wirft eine weitergehende Frage auf: Wenn Wissen über bewährte Nutzungspfade durch KI zunehmend extrahierbar wird, aber zugleich die Tendenz besteht, dieses Wissen als strategisches Kapital einzelner Akteure zu binden, wie kann dann eine kollektive Aneignungsfähigkeit der Software gesichert werden?

Eine mögliche Antwort liegt in der öffentlich kuratierten Dokumentation von Trampelpfaden in Form von Use Cases. Sie erfüllt eine Funktion, die über die Beschreibung von Praxis hinausgeht. Sie reagiert auf ein Defizit formaler Governance-Strukturen, ohne dieses Defizit auf der Ebene expliziter Entscheidungen beheben zu müssen. Wo keine Instanz verbindlich festlegt, welche Lösungswege als bevorzugt gelten sollen, kann eine Use-Case-Bibliothek diese Auswahl faktisch vorwegnehmen.

Dieses Defizit zeigt sich in wiederkehrenden Konstellationen: Soll ein Prozess über FormBuilder und FormProcessor modelliert werden oder über CiviRules und nachgelagerte Aktionen? Ist für wiederkehrende Abläufe eher eine verlaufsförmige Modellierung über Fälle oder eine punktuelle Modellierung über Aktivitäten vorzugswürdig? Sollen Segmentierungen primär über Gruppen, Tags oder andere Mechanismen erfolgen?

Solche Fragen werden oft nicht entschieden, weil sie schwer entscheidbar sind, unterschiedliche Anwendungsfälle unterschiedliche Antworten nahelegen und die Offenheit des Systems als Wert an sich gilt. Die Folge ist jedoch, dass Nutzer*innen mit einer Vielzahl plausibler Möglichkeiten konfrontiert sind, ohne Orientierung darüber, welche sich in der Praxis bewährt haben.

Hier setzt die kuratierte Dokumentation von Trampelpfaden an. Sie trifft keine formalen Entscheidungen, aber sie trifft Auswahlentscheidungen. Indem sie bestimmte Wege beschreibt und andere nicht, hebt sie einzelne Lösungsstrategien aus der Vielzahl möglicher Optionen hervor. Die Dokumentation sagt nicht: „So muss es gemacht werden.“ Sie sagt jedoch: „So wird es gemacht, so hat es sich bewährt, und so kann es gelernt werden.“ Darin liegt ihre implizite Entscheidungswirkung. Sie ersetzt keine formale Governance, kompensiert aber deren Ausbleiben.

Eine öffentliche und kollaborativ kuratierte Use-Case-Bibliothek übernimmt damit eine Form von Governance, die nicht auf formalen Beschlüssen beruht, sondern auf kollaborativ kuratierter Sichtbarkeit. Sie stabilisiert Erwartungen, reduziert Unsicherheit und ermöglicht Anschlussentscheidungen. Anwender*innen orientieren sich an dokumentierten Pfaden und verhalten sich so, als gäbe es bevorzugte Wege – auch dort, wo diese nicht formal festgelegt wurden.

Eine solche Form von Governance schließt alternative Lösungswege nicht aus, sondern verschiebt die Ausgangslage: Wer abweicht, weicht von einem erkennbaren Hauptweg ab und nicht mehr von einer unübersichtlichen Menge gleich plausibel erscheinender Möglichkeiten.

In diesem Sinne bildete eine öffentlich zugängliche Use-Case-Bibliothek eine vermittelnde Schicht zwischen Softwareentwicklung und Nutzung. Sie entscheidet dann nicht über den Code, aber sie beeinflusst, wie der Code verstanden, kombiniert und angewendet wird. Sie ersetzt nicht die formale Governance des Projekts, kompensiert jedoch deren Zurückhaltung, Nutzungspfade ausdrücklich zu priorisieren.

Dokumentation von Trampelpfaden ist daher nicht nur Beschreibung von Praxis, sondern selbst ein Eingriff in Praxis. Indem bestimmte Wege sichtbar gemacht werden, werden sie verstärkt. Indem sie als Use Cases aufbereitet werden, werden sie stabilisiert. Und indem sie öffentlich zugänglich sind, verhindern sie, dass Orientierung an bewährten Lösungen allein als privates Wissen einzelner Akteure verbleibt.

7. Wer trägt die Kosten der Trampelpfad-Dokumentation?

Aus der bisherigen Argumentation ergibt sich eine Anschlussfrage: Wer übernimmt die Kosten für die Erstellung und Pflege einer öffentlich kuratierten Use-Case-Bibliothek, die auf Trampelpfaden basiert?

Die Erstellung einer solchen Dokumentation ist aufwendig. Sie erfordert technisches Wissen und die Möglichkeit zur Auswertung praktischer Erfahrungen, um Nutzungsmuster zu erkennen. Sie ist auch ein Akt der Preisgabe potentiell monetarisierbarer Wissensvorsprünge. Es handelt sich um eine Kollektivgutleistung: Viele profitieren von ihr, aber nur wenige haben unmittelbare Anreize, sie zu erbringen. Ein möglicher Träger dieser Kollektivgutleistung sind Implementierungsagenturen, die ein wirtschaftliches Interesse daran haben, die Aneignungsfähigkeit der Software zu erhöhen.

Für diese Akteure entsteht ein indirekter Anreiz zur Bereitstellung kuratierter Trampelpfad-Dokumentation. Denn eine verbesserte Dokumentation senkt Einstiegshürden, reduziert Unsicherheit und erleichtert die Entscheidung für den Einsatz von CiviCRM. Sie wirkt damit als Form von Absatzförderung – insbesondere für Leistungen, die an eine erfolgreiche Nutzung der Software anknüpfen, etwa Hosting, Betrieb, Support und weiterführende Beratung.

Der entscheidende Punkt liegt darin, dass die Dokumentation nicht das eigentliche Produkt dieser Akteure ist, sondern ein komplementäres Gut. Sie erhöht die Nachfrage nach höherwertigen Leistungen, an denen Agenturen auch und gerade dann zuverlässig verdienen, wenn die Verbreitung und Nutzung der Software insgesamt steigt. Die Bereitstellung von Dokumentation kann damit rational sein, auch wenn sie selbst nicht direkt monetarisiert wird.

Allerdings ist dieser Anreiz ambivalent. Dieselben Agenturen haben zugleich ein Interesse daran, ihr spezifisches Erfahrungswissen nicht vollständig offenzulegen, da es einen Wettbewerbsvorteil darstellt. Die Bereitschaft zur Veröffentlichung hängt daher davon ab, in welchem Verhältnis die Vorteile einer erhöhten Marktnachfrage zu den Nachteilen eines möglichen Wissensabflusses stehen.

Vor dem Hintergrund der KI-Entwicklung verschiebt sich diese Situation möglicherweise. Wenn die Extraktion von Nutzungspfaden ohnehin zunehmend automatisierbar wird, sinkt der relative Vorteil, dieses Wissen vollständig exklusiv zu halten. Gleichzeitig steigt der Wert, sich als Referenzanbieter für strukturierte, verlässliche und anschlussfähige Dokumentation zu positionieren.

Die Finanzierung einer solchen Dokumentation erfolgt damit nicht direkt, sondern indirekt: über die Stärkung eines Marktes, in dem weiterführende Leistungen nachgefragt werden. Die Bereitstellung von Trampelpfad-Dokumentation wird so zu einer Investition in die eigene Nachfragebasis.

Die zentrale These lautet daher: Die Kosten der kuratierten Trampelpfad-Dokumentation werden von denjenigen Akteuren getragen, die ein Interesse daran haben, die Nutzung der Software insgesamt zu verbreitern und zu stabilisieren, weil sie an den daraus entstehenden Folgeaktivitäten partizipieren.

8. Anschlussarbeiten an dieses Papier

Das vorliegend Papier dient als internes Orientierungs- und Referenzdokument. Es beschreibt das Modell: Anwendungsebene, Orchestrierungsebene, Use Cases, Trampelpfade, Obsoleszenz, KI, Governance und Trägerschaft.

Aus dem Papier ergeben sich zwei Aufgaben.

Erstens lässt sich aus dem Papier ein Essay ableiten, in dem gezeigt wird, dass die Nutzung von CiviCRM nicht an fehlenden Funktionen scheitert, sondern an fehlender kollektiv zugänglicher Aneignungsfähigkeit, die ich an anderer Stelle als zweite Ebene einer suboptimalen Versorgung mit freier Open Source Software bezeichne. Dieses Essay liegt bereits unter dem Titel „Auf Trampelpfaden durch CiviCRM. Use-Cases, Aneignungsfähigkeit und kollektive Wissensinfrastruktur“ vor.  Eine kuratierte Trampelpfad-Dokumentation ist ein möglicher Weg, diese Unterversorgung zu bearbeiten.

Zweitens stellt sich die Aufgabe, eine operative Use-Case-Bibliothek aufzubauen. Sie beschreibt konkrete Nutzungspfade, priorisiert typische Aufgaben und übersetzt die hier entwickelte Theorie in handhabbare Arbeitsrezepte.

9. Konturen einer Use-Case-Bibliothek

Die aus diesem Arbeitspapier abzuleitende Use-Case-Bibliothek sollte nicht als vollständige Dokumentation aller Funktionen von CiviCRM angelegt werden, sondern als kuratierte Sammlung zentraler Aneignungspfade. Ausgangspunkt sind typische Aufgabenstellungen, die in unterschiedlichen organisatorischen Kontexten wiederkehren und für die sich in der Praxis stabile Trampelpfade herausgebildet haben. Ziel ist es, diese Pfade sichtbar zu machen, zu strukturieren und in einer Weise aufzubereiten, die ihre Wiederverwendung erleichtert.

Eine erste Ordnung dieser Bibliothek kann entlang zentraler Anwendungsbereiche erfolgen. Dazu zählen insbesondere:

  • die grundlegende Konfiguration einer Instanz nach der Installation,
  • das Arbeiten mit Kontakten und Beziehungen,
  • der Umgang mit Gruppen und Kommunikationsprozessen,
  • die Verwaltung von Zuwendungen einschließlich Spendenbescheinigungen,
  • die Organisation von Veranstaltungen,
  • die Verwaltung von Mitgliedschaften sowie
  • die Bearbeitung von Fällen beziehungsweise Vorgängen.

Ergänzend dazu treten bereichsübergreifende Werkzeuge wie SearchKit zur Auswertung und Orientierung im Datenbestand.

Neben diesen anwendungsbezogenen Bereichen ist eine zweite Dimension zu berücksichtigen: die Orchestrierung typischer Abläufe. Hierzu gehören insbesondere wiederkehrende Muster im Zusammenspiel von FormBuilder und FormProcessor zur Datenerfassung, von CiviRules zur ereignisgesteuerten Automatisierung sowie vom Search Action Designer zur Verarbeitung von Ergebnismengen. Auch die Nutzung von APIv4 als verbindendes Element komplexerer Abläufe kann Teil solcher Orchestrierungspfade sein.

Die Use-Case-Bibliothek sollte diese Muster nicht isoliert nach Werkzeugen darstellen, sondern entlang konkreter Aufgabenstellungen.

Didaktisch folgt die Bibliothek einem doppelten Prinzip: Sie soll einerseits konkrete Wege bereitstellen, die ohne vertiefte Systemkenntnis nachvollzogen werden können. Andererseits soll sie die zugrunde liegenden Strukturentscheidungen sichtbar machen, die diesen Wegen zugrunde liegen. Ziel ist es nicht nur, die Ausführung zu ermöglichen, sondern auch das Verständnis zu fördern, das notwendig ist, um von bestehenden Pfaden abweichen und eigene Lösungen entwickeln zu können.

Die Auswahl der aufgenommenen Use Cases erfolgt nicht nach dem Kriterium der Vollständigkeit, sondern nach ihrer Relevanz und Häufigkeit. Die Bibliothek bildet damit keine Gesamtsicht aller Möglichkeiten ab, sondern eine priorisierte Sicht auf das, was sich in der Praxis als tragfähig erwiesen hat. In diesem Sinne stellt sie eine kuratierte Verdichtung von Erfahrung dar und bildet die operative Entsprechung des in diesem Arbeitspapier entwickelten Modells.