Ausgangspunkt der dargelegten Überlegungen ist die laufende Konfiguration einer CiviCRM Standalone-Instanz im Projekt unter https://worms.social auf der Grundlage meiner Erörterung einer Umsetzung eines Stakeholder- und Issue Managements mit CiviCRM. Die konkrete Instanz soll dem Stakeholder- und Issue Management in der kommunalen Arena dienen sowie der Organisation und der Durchführung von Aktionen. Handlungsleitend ist hier die Idee, dass der Aufbau einer im Fediverse föderierenden Struktur lokaler Öffentlichkeit wie #WormsSocial kein Selbstläufer ist, sondern dass ein Onboarding interessierter Kreise einer kommunalen Arena im Fediverse aktiv gesteuert werden muss, wobei CiviCRM das Arbeitsmittel für diesen Prozess ist.

Inhaltsverzeichnis

• 1. Zur Benutzerfreundlichkeit
  • 1.1 Zugriffsrechte
  • 1.2 Menüführung
  • 1.3 Bennenungen
  • 1.4 Listenansichten
  • 1.5 Vereinfachungen von Oberflächen
• 2. Zur Verwaltung von Themen mit Hilfe des Fallmanagements
  • 2.1 Abbildung der Politikzyklusphase eines Themas
  • 2.2 Abbildung der Zugehörigkeit eines Themas zu einem Politikfeld
  • 2.3 Rollen der Stakeholder in einem Thema/Fall
    • 2.3.1 Themen/Fällen mehreren Fallklient*innen zuordnen
    • 2.3.2 Stakeholderbeziehungen zum Thema/Fall dokumentieren
  • 2.4 Issue Monitoring und Issue Management mittels Aktivitäten

1. Zur Benutzerfreundlichkeit

1.1 Zugriffsrechte

Die mich leitende Idee ist, einer beliebigen Anzahl Interessierter Nutzungsrechte in einer CiviCRM-Instanz zu geben, um die Instanz als kollaboratives Arbeitsmittel entlang der Wertkette politischer Arbeit in der gemeinsam bearbeiteten politischen Arena zu nutzen. Daraus ergeben sich Anforderungen, wie beispielsweise

• allen Benutzer*innen hinreichende Rechte zu geben,
  • alle Kontakte zu sehen, dabei aber im Sinne des Datenschutzes und der von der Datenschutzgrundverordnung (DSGVO) verlangten Datensparsamkeit mittels Zugriffskontrollisten (ACL) nur bestimmte, ehedem öffentliche personenbezogene Daten sichtbar zu machen
  • alle Themen/Fälle zu sehen,
• die Möglichkeit der Bearbeitung und Löschung von Daten ggf. einschränken zu können, um versehentliche oder mutwillige Beschädigungen des gemeinsamen Datenbestands zu vermeiden,
• nur bestimmten Benutzer*innen weiterreichende Rechte zu geben, weitere Funktionen von CiviCRM sehen und benutzen zu dürfen (z.B. Verwaltung von Mailinglisten, Rundschreiben, Veranstaltungen, Zuwendungen uvm.)
• nur wenigen Benutzer*innen volle administrative Rechte zu geben, das gesamte System und die Benutzer*innen zu verwalten.

Um entsprechende Zugriffs- und Bearbeitungsrechte zu gewähren, verfügt CiviCRM

1. über ein Rollen -und Rechtemanagement, mit dessen Hilfe der Zugang zu Funktionsbereichen von CiviCRM geregelt wird sowie
2. über die Möglichkeit, mittels Zugangskontrollisten (Access Control Lists – ACL) zu bestimmen, für wen welche Datenfelder sichtbar und bearbeitbar werden.

Die Administration der Benutzerkonten und Rollen erfolgt in CiviCRM Standalone unter „Administration > Benutzer und Berechtigungen“. Dort lassen sich Benutzerkonten verwalten und Rollen definieren, die den Benutzerkonten zugewiesen werden können.ⁱ

Die Zuweisung der in den Zugangskontrollisten definierten Zugriffsreche erfolgt über Zugangsberechtigungsgruppen, die unter „Kontakte > Gruppen verwalten“ angelegt werden. Wird ein in CiviCRM verwalteter Kontakt einer solchen Zugangsberechtigungsgruppe zugeordnet, gelten für ihn (bzw. für das mit dem Kontakt verbundene Benutzerkonto) die entsprechend der Gruppe zugeordneten Zugangskontrollisten. Die Konfiguration der Zugriffskontrollisten und ihre Zuordnung zu Zugangsberechtigungsgruppen erfolgt unter „Administration > Benutzer und Berechtigungen > Zugangskontrollisten“.

