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

[Guido S. <wa...@gm...>]

Hallo.
Das ist ja fast schon ein Lastenheft :-)

> Utopisches Ziel:
> Vollstaendiger Ersatz der derzeitigen A2LL-Software
> Motiv:
> Technologie-Demonstration als Beweis der hoffnungslosen Unfaehigkeit  
> von T-Systems in diesem Projekt

Das stimmt ich 100%ig zu, aber wenn ich (oder ein besserer HTML-Coder) 
unserer Webseite zur Projektpraesentation macht, sollten wir es 
vielleich etwas diplomatischer formulieren. Andererseits.....seit wann 
bin ich diplomatisch? ;-)

> Realistisches Ziel:
> Bereitstellung eines freien Tools zur Nutzung durch ALG-2-Empfaenger  
> zur Bescheidberechnung

Waere schoen, wenn das als wichtiges Teilziel festegelegt wird. 
T-Systems eins auszuwischen, ist ein wunderbares Motiv. Die eigene 
Arbeit real benutzt zu sehen, doch etwas befriedigender. 

> Referenz fuer die Beteiligten
> Kenntniserweiterung und -vertiefung der Beteiligten
> Module:
> Frontend:
> Programm interpretiert Strukturen, die durch xml-Dateien vorgegeben  
> werden. Dadurch wird die benoetigte Funktionalitaet zur Berechnung,  
> Speicherung und Verwaltung der Arbeitslosengeld-2-Antraege und  
> Bescheide zur Verfuegung gestellt.
> Dies beinhaltet insbesondere (schrittweise analog zur gedachten  
> Arbeitsweise):
> Login beim Datenbankserver mit Zugriffsgenehmigung
> ? Ueberpruefung der Antragstellerdaten auf bereits gestellte Antraege  
> oder andere Widerspruechlichkeiten, die sich aus den Daten des  
> Datenbankservers ergeben
> ? Erfassung aller antragsrelevanten Daten
> ? Vorlaeufige Berechnung des Leistungsanspruches
> ? Speicherung der gesamten erfassten Daten und berechneten Ansprueche  
> auf dem zentralen Datenbankserver, ersatzweise voruebergehend lokal
> ? Veranlassung bzw. Verwaltung von Vorschuessen,  
> Berechnungsaenderungen, nachtraeglichen Anrechnungen von  
> Zuverdiensten etc.
> Als Implementierung ist angedacht: Schluessel werden durch den  
> Personalrat an die Mitarbeiter gegen Unterschrift ausgegeben. Die  
> Schluessel sind seitens des Softwarebetreibers einzelnen  
> Dienststellen, aber nicht einzelnen Mitarbeitern zugeordnet, um die  
> Anforderungen des Personalrats an anonymisierte Nutzung des Systems  
> zu gewaehrleisten und gleichzeitig unbefugte Zugriffe zu minimieren.
> Schluessel werden beim ersten Login durch ein frei waehlbares  
> Passwort des Sachbearbeiters "aktiviert". Das heisst: Ab diesem  
> Moment ist das Schluesselmedium nur zusammen mit dem bei jedem Login  
> einzugebenden Passwort nutzbar.
> Nach dem Login stehen folgende Optionen bereit:
> ? Status abfragen (also: Existiert zu bestimmten Personen bereits ein  
> Antrag, ein Bescheid etc.?)
> ? Neuantrag erfassen
> ? Antrag bearbeiten / Folgeantrag stellen
> Bei der Statusabfrage kann mit den Kriterien  
> Rentenversicherungsummer, Vorname, Name, Geburtsdatum, Meldeadresse,  
> Geburtsname, Geburtsort, Namen der Eltern abgefragt werden.
> Hier erhaelt man auch keine weiteren Informationen.
> Beim "Neuantrag" steht die Statusabfrage fuer alle Mitglieder der im  
> Antrag genannten Bedarfsgemeinschaft am Anfang, anschliessend werden  
> mit einem Layout voellig analog zum Antragsbogen alle dort  
> eingetragenen Daten uebernommen. Dabei stehen dem Sachbearbeiter zu  
> den einzelnen Eingabe- und Optionsfeldern jeweils die relevanten  
> Gesetzes- und Verfahrensanordnungstexte hinterlegt zur Verfuegung  
> (dies ist ein erheblicher Sorgfaltsaufwand!).

