CiviCRM ist eine freie Open-Source-Software für „Constituent Relationship Management“ oder auch „Citizen Relationship Management“, also für die Arbeit mit Kontakten und mit Vorgängen, die mit Kontakten in Verbindung stehen. CiviCRM stellt sehr viele mächtige Werkzeuge bereit, macht jedoch kaum Vorschläge zu Zwecksetzungen oder Arbeitsweisen.

Obwohl die Software seit über zwanzig Jahren entwickelt und weltweit eingesetzt wird, bleibt ihre praktische Aneignung bislang voraussetzungsvoll. Die Software ist nicht instruktiv. Mächtig wird sie vor allem in den Händen derjenigen, die bereits über das Wissen und die Methoden verfügen, wie und wozu solche Software eingesetzt wird. Entsprechend ist die vorhandene Dokumentation überwiegend feature-zentriert und entfaltet sich nur begrenzt entlang der Beschreibung einer realen Nutzungswirklichkeit.
Dieses Papier greift meine Überlegungen „Zur Überwindung einer suboptimalen Versorgung mit freier Open-Source-Software am Beispiel von CiviCRM“ auf. Weil eine Darstellung typischer Wege fehlt, wie Menschen ohne Vorkenntnisse organisatorische Probleme im Alltag mit CiviCRM lösen, bleiben Verbreitung und Nutzung der Software unter ihren Möglichkeiten.

Ich schlage daher zur Beschreibung funktionierender Wege der Nutzung den Begriff des „Trampelpfads“ („Desire Path“) als Leitmetapher vor. Trampelpfade entstehen dort, wo Menschen unter realen Bedingungen wiederholt ähnliche Wege gehen. Übertragen auf CiviCRM bezeichnet der Begriff mögliche, noch unbefestigte Wege, wie tatsächlich mit der Software gearbeitet wird und wie sie für konkrete Zwecke konfiguriert wird – etwa um Kontakte nachzuhalten, Beziehungen zu pflegen, Vorgänge zu verwalten, Veranstaltungen zu organisieren oder Spenden zu verwalten.

Ich unternehme den Versuch, Leitlinien für eine verbesserte Dokumentation zu entwickeln, indem ich vorschlage, die Software von den Trampelpfaden ihrer Nutzung her zu denken. Der Begriff des Trampelpfads ist bildhaft, weil sich die Nutzung durch Störungen kontinuierlich ändert. Obsoleszenz, Störungen oder Neuheiten verändern die Wege der Nutzung permanent. Jede Veränderung der Wirklichkeit, in der diese Pfade verlaufen, muss notwendig in ihre Kartierung zurückkoppeln, soll die Dokumentation aktuell bleiben. Im Folgenden suche ich nach einem einheitlichen Ansatz zur Beschreibung solcher Nutzungswirklichkeiten, identifiziere Muster tatsächlichen Handelns und entwickle Ideen für eine trampelpfadbasierte Dokumentation.

Das Papier beinhaltet darüber hinaus Überlegungen dazu, inwiefern eine solche Dokumentation nicht nur als Bestandteil der Aneignungsfähigkeit der Software und damit als Teil des Kollektivguts „CiviCRM“ verstanden werden muss, sondern zugleich als möglicher Referenzpunkt einer Governance-Struktur. Denn erst eine von der Anwendungswirklichkeit her gedachte Dokumentation ermöglicht es, die Auswirkungen von Entscheidungen in der Softwareentwicklung frühzeitig zu antizipieren und Anwender*innen als Betroffene solcher Entscheidungen die jeweils zur Entscheidung stehenden Fragen überhaupt erst nachvollziehbar zu machen und ihre intrinsische Motivation zur Mitwirkung an solchen Entscheidungsprozessen zu wecken.

Inhaltsverzeichnis

• 1. Die Suche nach Trampelpfaden
• 2. Die Wirklichkeit der Nutzung
  • 2.1 Verlustrisiken als Motiv von Anwendungsfallszenen
  • 2.2 Szenische Darstellung als Schlüssel zum Verständnis
• 3. Zehn Muster tatsächlichen Handelns
• 4. CiviCRM als Modellbaukasten: Use-Cases statt Funktionen
  • 4.1 Fünf Kriterien für gute Use-Cases
  • 4.2 Use-Cases als „Kochrezepte“
  • 4.3 Vom Einstieg zur Systembeherrschung
  • 4.4 Roadmap: Aufbau einer Trampelpfad-basierten Dokumentation
• 5. Strategische Einordnung: Aneignungsfähigkeit als kollektives Gut
  • 5.1 Aneignungsfähigkeit als unterversorgtes Kollektivgut
  • 5.2 Implementierungsagenturen im Spannungsfeld
  • 5.3 KI und die Zukunft der Dokumentation
  • 5.4 Trampelpfad-Dokumentation als Gegenbewegung
  • 5.5 Zwischen Commons und Clubgut
  • 5.6 Perspektive: Aneignung als gestaltbare Infrastruktur

1. Die Suche nach Trampelpfaden

