Anwendungen

Hier ein Teil der Anwendungen und Themengebiete an denen ich für das Rathaus Bregenz arbeiten konnte:

Mein erstes Projekt f. Bregenz: die Stadtmarketing Bregenz braucht auf ihrer WebSite einen DB-gestützen Veranstaltungskalender mit Suche, Kategorien etc. plus einem WartungsInterface zum Befüllen und automatischem Import von Veranstaltungsdaten aus dem Termin-Management System des Festspielhaues.

Wir wollen Erfahrungen mit opensource Techniken machen und verwenden den ZOPE Anwendungsserver als Basis; mit seinen Vererbungs-Mechanismen baue ich das Benutzerfrontend so, daß auf unterschiedlichen WebSites der selbe Code mit unterschiedlichem Layout (Css, Wording etc) benutzt wird.

Einsatz auf den Sites der Stadtmarketing Bregenz und des Rathauses.

Aufgabe: eine WebSite mit Contentmanagement erstellen für die rathaus-interne Kommunikation der Mitarbeiter im IntraNet

Umsetzung mit opensource Contentmanagement-System OpenCms ab V 5.0.

Umfang:

• Installation
• Umsetzung des vorgegebenen Layouts nach Vorgabe von der GrafikerIn
• Adaptierung der NavigationsKlassen
• Anbindung der Luzene-Suchmachine
• Schulung der Redakteure
• diverse kleine WebAnwendungen als JSP-Seiten im Layout von BregenzIntern integriert (Berichte und Etiketten etc, WebFront zur Anlagebuchhaltung)
• später Upgrade von OpenCms 5.x auf 6.2

Für das EDVneu-Projekt in Bregenz waren wir längere Zeit auf der Suche nach nach Partnern, die effiziente Softwareproduktions-Werzeuge in das Projekt einbringen - wir waren auf der Suche nach einer offenen Lösung, mit der wir leicht, kostengünstig und effizient unterschiedliche Geschäftsprozesse umsetzen können, die unserer Vision der kommunalen Anwendungslandschaft (entsprechend der BITL-Vision) entsprechen; insbesondere sollten beliebige Geschäftsprozesse abgebildet werden können, Dienst-Aufrufe als Server und als Client möglich sein, und es sollten die diversen dringend benötigten Infrastrukturdienste einfach und billig einzubinden sein.

So sind wir in Kontakt mit der bayrischen Firma 'daidalos' gekommen, die um ihren Verarbeitungskern und dem dazu passenden generischen betriebswirtschaftlichen DatenModell (großartige Sache!!) eine Reihe von Werkzeugen für Abbildung und Ausführung von Geschäftsprozessen auf konzeptionell sehr hoher Stufe hatte.

Was uns ausserdem gefallen hatte war, daß mehrere mit diesem Toolset modellierte Geschäftsprozesse letzendlich ins selbe Datenmodell abgebildet wurden, wodurch schrittweise ein einziger, semantisch homogener Datenhaushalt über alle diese Prozesse entsteht - genau das, was Bregenz für die Verwaltungsreform und im Speziellen für die KLR gesucht hatte.

In der Folge haben ich daher für Bregenz zwei Prototypen mit den daidalos Werkzeugen erstellt:

• Den ersten sehr beschränkten und kleinen Prototypen eines Stammdaten-Dienstes: Personen- und Adressdaten in einer zentralen Anwendung, mit Dialogen/Masken zum Anlegen und Ändern von Personendaten, ansprechbar über ein SOAP-Api.
• Als zweites einen Prototypen für die Fachanwendung Kanalbescheid, der gleichzeitig der erste Client zum provisorischen Stammdaten-Dienst war.

Die Programmierung auf konzeptionell sehr hoher Stufe war nur mäßig erfolgreich, da ich mich recht lange in ein völlig neues Paradigma hatte einarbeiten müssen - mit gutem Erfolg für die Standard-Probleme, aber absolut ohne Aussicht, uns selber bei diversen Technischen Details helfen und gestalten zu können. Ausserdem hatten wir einige (kleinere) Probleme mit der Dienst-Kommunikation. Viel drastischer war allerdings, daß daidalos in Konkurs ging und wir die Partnerschaft umsonst begonnen hatten.