Nicht mehr oder weniger grosser Sorfaltsaufwand, als fuer die zu 
interpretierenden in XML gegossenen Regeln, die die Berechnung machen. 
Ich finde, das ist eine gute Idee und hilft uns auch bei der Entwicklung 
der Regeln, wenn gleichzeitig der Gesetzestext mit eingebunden wird.


> Bei allen erhobenen  
> Daten kann -wie auch auf dem Papierbogen- vermerkt werden, wodurch  
> die Daten belegt wurden und ob eine Kopie des belegenden Dokumentes  
> erstellt und der Akte beigefuegt wurde.

Wird das derzeit schon gemacht? Ich meine, wird das bereits in der 
vorhandenen A2LL Datenbank abgespeichert? Brauchen wir dazu Freiform, 
oder koennen wir eine feste Auswahl von Moeglichkeiten, wie ein 
bestimmtes Datum belegt werden kann z.B. per ListBox anbieten?

> Zum Abschluss der Erfassung wird der Anspruchsbetrag berechnet, ein  
> vorlaeufiger Bescheid erstellt und die Daten auf dem Datenbankserver  
> gespeichert. Bei Netzwerk- oder Serverausfall entfaellt hierbei die  
> Statusabfrage und die zentrale Speicherung, ersatzweise wird auf dem  
> lokalen Rechner zwischengespeichert. Bei der naechsten Verbindung zum  
> Server werden automatisch die lokal gespeicherten Daten erstmal  
> ueberprueft (automatisierte Statusabfrage aller Personen der  
> Bedarfsgemeinschaft), falls keine Konflikte dabei auftreten werden  
> die Daten vom Sachbearbeiter unbemerkt zentral gespeichert. Ansonsten  
> wird eine Fehlermeldung ausgegeben und die erneute Bearbeitung des  
> Falles verlangt.
> Bei "Antrag bearbeiten / Folgeantrag erstellen" werden die zur  
> Vorgangsnummer gehoerenden Daten dem Frontend uebermittelt, in  
> folgenden Abstufungen: Wurden die Daten mit dem jetzt auch  
> verwendeten Schluessel damals gespeichert, so werden sie einfach zur  
> Bearbeitung freigegeben ohne weitere Nachfrage. Werden die Daten von  
> einem anderen Schluessel der selben Dienststelle angefordert, wird  
> nachgefragt, ob man wirklich bearbeiten moechte. Werden die Daten von  
> einem Schluessel einer anderen Dienststelle angefordert, so werden  
> lediglich die Daten lesend angezeigt, die man auch in der  
> Statusabfrage sehen kann.

Kennst du dich so gut aus, dass du beurteilen kannst, dass wir da nicht 
evtl. voellig an den Beduerfnissen der Aemter vorbei designen? Ich 
wuerde gerne mit jemanden aus einem Arbeitsamt sprechen. Tja, bisher hat 
sich noch niemand auf meine Emails gemeldet. So richtig Interesse 
scheint bei denen nicht zu bestehen.


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

Ich habe halt Angst, dass es evtl. boeses Blut geben koennte, wenn ein 
MA seine Daten eingibt, 2 Wochen in Urlaub faehrt, und wenn er 
zurueckkommt aus irgendwelchen Gruenden ploetzlich nur noch Lesezugriff 
hat. 

> Durch den obigen Vorgang koennen die Bearbeitungs-Zugriffe erheblich  
> eingeschraenkt werden, und zwar auf die wirklich zustaendige  
> Dienststelle, und lesende Zugriffe sind ausser bei den von der  
> eigenen Behoerde bearbeiteten Faelle nur auf die "oeffentlichen"  
> Stammdaten moeglich.
> Durch das Logging aller Zugriffe und die indirekt moegliche Zuordnung  
> eines Schluessels zu einem bestimmten Sachbearbeiter (ueber den Umweg  
> Personalrat) ist immerhin bei deliktischen Vergehen auch eine Ahndung  
> moeglich.
> So wird die Schwelle fuer Datenmissbrauch erheblich hoeher gesetzt  
> als bei der derzeitigen Loesung, auch wenn Datenmissbrauch nicht  
> ausgeschlossen wird. Die Schwelle noch hoeher zu setzen erscheint vom  
> Verwaltungsaufwand her und wegen des fehlenden Zugriffs auf die  
> Hardware vor Ort in den Dienststellen nicht umsetzbar.
> Was muss das Frontend noch koennen?

