In diesem Essay beschreibe ich, wie Mitglieder eines politischen Vereins (z.B. einer politischen Partei, eines Verbands, einer Initiative, usw.), politisch ambitionierte Personen, Social Entrepreneure oder Mitarbeiter*innen partikularinteressenvertretender Agenturen, „Constituent Relationship Management“ oder auch „Citizen Relationship Management“ mittels der Software CiviCRM nutzen können, um (1) Organisationen und Personen als Anspruchshalter (stakeholder) in politischen Arenen zu erfassen und (2) deren Ansprüche (stakes) in Arenen oder an Themen (issues), die in diesen Arenen bearbeitet werden. CiviCRM wird dabei zu einem Teil der alltäglich genutzten Infrastruktur politischer Arbeit, in der eine beliebige Anzahl an Nutzer*innen in unterschiedlichen Rollen zu einer beliebigen Anzahl an Themen und Ereignissen zusammenarbeiten können.

Inhaltsverzeichnis

• 1. Einführung
  • 1.1 CiviCRM als Werkzeug politischer Arbeit
  • 1.2 Stakeholder Management mit CiviCRM
  • 1.3 Konzeptionelle Grundlagen
• 2. Basiskonzept: Organisationen, Personen und Gremien
• 3. Stakeholder: Kontakte mit Ansprüchen
• 4. Politikfelder, Arenen und die Bedeutung von Stakeholdern
  • 4.1 Politikfelder als schlagwortartige Themenkategorien
  • 4.2 Arenen als Räume des Handelns
  • 4.3 Bedeutung von Stakeholdern in einer Arena
• 5. Themen als in Arenen zur Verhandlung stehende Sachen

1. Einführung

1.1 CiviCRM als Werkzeug politischer Arbeit

CiviCRM wird meist als Werkzeug für operative Aufgaben wie die Abwicklung eines E-Mail-Massenversands, die Erstellung von Serienbriefen oder die Termin- und Aktivitätenplanung genutzt. Die Möglichkeit, in CiviCRM Kontakte sowie Beziehungen zwischen diesen Kontakten zu verwalten, dient vielen Anwender*innen meist als leistungsstarkes Adressbuch und zur Gruppierung von Adressatenkreisen.

Hinzu kommen Funktionen für Sekundärprozesse einer Organisation, wie etwa die Einwerbung, Bescheinigung und Verwaltung finanzieller Zuwendungen (CiviContribute), die Verwaltung von Mitgliedern (CiviMember) oder auch die Organisation von Veranstaltungen (CiviEvent) vom Einladungs- und Anmeldeverfahren bis hin zur Verwaltung von Teilnehmenden, der Abrechnung von Teilnahmegebühren oder die Bescheinigung von Teilnahmen.

CiviCRM kann aber nicht nur auf der Wertschöpfungsstufe der Operation oder für Sekundärprozesse der Organisation eingesetzt werden, sondern entlang der gesamten Wertkette politischer Arbeit:

Als Ort der Sammlung von Berichten, als Medium der internen Verbreitung verfügbar werdender Informationen zu Stakeholdern, als Verweisssammlung auf Analysen und laufende Diskussionen (bspw. in Foren und Gremien), als Bezugspunkt der informierten Diskussion und – erst dadurch – als Werkzeug zur Planung und Steuerung kommunikativen Handelns bis hin zu Kampagnen, die dann eben mit den oben erwähnten Funktionen der Software umgesetzt werden können.

Durch ihre Mehrbenutzerfähigkeit ist die Software hervorragend geeignet für arbeitsteiliges Arbeiten im Bereich des Stakeholder und Issue Managements. So entsteht in CiviCRM die Informationsgrundlage für Analysen und Entscheidungen.

1.2 Stakeholder Management mit CiviCRM

CiviCRM gestattet es, alle verfügbar werdenden Informationen zentral zu verwalten und das Beziehungsgeflecht zwischen Organsiationen, Personen, Gremien, Arenen und verhandelten Sachen dokumentierbar, historisierbar und durchsuchbar zu machen.

Entlang der Wertkette politischer Arbeit werden Informationen zu folgenden Fragen verarbeitet:

• Welche Stakeholder sind in welcher Arena relevant?
• Welchen Anteil und welche Ansprüche (stakes) haben sie dort – inhaltlich, aber auch in Form von Macht, Legitimität, Dringlichkeit, Einfluss?
• Welche Gremien sind für eine Arena entscheidend?
• Welche Sachen (issues) werden gerade verhandelt – und durch wen?
• Was geschieht und was wird geschehen?

In einer Praxis, in der keine Software wie CiviCRM eingesetzt wird, fehlt oft

