Competence Center eGovernment - Projekte

Projekt DUS:DLR

Zur Umsetzung der EU-DLR wurde das Projekt „DUS:DLR – die Landeshauptstadt Düsseldorf auf dem Weg zur Umsetzung der EU-Dienstleistungsrichtlinie“ initiiert.

Das Projekt wurde zu Beginn in den klassischen 4 Projekt-Phasen geplant.

Im Rahmen dieses Projektes wurden diverse Online-Formularerweiterungen getestet. Diese Tests sind nunmehr erfolgreich abgeschlossen. Die Online-Gewerbe-Anmeldung ist unter anderem im Virtuellen Mittelstandsbüro und im allgemeinen Formularservice der Landeshauptstadt Düsseldorf erreichbar und verbindet das funktionserweiterte Online-Formular nun medienbruchfrei mit der Fachanwendung in der Gewerbemeldestelle.

Vorgehensmodell DUS:DLR

Zur Durchführung des Projektes wurde das im folgenden näher bechriebene Vorgehensmodell erarbeitet sowie im Laufe des Projektes fortentwickelt. Die Abbildung zeigt das entwickelte Vorgehensmodell im Überblick. Es umfasst die spezifizierten vier Projekt-Phasen mit jeweils korrespondierenden Teilaktivitäten. Dieses Modell ist das Resultat eines iterativen Entwicklungsprozesses eines 8-köpfigen Expertenteams.

Anwendung des Vorgehensmodell im Projekt DUS:DLR

Die Landeshauptstadt hatte die Umsetzung der Anforderungen zur elektronischen Verfahrensabwicklung als Ziel definiert. Die Projektorganisation und der Zeit-, Aktivitäten- und Ressourcenplanung erfolgte nach den gängigen Regeln zum Projektmanagement mit durchgängiger Dokumentation im Rahmen des im weiteren beschriebenen Vorgehensmodells.

• Phase 1: Anforderungen und Zielsetzungen
  Die Projektinitiierung repräsentiert den Projektstart und leitet die Aktivitäten des Vorgehensmodells ein. Im Rahmen der Voruntersuchung erfolgt zunächst eine Standortbestimmung und es werden die Rahmenbedingungen des Projektes (organisatorische, fiskalische, politische) eruiert und festgelegt. Kernanforderungen zur Umsetzung der elektronischen Verfahrensabwicklung gemäß der EU-DLR sind technikbezogen (Abschnitt 2) und somit als technische Basisfunktionalitäten und Dienste zu berücksichtigen. Die Ausprägung des Technisierungsgrades der elektronischen Verfahrensabwicklung (DOL 2008, Stufe 1, 1a oder 2) ist projektindividuell festzulegen; in Düsseldorf wurde die Stufe 2 realisiert. Den Anforderungen folgen die Festelegung der Zielsetzungen und die Phasenplanung.
• Phase 2: Analyse, Bewertung und Konzeption
  Im Rahmen der Analyse werden die unternehmensbezogenen Produkte und Prozesse identifiziert und dargestellt. Für die Ist-Modellierung bieten sich Beschreibungssprachen an, die durch Modellierungswerkzeuge technisch unterstützt werden. Aufgrund der im Regelfall geringeren Methodenkompetenz von Mitarbeitern in Fachbereichen sind für diesen Adressatenkreis leicht verständliche grafische Modelle hilfreich. Die Bewertung der Prozesse im Rahmen einer Schwachstellenanalyse nimmt hierbei eine bedeutende Rolle ein, um Verbesserungspotentiale erkennen und heben zu können. Zur Umsetzung von Prozessoptimierungen bildet das weiter unten beschriebene IPP-Rahmenkonzept die modelltheoretische Grundlage. Weiterer wesentlicher Teil der Konzeption ist ein Schulungskonzept, damit notwendige Kompetenzen aufgebaut und Weiterentwicklungen frühzeitig kommuniziert und vorbereitet werden; bspw. bezogen auf die Verbesserung von Verwaltungsprozessen.
• Phase 3: Design und Implementierung
  Die Teilaktivitäten der Phase 3 repräsentieren den Wechsel von der Konzeptionierung und Modellierung hin zum DV-bezogenen Design der Prozessteile/ -aktivitäten, die als Ergebnisse der Analyse- und Bewertungsphase als Projektzielsetzung zukünftig (teil-)automativ erfolgen sollen. Hier kommt der Auswahl servicebasierter Bausteine eine besondere Bedeutung zu, da das Ersetzen manueller Arbeitsschritte durch wieder verwendbare bausteinbasierte Dienste verschiedenste Optimierungs- und Synergiepotentiale bietet. So kann die, durch einen SOA-Dienst, frei gewordene Arbeitszeit bspw. in die Intensivierung der Bürger- und Unternehmensberatung eingesetzt werden. Die Implementierung umfasst die klassischen Teilschritte über das Prototyping bis hin zur technischen Abnahme.