Vorrausetzung für dieses Projekt war die Änderung der Abschreibungsvorschriften für hoheitliches Anlagevermögen und die Unmöglichkeit, diese neuen Anforderungen in der damals benutzten Software abzubilden oder eine entsprechende Änderung der Software zu erwirken. Im Rahmen des KLR-Projektes der Stadt habe ich eine kleine provisorische Anlagenbuchhaltung entwickelt - als Übergangslösung bis zur Einführung der geplanten neuen Finanzsoftware, die dann später aus Budgetgründen abgesagt wurde.

Die Umsetzung erfolgte

• als Desktop-Db Anwendung (Access) mit der Datenbank am zentralen SqlServer,
• mit Berichten über den ReportMan WebReport-Server,
• mit einer WebAnwendung auf der IntraNet-WebSite auf der die Dienststellen die Bestände in ihren Bereich selbst korrigieren können (plus Bestätigung durch die Buchhaltung),
• mit Einzel- & Stapelbuchungen für einzelne Anlagegüter oder ganze Objekte und Bereiche; jährliche Abschreibungsläufe, Jahresabschluß, einmalige Umstellungsbuchung von den alten auf die neuen Bewertungs- und Abschreibungs-Richtlinien.

In der folge war Bregenz die erste Gemeinde in Voralberg, deren AnBu den neuen Vorschriften entsprecht (2Jahre vor der Frist) und die ihre Anlagegüte entsprechend umbewerten konnte (mit hochwünschenswerten Effekten auf die damalige Billanz).

Vorraussetzung: im neuen WebAuftritt der Stadt (ein fremdes Projekt) sind alle Vereine in Bregenz über eine DB verfügbar, die Dienststelle für die Vereine pflegt die Daten über eine Wartungs-Schnittstelle.

Aufgabe: Nutzbarmachen der gepflegten Daten für die tägliche Büroarbeit der Dienststelle - gewünscht sind vor allem Adress-Ettiketten und ein Stammdaten-Blatt mit allen Daten eines Vereins.

Umsetzung: Zugriffskontrolle und Aufbereitung der Parameter in einer kleinen JSP-Anwendung im IntraNet, Erstellung der Berichte am ReportMan WebReport Server.

Eine Zeit lang haben wir die Ettiketten auch am Desktop mit OpenOffice gemischt, weil dabei mehr Flexibilität beim Filtern und sortieren besteht - dies wurde aber von den Anwendern nicht gut angenommen (selten genutzt, Flexibilität nicht benötigt, der Vorgang ist 'freihändig' zu komplex). Wir haben darum später auf nicht filterbare Ettiketten vom BerichtsServer umgestellt und nun sind alle zufrieden.

Anforderung: das Rathaus braucht eine WebAnwendung zum Führen der Journale für die Bargeld-Kassen in den Dienststellen. Sie soll vollständiges Buchungsmaterial für d. Hauptbuchhaltung zur Verfügung stellen (Kontierung) und soll für die verscheidenen zukünftigen Fachanwendungen eine dienstfähige Schnittstelle für 'Nebenbuchhaltungen' der Hauptbuchhaltung bieten.

Die Kassen sind entweder Handkassen mit kontierten Ein- und Ausgangs- Buchungen unter Verwendung des Kontenplanes der Hauptbuchhaltung.

Oder sie sind Gebühren-Verzeichnisse mit fixer Kontierung, mit Aufteilung der Eingänge in Gebühren f. Bund, Postgebühren und Gebühren der Gemeinde. Gebühren-Verzeichnisse wicklen in erster Linie die Eingänge im Parteienverkehr ab (bar oder über Zahlscheine) - mit ca monatlichen Ausgängen zur Abschöpfung und mir Unterstützung zur Verfolgung der BankEingänge durch die Buchhaltung (unter Zuordnung zu den Zahlscheinen).

Die Anwendung wurde in Java als Dienst (SOAP) ausgeführt (mit apache Axis als Soap-Bibliothek), das erlaubt beliebigen Fachanwendungen eine eigene Kassa zu führen. Und es gibt einen generischen Client als WebAnwendung dazu, der von den Dienststellen vor allem für die Gebührenverzeichnisse verwendet wird

Der KassenDienst ist nun seit Frühling 06 im Einsatz, allerdings nur für Gebührenverzeichnisse und nur über den WebClient - leider hatte es rund um die Behandlung von Handkassen einige Unklarheiten gegeben und als es eine längere Zeit zu keinen Entscheidungen gekam, wurde beschlossen, vorerst nur die Gebührenverzeichnisse zu betreiben - dabei ist es dann bis jetzt (Juni 07) geblieben.