Wer CiviCRM verstehen will, sollte nicht bei seinen Funktionen beginnen, sondern bei den Wegen, auf denen Menschen versuchen, mit CiviCRM reale organisatorische Aufgaben zu lösen.

Auf der Anwendungsebene begegnet man intuitiv verständlichen Entitäten: Kontakte, Aktivitäten, Beziehungen, Gruppen, Rundschreiben, Veranstaltungen, Zuwendungen und Fälle. Fälle sind Aktenvorgänge, d.h. Abfolgen von Aktivitäten, in die viele Kontakte involviert sein können.

Um mit diesen Entitäten zu arbeiten und sie miteinander in Beziehung zu setzen, benötigt man Funktionen der Orchestrierungsebene: Formulare bauen, Formulareingaben verarbeiten, Datenbestände als Listen aufbereiten, mit aufbereiteten Datenbeständen weiter arbeiten und Aufgaben automatisieren, um nur einige zu nennen.

Die Funktionen der Anwendungs- und Orchestrierungsebene ermöglichen dann die Umsetzung dessen, was auf der Ebene der Anwendungsfälle beschreibbar ist. Dies sind typische Aufgaben, die mit CiviCRM bearbeitet werden sollen. CiviCRM gibt sehr viele Möglichkeiten, aber nur in sehr begrenztem Umfang vordefinierte Lösungswege zu diesen Aufgaben vor.

CiviCRM bietet alle notwendigen Funktionen, bestimmt aber keinen eindeutigen Lösungsweg zur Bearbeitung einer Aufgabe. Sich CiviCRM zu erschließen bedeutet deshalb, angesichts vieler möglicher Lösungen die für den eigenen Anwendungsfall gangbaren Wege zu finden.

Die Nutzung von CiviCRM ist insofern eine Sache für Kundschafter und Pfadfinder, die Wege suchen und ausgetretene Trampelpfade („Desire Paths“) zu finden hoffen, zuverlässig zu gewünschten Ergebnissen zu gelangen. Die Herausforderung besteht darin, dass diese Trampelpfade nur unzureichend dokumentiert sind. Während die Software selbst frei verfügbar ist, fehlt es an einer ebenso frei zugänglichen, systematischen Darstellung ihrer Nutzung. Das Wissen um die Trampelpfade ist ungleich verteilt.

Dieses Papier entwickelt keinen vollständigen Katalog solcher Trampelpfade, sondern begründet, warum ihre systematische Dokumentation notwendig ist und wie eine solche Dokumentation aufgebaut werden könnte.

2. Die Wirklichkeit der Nutzung

Die Wirklichkeit der Nutzung von CiviCRM ist unspektakulär. Sie besteht aus alltäglichen Situationen, in denen Menschen versuchen, gemeinsam etwas zu organisieren – mit begrenzten Ressourcen, häufig ehrenamtlich und oft unter Zeitdruck.

Typische Situationen finden sich in vielen Zusammenhängen: in Vereinen, Parteien, Bürgerinitiativen, kirchlichen Gruppen, Organizing, Gemeinwesenarbeit, Stiftungen, Kampagnenorganisationen, in der Flüchtlingshilfe, in Bildungsprojekten, in der Koordination ehrenamtlicher Arbeit uvm. So unterschiedlich diese Kontexte erscheinen, so ähnlich sind die Herausforderungen, die in ihnen auftreten. Immer geht es darum, Beziehungen zwischen Menschen über Zeit hinweg zu organisieren und gemeinsam handlungsfähig zu werden. Diese Situationen lassen sich szenisch beschreiben.

2.1 Verlustrisiken als Motiv von Anwendungsfallszenen

Eine Person sitzt spät abends am Küchentisch und versucht, eine E-Mail-Liste zu vervollständigen. Namen fehlen, Adressen sind veraltet, Rückmeldungen wurden nicht systematisch festgehalten.
Ein Ehrenamtlicher steht auf einem Wochenmarkt, führt ein gutes Gespräch und nimmt sich vor, den Kontakt später nachzuhalten – ohne einen verlässlichen Ort zu haben, sich das zu notieren. In einem Verein geht eine Spende ein, die nicht eindeutig zugeordnet werden kann. Man möchte sich bedanken, verliert das aber aus den Augen. Nach einer Veranstaltung gibt es Interessierte, die sich weiter engagieren möchten. Zwei Monate später erinnert sich niemand mehr, wer das im Einzelnen gewesen ist. Eine Person meldet sich freiwillig, um zu helfen. Es gibt keine gemeinsame Struktur, die Sache aufzunehmen. Die Freiwillige erhält keine Rückmeldung. Drei Wochen später ist sie nicht mehr erreichbar.

Diese Szenen sind banal. Sie zeigen keine Ausnahmesituationen, sondern den Normalzustand organisatorischer Praxis. Weder mangelt es jeweils an Engagement oder Motivation, noch an Ideen. Auch fehlt es oft auch nicht an Ressourcen im engeren Sinne. Was fehlt, ist die Fähigkeit, das, was einmal vorhanden war, der Kontakt, die mit ihm verbundene Information, über Zeit hinweg anschlussfähig zu erhalten.