CiviCRM Standalone legt bei der Installation drei Standardrollen an: „Everyone, including anonymous users“, „Staff“ und „Administrator“. Es können beliebig viele weitere Rollen hinzugefügt werden.

Mein Vorschlag lautet, eine Rolle namens „Mitglied“ einzurichten. Dies in der Annahme, dass die Nutzer*innen der CiviCRM-Instanz selbst eine Gruppe wie bspw. einen Verein bilden, deren Mitglied sie sind. Dieser Rolle werden nur Rechte zur Nutzung der notwendigen Basisfunktionen zugeordnet, also die Möglichkeit der Ansicht und Bearbeitung von Kontakten sowie die Möglichkeit der Ansicht und Bearbeitung von Themen bzw. Fällen.

Die Vergabe folgender Berechtigungen („User Permissions“) bietet sich an:

Berechtigung	Erläuterung
CiviCRM: Zugriff auf CiviCRM-Backend und -API	Die grundlegende Eintrittskarte in CiviCRM: Ohne dieses Recht ist weder das Backend noch die interne API nutzbar. Alle weiteren CiviCRM-Rechte greifen nur, wenn dieses Basisrecht vorhanden ist.
CiviCRM Standalone Users: Allow users to access the reset password system	Erlaubt Benutzern im Standalone-Betrieb den Zugriff auf den „Passwort vergessen“-Workflow. Hat keinerlei Einfluss auf fachliche Zugriffsrechte innerhalb von CiviCRM.
CiviMail: Zugriff auf CiviMail An- und Abmelde-Seiten – Anmeldung/Abmeldung von der Newsletter-Gruppe	Erlaubt den Zugriff auf öffentliche CiviMail-Seiten zur Newsletter-Anmeldung und -Abmeldung. Relevant für Self-Service-Szenarien und datenschutzkonforme Einwilligungsprozesse.
CiviCRM: Kontaktübersicht	Steuert den Zugriff auf die Kontaktübersichtsseite (Contact Summary). Ohne dieses Recht sind viele Detailansichten und Navigationselemente im Kontaktkontext nicht verfügbar.
CiviCRM: Alle Kontakte betrachten	Erlaubt das Lesen aller Kontakte sowie das Ausführen kontaktbezogener Aktionen (z. B. E-Mail senden, Aktivitäten erfassen), jedoch ohne Kontaktdaten zu ändern. Typisch für Leserechte oder operative Rollen ohne Datenhoheit.
CiviCRM: Alle Kontakte bearbeiten	Erlaubt uneingeschränkten Zugriff auf alle Kontakte: ansehen, bearbeiten, löschen, Beziehungen pflegen, Tags setzen. Dieses Recht ist sehr mächtig und sollte nur an stark vertrauenswürdige Rollen vergeben werden.
CiviCRM: Meine Kontaktdaten ansehen	Erlaubt einem Benutzer, den eigenen Kontakt-Datensatz einzusehen. Relevant für Selbstverwaltung, auch wenn sonst kaum Rechte vergeben sind.
CiviCRM: Kontakte hinzufügen	Erlaubt das Anlegen neuer Kontakte in der Datenbank. Ohne dieses Recht können bestehende Kontakte ggf. bearbeitet, aber keine neuen erstellt werden.
CiviCRM: Meine Kontaktdaten bearbeiten	Erlaubt dem Benutzer, die eigenen Kontaktdaten (z. B. Adresse, Telefonnummer) selbst zu ändern. Wird häufig zusammen mit dem vorherigen Recht vergeben.
CiviCRM: Alle Notizen anzeigen	Macht alle Notizen sichtbar, auch solche, die eigentlich nur für den Ersteller bestimmt sind. Dieses Recht hebelt die Vertraulichkeit von Notizen aus und sollte daher sehr restriktiv vergeben werden.
CiviCRM: füge Kontaktnotiz hinzu	Erlaubt das Anlegen von Notizen zu Kontakten. Die Sichtbarkeit der Notizen hängt zusätzlich von weiteren Rechten (z. B. „Alle Notizen anzeigen“) ab.
CiviCRM: Alle Aktivitäten anzeigen – Zeige alle Aktivitäten (für sichtbare Kontakte)	Erlaubt das Anzeigen sämtlicher Aktivitäten (z. B. Anrufe, E-Mails, Meetings) zu sichtbaren Kontakten. Ohne dieses Recht sieht der Benutzer nur selbst erstellte oder explizit zugewiesene Aktivitäten.
CiviCase (Fallmanagement): Zugriff auf meine Fälle und Aktivitäten – Nur die eigenen Fälle des Benutzers können betrachtet und bearbeitet werden	Beschränkt den Zugriff auf Fälle, bei denen der Benutzer selbst als Rolleninhaber oder Beteiligter eingetragen ist. Ideal für Sachbearbeitung, um Fremdfälle auszublenden.
CiviCase (Fallmanagement): Zugriff auf alle Fälle und Aktivitäten – Alle Fälle ansehen und bearbeiten (für sichtbare Kontakte)	Ermöglicht den Zugriff auf alle Fälle und deren Aktivitäten, sofern die zugehörigen Kontakte sichtbar sind. Dieses Recht ist für koordinierende oder leitende Rollen gedacht, die einen Gesamtüberblick benötigen.
CiviCase (Fallmanagement): Fälle hinzufügen – Neuen Fall eröffnen	Erlaubt das Anlegen neuer Fälle auf Basis eines definierten Case-Typs. Ohne dieses Recht kann ein Benutzer bestehende Fälle ggf. sehen oder bearbeiten, aber keine neuen Fallprozesse starten.