> Messaging zu anderen Sachbearbeitern, Dienststellen und Helpdesk

Ist das sinnvoll? Unser Programm ist eines von vielen, die auf den 
Rechnern der Bearbeiter laufen. Muss denn gerade unseres Email-Client, 
Messenger, Kaffeemaschine (ok, Uebertreibung) sein? Messaging sehe ich 
zwar als einen moeglichen, aber doch ganz erheblich aufwendigen 
Nebenkriegsschauplatz an. Wie stellst du dir die Realisierung vor? Aus 
dem Programm Emails zu verschicken, halte ich dagegen als relativ gut zu 
implementieren, was das Kosten/Nutzen-Verhaeltnis angeht.  

> Darstellung der gesamten Historie eines Vorganges
> Mannigfaltige Bearbeitungs- und Gespraechsvermerke
> Leistungsminderungsverwaltung
> Backend:
> Loginserver. An diesem melden sich die Clients mit einem Zertifikat  
> als "Benutzername" und einem "Passwort" an. Der Login-Server  
> uebergibt das Zertifikat zur Ueberpruefung an den Cert-Server und  
> reicht nach dem "ok" die Verbindung an den Datenbankserver weiter.  
> Einen dazwischenliegenden AppServer zur Bearbeitung der Abfragen etc.  
> wuerden wir gerne vermeiden, da es sich ausschliesslich um  
> unabhaengige simple Such- (Lese-) und Schreibprozesse handelt, die  
> einfach abhandelbar sind und die eigentliche Berechnung auf den  
> Clients erfolgt.
> Cert-Server:
> Hier sind die Zertifikate gespeichert und hier werden die abgefragten  
> Zertifikate auf ihre Gueltigkeit hin ueberprueft. Hier erfolgt auch  
> die Gruppen-Zuordnung (dienststellenweise) der einzelnen Zertifikate,  
> und hier wird auch bestaetigt, ob es sich um ein "normales"  
> Zertifikat handelt oder um einen "Masterkey". Diese Information wird  
> an den Login-Server zurueckgegeben, der die Verbindung entsprechend  
> an den Datenbankserver weiterreicht.
> Datenbankserver:
> Dieser speichert alle Antrags- und Bescheiddaten, generiert taegliche  
> "Berichte" als Ueberweisungsauftrag an die Buchhaltungssoftware  
> (anscheinend immer noch EDIFAKT), an die Krankenkassen (ebenfalls  
> anscheinend noch EDIFAKT), an die Rentenversicherer und die  
> Sozialaemter. Diese Berichte werden bereitgestellt und abgeholt.
> Monatlich und jaehrlich werden diverse statistische Auswertungen  
> generiert.
> Laufend werden die Abfragen des Frontends und der Sozialaemter,  
> Optionskommunen, Rentenversicherer ("Statusabfragen") beantwortet  
> sowie die Neuantraege und Aenderungen bestehender Antraege  
> gespeichert. Fuer die Sozialaemter, Optionskommunen und  
> Rentenversicherer muss ein wohldefiniertes Abfrage-Interface  
> bereitgestellt werden, das exakt die Funktionalitaet der  
> Statusabfrage abbildet und in andere Software einfach implementiert  
> werden kann.
> 
> Fuer Berichte, Statistiken und Wartungsarbeiten stehen die Naechte,  
> Feiertage und Wochenenden zur Verfuegung, sodass diese nicht waehrend  
> des laufenden Betriebes zusaetzliche Last oder Ausfallzeit erzeugen.
> 
> Soweit bisher, mit der Bitte um Ergaenzungen

Damit sind wir schon recht weit. Ich veruche mal daraus etwas 
graphisches zu machen, damit wir wenigstens eine einfach Webseite haben, 
auf die wir Interessenten verweisen koennen.

Gruesse,
Guido