Die Szenen machen fünf Probleme sichtbar, die es zu bewältigen gilt.

1. Es geht Zeit verloren. Tätigkeiten werden doppelt ausgeführt, Informationen müssen gesucht oder rekonstruiert werden, Prozesse beginnen immer wieder von vorn. Zeitverlust ist der Preis fehlender Struktur.
2. Es geht Geld verloren – nicht notwendigerweise im Sinne eines direkten Verlusts, sondern im Sinne nicht realisierter Möglichkeiten. Spendenbereitschaft wird nicht bekannt, wird nicht nachgehalten, Unterstützer werden nicht gehalten, Förderchancen werden nicht genutzt.
3. Es gehen Möglichkeiten verloren. Interesse entsteht, Engagement wird angeboten, Beziehungen beginnen – und geraten wieder in Vergessenheit, weil es keine Notation gibt, die Beziehung zu pflegen. Möglichkeiten haben ein Zeitfenster, das sich ohne geeignete Struktur schnell wieder schließt.
4. Es geht Glaubwürdigkeit verloren. Schnell ist dahingesagt: „Wir melden uns“, und dann tut man es versehentlich doch nicht. Nicht aus bösem Willen, sondern weil es untergeht. Die Folge ist ein Verlust an Glaubwürdigkeit, der über den einzelnen Vorgang hinausreicht.
5. Es geht Wissen verloren. Nicht nur das Wissen, wer Interesse zeigt oder engagiert ist, es geht auch um den Zugang zu Personen und um das an sie gebundene Wissen und ihre Handlungspotentiale.

Die fünf Arten von Verlust – Zeit, Geld, Möglichkeit, Glaubwürdigkeit und Wissen – sind miteinander verbunden. Sie verstärken sich gegenseitig. Zur Ressourcenschwäche einer mit guten Absichten verfolgten Sache kommt hinzu, dass man ohne Struktur rasch wieder verliert, was mühsam erarbeitet und eigentlich vorhanden ist.

2.2 Szenische Darstellung als Schlüssel zum Verständnis

Auch die historische Entwicklung von CiviCRM wird gut nachvollziehbar, wenn man sie sich szenisch vorstellt. Die Komponenten und Erweiterungen von CiviCRM sind keine technischen Kategorien. Sie sind institutionelle Antworten auf wiederkehrende Alltagsaufgaben in Organisationen.

Einer Legende nach liegen die Ursprünge der Entwicklung von CiviCRM vor über 20 Jahren unter anderem im Haustürwahlkampf. In einem Haustürwahlkampf macht es sehr viel Sinn, Gespräche zu dokumentieren, um die im persönlichen Kontakt kennengelernten Sorgen und Nöte einzelner Haushalte in der politischen Arbeit aufgreifen zu können. Die Notwendigkeit, persönlich zu Betroffenen Kontakt zu halten, Anliegen als Vorgänge zu begreifen und Aktivitäten zu steuern, die sich auf die Stakeholder eines Vorgangs und die mit ihnen in Beziehung stehenden Anliegen beziehen, ist mit dem Beispiel eines Haustürwahlkampfs sehr gut illustrierbar.

Auch jede andere Funktion der Anwendungs- und Orchestrierungsebene hat einen solchen historischen Ausgangspunkt: Etwa die Schaffung der Möglichkeit, über ein Formular auf einer Webseite einen Newsletter zu abonnieren oder ein Anliegen vorzutragen. Der Versand von Rundschreiben, gleichgültig ob per Brief oder per E-Mail, setzt voraus, dass Verteiler-Gruppen definiert und Kontakte korrekt adressiert werden können. Und ohne die systematische Erfassung von Zuwendungen lassen sich keine Spenden bescheinigen. Die Organisation von Veranstaltungen erfordert die Verwaltung von Anmeldungen und Teilnahmen. Länger laufende Anliegen führen zur Entwicklung einer Vorgangsverwaltung. In CiviCRM ist das Beispiel der Wohnungslosenunterstützung als einer solchen wiederkehrenden Art von Vorgängen bekannt. Man spricht dann auch von „Fällen“, weil hier dann z.B. Fälle von Wohnungslosigkeit betreut werden.

3. Zehn Muster tatsächlichen Handelns

Die Sorge, Zeit, Geld, Möglichkeit, Glaubwürdigkeit und Wissen zu verlieren, zwingt uns, bestmögliche Wege zu finden, mit Situationen umzugehen, in denen solche Verluste drohen . In der Praxis entstehen solche Wege selten allein durch Planung. Meist improvisieren wir und zwar auch, weil sich das zu lösende Problem erst spät, lange nach der eigenen Planung zu erkennen gegeben hat. Durch die Wiederholung des einmal gefundenen Lösungsweges entstehen dann stabile Muster. Trampelpfade eben.

