[A2open-diskussion] A2Open

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

Hallo Liste,

ein paar grundsaetzliche Ueberlegungen und Anmerkungen zu Burkhardt:

Wir sind inzwischen nicht mehr stehengeblieben bei dem Gedanken an  
lokale Server. Und das, obwohl dort die von mir so geschaetzten  
"Pralinenschachteln" (also simple Minirechner mit Flash-Laufwerken,  
ohne aktive Kuehlung etc. mit Via-Chipsatz) ausgereicht haetten,  
gerade auch, weil die Via-Loesung die ganze Verschluesselung in  
Hardware geliefert haette. Da waere dann ein fertig konfigurierter  
Server etwa bei 500 EUR gelegen, aber das wenigstens 700 mal macht  
immerhin auch 350000 EUR zzgl. Wartung etc., das ist schlicht zu viel.

Zur Zugriffskontrolle auf den zentralen Datenbankserver hatten wir  
bisher jetzt folgende Ueberlegung:
Es werden Schluessel ausgegeben, wahlweise (je nach installierter  
Hardware vor Ort) auf Diskette, CD oder USB-Stick. Zugriff ist immer  
nur moeglich mit lokal zugreifbarem Schluessel. Da bekommen wir im  
Ernstfall Probleme, wenn irgendwann in einer Dienststelle  
tatsaechlich keine externen Laufwerke mehr ansprechbar sein sollten.  
Dann muessen wir zwangslaeufig auf USB- oder serielle oder ps2- 
Dongles ausweichen, die zwischen Tastaturkabel und Rechner gesteckt  
werden. Auch die kosten nicht die Welt.

Die Schluessel sind eindeutig einer Dienststelle zugeordnet, und jede  
Dienststelle erhaelt zwei "Masterschluessel". Die Schluessel werden  
anbieterseitig nicht Personen zugeordnet (wichtig, da eine indirekte  
Arbeitskontrolle bei vielen Mitarbeitern des oeffentlichen Dienstes  
nicht zulaessig ist), aber die Schluessel werden gegen Unterschrift  
und Pfand durch den Personalrat ausgegeben. Dadurch ist indirekt doch  
eine (auch strafrechtliche) Ahndung bei missbraeuchlichen Zugriffen  
moeglich. Abhandengekommene Schluessel werden zentral gesperrt.

Zugriffsbeschraenkungen:
Schreibenden Zugriff auf einen Datensatz erhaelt ohne irgendwelche  
Einschraenkungen immer der Ersteller (also der mit dem  
Erstellerschluessel autorisierte Rechner).
Vollstaendigen lesenden Zugriff erhalten alle mit einem Schluessel  
der selben Dienststelle autorisierten Rechner. Will einer dieser  
Rechner schreibenden Zugriff, so ist dieser extra anzufordern  
(lediglich ein Klick, aber immerhin eine erste Schwelle). Jeder  
lesende und schreibende Zugriff wird geloggt.