Tabelle 1: Berechtigungen für eine Rolle „Mitglied“

1.2 Menüführung

Die Benutzungsfreundlichkeit profitiert bekanntermaßen erheblich von Vereinfachung. Dies gilt vor allem für die Menüführung über Navigationsmenüs. User Experience (UX) Design empfiehlt, in Hauptmenüs nicht mehr als 5-7, in Untermenüs nicht mehr als 4-8 Punkte zur Auswahl zu stellen. Aufgrund seines großen Funktionsumfangs und seiner sehr unterschiedlichen Verwendungen neigt CiviCRM zu einer tendentiell überfrachteten Menüführung.

Das Navigationsmenü von CiviCRM lässt sich unter „Administration > Daten anzeigen und anpassen > Navigationsmenü“ bearbeiten. Es lassen sich im Menü neue Menüpunkte hinzufügen, Menüpunkte umbenennen und auch die Positionen der Menüpunkte ändern.ⁱⁱ

CiviCRM bietet zudem die Möglichkeit, unter „Administration > Systemeinstellungen“ Komponenten zu aktivieren und zu deaktivieren, wodurch die Menüführung von nicht genutzten Komponenten entlastet werden kann. Es ist aber besser, den gleichen Effekt dadurch zu erreichen, dass man eine Rolle einrichtet, die einfach keine Zugriffsrechte in der entsprechenden Komponente hat. Damit erhält man sich die Möglichkeit, bestimmten Benutzer*innen mit anderen oder weiteren Rollen die entsprechenden Funktionen fallweise eben doch zur Verfügung zu stellen.

Bei der Bearbeitung des Navigationsmenü unter „Administration > Daten anzeigen und anpassen > Navigationsmenü“ kann auch eingestellt werden, für wen (abhängig von einer spezifischen Berechtigung) ein Menüpunkt angezeigt wird.

Im Navigationsmenü lassen sich so zum Beispiel unter „Unterstützung“ („Support“) die voreingestellten Links auf

• Support > Register Your Site
• Support > Join CiviCRM

für die Mitglieder ausblenden, indem man die Berechtigung dafür auf „Standalone Users: Administer settings“ einschränkt.

Bei der Benutzung von CiviCRM Standalone kann es für die Benutzer*innen angenehm sein, direkt sichtbar die Möglichkeit zur Abmeldung vom System im Menüband angezeigt zu bekommen. Diese Funktion ist ansonsten unter dem CiviCRM-Logo am Anfang des horizontalen Menübands versteckt. Hierzu einfach im Navigationsmenü entsprechend einen neuen Menüeintrag auf der obersten Ebene einfügen.

1.3 Benennungen

Die Standardsprache von CiviCRM, in der die Software auch entwickelt wird, ist Englisch. Die Bennenungen orientieren sich an den in der Nutzergemeinschaft dominanten Verwendungen. Die Übersetzung der Oberfläche basiert technisch auf gettext und .po-Dateien und wird von der Nutzergemeinschaft über die Übersetzungsplattform Transifex organisiert. Der Effekt ist, dass Benennungen nicht immer ideal zur Anwendungsfall passen, für den CiviCRM gerade eingesetzt wird. Zudem verändern sie sich gelegentlich von Version zu Version, weil dem Übersetzungsteam fallweise andere Begriffe oder Redewendungen geeigneter Erscheinen, die dann mit bisherigen Seh- und Lesegewohnheiten brechen.