Solche Trampelpfade duch CiviCRM sind bislang nicht formal definiert. Sie sind wiederkehrende Problemlösungen, die sich unter den realen Bedingungen als praktikabel erwiesen haben, sie sind aber selten mehr als mündlich überliefert und zumeist nur als personengebundenes Wissen verfügbar. Typisch für einen Tampelpfad ist, dass er sich leicht verändert, wenn neue Hindernisse oder Möglichkeiten auf dem Weg auftauchen. Jeder Nutzer passt dann für sich individuell den Pfad an, ohne dass dadurch der veränderte Verlauf des Weges irgendwo dokumentiert werden würde. Unterschiedliche Organisationen können daher sehr ähnliche Trampelpfade entwickeln, selbst wenn sie unterschiedliche Werkzeuge oder Konfigurationen verwenden. Die Rückbindung veränderter Wegeführung der individuell gewählten Trampelpfade an eine von Trampelpfaden inspirierte Dokumentation ist insofern eine Sache einer gelingenden Governance der CiviCRM-Nutzer-Gemeinschaft.

Wer den Versuch unternehmen möchte, die Trampelpfade zu dokumentieren, wird die reale Nutzung von CiviCRM analysieren, um stabile Handlungsmuster zu identifizieren. Solche Handlungsmuster bilden den eigentlichen Kern der praktischen Aneignung von CiviCRM.

Es lassen sich mindestens zehn Muster unterscheiden.

1. Ein Kontakt entsteht, der nutzbar gemacht werden soll. Eine Person tritt in Erscheinung – durch eine spontane Begegnung, eine Veranstaltung oder ein Formular – und muss in eine Struktur überführt werden, die die weitere Arbeit mit diesem Kontakt ermöglicht. Ohne diesen Schritt bleiben alle weiteren Prozesse unmöglich.
2. Ereignisse müssen dokumentiert werden. Ein Gespräch, eine Anfrage oder eine Interaktion wird als Aktivität festgehalten oder – wenn sie sich über längere Zeit erstreckt und vielleicht mehrere Kontakte involviert sind – als Fall organisiert. Das Anlegen einer Akte oder eines Falles stellt den Unterschied dar zwischen einem isoliertem Ereignis und einem zusammenhängenden Prozess.
3. Verarbeitung von Eingaben. Formulare dienen dabei lediglich als Oberfläche. Die eigentliche Logik liegt in der strukturierten Verarbeitung der eingegebenen Daten: Es muss geprüft werden, ob der zugehörige Kontakt bereits besteht oder neu angelegt werden muss und es müssen dann Beziehungen hergestellt, Aktivitäten dokumentiert und die Sache der Eingabe hinterlegt werden: zum Beispiel die Geldzuwendung, die Information der Veranstaltungsteilnahme oder Informationen einen Fall betreffend. Angesichts dessen wird klar, dass es hinsichtlich der Verarbeitung von Eingaben sehr viele denkbare Trampelpfade gibt, je nachdem, was das Arbeitsfeld der Organisation ist, in deren Kontext man CiviCRM betreibt.
4. Übergang zur Automatisierung. Ereignisse im System lösen Aktionen aus: E-Mails werden versendet, der Status von Kontakten, Aktivitäten, Beziehungen, Zuwendungen, Veranstaltungsteilnahmen oder Fällen verändert sich. Gegebenfalls werden im Zuge dessen auch Dokumente erzeugt. Solche Automatisierungen sind vom System nur sporadisch vorgegeben. Sie müssen von den Benutzer*innen bezogen auf den Verwendungszusammenhang angelegt werden.
5. Erzeugung und Nutzung von Dokumenten. Bestätigungen, Bescheinigungen oder Verträge müssen erstellt und versendet werden.
6. Segmentierung. Organisationen müssen bestimmen, wer zu welcher Gruppe gehört, wer angesprochen wird und wer nicht. Diese Einordnung bildet die Grundlage für nahezu alle weiteren Prozesse, insbesondere für Kommunikation und Automatisierung.
7. Gezielte oder automatisierte Kommunikation. Einzelne Kontakte oder definierte Gruppen werden angesprochen, Reaktionen werden erfasst und wiederum in den Datenbestand zurückgeführt.
8. Modellierung von Zuständen. Prozesse verlaufen nicht statisch, sondern durchlaufen Zustände: offen, in Bearbeitung, abgeschlossen. Diese Zustände zu definieren und nachzuhalten, ist entscheidend, um Wiederholungen, Fehler und doppelte Arbeit zu vermeiden.
9. CiviCRM mit anderen Systemen verbinden. Die realen Arbeitsabläufe gehen häufig über die Grenzen eines einzelnen Systems hinaus. Zum Beispiel, wenn Lastschriftmandate an die Bank übergeben werden, Buchhaltungsdaten an die Buchhaltung oder auch Informationen zur Berechtigung von Kontakten in anderen Systemen. Daten werden dann weitergegeben, Prozesse angestoßen oder externe Systeme integriert.
10. Debugging und Verstehen des Systems selbst. Nutzerinnen und Nutzer entwickeln Wege, um herauszufinden, was im System geschieht, warum bestimmte Dinge funktionieren oder nicht funktionieren und wie sich Fehler beheben lassen.