• Phase 4: Betrieb und Evaluation
  Die Teilaktivitäten des Betriebs untergliedern sich in die Festlegung der dauer-haften Modell- und Prozessverantwortung, über den Pilotbetrieb bis hin zum Produktivbetrieb. Zur Überwachung des Betriebs bietet sich der Einsatz eines Betriebs- und Evaluationsmonitorings an, um systematisch überprüfen zu können, ob und ggf. im welchem Maße die Zielsetzungen dauerhaft erreicht werden. Aktivitätenplanung zur Betriebsstabilisierung und Wartungsmodalitäten sind weitere Teilaspekte. Auch können die zugrunde liegenden Entscheidungsparameter (aus der Analyse- und Bewertungsphase) validiert und für Folgeprojekte konkretisiert und weiterentwickelt werden. In wieweit die Funktionalitäten und die Präsentation der Services (im Frontoffice) den Anforde-rungen der Zielgruppe entsprechen, sollte in Usability-Testings mit den Unternehmen/Bürgern evaluiert werden. Dies bietet weiteres Potential zur Optimierung und Weiterentwicklung der elektronischen Verfahrensabwicklung im Betrieb. Je nach Rahmenbedingungen und individueller Projektziele kann sowohl die Reihenfolge von Teilaktivitäten variieren als auch Teilschritte ganz entfallen. Die Phasenanordnung kann entweder streng sukzessiv aufgebaut sein, aber auch mehrere parallel auszuführende Phasenaktivitäten aufweisen.

Zur Umsetzung wurden 3 Unterarbeitsgruppen eingerichtet, die Teilaspekte in den einzelnen Projektphasen betrachten und Lösungen entwickeln:

• Aufstellung und Evaluation eines Produkt- und Dienstleistungsplanes mit Bezug zur EU-DLR
• Prozessbeschreibung (Organisatorische- und IT-Beschreibung)
• Basisdienste (Dokumentensafe, Metaformularservice etc.)

Modelle und Architekturen

Zur Umsetzung der EU-DLR werden neuartige Konzepte und Architekturen benötigt. Nur mit diesen können Ziele der Richtlinie erreicht werden und die vorhandenen heterogenen Umgebungen neu ausgerichtet werden.

Integriertes Produkt und Prozessmodell

Integrierte Produkt- und Prozessmodelle sind hierzu eine notwendige Voraussetzung, um die IT-systemtechnische Architektur auf die neuen Anforderungen hin ausrichten.

Die vorhandene IT-Infrastruktur wird auf Workflow- und Webfähigkeit hin überprüft. Produkte werden zukünftig auch unter Berücksichtigung dieser Fähigkeiten und Integrationsfähigkeit in Bezug auf eine Dienstebasierte Infrastruktur hin beschafft.

Hersteller bisher in Düsseldorf eingesetzter Verfahren werden bezüglich ihrer Entwicklungen zur Bereitstellung bzw. Öffnung von Datenschnittstellen (insbesondere XML), Implementierung von Konnektoren für eine service orientierte Architektur und allgemeiner Webintegration befragt.

Die effektive Bereitstellung unternehmensbezogener öffentlicher Dienstleistungen erfordert eine Verknüpfung betriebswirtschaftlicher Aspekte, der zur Verfahrensabwicklung eingesetzten Geschäftsprozesse und der technischen Dienste. Dies bedingt eine korrespondierende Produkt- und Prozessarchitektur mit darauf ausgerichteten Anwendungssystemen und IT-Infrastruktur. Die folgende Abbildung stellt die Komponenten eines Integrierten Produkt- und Prozessmodells dar:

Die Umsetzung der EU-Dienstleistungsrichtlinie erfordert, dass die unternehmensbezogenen Dienstleistungen elektronisch verfügbar gemacht werden und auch „aus der Ferne“ in Anspruch genommen werden können. Das entwickelte Integrierte Produkt- und Prozessmodell stellt im Frontoffice über eine Portalkomponente die Unternehmensdienstleitungen so bereit, dass individuelle am Bedarf ausgerichtete Servicepakete durch die Unternehmen zusammengestellt werden können. Das Produktmodell umfasst alle unternehmensbezogenen Verwaltungsleistungen und bildet so die Basis für das Portalangebot. Hinter dem Produktmodell liegen jeweils korrespondierende Prozessmodelle.

Die dienstebasierte Architektur bildet die Basis für die Bereitstellung des Portalangebotes sowie der (Teil-)Automatisierung der Prozesse. Ein wesentliches Ziel eines integrierten Produkt- und Prozessmodells ist die Wiederverwendbarkeit von Prozessbausteinen und Softwarekomponenten. Hieraus resultieren flexiblere Anpassungen bei Prozessänderungen und damit kürzere und kostengünstigere Implementierungszeiten.

Dienste bzw. Services bilden die Basis für die dynamischen Interaktionen innerhalb von Serviceorientierten Architekturen (SOA). Hinter einem Dienst können dabei entweder ein komplexer Geschäftsprozess, ein kleiner Teilprozess oder ein Verarbeitungsschritt stehen. Geschäftsprozesse entstehen dabei über Komponenten hinweg durch eine Orchestrierung der Dienste und Services.

Weitere Erläuterungen zu den im Projekt DUS:DLR erarbeiteten und ständig weiter entwickelten Modellen und Methoden finden Sie in den Beiträgen im Bereich Downloads.