Ohne Eingriff in den Quellcode und ohne Möglichkeit, an der Übersetzung via Transifex mitzuarbeiten, bestehen mindestens drei Möglichkeiten, Benennungen anzupassen:

1. Benennungen im Navigationsmenü ändern, indem man den Menüpunkt umbenennt.
2. unter „Administration > Daten und Anzeigen anpassen > Wortersetzungen“ Wörter bzw. Zeichenketten ersetzen. Diese Möglichkeit eröffnet in eher geringerem Umfang Möglichkeiten, da abhängig von der Art der Umsetzung im Quellcode die Wortersetzung nicht anschlägt oder nur Teilzeichenketten ersetzt werden.
3. andere Benennungen und auch andere Logiken der Darstellungen zu erhalten, in dem man sich eigene Listenansichten erzeugt und entsprechend selbst beschriftet.

Das Thema der Benennung wird relevant, weil es in unserem Fall etwas irreführend ist, dass wir – vom Issue Management her kommend – von „Themen“ sprechen, die CiviCRM-Fallverwaltung aber stets von „Fällen“ bzw. „Cases“ spricht. Mit Bordmitteln ist eine „einfache“ und durchgehende Wortersetzung in Menüführung und Oberflächen nicht möglich. Es bieten sich jedoch folgende Wortersetzungen an:

• Case: Thema/Fall
• Cases: Themen/Fälle
• New Case: Neues Thema/neuer Fall
• Find Cases: Thema/Fall suchen
• Case Reports: Berichte zu Themen/Fällen

Das Wort „Fall“ ist im Zusammenhang mit Issue Management nicht ganz falsch. In der Politikzyklusphase der Problemformulierung wird eine Sache meist durch eine Art Fall zum Thema. Vergleiche hier die „Mängelmelder“, wie sie von Kommunen mittlerweile oft als Online-Meldemöglichkeit von Missständen im öffentlichen Raum angeboten werden. Auch die politische Arbeit entlang der Wertkette politischer Arbeit hat solch eine „Mängelmelde-Funktion“ inne und es ist auch denkbar, formularbasiert Dritten ohne Benutzerkonto die Möglichkeit zu geben, Themen in das CiviCRM-System hinein zu melden – bspw. über ein per iframe in die Webseite des politischen Vereins eingebundens CiviCRM-Melde-Formular.

1.4 Listenansichten

Für das kollaborative Stakeholder- und Issue Management sind zwei Ansichten relevant:

• eine Liste der Kontakte bzw. „Stakeholder“
• eine Liste der Themen bzw. „Fälle“

Listenansichten lassen sich in CiviCRM mit Hilfe von „SearchKit“ unter „Suche > SearchKit“ erzeugen und mit Hilfe von „FormBuilder“ dauerhaft in die Menüführung einbinden.

Eine nicht weiter konfigurierte Installation von CiviCRM beinhaltet keine „einfache“ Listendarstellung der im System vorhandenen Bestandskontakte. Die Standardlogik verlangt, über „Suche > Kontakte finden“ oder „Suche > Erweiterte Suche“ mit Hilfe von Suchkriterien“ Listen zu erzeugen. Dies ist im Alltag weder intuitiv, noch effizient. Deshalb ist es ratsam, sich eine eigene und ad hoch durchsuchbare Listenansicht der im System vorhandenen Kontakte / Stakeholder zu erzeugen.

Auch die für das Fallmanagement zuständige Komponente CiviCase ist ohne weitere Konfiguration nicht einfach zu verstehen. Dies gilt auch für die Liste der Themen bzw. Issues, die man im System verwaltet.

Mittels SearchKit legt man dafür zwei „Suchen“ an:

1. Kontakte / Stakeholder finden
2. Themen- und Fallliste

Verfahrensweise am Beispie für eine Kontakteliste mit SearchKit:

1. Anlegen einer „neuen Suche“ unter „Suche > SearchKit“
2. „Search for“: „Kontakte“
   1. with (optional): Kontakt Webseiten
   2. with (optional): Kontakt E-Mails
      if „Ist Haupteintrag“ = Wert „Ja“