Diese Muster haben eine gemeinsame Eigenschaft: Sie sind nicht eindeutig festgelegt. Für viele dieser Probleme existieren mehrere mögliche Lösungswege, die jeweils aus unterschiedlichen historischen Kontexten hervorgegangen sind. So kann etwa eine Anfrage als Aktivität oder als Fall modelliert werden, eine Automatisierung über unterschiedliche Werkzeuge erfolgen oder eine Segmentierung über verschiedene Mechanismen umgesetzt werden.

Die Praxis ist daher nicht durch klare Vorgaben der Software geprägt, sondern durch die Koexistenz konkurrierender Trampelpfade, auf denen Nutzerinnen und Nutzer versuchen, mit der Software tragfähige Lösungen zu finden. Diese Offenheit des Systems führt jedoch dazu, dass Nutzerinnen und Nutzer vor einer Vielzahl plausibler Möglichkeiten stehen, ohne Orientierung darüber, welche sich in der Praxis bewährt haben. Genau hier liegt der Ansatzpunkt für eine trampelpfadbasierte Dokumentation, die tatsächlich existierenden Trampelpfade sichtbar zu machen, ihre Unterschiede zu erklären und auf dieser Grundlage begründete Hauptpfade zu formulieren. Diese Vorgehensweise ermöglicht eine doppelte Struktur: Für jeden relevanten Anwendungsfall wird ein kuratierter Hauptpfad beschrieben, der als stabil und lehrbar gilt. Zugleich bleibt sichtbar, dass alternative Wege existieren und es existiert durch den Hauptpfad ein Bezugspunkt, um die Bedingungen zu bestimmen, unter denen ein Abweichen vom Hauptpfad sinnvoll sein kann. Der Vorteil dieser Vorgehensweise: Sie ermöglicht es, die Komplexität des CiviCRM zu reduzieren und beherrschbar zu machen, ohne die Anpassungsfähigkeit und universelle Verwendbarkeit des Systems einzuschränken.

4. CiviCRM als Modellbaukasten: Use-Cases statt Funktionen

Überführt man die erfahrungsbasierten, meist nirgends niedergeschriebenen Nutzungsmuster in eine reproduzierbare und lehrbare Form, so erhält man eine Use-Case-Bibliothek. Die Aneignung und Nutzung von CiviCRM verändert sich dann. Beiträge der Use-Case-Bibliothek beschreiben nicht, was CiviCRM kann, sondern wie typische organisatorische Probleme unter realen Bedingungen mit CiviCRM gelöst werden. Der Gegenstand solch einer Dokumentation sind deshalb Trampelpfade der wirklich funktionierenden Benutzung.

Die grundlegenden Bausteine von CiviCRM lassen sich dabei auf ein begrenztes Set von Daten- und Handlungslogiken reduzieren: Kontakte, Beziehungen, Aktivitäten, Gruppen, E-Mail-Kommunikation, Verwaltung von Vorgängen oder Themen – in Form von Fällen -, Veranstaltungsorganisation und zuletzt Verwaltung von Zuwendungen. Diese Elemente strukturieren soziale Realität. Wer mit ihnen arbeitet, verändert Zustände, weil er die Elemente über Zeit hinweg kombiniert und versteht.

Auch eine Use-Case-Bibliothek benötigt einen synoptischen Überblick über die Funktionsbereiche von CiviCRM, d.h. sowohl über die Funktionsbereiche der Anwendungsebene, als auch über die Funktionsbereiche der Orchestrierungsebene. Dies ist sinnvoll, um dem Lerner Orientierung zu geben, was an Werkzeugen überhaupt zur Verfügung steht und um zu verstehen, wie er sie für sich selbst einordnen und priorisieren kann.

4.1 Fünf Kriterien für gute Use-Cases

Die Use-Cases müssen fünf Kriterien genügen, die über einen Funktionsüberblick oder eine bloße Funktionsbeschreibung hinausgehen:

1. Ausgangspunkt sind wiederkehrende Situationen, nicht Funktionen.
   Jeder Use-Case beginnt mit einer konkreten Handlungssituation, wie sie im vorangegangenen Abschnitt beschrieben wurde.
2. Jeder Use-Case bildet einen Trampelpfad ab.
   Er beschreibt einen stabilen Weg, wie eine solche Situation typischerweise mit vorhandenen Mitteln gelöst wird.
3. Jeder Trampelpfad wird als Kombination von Grundlogiken dargestellt.
   Es wird explizit gemacht, welche Entitäten beteiligt sind, welche Prozesse stattfinden und welche Entscheidungen getroffen werden.
4. Für jeden Use-Case werden alternative Pfade sichtbar gemacht.
   Die Dokumentation legt zwar einen Weg fest, aber sie zeigt sich durch ihre ausdrückliche Begrenzung und durch Ausblicke, dass auch andere Wege existieren und unter welchen Bedingungen sie sinnvoll sein können.
5. Die zugrunde liegenden Strukturentscheidungen werden erklärt.
   Es wird nicht nur gezeigt, wie etwas funktioniert, sondern warum eine bestimmte Modellierung gewählt wird.

4.2 Use-Cases als „Kochrezepte“

