Jede Organisation, die ihren Menschen etwas bietet, führt eine Liste, wer darauf Anspruch hat. Ein Unternehmen für die Ferienwohnungen, ein Verein für die Mitgliederrabatte, ein Betriebsrat für seine Veranstaltungen. Meist stehen diese Listen in Tabellen, und jemand verbringt jeden Monat einige Stunden damit, sie aktuell zu halten.
appsolut ONE ersetzt diese Listen durch Regeln. Statt zu pflegen, wer was nutzen darf, beschreiben Sie einmal, woher Ihre Menschen kommen und wer von ihnen wohin gehört. Das Studio, die Verwaltungsanwendung von appsolut ONE, rechnet den Rest bei jeder Anmeldung selbst aus. Dieser Beitrag erklärt die drei Bausteine, Register, Mitgliedschaftsdefinition und Communities, an einem durchgehenden Beispiel.
Das Beispiel: die Pannoniqa AG
Die Pannoniqa AG ist ein erfundener Industriebetrieb, der in unserer ganzen Dokumentation vorkommt. Sie will zwei Angebote machen:
- das „Pannoniqa Portal“, eine Website mit Neuigkeiten, Vorteilen und Urlaubsangeboten für alle Beschäftigten, aktive wie pensionierte;
- die „Pannoniqa App“, eine mobile App mit Schichtinformationen und internen Neuigkeiten, nur für aktive Mitarbeitende.
Die Menschen von Pannoniqa stehen in drei Quellen: im Personalsystem, in einer Liste der Pensionisten, die die Pensionsabteilung führt, und in einer Liste der Betriebsratsmitglieder.
Baustein 1: Register
Ein Register ist eine Liste von Personen, die Mitglied werden können. Jede Person darin ist durch eine Mitgliedsnummer bestimmt, und dieselbe Person hat in jedem Register der Organisation dieselbe Mitgliedsnummer. Bei Pannoniqa ist das die Personalnummer.
Es gibt zwei Arten von Registern:
- Ein externes Register bleibt im System der Organisation und wird live über die appsolut Register-API abgefragt. Pannoniqa bindet sein Personalsystem als externes Register „SAP HR“ an. Niemand lädt die Gehaltsliste irgendwohin hoch; das Studio fragt SAP, wenn es eine Antwort braucht.
- Ein internes Register wird im Studio selbst geführt, per Upload oder von Hand. Pannoniqa führt zwei: „Pensionisten“, jeden Monat aus der Tabelle der Pensionsabteilung hochgeladen, und „Betriebsrat“.
Ein Registereintrag enthält die Angaben, mit denen sich eine Person ausweist, etwa Name und Geburtsdatum, sowie einen Status. Einträge können außerdem Gruppen tragen, Bezeichnungen wie „Schichtarbeit“ oder „Lehrlinge“, nach denen später gefiltert wird.
Baustein 2: die Mitgliedschaftsdefinition
Die Register sagen, wer Mitglied sein könnte. Die Mitgliedschaftsdefinition entscheidet, wer es tatsächlich ist. Sie ist eine geordnete Liste von Registerzuordnungen, und das Studio beschreibt sie selbst am besten: „Eine Person wird von oben nach unten in jedem gesucht, und das erste Register, das entscheidet, gilt.“
Jede Registerzuordnung hat ein Ergebnis, „Lässt zu“ oder „Lehnt ab“, und optionale Filter: „Status“, „Gruppen“, „Mitgliedschaftsbeginn“, „Mindestdauer der Mitgliedschaft“ und bei externen Registern „Claim“. Wer die Filter eines Registers nicht erfüllt, wird dort nicht entschieden, und das nächste Register wird gefragt.
Bei Pannoniqa sieht die Mitgliedschaftsdefinition so aus:
- „SAP HR“, Lässt zu. Alle, die das Personalsystem als Beschäftigte kennt, sind Mitglied.
- „Pensionisten“, Lässt zu. Ehemalige auf der Liste der Pensionsabteilung sind ebenfalls Mitglied.
- „Betriebsrat“, Lässt zu. Damit sind auch die seltenen Betriebsratsmitglieder erfasst, die in keinem der beiden anderen Register stehen.
Die Reihenfolge zählt. Wer sowohl in „SAP HR“ als auch in „Betriebsrat“ steht, wird von „SAP HR“ entschieden, weil es zuerst kommt. Deshalb steht die aktuelle, maßgebliche Quelle ganz oben.
Das Ergebnis „Lehnt ab“ ist für Ausnahmen gedacht. Muss Pannoniqa einmal bestimmte Personen ganz von der Mitgliedschaft ausschließen, etwa eine Liste gesperrter Mitglieder, führt es sie in einem internen Register mit dem Ergebnis „Lehnt ab“ und stellt dieses ganz nach oben. Wer dort steht, wird abgelehnt, auch wenn ein späteres Register ihn aufnehmen würde, und ist damit bei keinem Frontend Mitglied. Mitglieder nur von einem bestimmten Frontend fernzuhalten, ist Sache seiner Community, die weiter unten beschrieben ist.
Vor dem Speichern zeigt der Editor unter „Berechtigte Personen“, wie viele Menschen eine Änderung je internem Register berechtigen würde, und „Mitgliedsnummer testen“ zeigt, wie die ungespeicherte Definition über eine bestimmte Person entscheiden würde. „Speichern und veröffentlichen“ veröffentlicht die Definition dann sofort als neue Version. Jede Version bleibt im „Versionsverlauf“ erhalten, und jede Prüfung vermerkt die Version, unter der sie lief. Die Frage „Warum wurde diese Person im März aufgenommen?“ hat also eine Antwort.
Die Mitgliedschaftsprüfung
Wann immer eine Person nachweist, wer sie ist, führt das Studio eine Mitgliedschaftsprüfung gegen die Definition durch. Das geschieht in drei Situationen:
- wenn jemand Mitglied wird und im Schritt „Mitgliedschaft bestätigen“ von Login with appsolut Mitgliedsnummer und Angaben eingibt;
- bei jeder späteren Anmeldung, nur mit der gespeicherten Mitgliedsnummer, sodass jemand nach dem Austritt bei der nächsten Anmeldung den Zugang verliert;
- wenn das Backend einer Website oder App fragt, ob eine Person berechtigt ist, ohne dass sie sich anmelden muss.
Die Antwort ist immer eine von dreien: gültig, nicht gültig oder nicht verfügbar, wenn ein externes Register nicht erreichbar ist. Ein gültiges Ergebnis macht die Person zum Mitglied der Organisation und ordnet sie den Communities zu, zu denen sie gehört.
Baustein 3: Communities
Die Mitgliedschaftsdefinition beantwortet die Frage „Gehört diese Person zu uns?“. Eine Community beantwortet „Zu welchen von uns?“. Sie ist ein benannter Filter über das Mitgliederverzeichnis, und jedes Frontend, also jede Website und App, bei der sich Menschen anmelden, wird von genau einer Community bedient.
Pannoniqa legt drei an:
- „Aktive Mitarbeitende“ mit dem Filter „Register“ auf „SAP HR“. Sie bedient die Pannoniqa App.
- „Pensionisten“ mit dem Filter „Register“ auf „Pensionisten“.
- „Alle Beschäftigten“ ganz ohne Filter. Im Studio heißt es dazu: „Ohne Filter gehören alle Mitglieder dazu.“ Sie bedient das Pannoniqa Portal.
Community-Filter können auch Status, Gruppen und Claims aus externen Registern verwenden. Eine Community „Lehrlinge in der Produktion“ ist also nur einen Filter entfernt. Niemand ordnet Mitglieder von Hand zu: Die Communities eines Mitglieds ergeben sich aus seiner letzten Mitgliedschaftsprüfung, und eine Filteränderung gilt sofort.
Warum Regeln besser sind als Listen
Der Unterschied zeigt sich an dem Tag, an dem sich etwas ändert.
- Jemand tritt aus. Die Person verschwindet aus „SAP HR“. Bei der nächsten Anmeldung ist die Prüfung nicht mehr gültig, und die Pannoniqa App lässt sie nicht mehr hinein. Niemand musste daran denken, sie zu entfernen.
- Jemand geht in Pension. Die Pensionsabteilung nimmt die Person in „Pensionisten“ auf. Sie behält Konto und Mitgliedsnummer, wechselt von „Aktive Mitarbeitende“ zu „Pensionisten“ und nutzt weiterhin das Pannoniqa Portal.
- Ein neues Angebot kommt. HR möchte eine Seite nur für die Schichtarbeit. Das ist eine neue Community mit einem Filter „Gruppen“, keine neue Tabelle.
Jede Prüfung steht im Prüfprotokoll, mit dem antwortenden Register, dem Ergebnis und der Version der Definition, aber nie mit den Angaben, die eine Person eingetippt hat. Prüferinnen und Betriebsrat sehen, dass die Regeln angewendet wurden, ohne dass das Studio mehr personenbezogene Daten aufbewahrt als nötig.
Der Einstieg
Beginnen Sie mit den Quellen, die Sie schon haben. Listen Sie die Systeme und Tabellen auf, die Ihre Menschen kennen, entscheiden Sie, welche davon maßgeblich ist, und stellen Sie diese an die erste Stelle. Benennen Sie dann die Gruppen, die unterschiedliche Angebote brauchen; jede wird eine Community. Die Studio-Dokumentation erklärt jeden Baustein im Detail.