3. „Filter Conditions“: keine
4. „Select Fields“:
   1. CiviCRM-ID
   2. Kontaktart
   3. Sortiername
   4. Webseite
   5. E-Mail
5. Hinzufügen: „Table“
   1. wähle dort rechts oben unter „Form“ die zweite Option „Create form for …“
   2. Erzeuge ein Formular. Sobald das Formular benannt ist, man eine „Page Route“ eingegegeben hat und man es gespeichert hat, kann man es über „Add to Navigation Menu“ im Navigationsmenü einbetten.

SearchKits bzw. „Gespeicherte Suchen“ lassen sich exportieren und in andere CiviCRM-Instanzen als SearchKit importieren.

• Vorlage für eine einfache Kontakteliste
• Vorlage für eine Themen- und Fälleliste

1.5 Vereinfachungen von Oberflächen

Die Benutzbarkeit von CiviCRM lässt sich auch noch an anderen Stellen ein wenig verbessern.

Die Arbeit mit Zugangskontrolllisten (ACL) hat zur Folge, dass die Zahl der sichtbaren und bearbeitbaren Felder für die Benutzer*innen mit entsprechend eingeschränkten Rechten von vornherein geringer ausfällt als die Zahl der standardmäßig von CiviCRM vorgesehenen Datenfelder.

Zusätzlich ist es möglich, mit Hilfe der CiviCRM Erweiterung „Contact Layout Editor“ die Ansicht der Stammdatenmaske der einzelnen Kontakte zu vereinfachen und sinnlogisch richtig anzuordnen.

CiviCRM unterscheidet bei Kontakten typologisch zwischen Organisationen (d.h. juristischen Personen), Personen und Haushalten. Wer CiviCRM im Zusammenhang mit einem Haustürwahlkampf oder im Zusammenhang mit einer anderen Form an Haustüren klingelnden Form der politischen Arbeit benutzen möchte, für den mögen Haushalte eine interessante Kontaktkategorie sein. Für die übliche Arbeit sind Haushalte jedoch oft eine irreführende Art der Kontaktverwaltung, zum Beispiel, weil man aus irgendeinem Grund irgendwann einmal ein Ehepaar oder eine „Familie“ in den Kontaktbestand aufgenommen hat, mit der Folge einer mangelnden Zurechenbarkeit bspw. von Zuwendungen/Spenden oder auch dem problematischen Effekt der Sippenhaft usw. Es empfiehlt sich daher, auch um Verwirrung zu minimieren, die Kontaktart „Haushalt“ zu deaktivieren. Gehe hierzu „Administration > Daten und Anzeigen anpassen > Kontaktarten“ und deaktiviere (!) die Kontaktart „Haushalt“.

Eine weitere Irritation besteht im in CiviCRM standardmäßig aktivierten Eingabefeld „Zweiter Vorname“, der im anglo-amerikanischen Raum üblich ist. Dieser wird deaktiviert unter „Administration > Daten und Anzeigen anpassen > Voreinstellungen für die Anzeige“. Hier unter „Kontakte bearbeiten > persönliche Namensfelder“ die Checkbox „zweiter Vorname“ deaktivieren.

2. Zur Verwaltung von Themen mit Hilfe des Fallmanagements

Ich knüpfe hier an die Vorüberlegungen zu Themen als in Arenen zur Verhandlung stehende Sachen an. Handlungsleitend für die Nutzung des CiviCRM Fallmanagements „CiviCase“ für Issue Management sind die im Issue Management zur Anwendung kommenden Konzepte der Politikfeldanalyse.

2.1 Abbildung der Politikzyklusphase eines Themas

Relevant ist hier zu aller erst das Konzept des Politikzyklusⁱⁱⁱ, der fünf Phasen eines politischen Prozesses unterscheidet:

1. Problemformulierung,
2. Lösungsentwurfphase
3. Entscheidungsphase
4. Implementierungsphase
5. Evaluationsphase

Ein Thema oder Fall lässt sich danach unterscheiden, in welcher Politikzyklusphase sich eine Sache befindet. Dies kann in CiviCase mit Hilfe der Fallstatus abgebildet werden. Die Fallstatus werden konfiguriert unter „Administration > CiviCase (Fälle) > Fallstatus“.

2.2 Abbildung der Zugehörigkeit eines Themas zu einem Politikfeld