• ein einheitliches Datenmodell,
• ein verlässlicher Überblick über Stakeholder im Politikzyklus
• die Möglichkeit, Beziehungen mit Attributen (z. B. Kontrolle über bestimmte Ressourcen) zu beschreiben und die Beziehungsstruktur in einer Arena zu analysieren,
• eine Struktur zur leistbaren Handhabung von Informationen zu allen Facetten von Akteuren, Ereignissen und Prozessen – auch über verschiedene Arenen hinweg,

1.3 Konzeptionelle Grundlagen

Konzeptionell besteht der Ansatz des Folgenden darin, ähnlich wie juristische Personen auch Arenen und Gremien als „Organisationen“ zu verstehen und in CiviCRM technisch als Unterkontaktarten zu behandeln, sodass Ansprüche bzw. Anteile an Politik (stakes) als Beziehungen von Organisations- oder Personenkontakten zu Arenen und Gremien abgebildet und beschrieben werden können.

Ein Anteil/Anspruch (stake) wird durch ein Bündel an Eigenschaften der Beziehung des Anspruchshalters zu einer Arena oder einem Thema beschrieben. Zu diesen Eigenschaften zählen

(a) eine freitextliche Beschreibung des Anspruchs

(b) eine Einschätzung zur Bedeutung (salience) per Ordinal- oder Nominalskala, mittels der Attribute wie Macht, Legitimität, Dringlichkeit oder Einfluss des Anteils am Geschehen beschrieben wird.

Beziehungstypen, die sich zur Beschreibung von Beziehungen von Kontakten zu Arenen verwenden lassen, können auch verwendet werden, um Ansprüche von Kontakten an konkrete Themen („issues“) zu beschreiben, die ihrerseit mit dem CiviCRM-Fallmanagement (CiviCase) verwaltet werden.

Für jede einzelne Anspruchshalter-Arena-Beziehung oder Anspruchshalter-Themen-Beziehung kann eine inhaltliche Beschreibung und eine Beschreibung von Salience gepflegt werden. Damit wird es möglich, das Geschehen in einer Arena, einem Politikfeld und in einer konkreten Sache (issue) abzubilden und es ist möglich, auf der Basis der genauen Kenntnis der involvierten Anspruchshalter Analysen und Szenarien zu entwerfen, bei der Arbeit mit Anspruchshaltern zu priorisieren und das eigene kommunikative Handeln zu steuern.

Im folgenden erörtere ich, wie das Konzept des Stakeholdermanagements alltagstauglich und praktikabel im Datenmodell von CiviCRM abgebildet und wie hierauf aufbauend CiviCRM für Issue Management eingesetzt werden kann.

2. Basiskonzept: Organisationen, Personen und Gremien

Üblicherweise wird das Datenmodell von CiviCRM zur Abbildung von Beziehungen zwischen Organisationskontakten (juristischen Personen) und Personenkontakten (natürlichen Personen) verwendet.

Dieses Modell lässt sich um einen Entitätstyp wie „Gremien“ erweitern. Entweder, indem die Art einer Beziehung zu einer Organisation das Vorhandensein eines Gremiums impliziert (mit Beziehungstypen wie bspw „ist Vorstandsmitglied von“ usw.) oder explizit, indem Gremien als Unterkontaktart vom Kontakttyp „Organisation“ angelegt werden, sodass Gremien als eigenständige Organisationen existieren, die ihrerseits wiederum in Beziehungen mit anderen Organisationen stehen können.

Das Datenmodell von CiviCRM legt es nahe, Gremien als Kontakte anzulegen und dann mit Hilfe von Beziehungen zu dokumentieren, welche Rollen und Funktionen (einschließlich Eigenschaften sowie Start- und Enddatum) Organisations- und Personenkontakte in Gremien inne haben. Erstens wird damit das Eigenleben von Gremein abbildbar. Das auf ein Gremium bezogene Handeln kann und der Anteil von Gremien an Arenen oder Issues wird verwaltbar. Auch wird die Historie von Gremienzugehörigkeiten von Personen dokumentierbar.

Schaubild 1: Basismodell Organisation – Person – Gremium

Hierfür können Beziehungstypen für die Beziehung (a) zwischen Organsisationen und Personen, für die Beziehung (b) zwischen Person und Gremium und für die Beziehung (c) zwischen Organisation und Gremium definiert werden.

Zum Beispiel steht eine Person in Beziehung mit einer Organisation (z.B. als a = „Arbeitgeber von / arbeitet bei“), in einer Beziehung zu einem Gremium (z.B. b = „Betriebsrat von / Betriebsratsmitglied von“), wobei das Gremium ggf. zurückwirkt auf die Organisation (z.B. c =„organisiert durch Betriebsrat / Betriebsrat des Betriebs“).

