[A2open-diskussion] A2Open-Brainstorm Resumee-Versuch:

[Gottwalt T. <got...@ma...>]

Utopisches Ziel:
Vollstaendiger Ersatz der derzeitigen A2LL-Software
Motiv:
Technologie-Demonstration als Beweis der hoffnungslosen Unfaehigkeit =20
von T-Systems in diesem Projekt
Realistisches Ziel:
Bereitstellung eines freien Tools zur Nutzung durch ALG-2-Empfaenger =20
zur Bescheidberechnung
Referenz fuer die Beteiligten
Kenntniserweiterung und -vertiefung der Beteiligten
Module:
Frontend:
Programm interpretiert Strukturen, die durch xml-Dateien vorgegeben =20
werden. Dadurch wird die benoetigte Funktionalitaet zur Berechnung, =20
Speicherung und Verwaltung der Arbeitslosengeld-2-Antraege und =20
Bescheide zur Verfuegung gestellt.
Dies beinhaltet insbesondere (schrittweise analog zur gedachten =20
Arbeitsweise):
Login beim Datenbankserver mit Zugriffsgenehmigung
=95 Ueberpruefung der Antragstellerdaten auf bereits gestellte Antraege =20=

oder andere Widerspruechlichkeiten, die sich aus den Daten des =20
Datenbankservers ergeben
=95 Erfassung aller antragsrelevanten Daten
=95 Vorlaeufige Berechnung des Leistungsanspruches
=95 Speicherung der gesamten erfassten Daten und berechneten Ansprueche =20=

auf dem zentralen Datenbankserver, ersatzweise voruebergehend lokal
=95 Veranlassung bzw. Verwaltung von Vorschuessen, =20
Berechnungsaenderungen, nachtraeglichen Anrechnungen von =20
Zuverdiensten etc.
Als Implementierung ist angedacht: Schluessel werden durch den =20
Personalrat an die Mitarbeiter gegen Unterschrift ausgegeben. Die =20
Schluessel sind seitens des Softwarebetreibers einzelnen =20
Dienststellen, aber nicht einzelnen Mitarbeitern zugeordnet, um die =20
Anforderungen des Personalrats an anonymisierte Nutzung des Systems =20
zu gewaehrleisten und gleichzeitig unbefugte Zugriffe zu minimieren.
Schluessel werden beim ersten Login durch ein frei waehlbares =20
Passwort des Sachbearbeiters "aktiviert". Das heisst: Ab diesem =20
Moment ist das Schluesselmedium nur zusammen mit dem bei jedem Login =20
einzugebenden Passwort nutzbar.
Nach dem Login stehen folgende Optionen bereit:
=95 Status abfragen (also: Existiert zu bestimmten Personen bereits ein =20=

Antrag, ein Bescheid etc.?)
=95 Neuantrag erfassen
=95 Antrag bearbeiten / Folgeantrag stellen
Bei der Statusabfrage kann mit den Kriterien =20
Rentenversicherungsummer, Vorname, Name, Geburtsdatum, Meldeadresse, =20
Geburtsname, Geburtsort, Namen der Eltern abgefragt werden.
Hier erhaelt man auch keine weiteren Informationen.
Beim "Neuantrag" steht die Statusabfrage fuer alle Mitglieder der im =20
Antrag genannten Bedarfsgemeinschaft am Anfang, anschliessend werden =20
mit einem Layout voellig analog zum Antragsbogen alle dort =20
eingetragenen Daten uebernommen. Dabei stehen dem Sachbearbeiter zu =20
den einzelnen Eingabe- und Optionsfeldern jeweils die relevanten =20
Gesetzes- und Verfahrensanordnungstexte hinterlegt zur Verfuegung =20
(dies ist ein erheblicher Sorgfaltsaufwand!). Bei allen erhobenen =20
Daten kann -wie auch auf dem Papierbogen- vermerkt werden, wodurch =20
die Daten belegt wurden und ob eine Kopie des belegenden Dokumentes =20
erstellt und der Akte beigefuegt wurde.
Zum Abschluss der Erfassung wird der Anspruchsbetrag berechnet, ein =20
vorlaeufiger Bescheid erstellt und die Daten auf dem Datenbankserver =20
gespeichert. Bei Netzwerk- oder Serverausfall entfaellt hierbei die =20
Statusabfrage und die zentrale Speicherung, ersatzweise wird auf dem =20
lokalen Rechner zwischengespeichert. Bei der naechsten Verbindung zum =20=

Server werden automatisch die lokal gespeicherten Daten erstmal =20
ueberprueft (automatisierte Statusabfrage aller Personen der =20
Bedarfsgemeinschaft), falls keine Konflikte dabei auftreten werden =20
die Daten vom Sachbearbeiter unbemerkt zentral gespeichert. Ansonsten =20=

wird eine Fehlermeldung ausgegeben und die erneute Bearbeitung des =20
Falles verlangt.
Bei "Antrag bearbeiten / Folgeantrag erstellen" werden die zur =20
Vorgangsnummer gehoerenden Daten dem Frontend uebermittelt, in =20
folgenden Abstufungen: Wurden die Daten mit dem jetzt auch =20
verwendeten Schluessel damals gespeichert, so werden sie einfach zur =20
Bearbeitung freigegeben ohne weitere Nachfrage. Werden die Daten von =20
einem anderen Schluessel der selben Dienststelle angefordert, wird =20
nachgefragt, ob man wirklich bearbeiten moechte. Werden die Daten von =20=