Im weiteren ist die Politikfeldanalyse relevant, weil in unserem Anwendungsfall kommunale Handlungsfelder als eine spezifische Art von Politikfeldern mittels Falltypen abgebildet werden können.

Dieser Ansatz greift die Idee auf, Politikfelder als schlagwortartige Themenkategorien zu betrachten, die mittels Schlagworten (Tags) notiert werden, geht aber über diesen Ansatz hinaus, weil Politikfelder in CiviCase eben nicht nur als Schlagworte (Tags) verwaltet werden können, sondern eben auch als Falltypen.

Dazu muss man allerdings wissen, dass die systemweit verwalteten Schlagworte für Themen/Fälle erst dann verfügbar werden, wenn man unter „Administration > Daten und Anzeigen anpassen > Benutzerdefinierte Felder“ für den Entitätstyp „Cases“ eine Feldgruppe einrichtet, der man dann ein Feld vom Datentyp „Entitätsreferenz“ hinzufügt, in dem man dann vorgefundene Schlagworte auswählen kann, mit dem man das Thema/den Fall kennzeichnet. Ob das in der Praxis nützlich ist, muss man ausprobieren.

Zur Entscheidung, welche Politikfelder unterschieden und als Falltypen angelegt werden, können im Falle einer Anwendung von CiviCRM für Politikmanagement auf der Ebene der Kommunalpolitik die Handlungsfelder kommunaler Verwaltung zu Rate gezogen werden. Es ist nämlich nicht so sehr von Belang, ob politische Gremien der kommunalen Ebene informations- und entscheidungsbefugt sind, sondern, welche Themen überhaupt im kommunalen Kontext bearbeitet werden, auch wenn es sich um bundes- und landesgesetzlich auferlegte Pflichtaufgabenfelder handeln mag, die sich einer Informations- und Mitbestimmungsbefugnis lokaler Gremien entziehen.

Eine Liste in Frage kommender Handlungsfelder findet sich bei Henneke et al und dort noch weiterführend ausdifferenziert^iv:

1. Soziale Leistungen
2. Bildung, Sport und Kultur
3. Gesundheit und Veterinärwesen
4. Bauwesen, Umwelt und Natur
5. Ordnung und Sicherheit
6. Verkehr
7. Wirtschaft und Sparkassen
8. Integration von Migranten
9. Personal und Organisation der kommunalen Verwaltung
10. kommunale Finanzen

In CiviCRM ergibt sich unter „Themen/Fälle > Übersicht“ daraus beispielhaft eine Matrix aus 50 Feldern, bestehend aus eben jenen 10 Handlungsfeldern/Falltypen als Zeilen einer Tabelle, die in fünf Spalten der Politikzyklusphasen/Fallstatus aufgeschlüsselt werden. Es ergibt sich dadurch eine direkte Übersicht, wieviele Themen/Fälle je Politikfeld und Politikzyklusphase im System verwaltet werden. Die numerische Angabe ist dort ein Hyperlink, über den man die Liste der entsprechend kategorisierten Themen/Fälle erhält.

Die Anlage von Politik- und Handlungsfeldern als Falltypen hat noch einen weiteren, sehr nützlichen Nebeneffekt. In CiviCRM lassen sich nämlich falltypspezifisch unterschiedliche benutzerdefinierte Datenfelder anlegen. Ein Thema/Fall aus dem Bereich Verkehr beinhaltet naturgemäß andere Basis-Informationen, als beispielsweise ein Thema/Fall aus dem Bereich Schulbau.

2.3 Rollen der Stakeholder in einem Thema/Fall

Ein Thema/Fall in CiviCRM steht abstrakt für eine Sache,

• die bestimmte Aktivitäten und/oder Dokumente beinhaltet,
• an der ein oder mehrere Kontakte beteiligt sein können und
• die durch Benutzer*innen mit einer entsprechenden Rolle koordinert werden.

2.3.1 Themen/Fällen mehreren Fallklient*innen zuordnen

Typischerweise wird in CiviCase jeder Fall einem Kontakt als „Fall-Klienten“ zugeordnet, der am Prozess beteiligt ist. Im Falle der Verwaltung politischer Themen/Fällen ist es aber sinnvoll, einem einzelnen Fall nicht nur einen einzelnen Kontakt, sondern mehrere Kontakte als Fall-Klient*innen zuordnen zu können. Denn der mit dem Thema verbundene Prozess bspw. einer Interessenvertretung ist nicht auf einen einzelnen Kontakt beschränkt, das Thema bzw. der Fall ist also potentiell nicht nur die „Akte einer Person“, sondern kann als gemeinsamer Prozess vieler Beteiligter verstanden werden.