Beziehungstypen können in CiviCRM mit beziehungstypspezifischen Eigenschaften versehen werden, bei einer Gremienmitgliedschaft z.B. mit einer Beschreibung des Stimmrechts, des Stimmgewichts uvm.

3. Stakeholder: Kontakte mit Ansprüchen

Organisationen oder Personen werden erst in Kontexten zu Stakeholdern (Anspruchshaltern). Sie sind erst dann Stakeholder, wenn sie Ansprüche innerhalb einer Polity haben, d.h. in einer Arena verortet werden können, in der ihre Sozialbeziehungen institutionalisiert gefasst sind und dort mit einem Politikfeld und/oder einer konkreten Sache (issue) in Verbindung gebracht werden können. Im Sinne des Datenmodells von CiviCRM handelt es sich bei Ansprüchen ebenfalls um Beziehungen.

Ansprüche von Stakeholdern haben auch eine zeitliche Dimension. Der Anspruch eines Kontakts entsteht (Startzeitpunkt), vergeht (Endzeitpunkt), ist beschreibbar und archivierbar. Wandelt ein Anspruch sich, kann dies als Ende eines bisherigen und den Beginn eines neuen Anspruchs aufgefasst werden. Ergo gibt es auch eine Geschichte der Ansprüche je Stakeholder.

4. Politikfelder, Arenen und die Bedeutung von Stakeholdern

Das Datenmodell von CiviCRM gestattet eine konzeptionell saubere Unterscheidung zwischen Politikfeld, Arena und Thema.

4.1 Politikfelder als schlagwortartige Themenkategorien

Ein „Politikfeld“ (synonym für Themenfeld) bezeichnet ein in Themen untergliederten Bereich, in dem thematisch ähnliche Probleme, Lösungsansätze und Aufgaben bearbeitet werden.

Die rein typologisierend verwendete Kategorie des „Politikfeld“ ist eher deskriptiver Natur, dient als Sammelbegriff und unterliegt anders als die Kategorie der „Arena“ stark der situativen Interpretation und Sprachmode.

Für die Zurechnung von Organisations- und Personenkontakten sowie Gremien und Arenen zu Politikfeldern bietet sich im Datenmodell von CiviCRM das Schlagwortsystem („Tags“) an. Dies auch, weil das Schlagwortmanagement in CiviCRM bedeutend flexibler gehandhabt werden kann, als die Verwaltung von Optionen in Dropdown-Menüs.

Da Tags hierarchisch strukturiert werden können, können Themenfelder in Ober- und Unterkategorien gegliedert werden. In CiviCRM werden Schlagworte systemweit zentral verwaltet. Dies stellt eine systemweit benutzerübergreifend einheitliche Verwendung von Schlagworten sicher.

4.2 Arenen als Räume des Handelns

Im Gegensatz zur Kategorie des „Politikfelds“ ist eine „Arena“ der territoriale, soziale und durch Normen geregelte Raum der Verhandlung und Umsetzung. Organsationen und Personen können zu einer beliebigen Anzahl an Arenen in Verbindung stehen. Auch können in einer Arena verschiedene Gremien existieren oder für die Arena verschiedene Gremien relevant sein.

Um diese sehr konkret fassbare Kategorie der „Arena“ im Datenmodell von CiviCRM abzubilden, bietet es sich an, eine Unterkontaktart vom Typ „Arena“ anzulegen. Technisch gesehen werden Arenen so als Kontakte verwaltet.

Durch die Anlage benutzerdefinierter Datenfelder, die allein für Kontakte vom Typ „Arena“ gelten, ist es möglich, die Merkmale von Arenen abzubilden: z.B. quantitative oder qualitative Merkmale, die die Arena beschreiben, Links zu Politybriefings, geltende Satzungen, Gesetze, Sitzungskalender, uvm.

Die Definition arenenspezifischer Aktivitätstypen ist denkbar. Hier eröffnet sich eine erste Möglichkeit für ein Issue Monitoring, indem Ereignisse als Aktivität an der Arena notiert werden. Alternativ könnte in einem benutzerdefinierten Feld auf einen Datenraum verwiesen werden, der z.B. die für die Arena relevanten Briefings, Monitorings, Datenräume bspw. von Arbeitskreisen, auf Chatkanäle oder Discourse-Foren verweisen, die sich auf die Arena beziehen.

4.3 Bedeutung von Stakeholdern in einer Arena

Technisch wird durch die Verwaltung von Arenen, Gremien, Organisationen und Personen als „Kontakte“ das Beziehungsgeflecht Arena – Gremium – Stakeholder abbildbar und verwaltbar.