FormularServer sind im E-Government zu einem festen Bestandteil geworden - sie erlauben nur durch Bedienen einer Anwendung die Erstellung und Benutzung E-Government-Formularen. Der FormularServer sorgt als zentrales Werkzeug dafür, daß die Formulare dem StyleGuide des österreichischen E-Government entsprechen, und er ist die zentrale Komponente von der aus die MOA-Module des Bundes angesteuert und die Funktionen der Bürgerkarte abgewickelt werden.

Die Vorteile eines zentralen FormularServers im E-Government liegen auf der Hand und so hat Bregenz für sein E-Government den Anecon-FormularServer angeschafft; ich habe in der Folge in diversen Treffen der UserGruppe die bregenzer Sichtweise vertreten.

Der Nachteil der (damals aktuellen) Lösungen war aus unserer Sicht, daß es damals keine architektonisch nachhaltigen Ansätze gab, wie die Formulare an die Geschäftsprozesse im BackOffice angebunen sein sollen; Standard war und ist die Zustellung der sigierten Formular- Eingänge per Mail an die Sachbearbeiter - was aus unserer Sicht einen weiteren Medienbruch mit all seinen unerwünschten Folgen darstellt.

Dieser Forderungen entsprechend hat Bregenz von einem Kollegen einen generischen Eingangs-Dienst bauen lassen, der die Eingänge vom FormularServer im BackOffice als Soap-Dienst entgegen nimmt und (mit Transaktions-Nummern bestätigt) in einer DB abspeichert. Bregenz hat dazu extra eine Erweiterung des Anecon FormularServers in Auftrag gegeben und den anderen Usern zur Nutzung angeboten.

Zur internen Weiterverteilung der Anträge habe ich dann später den Eingangs-Verteiler als WebAnwendung und zur Benachrichtigung per Email gebaut.

Entsprechend haben wir passend zur Architektur der BITL, der Bregenzer IT-Landschaft, formuliert, daß der Formularserver für uns als der Frontend-Controller im Sinne einer schichgetrennten MVC-Architektur zu verstehen sei - weitere Controller für andere Kanäle (Vioce/Telefon, Fax, Palm, WAP-Handy usw) wären die logische Konsequenz.

Wir haben diese Ideen einige Zeit lang über Vorträge in Gremien und UserGroups zur Diskussion gestellt und haben inoffiziell viel Bestätigung und Zustimmung erhalten, konnten aber leider in den Gremien keine Diskussion über diese Dinge und schon gar keine entsprechende Zielsetzung bei den gemeinsam finanzierten Produkten erreichen - das Thema Architektur war den anderen Anwendern von FormularServern (des AFS) einfach nicht wichtig genug.

Bregenz hat sich darum entschlossen, alleine in diese Richtung weiterzugehen und wir haben uns auf die Suche nach aufgeschlosseneren Produzenten und für die Zukunft geeigneteren Produkten gemacht. Über einen Tip der Zertifizierungsstelle für das E-Gov Gütesiegel (dem IKT-Board) sind wir so zu einem alternativen FormularServer gelangt, der als eine für die E-Gov Zwecke konfigurierte Instanz des Mozart Presentation Framework der Fa Plot entstanden ist.

So wurde binnen weniger Treffen die Fa Plot aus Wien zum EDVneu-Partner und in Bregenz wurde der FormularServer ausgetauscht. Mit diesem neuen und vor allem Dienst-tauglichen FormularServer hat Bregenz dann bald eine Technologie-Demonstration erstellen lassen und später auf Tagungen vorgeführt: durch eine Sequenz von Formularen vom Plot-FormularServer wurde ein E-Gov konformer Bürgerprozess im Web gegen einen in Bregenz als Dienst laufende FachAnwendung (Kanelbescheid) umgesetzt, in dem ein Bürger den Status seines Verfahrens im Web abfragen konnte.

Als Ergänzung zum Eingangs-Dienst, der die Eingänge des FormularServers im BackOffice entgegennimmt, habe ich dann später den Eingangs-Verteiler gebaut. Er liest die Daten aus der DB des Eingangs-Dienstes, kennt die Zuständigkeit der Schabearbeiter zu den einzelnen Formularen, er versendet dazu optional Benachrichtigungen per Mail und er zeigt den Sachbearbeitern ihre nicht noch nicht bearbeiteten Antragseingänge an .

Die Umsetzung erfolgte als gescriptete Webanwendung in Groovy mittels Groovy Server-Pages (GSPs) und GSQL.