Mitarbeiter anderer Dienststellen erhalten lediglich lesenden Zugriff  
auf die Stammdaten aller Antragsteller (also: Name, Vorname,  
Geburtsname, Geburtsort, vollstaendige Anschrift, Eltern,  
Rentenversicherungsnummer und betreuende Dienststelle). Wollen sie  
weitergehenden Zugriff (z. B. weil jemand dorthin gezogen ist), so  
erhalten sie diesen entweder, indem sie ihn beim Ersteller des  
Datensatzes anfordern (der Ersteller erhaelt eine Nachricht  
"Mitarbeiter xyz der Dienststelle nop will die Bearbeitung des  
Datensatzes von Frau abc uebernehmen. Genehmigen?") oder indem sie  
sich den Zugriff durch den "Masterkey", der zweifach in jeder  
Dienststelle vorliegt. Ab dem Moment wird der entsprechende Antrag  
vollstaendig der neuen Dienststelle zugeordnet, die alte Dienststelle  
hat nun nur noch lesenden Zugriff auf die Stammdaten.

Dies ist keine lueckenlose Zugriffs- und Missbrauchsabsicherung, aber  
eine pragmatische Erschwernis, die es verhindern kann, dass tausende  
Datensaetze illegal genutzt werden. Einfach, weil das zu muehsam  
waere. Und es ermoeglicht im Ernstfall die Ahndung strafrechtlich  
relevanten Missbrauchs.

Zur Software an sich: Zur Erfassung werden im Grunde stur die Daten  
des Antragsbogens erfasst. Dabei wird zu Anfang bei jeder Person, die  
im Antrag steht, ein Datenabgleich durchgefuehrt, um sicherzustellen,  
dass Kinder nicht bei beiden geschiedenen Eltern der  
Bedarfsgemeinschaft angerechnet werden etc.
Dann werden stur die Daten erfasst, bei den einzelnen entsprechenden  
Feldern wird vermerkt, in welcher Form die entsprechenden Daten  
nachgewiesen wurden (z. B. Miete gem. Mietvertrag,  
Unterhaltsverpflichtung gem. duesseldorfer Tabelle bzw. gem. Urteil,  
Mehrbedarf gem. aerztlichem Attest etc. pp.). Und immer der Vermerk,  
ob das Nachweis-Dokument als Kopie der Akte beigefuegt wurde. Bei  
jedem einzelnen Punkt koennen die relevanten Gesetzes- und  
Verfahrensanordnungstexte aufgerufen werden (die muessen also jeweils  
hinterlegt sein) und zum Schluss wird das Ergebnis berechnet. Daraus  
wird ein vorlaeufiger Bescheid erstellt und die gesamten erfassten  
Daten werden auf dem zentralen Server gespeichert.
Was bietet das Frontend noch?
Die Eingabe von Aenderungen mit dem Datum, ab wann (und bis wann) die  
Aenderung wirksam wird (z. B. Zuverdienst, Heirat, Auszug der Kinder  
usw.).
Verwaltung von Bar-, Ueberweisungs- oder Scheckvorschuessen.
Verwaltung von Rueckforderungen, Kuerzungen, Nachzahlungen.
Messaging zwischen den Mitarbeitern und den Dienststellen zu den  
einzelnen Faellen (wie oben schon beschrieben z. B. bei der  
Uebernahme eines Falles)
Darstellung eines Falles im Verlauf (also: Historie eines  
Antragstellers, z. B.).
Anmerkungen und Notizen zum jeweiligen Fall.

Was macht das Backend?
Erfassung und Speicherung der eingegebenen Faelle
Abgleich mit den Rentenversicherungen als Kontrolle wg. paralleler  
meldepflichtiger Beschaeftigung
Abgleich mit den Sozialaemtern (sind beides wohldefinierte  
Schnittstellen, laeuft jeweils ueber die Rentenversicherungsnummer)
Ausloesung der Ueberweisungen (taeglicher "Bericht", der an die  
Buchhaltungssoftware geleitet wird, wohldefinierte Schnittstelle)
Statistik
Historie der einzelnen Verlaeufe
regelmaessiger Bericht an die Rentenversicherungstraeger und  
Krankenkassen

Im Grunde war es das.

Die Verwaltung der Zielvereinbarungen, 1-EUR-Jobs,  
Vermittlungstaetigkeit etc. erfolgt in separaten Loesungen. Das kann  
man zwar Schritt fuer Schritt mit uebernehmen, theoretisch. Aber hier  
gehts erstmal nur um den Funktionsumfang von A2LL.

Ich bin der zuversichtlichen Ansicht, dass Guidos Idee, ein  
Grundprogramm zu erstellen, das seine konkrete Erscheinungsform durch  
definierende Konfigurationsfiles erhaelt, voellig richtig ist. Und  
diese Files koennen meinetwegen als .xml-Files oder in einem anderen  
sinnvollen Format vorliegen. Das muss man nur einmalig festlegen. Das  
Programm an sich laeuft und rechnet dann lokal, die Ergebnisse werden  
zentral gespeichert und zentral verwaltet.
Voraussetzen koennen wir Rechner mit Windows NT ab NT 4 bis NT 5.1  
mit Netzwerkanschluss, entweder ueber Internet oder ueber das  
separate Arbeitsamtsnetz. Es muessen maximal zwanzigtausend Clients  
lesenden Zugriff auf den zentralen Datenbankserver erhalten (ARGEn,  
Dienststellen, Optionskommunen) zum Abgleich, und es existieren  
einige explizite Abfrage- bzw. Datenuebergabeschnittstellen fuer  
andere Software (Rentenversicherungen, Krankenkassen, Sozialaemter,  
Buchhaltungssoftware).

Ist das soweit klar und vernuenftig?

Gruss

Gottwalt