Voraussetzung ist, CiviCase unter „Administration > CiviCase (Fälle) > CiviCase Einstellungen“ so zu konfigurieren, dass mehrere Klienten pro Fall erlaubt sind.

Der entscheidende Vorteil dieser Einstellung besteht darin, dank Mehrfach-Klient*innen keine identischen Fälle mehrfach anlegen zu müssen – mit doppelten Aktivitäten, Dokumenten und entsprechendem Synchronisationsaufwand und man auf diese Weise viele gleich gelagerte Fälle zusammen betrachten kann.

2.3.2 Stakeholderbeziehungen zum Thema/Fall dokumentieren

Wenn CiviCase zur Verwaltung politischer Themen genutzt wird, bietet es sich an, über das reine „Mehrere Fallklienten“-Modell hinauszugehen und Stakeholderbeziehungen auf den konkreten Fall zu beziehen. Hierfür lassen sich unter „Administration > Daten und Anzeigen anpassen > Beziehungsarten“ Beziehungsarten definieren, die über den Typus des „Fallklient“ hinausgehen.

Auf diese Weise lässt sich dann nämlich nicht nur die Frage beantworten, wer als „Fallklient*in“ betroffen ist.

Durch die Verwendung strukturierter Beziehungen nach dem Salience-Modell lässt sich auch dokumentieren und darauf aufbauend analysieren, wer als Stakeholder relevant ist – und warum.

Schaubild: Beziehungen von Themen/Fällen zu Organisationen, Personen, Gremien oder Arenen als Stakeholder-Beziehungen

Mehrere Fall-Klient*innen bilden gut ab, wer formal beteiligt ist, d.h. Teil des Prozesses ist und im Workflow „mitläuft“. Wenn man sich aber bloß auf die Verwendung der Rolle der Fall-Klient*innen beschränkte, verpasste man die Chance zu unterscheiden, wer Macht besitzt oder wer bloß betroffen ist, wer Möglichkeiten einer formellen oder informellen Einflussnahme besitzt, wessen Anspruch in der Sache dringlich ist oder wer bloß strukturelle Relevanz in der Sache besitzt.

Durch die Definition geeigneter Beziehungstypen ist aber genau dies dokumentier- und beobachtbar.

Denkbar ist die Verwendung dimensionaler oder klassifizierender Beziehungstypen:

Beziehungstyp	Bedeutung
Hat politische Entscheidungsmacht über	Macht
Hat legitimierten Anspruch in Bezug auf	Legitimität
Übt zeitkritischen Druck aus auf	Dringlichkeit

Tabelle 2: Dimensionale Beziehungen

Ein Stakeholder kann zu einem Thema/Fall mehrere dieser Beziehungen gleichzeitig haben.

Beziehungstyp	Salience
Dominanter Stakeholder	Macht + Legitimität
Abhängiger Stakeholder	Legitimität + Dringlichkeit
Gefährlicher Stakeholder	Macht + Dringlichkeit
Definitiver Stakeholder	alle drei

Tabelle 3: Klassifizierende Beziehungen (Salience-Typen)

Die Dokumentation klassifizierender Beziehungen zum Thema/Fall ist unter Umständen einfacher u.a. für Auswertungen, aber aufgrund der Veränderlichkeit der Situation möglicherweise weniger praktisch in der Handhabung.

Die Arbeit mit dimensionalen und/oder klassifizierenden Beziehungen zwischen Kontakten und Themen/Fällen bietet weiter Vorteile:

• die beidseitig der Beziehung ist dokumentiert
• die zeitlich Veränderung ist dokumentierbar
• es ist nach Beziehungen filterbar und die Beziehungen können in Berichten ausgewertet werden

Praktisch ergibt sich daraus die Möglichkeit,

• Stakeholder nach Einfluss zu priorisieren
• die Relevanz eines Stakeholders zu begründen
• leichter zu entscheiden, an wen man sich im Rahmen einer Kommunikationsstrategie wendet
• Entscheidungslogiken nachvollziehen zu können, transparent zu machen und Eskalationen (beobachtete oder provozierte) auf der Basis eines Datenmodells zu begründen.

2.4 Issue Monitoring und Issue Management mittels Aktivitäten

Im Fallmanagement mittels CiviCase sind Aktivitäten (Activities) das zentrale operative Element, mit dem Themen/Fälle nicht nur dokumentiert, sondern tatsächlich bearbeitet werden.

