Vereinsverwaltung – das Dilemma der geschlossenen Systeme

Wenn man sich mit der administrativen Verwaltung eines Vereins befasst, dann gibt es aktuell eine Reihe von Systemen, welche die Grundbedürfnisse der Administration abdecken. Dazu gehören im Wesentlichen die Verwaltung der Stammdaten, die Möglichkeit des Beitragseinzuges und der Gestaltung der Beiträge. Diverse Systeme bieten darüber hinaus auch noch die Möglichkeit einer für die meisten Vereine notwendigen Buchführung (EAÜ-Buchführung).

Sobald es aber darum geht, die Mitgliederdaten in anderen administrativen Prozesse zu nutzen, ist man meist am Ende der weiteren Nutzung der Daten. Zwei Beispiele hierzu:

Fall 1 – Mitglieder sind HospizbegleiterInnen

In diesem Fall benötigt man die Mitgliederdaten, um eine Verbindung zwischen begleiteten Personen (Patienten) und den HospizbegleiterInnen herzustellen. Darüber hinaus besteht natürlich auch die Notwendigkeit, die Verfügbarkeit der HospizbegleiterInnen verwalten zu können. Wie kommt man also an die bestehenden Informationen heran? In diversen Systemen, welche ich oberflächlich analysiert habe, werden in den „spezialisierten“ Systemen diese Informationen nochmals erfasst. Im Prinzip ein „No-Go“ aus Sicht der IT. Hier gilt immer das Prinzip der Datenredundanzvermeidung, was sich aber schwerlich durchsetzen lässt, wenn man eben die genannten Dateninseln verwalten muss.

Fall 2 – Mitglieder in einem Fischereiverein

Mit den i.d.R. angebotenen Möglichkeit der Abbildung des Mitgliedsbeitrages kommt in einen Fischereiverein (oder auch Angelverein genannt) nicht weit. Hier gibt es weiterreichende Anforderungen wie Erfüllung von Arbeitsdiensten, Besatzkosten (einmalig oder regelmäßig), Zufahrtskosten für die Angelgründe, usw. usw.. Ein Fischereiverein hat daneben aber noch andere Aspekte wie Gebühren für Tageskarten, besondere Angelevents. Kurz: die „normale“ Mitgliederverwaltung greift hier viel zu kurz, um die Vielfältigkeit eines Bereiches wie die Beitragsabrechnung für ein Mitglied abzubilden.

Gibt es einen Ausweg?

Eine Möglichkeit wäre es, die Eingangs genannte Software für Mitgliederverwaltung offener zu gestalten. „Offen“ in dem Sinne, dass Erweiterungen eingebracht werden könnten. Nimmt man sich z.B. System wie WordPress zum Vorbild, dann gibt es dort eben sog. „Hooks“, an denen man sich in die Systemlogik einklinken kann.

Oder noch weiter gegriffen -> man nimmt sich SAP als Vorbild. Was ist hier „vorbildlich“? Nun – SAP hat bereits in seinen Gründerzeiten nie ein Geheimnis um den Programmcode gemacht. Der Code konnte vom Benutzer erweitert werden. Das war natürlich auch mit der Gefahr verbunden, dass mit jedem Releasewechsel die gemachten Änderungen überprüft werden mussten. Das hat sich dann mit der Zeit geändert und die Punkte, wo man im Code selbst Erweiterungen machen konnte, wurden so gestaltet, dass sie weitestgehend Release-unabhängig wurden. Natürlich liegt die Verantwortung hier immer bei demjenigen, der die Änderung eingebracht hat.

Fazit

Aktuell sieht es in dem von mir grob skizzierten Bereich nicht besonders gut aus. Die Folge sind Dateninseln oder „Krücken“ wie z.B. der Download von Stammdaten in – oh Wunder – Excel-Formate, damit mit diesen dann der Benutzer seine besonderen Anforderungen in welcher Form auch immer dann ergänzen kann. Es wäre schön, wenn sich die Softwarehersteller mehr in Richtung von offenen API-Schnittstellen hin bewegen würden, um hier eine Öffnung der Datennutzung bereitzustellen.