Schaubild 2: Erweiterung des Basismodells um den Organisationstyp „Arena“

Beziehungen vom Typ (d) bilden ab, welche Gremien für eine Arena in Bedeutung sind, Beziehungen vom Typ (e) und (f) beschreiben die Ansprüche der Stakeholder (Organisationen und Personen) in der Arena.

Die Bedeutung des Stakeholders ergibt sich aus der Qualität seiner Ansprüche (stakes), die sich von Arena zu Arena unterscheiden. Der Anspruch eines Stakeholders mag in unterschiedlichen Arenen legitim sein, vielleicht nur manchmal dringend und nur in bestimmten Arenen wird er Macht besitzen.

Der Schlüssel zur Umsetzung eines Stakeholdermanagements mit CiviCRM, das die Option einer praxistauglich anwendbaren Umsetzung des Salience-Modells beinhaltet, ist, dass Organisations- und Personenkontakte nicht nur untereinander und zu Gremien in Beziehungen stehen können, sondern auch zu Arenen.

Konkret für diesen Typus der „Stakeholder-Arena-Beziehung“ werden im Datenmodell von CiviCRM Beziehungstypen definiert, die mit benutzerdefinierten Feldern erweitert werden, die die Dokumentation von Arenen-Kontakt-Beziehungen definierbar machen. Diese können dann optional mit Nominal- oder Ordinalskalen sowie mit Freitext beschreibbare Eigenschaften haben wie bspw. Macht, Legitimität, Dringlichkeit oder Einfluss. Zusätzlich kann hier auch festgehalten werden, in welcher Phase eines Politikzyklus die Beziehung in der Arena relevant wird: ob also bereits in der Phase der Evaluation und Problembeschreibung, in der Phase des Lösungsentwurfs, in der Phase der Entscheidung oder in der Phase der Implementierung.

Will man dann identifizieren, welche Stakeholder in einer oder mehreren Arenen relevant sind, sind dann mit Hilfe von SearchKit und Formbuilder gestaltbare Verwaltungsoberflächen möglich, mit deren Hilfe Benutzer*innen sehr rasch anhand von Politikfeld (Tag), Beziehungstyp und spezifische Eigenschaften gesuchter Beziehungen (zeitliche Gültigkeit, Ausprägung, Politikzyklusphase) heraussuchen können, welche Stakeholder je gewähltem Kriterienprofil von Bedeutung („salient“ = „hervorstechend“) sind.

Aus solchen Auswahlen lassen sich dann in CiviCRM bspw. ad hoc Verteilergruppen oder Kampagen bilden.

5. Themen als in Arenen zur Verhandlung stehende Sachen

Das Datenmodell von CiviCRM gestattet es, zur Diskussion stehende Sachverhalte, Themen oder Streitpunkte („issues“) als Fälle („cases“) zu verwalten. Die Fallverwaltung eröffnet die Möglichkeit echten „Issue Managements“, d.h. Themen

• als arbeitsteilige Prozesse zu fassen,
• als in bestimmten Gremien verhandelte Sachen zu kennzeichnen (i),
• in Arenen zu verorten (j),
• Stakeholderbeziehungen auf den konkreten Fall zu beziehen (g, h), wobei im Prinzip die gleichen Beziehungstypen verwendet werden können, die auch bei der Zurechnung zu Arenen verwendet werden (e,f)
• das Geschehen als Aktivitäten fallbezogen zu dokumentieren und in falltypspezifisch definierbaren Datenfeldern fallbezogenene Informationen abzulegen oder zu verlinken, wie bspw. Lageanalysen abzulegen. Ferner kann das fallbezogene Aktivitätenmanagement dazu genutzt werden, das themenbezogene operative Handeln zu koordinieren, indem Aktivitäten gleichzeit dem Thema als auch den mit dem Thema in Beziehung stehenden Kontakten zugewiesen werden können.

Schaubild 3: Issue Management mittels CiviCase

Das Datenmodell sieht vor, einen Fall immer einem Fallklienten zuzuordnen. Werden in CiviCRM nicht nur Organisationen und Personen, sondern auch Gremien und Arenen als Kontakte angelegt, entsteht eine große Flexibilität, ob man ein Issue einer Arena, einem Gremium oder einem Organisations- oder Personenkontakt als Fallklient zuordnet. Im weiteren gestattet es das Datenmodell, die Beziehungen von Organisationen, Personen, Gremien und Arenen mit diesem Fall zu verbinden und das fallbezogene Geschehen als Aktivitäten am Fall zu dokumentieren.

Siehe hierzu vertiefend die weiteren Überlegungen zu Issue Management mittels CiviCRM in kommunalpolitischen Arenen.