Ein Kochrezept beantwortet zwei einfache Fragen: „Was will ich erreichen? Wie gehe ich vor?“ Es beschreibt das Ziel und erklärt die Vorgehensweise in klaren, nachvollziehbaren Schritten.

Auch für CiviCRM benötigt man solche Kochrezepte.

Typische Beispiele sind:

1. das initiale Einrichten von CiviCRM, um arbeitsfähig zu werden
2. die Konfiguration der Anbindung an einen E-Mail-Server und die Verwendung von E-Mail-Adressen
3. wie man bestehende Kontaktdaten und andere Daten in CiviCRM importiert
4. die Erstellung eines Webformulars, das auf einer beliebigen Webseite eingebunden wird und dann Daten an CiviCRM übermittelt, z.B.
   1. die Anmeldung zu einem Newsletter
   2. die Anmeldung zu einer Veranstaltung
   3. das Entrichten einer Spende über ein Formular
5. die Verknüpfung mit einem Fundraising- und Zahlungsabwicklungsdienstleister wie bspw. Twingle, PayPal oder Stripe
6. das Einrichten einer Online-Spende
7. die Umsetzung der Sammlung und Einreichung von SEPA-Lastschriften
8. die Organisation einer Veranstaltungsanmeldung
9. der Versand eines Newsletters
10. das Anlegen eines Falles, ggf. aus Formulardaten, der also aus einem einreichenden Kontakt und aus den die Sache beschreibenden Daten besteht.

Diese Kochrezepte sind bereits Trampelpfade. Und sie bleiben nicht isoliert. Vielmehr stellen sie teils entweder selbst Verknüpfungen mehrerer eigenständiger Trampelpfade dar, oder aber, sie sind offen für die Verknüpfung mit anderen. Das wird in der Liste oben bereits erkennbar: Um einen Fall aus einer Formulareingabe eines Webseitenbenutzers zu erzeugen, müssen bereits mehrere solcher Pfade gegangen werden.

Jedes Kochrezept kann mit einem die gewonnene Erkenntnis sichernden Kapitel abgeschlossen werden. Nach der praktischen Anleitung stellt sich die Frage: Was passiert hier eigentlich? Hier wird der Use-Case analytisch aufgeschlüsselt. Die beteiligten Entitäten, Prozesse und Entscheidungen werden sichtbar gemacht. Dadurch wird aus einer bloßen Anleitung ein Lerngegenstand. Diese doppelte Struktur – Ausführung und Verständnis – ist zentral für die dauerhafte Befähigung der Nutzerinnen und Nutzer, die nicht nur handlungsfähig werden, sondern auch durch Reflektion verstehen lernen, was sie da eigentlich, technisch gesehen tun.

4.3 Vom Einstieg zur Systembeherrschung

Die Rezepte der Use-Case-Bibliothek kann man nach Schwierigkeitsgrad aufeinander aufbauend sortieren. Am Anfang stehen einfache und häufige Anwendungsfälle mit leichten und rasch zubereitbaren Rezepten. Darauf aufbauend werden komplexere Trampelpfade eingeführt, die mehrere Rezepte kombinieren.

Während Einsteiger auf diese Weise zunächst einzelne Elemente verstehen, lernen fortgeschrittene Nutzerinnen und Nutzer, diese Elemente zu vollständigen Abläufen zu kombinieren. Insbesondere die weniger intuitiv zugänglichen Werkzeuge der Orchestrierungsebene, wie FormBuilder, FormProcessor, SearchKit, CiviRules oder der Search Action Designer treten dann nicht als isolierte Funktionen auf, sondern als Mittel zur Kombination von Rezepten.

4.4 Roadmap: Aufbau einer Trampelpfad-basierten Dokumentation

Die Entwicklung einer solchen Use-Case-Bibliothek lässt sich selbst als Prozess beschreiben.

1. typische Nutzungssituationen identifizieren und in Form von Szenen beschreiben.
2. Daraus hervorgehende Trampelpfade rekonstruieren: Wie läuft es denn üblicherweise?
3. Pfade bündeln, vergleichen und priorisieren
4. Ausarbeitung in Form von Use-Cases und Kochrezepten.
5. Kontinuierliche Prüfung und Überarbeitung der „Wanderkarten“, idealerweise in Folge von Vormeldungen kommender Veränderungen durch die Maintainer der Komponenten oder aus der in der Governance-Struktur der Community organisierten Benutzer*innen

Dieser Prozess ist nicht einmalig, sondern iterativ. Trampelpfade verändern sich, neue entstehen, bestehende verlieren an Bedeutung. Die Use-Case-Bibliothek wird damit selbst zu einem dynamischen Element der Wissensinfrastruktur.

5. Strategische Einordnung: Aneignungsfähigkeit als kollektives Gut

Die vorangegangenen Abschnitte erläutern einen Ansatz, Benutzer*innen die praktische Aneignung von CiviCRM zu erleichtern. Die Verbesserung der Aneignungsfähigkeit ist jedoch kein individuelles Problem einzelner Nutzerinnen und Nutzer, sondern ein strukturelles Phänomen, das sich als ein kollektives Gut beschreiben lässt.