einem Schluessel einer anderen Dienststelle angefordert, so werden =20
lediglich die Daten lesend angezeigt, die man auch in der =20
Statusabfrage sehen kann. Zur Bearbeitung muss der Sachbearbeiter =20
entweder die Daten durch den zentralen "Masterkey" der Dienststelle =20
freigeben lassen (dadurch wird dieser Vorgang explizit der neuen =20
Dienststelle zugeordnet, die alte Dienststelle erhaelt dadurch nur =20
noch lesenden Zugriff auf die mit der "Statusabfrage" verfuegbaren =20
Daten) oder er schickt eine automatische Anfrage an die bisher =20
bearbeitende Dienststelle. Dort kann dann die Akte von einem =20
Sachbearbeiter explizit fuer die neue Dienststelle freigegeben =20
werden. Auch dann erhaelt die alte Dienststelle nur noch lesende =20
Zugriff auf die in der "Statusabfrage" verfuegbaren Daten.
Hintergrund: Im derzeitigen A2LL ist jeder Datensatz von jedem =20
Mitarbeiter frei einsehbar und jederzeit veraenderbar. Diese Zugriffe =20=

werden weder eingeschraenkt noch wenigstens kontrolliert.
Durch den obigen Vorgang koennen die Bearbeitungs-Zugriffe erheblich =20
eingeschraenkt werden, und zwar auf die wirklich zustaendige =20
Dienststelle, und lesende Zugriffe sind ausser bei den von der =20
eigenen Behoerde bearbeiteten Faelle nur auf die "oeffentlichen" =20
Stammdaten moeglich.
Durch das Logging aller Zugriffe und die indirekt moegliche Zuordnung =20=

eines Schluessels zu einem bestimmten Sachbearbeiter (ueber den Umweg =20=

Personalrat) ist immerhin bei deliktischen Vergehen auch eine Ahndung =20=

moeglich.
So wird die Schwelle fuer Datenmissbrauch erheblich hoeher gesetzt =20
als bei der derzeitigen Loesung, auch wenn Datenmissbrauch nicht =20
ausgeschlossen wird. Die Schwelle noch hoeher zu setzen erscheint vom =20=

Verwaltungsaufwand her und wegen des fehlenden Zugriffs auf die =20
Hardware vor Ort in den Dienststellen nicht umsetzbar.
Was muss das Frontend noch koennen?
Messaging zu anderen Sachbearbeitern, Dienststellen und Helpdesk
Darstellung der gesamten Historie eines Vorganges
Mannigfaltige Bearbeitungs- und Gespraechsvermerke
Leistungsminderungsverwaltung
Backend:
Loginserver. An diesem melden sich die Clients mit einem Zertifikat =20
als "Benutzername" und einem "Passwort" an. Der Login-Server =20
uebergibt das Zertifikat zur Ueberpruefung an den Cert-Server und =20
reicht nach dem "ok" die Verbindung an den Datenbankserver weiter. =20
Einen dazwischenliegenden AppServer zur Bearbeitung der Abfragen etc. =20=

wuerden wir gerne vermeiden, da es sich ausschliesslich um =20
unabhaengige simple Such- (Lese-) und Schreibprozesse handelt, die =20
einfach abhandelbar sind und die eigentliche Berechnung auf den =20
Clients erfolgt.
Cert-Server:
Hier sind die Zertifikate gespeichert und hier werden die abgefragten =20=

Zertifikate auf ihre Gueltigkeit hin ueberprueft. Hier erfolgt auch =20
die Gruppen-Zuordnung (dienststellenweise) der einzelnen Zertifikate, =20=

und hier wird auch bestaetigt, ob es sich um ein "normales" =20
Zertifikat handelt oder um einen "Masterkey". Diese Information wird =20
an den Login-Server zurueckgegeben, der die Verbindung entsprechend =20
an den Datenbankserver weiterreicht.
Datenbankserver:
Dieser speichert alle Antrags- und Bescheiddaten, generiert taegliche =20=

"Berichte" als Ueberweisungsauftrag an die Buchhaltungssoftware =20
(anscheinend immer noch EDIFAKT), an die Krankenkassen (ebenfalls =20
anscheinend noch EDIFAKT), an die Rentenversicherer und die =20
Sozialaemter. Diese Berichte werden bereitgestellt und abgeholt.
Monatlich und jaehrlich werden diverse statistische Auswertungen =20
generiert.
Laufend werden die Abfragen des Frontends und der Sozialaemter, =20
Optionskommunen, Rentenversicherer ("Statusabfragen") beantwortet =20
sowie die Neuantraege und Aenderungen bestehender Antraege =20
gespeichert. Fuer die Sozialaemter, Optionskommunen und =20
Rentenversicherer muss ein wohldefiniertes Abfrage-Interface =20
bereitgestellt werden, das exakt die Funktionalitaet der =20
Statusabfrage abbildet und in andere Software einfach implementiert =20
werden kann.

Fuer Berichte, Statistiken und Wartungsarbeiten stehen die Naechte, =20
Feiertage und Wochenenden zur Verfuegung, sodass diese nicht waehrend =20=

des laufenden Betriebes zusaetzliche Last oder Ausfallzeit erzeugen.

Soweit bisher, mit der Bitte um Ergaenzungen

Gruss

Gottwalt=