Ein Thema/Fall ist der Rahmen, der alle Aktivitäten des mit dem Thema/Fall verbundenen Arbeitsprozesses bündelt. Mit Aktivitäten bildet man also den Kern der Informationsarbeit entlang der Wertkette politischer Arbeit ab: Sie bilden das „Geschehen“ innerhalb eines Themas/Falls ab – alles, was passiert, dokumentiert, analysiert, entschieden und kommuniziert wird.

Aktivitäten sind die kleinste sinnvolle Arbeitseinheit in CiviCase. Sie repräsentieren konkrete Ereignisse/Handlungen wie Sitzungen, Sitzungsprotokolle, Presseberichte, Gespräche, E-Mails, Entscheidungen, Fristen oder interne Vermerke. Jede Aktivität besitzt einen Aktivitäts-Typ (z. B. Treffen/Meeting, Telefonat, E-Mail, Notiz), einen Status, Zeitangaben, Verantwortlichkeiten und kann mit Dateien, Notizen oder Ergebnissen angereichert werden. Dadurch lassen sich sowohl laufende als auch abgeschlossene Vorgänge nachvollziehbar abbilden.

Eine zentrale Funktion der Aktivitäten ist die Chronologie. Die Fallübersicht in CiviCase ist im Kern eine zeitlich abwärts sortierte Aktivitäten-Timeline. Sie beantwortet Fragen wie: Was ist bisher passiert?, Wer war beteiligt?, Wann wurde was entschieden? und Welche Schritte stehen noch aus? Damit sind Aktivitäten das primäre Mittel der täglichen Arbeit zu einem Thema/Fall.

Darüber hinaus sind Aktivitäten das Bindeglied zwischen Thema/Fall und den mit dem Thema/Fall verbundenen Kontakten. Zwar ist jede Aktivität immer dem Thema/Fall zugeordnet, sie kann aber zusätzlich einzelnen Kontakten explizit zugewiesen werden – zum Beispiel als beteiligte Person, als Zielkontakt oder Verantwortliche:r. Gerade in Fällen mit mehreren Fallklient:innen oder Stakeholdern ermöglicht dies eine differenzierte Zuordnung: Nicht jede Handlung betrifft automatisch alle Beteiligten gleichermaßen. Aktivitäten erlauben es, diese Differenzierung sauber zu dokumentieren, ohne den Fall künstlich aufzuteilen.

Ein weiterer wichtiger Aspekt ist dieArbeitsprozess-Steuerung. Für die in CiviCase definierten als Falltypen definierten Politikfelder können optional empfohlene oder verpflichtende Abfolgen von Aktivitäten definiert werden: Analyse, Maßnahmenplanung, Umsetzung, Abschluss usw. Aktivitäten fungieren hier als Träger des Prozessfortschritts. Statuswechsel (Wechsel der Politikzyklusphase) eines Themas/Falls, Fristen oder Eskalationen sind häufig direkt oder indirekt an bestimmte Aktivitäten gekoppelt. Damit wird der abstrakte „Fallstatus“ erst durch Aktivitäten mit Bedeutung gefüllt. Zum Beispiel wechselt der Politikzyklus mit der Aktivität der Gremienentscheidung von der Phase der Entscheidungsfindung in die Phase der Implementierung.

Aktivitäten übernehmen außerdem eine kommunikative Funktion. In vielen Organisationen ist der überwiegende Teil der fallbezogenen Arbeit Kommunikation: Telefonate, Mails, Abstimmungen, Anhörungen, Gespräche mit Betroffenen oder Dritten. All diese Interaktionen werden in CiviCase als Aktivitäten erfasst und zentral archiviert. Das Thema bzw. der Fall wird so zur vollständigen Kommunikationsakte, unabhängig davon, über welchen Kanal kommuniziert wurde.

Nicht zuletzt sind Aktivitäten entscheidend für Auswertung und Steuerung. Die Erzeugung von Berichten in CiviCase basiert weniger auf Themen oder Fällen als Ganzem, sondern auf den mit den Themen/Fällen assoziierten Aktivitäten: Anzahl und Art von Kontakten, Bearbeitungsdauer, Reaktionszeiten, offene vs. abgeschlossene Schritte, Arbeitslast pro Rolle oder Person. Wer verstehen will, wie gearbeitet wird, muss Aktivitäten auswerten – nicht nur Fallzahlen.

---