5.1 Aneignungsfähigkeit als unterversorgtes Kollektivgut

Die Fähigkeit, typische Nutzungssituationen zuverlässig zu bewältigen, entsteht nicht automatisch durch die Nutzung der Software. Sie ist nicht selbst erklärend und sie kann das vermutlich angesichts ihres vergleichsweise großen Funktionsumfangs und der Komplexität der möglichen Verwendungszusammenhänge auch kaum sein.

Die Aneignungsfähigkeit beruht auf der Verfügbarkeit von Wissen: darüber, welche Aufgaben typischerweise gelöst werden sollen, welche Probleme dabei üblicherweise auftreten, welche Lösungswege sich bewährt haben und wie diese Wege konkret umgesetzt werden können.

Dieses Wissen ist in der Praxis vorhanden – in Form von Erfahrungen, impliziten Routinen und organisationalem Gedächtnis. Es ist jedoch selten systematisch dokumentiert und öffentlich zugänglich. Damit entsteht eine klassische Konstellation: Viele profitieren von einer verbesserten Dokumentation und Schulung, aber nur wenige haben unmittelbare Anreize, diese bereitzustellen. Das Ergebnis ist eine strukturelle Unterversorgung, mit der Konsequenz hoher Einstiegsbarrieren, wiederkehrende Fehler, ineffizienter Arbeitsweisen und der Verstetigung des systematischen Verlusts von Zeit, Geld, Möglichkeiten, Wissen und Vertrauen, weil verfügbare Software nicht zur Anwendung kommt, obwohl sie kostengünstig verfügbar ist.

5.2 Implementierungsagenturen im Spannungsfeld

In dieser Situation kommt auf CiviCRM spezialisierten Implementierungsagenturen eine besondere Rolle zu. Sie verfügen über genau jene Erfahrungsbestände, aus denen sich Trampelpfade rekonstruieren lassen: Projektdokumentationen, Supportanfragen, Konfigurationen und wiederkehrende Anwendungsfälle.

Gleichzeitig befinden sie sich in einem Spannungsfeld.

Einerseits haben sie ein Interesse daran, die Aneignungsfähigkeit von CiviCRM zu verbessern. Eine bessere Dokumentation senkt Einstiegshürden, erhöht die Verbreitung der Software und schafft Nachfrage nach weiterführenden Leistungen wie Hosting, Betrieb, Support und Beratung. Andererseits stellt genau dieses Wissen einen Wettbewerbsvorteil dar. Wer über erprobte Lösungswege verfügt, kann Projekte effizienter umsetzen und sich im Markt differenzieren. Die vollständige Offenlegung dieses Wissens kann daher als Risiko erscheinen.

Diese Ambivalenz führt dazu, dass Wissen über Trampelpfade häufig nur partiell oder gar nicht veröffentlicht wird. Es gibt schlicht und ergreifend keinen Anreiz, dieses Wissen strukturiert preiszugeben. Es bleibt in den Organisationen gebunden und ist für Außenstehende nicht oder nur begrenzt zugänglich. Die Folge ist ein Gleichgewicht, das stabil, aber für die breite Masse möglicher Anwender*innen suboptimal ist: Die Aneignungsfähigkeit wird nicht in dem Maße bereitgestellt, wie es gesellschaftlich sinnvoll wäre.

5.3 KI und die Zukunft der Dokumentation

Mit dem Aufkommen von KI-Systemen verändert sich diese Konstellation, ohne dass das zugrunde liegende Problem gelöst wird. Auf individueller Ebene kann KI Aneignungsprozesse erleichtern. Sie kann Fragen beantworten, wahrscheinliche Lösungsansätze vorschlagen und dabei helfen, konkrete Probleme situativ zu bewältigen. In diesem Sinne wirkt sie als funktionaler Ersatz für fehlende Dokumentation. Auf struktureller Ebene bleibt jedoch ein entscheidender Mangel bestehen:
KI kann nicht zwischen denkbaren bzw. wahrscheinlichen Lösungen und stabilen, bewährten Trampelpfaden unterscheiden. KI kennt diese bewährten Lösungswege genau so lange nicht, solange sie nicht von Benutzer*innen auf der Basis tatsächlicher Erfahrung dokumentiert und als wiederholt bewährt kenntlich gemacht werden.

Ohne eine explizite Referenzstruktur aber fehlt die Möglichkeit, Lösungen einzuordnen und zu bewerten. Die individuelle Aneignung der Software mag durch KI erleichtert werden, aber noch immer entsteht dadurch keine kollektive Wissensbasis und auch keine Governance-Struktur, die die die Dokumentation der Trampelpfade zu den Entscheidungen in der Softwarenentwicklung und den Erfahrungen in der Anwendungspraxis in Beziehung setzt.