eine der dringenden Forderungen der BITL ist die nach einem zentralen Dienstes mit richtigen und aktuellen Daten der Personen und ihrer Adressen - die Fachanwendungen sollen dabei dann selbst keine Personen und Adresse mehr erfassen und warten, sondern ihre Geschäftsfälle (datenschutztechnisch sicher!) mit den aktuellen Daten im Dienst verknüpfen.

Es gibt also im ganzen Amt eine einzige Anwendung mit der Hoheit über die Daten - im Rathaus i.d.R. die Fachwendung des MeldeAmtes. Die anderen Anwendungen haben keine Dialoge zum Anlegen oder Bearbeiten der Daten, sie können nur in den Daten des Dienstes suchen, den gewünschten Satz auswählen und als Referenz in die eigenen Sätze einbinden; im Sinne eines Cache können die Daten auch in der Anwendung gespeichert, nie aber bearbeitet oder gar geändert werden.

Bregenz hat etwa im Jahr 2005 mit grosser PR die 'moile City' eingeführt: verscheidene Dienste rund ums Handy und SMS - ein Teil davon ist die Parkabgabe via SMS.

Bei der Einführung wurde ganz auf die Geschäftsprozesse der Stadtpolizei vergessen, so daß die Dienststelle nach Einführung des neuen Systemes plötzlich keinerlei Unterstützung beid er Verwaltung der Parkspnder hatte. Ich habe daher eine kleine Desktop-Datenbank in Access gebaut, die seither bei hoher Zufriedenheit im Einsatz ist.

Als bislang letztes großes Projekt in Rahmen von EDVneu habe ich seit Ende 2006 eine WebAnwendung für das WohnungsAmt im Rathaus Bregenz gemacht, die unsere Ziele bislang am konsequentesten und mit den besten Resultaten umsetzt und die bereits viel Lob erhalten hat, obwohl sie aus Budgetgründen noch nicht fertiggestellt ist (Stand Juni 07).

Die Entwicklung in GRAILS hat sich mehr als gelohnt und ich kann dieses Toolset für weitere Webanwendungen nur wärmstens empfehlen!

Auch im Entwurf sind wir mit dieser Anwendung unserem Ziel einen Riesenschritt weitergekommen, denn erstmals kann die FachAnwendung relevante Aufgaben an verschiedene Intragstruktur-Dienste delegieren und sich überwiegend auf den Geschäftsprozess konzentrieren. Besonders die Verfügbarkeit des Stada-Dienstes und der Ots-Suite mit Dms3 Dokumenten-Management und der E-Akte haben uns erlaubt, mit dieser Anwendung völlig neue Wege zu gehen:

• Die Anwendung speichert selbst keine Historien, Version von Objekten, alte Zustände oder Journale! Das DatenModell ist ganz flach gehalten und speichert nur den aktuellen Zustand des Objektes ab.
• Bei Abschluß jedes Anwendungsfalles erstellt die Anwendung einen Beleg mit den relevanten Daten und speichert ihn im DMS, wo er für 500 Jahre garantiert dokumentenecht und unabhängig von der erstellenden Anwendung auf Laserfilm archivierbar ist.
• Die E-Akte Webanwendung der OTS macht die Dokumente im DMS aus fachlicher Perspektive für alle anderen als die Sachbearbeiter zugänglich, vor allem für die politischen Entscheider und die Partner im Land und in den Wohnbauträgern.
  
  Ausserdem können in die E-Akte vom Sachbearbeiter noch beliebige weitere Dokumente verspeichert werden, wie zB Entscheidungshilfen (Berechnungen in Excel), gescannte handschriftliche Weisungen, gescannte Eingaben, Fotos, etc. Der Geschäftsprozess kann dadurch viel felxibler gestaltet werden.
• Die Anwendung ist als Client zum StaDa-Dienst ausgeführt und verwaltet als solche keine Personen- oder Adress-Daten - diese kommen aus der Anwendung des Einwohnermeldeamtes, das die vollkommene Hoheit über die Daten hat.
• Erstellung der PDF-Belege erfolgt durch Ansteuerung von OpenOffice im ServerModus aus Vorlagen, die die Sachbearbeiter selbst bearbeiten und in die Anwendung hochladen können.
• Alle Wohnungen sind mit GIS-Schlüsseln versehen und das GIS kann aus der Anwendung direkt aufgerufen werden.
• Angedacht und geplant (aber biskang noch nicht finanziert) ist der Anschluß der Anwendung an den dualen Zustelldienst und an den Portalverbund des Landes Vorarlberg.