Allerdings eröffnet KI neue Möglichkeiten auf Seiten der Implementierungsagenturen. Sie können ihre eigenen Datenbestände systematisch auswerten und daraus Trampelpfade extrahieren. Damit steigt die Wahrscheinlichkeit, dass sich das in den Implementierungsagenturen geborgene Wissen über Nutzungspfade wesentlich besser verfügbar und für diese strategisch nutzbar wird. Dies kann zu einer weiteren Verschiebung führen: Das zur Aneignung notwendige Wissen bleibt so gesehen nicht nur knapp, es wird potenziell auch aus geschäftsstrategischen Erwägungen stärker privatisiert.

5.4 Trampelpfad-Dokumentation als Gegenbewegung

Vor diesem Hintergrund erhält eine öffentlich kuratierte Dokumentation von Trampelpfaden eine strategische und gesellschaftliche Bedeutung. Sie stellt eine Form von Wissensinfrastruktur dar, die der strukturellen Unterversorgung entgegenwirkt. Indem sie implizites Erfahrungswissen explizit macht und zugänglich gestaltet, trägt sie dazu bei, Aneignungsfähigkeit als kollektives Gut bereitzustellen.

Dabei geht es nicht nur um die Bereitstellung von Informationen. Die Dokumentation wirkt selbst gestaltend. Sie macht bestimmte Wege sichtbar, stabilisiert sie und schafft Orientierung. In diesem Sinne übernimmt sie eine Funktion, die über klassische Dokumentation hinausgeht. Sie beeinflusst, wie die Software genutzt wird, indem sie die Trampelpfade zu institutionalisierten Wegen erweitert.

5.5 Zwischen Commons und Clubgut

Die Frage nach der Trägerschaft dieser Dokumentation ist offen. Anreize zur Bereitstellung sind vorhanden, aber ambivalent. Einerseits spricht vieles dafür, Trampelpfad-Dokumentation als öffentliches Gut zu organisieren. Sie erhöht die Gesamtfähigkeit zur Nutzung von CiviCRM, senkt Einstiegshürden und verbessert die Effizienz organisationaler Praxis. Andererseits erzeugen die Kosten der Pflege von Wissen Anreize, dieses Wissen als Clubgut bspw. in einem Vereion zu organisieren und dadurch eher exklusiv nutzbar zu machen.

Die tatsächliche Entwicklung wird vermutlich zwischen diesen beiden Polen verlaufen. Entscheidend ist nicht, eine vollständige Lösung zu anzustreben, sondern konkrete Schritte zu unternehmen, die in Richtung einer besseren Versorgung mit Aneignungsfähigkeit wirken. Da so verfügbar werdende Wissen wird dann ehedem tendentiell zu einem Teil des Kollektivguts werden, sobald es in die von der Community gepflegten Kernsysteme Einzug hält, die entweder direkt oder mittelbar der AGPLv3-Lizensierung unterworfen oder verpflichtet sind.

Mir erscheint es insofern sinnvoll, eine Doppelstrategie zu verfolgen.

Im Interesse der Nachhaltigkeit, der Bejahung vorhandener Strukturen und der Stärkung der Governance sollte man daran arbeiten, die unter https://docs.civicrm.org verfügbare Dokumentation vollständig durchzusehen, im Sinne der Trampelpfad-Idee zu erweitern und wo sinnvoll zu überarbeiten um Anschlussfähigkeit an die Wirklichkeit der Trampelpfade herzustellen.

Eine für die Community der potentiellen Anwender*innen von CiviCRM potentiell nachteilige Herausforderung besteht bei dieser Dokumentation allerdings daran, dass sie git-basiert auf der Basis von Markdown-Dateien gepflegt wird, einen Zugang zu der von der CiviCRM-Community gepflegten Gitlab-Instanz sowie das Wissen um das Arbeiten mit Git voraussetzt. Siehe dazu https://docs.civicrm.org/dev/en/latest/documentation/

Für die allermeisten Anwender*innen stellt dies eine Überforderung dar und also eine sehr hohe Hürde, sich zu beteiligen. Will man die Dokumentation von Trampelpfaden u.a. auch als Scharnierstelle der Governance ernst nehmen, wird man eine komplementäre, niedrigschwelligere Alternative entwickeln müssen, sich an der Dokumentation aus Anwender*innen-Sicht zu beteiligen.

5.6 Perspektive: Die Frage der Aneignung als Teil des Kollektivguts und seiner Governance

Die Frage, wie CiviCRM dokumentiert und vermittelt wird, ist nicht nur eine technische oder didaktische Frage. Sie ist eine Frage der Organisation von Wissen – und damit eine Frage von Governance.

Die Entwicklung einer trampelpfadbasierten Use-Case-Bibliothek ist meines Erachtens ein integraler Bestandteil der Versorgung mit CiviCRM als freier Software, insofern sie die Eigenschaft der Aneigungsfähigkeit als Kollektivgut verfügbar und kollektiv bearbeitbar macht. Sie verbindet die durch die Software gebotenen technischen Möglichkeiten mit der Wirklichkeit sozialer Praxis und die individuelle Nutzung mit kollektiver Wissensbildung.

 

---

Grafik: „Desire Paths“. London 2025, mit freundlicher Genehmigung von Chaz Hutton, https://chazhutton.com