DVZ. Konzept. Wissensmanagement in M-V Fachliche und technische Standards VERSION: 1.0. STATUS: freigegeben. VERTRAULICHKEIT: öffentlich

Transkript

1 DVZ. Konzept Wissensmanagement in M-V Fachliche und VERSION: 1.0 STATUS: freigegeben VERTRAULICHKEIT: öffentlich STAND:

2 Inhaltsverzeichnis 1 DARSTELLUNG DER ARBEITSPAKETE Arbeitspaket Arbeitspaket Arbeitspaket IN BEZIEHUNG STEHENDE MASSNAHMEN DOKUMENTENFÜHRUNG ZUSAMMENFASSUNG FACHLICHE STANDARDS IT-Planungsrat NEGS Steuerungsprojekt FIM LeiKa-Leistungsbeschreibungen GK-LeiKa Prozesse Formulare Weiterführende Betrachtungen zu FIM Erste Detaillierungsstufe Zweite Detaillierungsstufe des Zusammenspiels der FIM-Bausteine Dritte Detaillierungsstufe des Zusammenspiels der FIM-Bausteine FIM-Wirkprinzip Doppischer Produktplan Produktrahmenplan und LeiKa Produkte, Prozesse und Leistungen Koordinierungsstelle für IT-Standards XÖV Service der Bundesstelle für Informationstechnik (BIT) XÖV-Konformitätskriterien XÖV-Standards Vorhaben XLeistung XZufi Projekt XD Vorhaben XProzess Vorhaben XFormular öffentlich 2

3 5.9 Amtlicher Gemeindeschlüssel TECHNISCHE STANDARDS Datenmodell XML XML-Schema Kommunikation SOAP WS-Security Web Map Services Web Feature Services Applikationsarchitektur Java Platform Enterprise Edition Service Oriented Architecture ABBILDUNGSVERZEICHNIS TABELLENVERZEICHNIS DOKUMENTENLENKUNG öffentlich 3

4 1 DARSTELLUNG DER ARBEITSPAKETE 1.1 Arbeitspaket Arbeitspaket AP V1.0 Definition fachlicher Standards Inhalt: Definition und Festlegung der Anwendung fachlicher Standards Untersuchung vorhandener Daten und Datenmodelle der in AP 2 untersuchten Entitäten auf Definition notwendiger und optionaler Erweiterungen ( Landesstandard ) Identifikation und Definition von Metadatenstandards (z. B. nach ISO-Normen). Entwicklung von Mustern für Festlegungen und Deklarationen zum Umgang mit den Rechten an den Daten und der Zuständigkeit für die Daten (Verantwortung für Aktualität, Richtigkeit, Vollständigkeit, (Verfügbarkeit), Pflege der Metadaten) 1.2 Arbeitspaket Arbeitspaket AP V1.0 Definition Inhalt: Identifikation und Definition technischer Standards. Untersuchung der vorhandenen Businessund Analyselogik bzgl. der in AP 2 untersuchten Entitäten auf Benennung der zu verwendenden technischen Standards. Entwicklung von Mustern für Festlegungen bzgl. der Zuständigkeit für die Dienste (Verantwortung für die Verfügbarkeit (SLA), Pflege der Metadaten) 1.3 Arbeitspaket Arbeitspaket AP V1.0 Erweiterung der Standards im Kontext der Wissensverteilung Inhalt: Identifizierung vorhandener und benötigter Schnittstellen und Standards. Die in AP identifizierten Systeme und Projekte nutzen bereits spezielle Übertragungsformate und setzten hierbei teilweise auf technische sowie fachliche Standards (D115-XML-Bericht, Infodienste LeiKa) auf. Diese Standards müssen benannt und im Projekt öffentlich 4

5 WiMa M-V berücksichtigt werden. Darüber hinaus sind die weiteren Standards aus AP und gegen die IT-Infrastruktur auf Landes- und kommunaler Ebene zu spiegeln. Eine anschließende Bewertung muss den Einsatz bzw. die Integration weiterer Standards rechtfertigen. öffentlich 5

6 2 IN BEZIEHUNG STEHENDE MASSNAHMEN In der WiMa-Analyse des Arbeitspaketes wurden Maßnahmen identifiziert, die für den Erfolg des Projektes "Wissensmanagement in M-V" relevant sind. Im Kontext dieses Konzeptes stehen folgende Maßnahmen: Nr. Identifizierte Maßnahme aus WiMa-Analyse 6 Grobkonzept für ein zentrales WiMa-System in M-V auf Basis der Ergebnisse der bisherigen Teilprojekte durchführen 15 Grobkonzept für den Anschluss des Projekts Wissensmanagement in M-V an Projekte zum Wissensmanagement auf Bundesebene (FIM, LeiKa, Formularmanagement, NPB) erstellen 16 Konzept erarbeiten zur Integration von Organisations-, Fach- und Prozesswissen aus verschiedenen Quellen in ein zentrales WiMa- System Tabelle 1: Identifizierte Maßnahmen aus [AP: WiMa-Analyse] öffentlich 6

7 3 DOKUMENTENFÜHRUNG Folgende Abbildung zeigt den Aufbau der WiMa M-V Konzepte. Das vorliegende Konzept wird in der Struktur fettgedruckt dargestellt. Für die Erarbeitung der vorliegenden Inhalte sind alle darunter liegenden Konzepte relevant bzw. nützlich. Abbildung 1: WiMa M-V Dokumentenführung öffentlich 7

8 4 ZUSAMMENFASSUNG Dieses Dokument identifiziert fachliche und, die im Rahmen des Projekts "Wissensmanagement in M-V" (WiMa M-V) von Bedeutung sind. Für die Errichtung und den Betrieb der Kooperativen Informationsmanagementplattform M-V (KIM M-V) sind fachliche und zwingend, da mit dem Wort Kooperativ eine verwaltungs(ebenen)übergreifende Nutzung und Integration der Plattform verstanden wird. Dies kann nur gelingen, wenn ein hohes Maß an Interoperabilität vorliegt. Die Interoperabilität ist die Fähigkeit eines IT-Systems mit anderen IT-Systemen zu kommunizieren bzw. zu kooperieren. Ein uneingeschränkter Austausch zwischen verschiedenen IT-Systemen kann nur dann gewährleistet werden, wenn die beteiligten IT- Systeme ein gemeinsames Protokoll bzw. eine gemeinsame fachliche Sprache verwenden, in der die Formate und Reihenfolgen von Nachrichten sowie deren Bedeutung festgelegt sind. Die Festlegung von technischen Standards zielt auf die Nutzung einheitlicher Schnittstellen und Transportcontainer zur weiteren Unterstützung der Interoperabilität. In den Kapiteln 5 und 6 werden die fachlichen und technischen Standards, Standardisierungsgremien und -projekte untersucht und beschrieben, die für die Errichtung der KIM M-V Plattform relevant sind. öffentlich 8

9 5 FACHLICHE STANDARDS Der Bedarf an fachlichen Standards wird stark durch E-Government-Vorhaben getrieben. Im Kern geht es darum, dass Bürger, Wirtschaft und Verwaltung von den Möglichkeiten einer Internet-gestützten Kommunikation profitieren sollen. Nur unter Verwendung fachlicher Standards können verwaltungsübergreifende E-Government-Anwendung ihre Potentiale vollständig entfalten und damit die Öffentliche Verwaltung (ÖV) entlasten. Im Kontext der Projektanforderung (siehe Konzept Informationsdomänen und Relationen ) wurden fachliche Standards und Standardisierungsbemühungen identifiziert, die mit den Domänen Verwaltungsleistungen, Verwaltungsabläufe und Formulare in Beziehung stehen. In den folgenden Kapiteln werden die projektrelevanten fachlichen Standards und Standardisierungsbemühungen beschrieben und die entsprechenden Gremien genannt. 5.1 IT-Planungsrat Der IT-Planungsrat ist das zentrale Steuerungsgremium für die IT von Bund und Ländern. Die Zusammenarbeit von Bund, Ländern und Kommunen im Bereich der IT und des E-Government soll mit einer größeren Verbindlichkeit zum Wohle der Nutzer von Verwaltungsdienstleistungen, Bürgern und Wirtschaftsunternehmen befördert werden. Mit Inkrafttreten des Staatsvertrags zur Ausführung von Art. 91c GG (IT-Staatsvertrag) zum 1. April 2010 hat der IT-Planungsrat als zentrales Gremium für die föderale Zusammenarbeit in der Informationstechnik seine Arbeit aufgenommen. Der IT-Planungsrat löst somit auch die bisherigen Gremien der Bund-Länder übergreifenden IT-Steuerung, den Arbeitskreis der Staatssekretäre für E-Government in Bund und Ländern und den Kooperationsausschuss von Bund und Ländern für automatisierte Datenverarbeitung (KoopA ADV) sowie alle Untergremien ab. "Der IT-Planungsrat: koordiniert die Zusammenarbeit von Bund und Ländern in Fragen der Informationstechnik; beschließt fachunabhängige und fachübergreifende IT-Interoperabilitäts- und IT- Sicherheitsstandards; steuert die Projekte zu Fragen des informations- und kommunikationstechnisch unterstützten Regierens und Verwaltens (E-Government-Projekte), die dem IT- Planungsrat zugewiesen werden; übernimmt die in 4 dieses Vertrages genannten Aufgaben für das Verbindungsnetz nach Maßgabe des dort angeführten Gesetzes. 1 1 Nationale E-Government-Strategie, Beschluss des IT-Planungsrats vom 24. September 2010 öffentlich 9

10 5.2 NEGS Mit der Nationalen E-Government Strategie herrscht zum ersten Mal zwischen Bund, Ländern und Gemeinden ein gemeinsames Verständnis darüber, wie sich die elektronische Abwicklung von Verwaltungsangelegenheiten über das Internet zukünftig weiter entwickeln muss. Die NEGS definiert hierzu sechs zentrale Ziele, an denen sich die künftigen E-Government- Projekte ausrichten müssen: Zukunftsfähigkeit und Nachhaltigkeit Maßgebliche Orientierung am Nutzen von Bürgern, Unternehmen und Verwaltung Erhöhung der Effizienz im Verwaltungshandeln Herstellung von Transparenz über Daten und Abläufe Datenschutz Stärkung der gesellschaftlichen Teilhabe über Internetangebote des Staates. Zur Ausgestaltung der NEGS hat das Gremium verschiedene Steuer- und Koordinierungsprojekte sowie einen Maßnahmenkatalog ins Leben gerufen. Folgendes Projekt liefert entscheidende Inhalte und Vorgaben für das Projekt. Zur Konkretisierung der anstehenden Aufgaben für eine engere Zusammenarbeit zwischen Bund, Ländern und Kommunen werden in der Nationalen E-Government-Strategie folgende Aspekte herangezogen: Als Leitbild für koordiniertes Handeln in Eigenverantwortung: Die Nationale E- Government-Strategie strebt die gemeinsame strategische Ausrichtung von Bund, Ländern und Kommunen in der Weiterentwicklung von E-Government an und möchte das Handeln der Beteiligten koordinieren, um Interoperabilität und Wirtschaftlichkeit zu sichern. Hierfür formuliert sie ein Leitbild und gemeinsame Ziele für die Weiterentwicklung des E-Government, an denen sich Bund, Länder und Kommunen in ihrem jeweiligen Handlungs- und Zuständigkeitsbereich ausrichten können und sollen. Als Agenda gemeinsamer Vorhaben: Sie beschreibt Maßnahmen zur Koordinierung der Zusammenarbeit, zur Vereinbarung von Standards und E-Government-Projekten mit Leuchtturmcharakter, die für eine gezielte Weiterentwicklung und Neupositionierung des deutschen E-Government modellhaft und erfolgskritisch sind. Als Roadmap zur Umsetzung: Der IT-Planungsrat legt im Rahmen des IT- Staatsvertrags unter Beteiligung der kommunalen Spitzenverbände auf der Grundlage der Nationalen E-Government-Strategie gemeinsame Umsetzungsschritte sowie deren Finanzierung fest Steuerungsprojekt FIM Das Projekt Föderales Informationsmanagement (FIM) hat zum Ziel, auf organisatorischer, fachlicher und technischer Ebene eine nachhaltige Infrastruktur zu schaffen, welche Informationen zu Verwaltungsleistungen und -verfahren umfasst. Die in Kooperation stehenden E-Government-Vorhaben LeiKa (Leistungskatalog) und NPB (Nationale Prozessbibliothek) erarbeiten innerhalb der ÖV ein Komponenten-Framework, um den redaktionellen Aufwand in der Beschreibung von Verwaltungsleistung und -verfahren bei höherer Qualität zu senken. 2 Nationale E-Government-Strategie, Beschluss des IT-Planungsrats vom 24. September 2010 öffentlich 10

11 Mit FIM sollen vorhandene Informationen der verschiedenen föderalen Ebenen zu Verwaltungsverfahren zugänglich und wieder verwendbar gemacht werden, mit dem Ziel, ein koordiniertes Handeln der in die Einzelvorhaben involvierten Personen zu fördern, sowie Synergien bei der Ausführung von Verwaltungsleistungen auf allen föderalen Ebenen zu erschließen. FIM selbst steuert oder koordiniert nicht einzelne E-Government-Vorhaben, sondern gewährleistet Transparenz und erleichtert Zusammenarbeit und Transaktion zwischen diesen. In den folgenden Kapiteln sollen die drei Bausteine von FIM erläutert werden. Abbildung 2: FIM-Bausteine (Quelle: FIM-Ordnungsrahmen Feinkonzept) FIM definiert für die Anwendung der Informationsbausteine standardisierte Baukästen mit beigestellten Werkzeugen und einem Redaktionskonzept. Die FIM-Logik bildet den Kernbereich des FIM-Konzepts. Hier sind die Grundlagen der FIM- Bausteine spezifiziert, die Relationen zwischen den Bausteinen beschrieben und Regeln hinterlegt, die das Zusammenwirken der FIM-Bausteine definieren. Mit den FIM-Werkzeugen stehen Konzepte, Methoden und Standards bereit, mit denen die Pflege und Nutzung von FIM-Inhalten erfolgt. Im FIM-Baukasten enthalten sind alle strukturellen Elemente, die erforderlich sind, um FIM-Inhalte zu erstellen. Mit den Elementen des FIM-Baukastens können Inhalte für die FIM-Bibliothek erstellt werden. Nach FIM sind dies beispielsweise auf Basis von bundesrechtlichen Grundlagen erstellte Stammformulare, die sich aus Formularfeldern, Formularfeldgruppen und Regeln zusammensetzen, oder Stammtexte für eine Leistungsbeschreibung. Das FIM-Redaktionskonzept regelt, wer welche Rollen in FIM einnehmen kann, was gepflegt werden muss und genutzt werden kann und wie die Erstellung, die Pflege, der Zugriff oder die Qualitätssicherung erfolgen soll. öffentlich 11

12 Abbildung 3: FIM-Haus im Detail (Quelle: FIM-Ordnungsrahmen Feinkonzept) Inhalte aus: /DE/Projekte/Steuerungsprojekte/Steuerungsprojekte_NEGS/FIM LeiKa-Leistungsbeschreibungen Die Definition und Beschreibung von Leistungen der ÖV sind im ersten FIM-Baustein Leistungen verortet. Hierbei werden auf die Ergebnisse des E-Government-Vorhabens LeiKa zurückgegriffen. In der Vergangenheit ist im Vorhaben bereits analog zum FIM- Standardisierungsrahmen der Aufbau des Leistungskatalogs erfolgt. Der Leistungskatalog ist bereits etabliert und bekannt. Die Leistung wird durch LeiKa wie folgt definiert: Mit dem Begriff Leistungen wird das Handeln der öffentlichen Verwaltung bezeichnet, das nach außen gerichtet ist und auf das die Bürgerinnen und Bürger, die Wirtschaft sowie freie oder gemeinnützige Träger einen Anspruch haben oder das aufgrund öffentlich-rechtlicher Verpflichtungen genutzt oder geduldet werden muss. Unter Öffentliche Verwaltung sind sowohl die unmittelbare Staatsverwaltung (Bund und Länder) als auch die mittelbare Staatsverwaltung (Körperschaften, Anstalten, Stiftungen, Beliehene) gemeint. Ebenfalls im LeiKa verortet werden die verwaltungsinternen Leistungen und Leistungen zwischen den Verwaltungen. Der LeiKa ist somit als vollumfängliches Leistungsverzeichnis der ÖV zu verstehen. öffentlich 12

13 Folgend sollen die Standardisierungsschritte dargestellt werden. Im ersten Schritt wurde die Klassifikation für öffentliche Verwaltungsleistungen ausgebaut und optimiert. Die Klassifikation erfolgt über die Vergabe von eindeutigen LeiKa-Schlüsseln für alle öffentlichen Verwaltungsleistungen. Durch die einheitliche Zuordnung von verbindlichen LeiKa-Schlüsseln werden Leistungen im gesamten föderalen Verwaltungsgebiet vergleichbar. Für einzelne Leistungen von ausschließlich regionaler Bedeutung, die keinen Eingang in den LeiKa finden, können freie Adressräume des LeiKa im Kontext der Länderinstanz verwendet werden. Die im Schlüssel kodierten Attribute dienen der hierarchischen Gliederung einer Verwaltungsleistung nach Länderinstanz, Leistungsobjekten, Verrichtungen und Verrichtungsdetails. Abbildung 4: LeiKa 2.0 Grundstruktur (Quelle: GK-LeiKa) In der folgenden Tabelle werden die Attribute des LeiKa-Schlüssels dargestellt und beschrieben: Attribut Staatenkennung Instanz Leistungsobjekt (LG+LK) Beschreibung Bei Verwendung des LeiKa auf europäischer Ebene wird der LeiKa um die Staatenkennung gem. ISO erweitert. Die Staatenkennung ist im regelmäßigen Gebrauch innerhalb Deutschlands entbehrlich. Die Kennung für den LeiKa ist "99". In Deutschland erfolgt die Kennzeichnung von landesspezifischen Leistungskatalogen gemäß Länderkennung des Amtlichen Gemeindeschlüssels (AGS). Die Vergabe weiterer Instanzen ist grundsätzlich möglich. Instanzen anderer Staaten werden durch die GK LeiKa vergeben. Das Leistungsobjekt bezieht sich unmittelbar auf einen rechtlichen Regelungsgegenstand und stellt somit die Grundlage für das Verwaltungshandeln (=Verrichtung) dar. Durch die Kopplung von LG und LK wird die eindeutige Identifizierung von Leistungen für Fremdsysteme ( Fingerabdruck einer Leistung ) ermöglicht. öffentlich 13

14 Leistungsgruppierung (LG) Leistungskennung (LK) Verrichtung (VK+VD) Verrichtungskennung (VK) Verrichtungsdetail (VD) Die Leistungsgruppierungen erfüllen eine Systematisierungsfunktion innerhalb des LeiKa. Die Leistungsgruppierungen haben keinen Einfluss auf die Bildung einer Leistungsbezeichnung. Die Leistungskennung ist das zentrale Merkmal eines Leistungsobjektes und stellt den Regelungsgegenstand einer Leistung dar. Durch die Verknüpfung LG + LK = LO entsteht eine feste Verdrahtung, die nachträglich nicht verändert werden sollte, um große Aufwendungen zur Nachpflege zu vermeiden. Verrichtungen beschreiben, welches Verwaltungshandeln an einem Leistungsobjekt durchgeführt wird. Die Verrichtungskennung beschreibt das Ergebnis des Verwaltungshandelns in Bezug auf das Leistungsobjekt. Verrichtungskennungen werden im LeiKa standardisiert in Form von Substantivierungen vorgegeben. Das Verrichtungsdetail spezifiziert die Verrichtungskennung insbesondere in Bezug auf verschiedene Verfahrensabläufe, Zielgruppen oder Ausnahmen innerhalb einer Leistung. Verrichtungsdetails werden zu jeder Verrichtung eines Leistungsobjektes fortlaufend vergeben. Tabelle 2: Attribute des LeiKa-Schlüssels (Quelle: FIM-Ordnungsrahmen Feinkonzept) In einem zweiten Schritt wurde die fachliche Struktur der Verwaltungsleistung spezifiziert und einheitliche Definitionen der Felder zur Leistungsbeschreibung festgelegt. Durch den einheitlichen Aufbau können Leistungsbeschreibungen aller föderalen Ebenen und Organisationen auch inhaltlich gleich behandelt und miteinander verglichen werden. Somit wird auch die einheitliche Verarbeitung der Leistungsbeschreibungen in Software-Systemen ermöglicht. Im dritten Schritt sollen die Leistungsbeschreibungen inhaltlich, soweit möglich, harmonisiert werden. Dazu wurden einheitlich Qualitätsstandards (weitestgehend) festgelegt. Ziel ist es, ein Stammtext-Management aufzubauen, welches Stammtexte zu Leistungsbeschreibungen bedarfsgerecht zur Verfügung stellt und damit eine synergetische, effiziente Erstellung von Leistungsbeschreibungen auf alle föderalen Ebenen ermöglicht. Im letzten Schritt sind Bemühungen vorangeschritten, ein Austauschformat für Verwaltungsleistungen zu spezifizieren. Der standardisierte Zugriff auf Verwaltungsleistungen erfolgt unter Beteiligung des Stammtexte-Managements Inhalte von LeiKa Jeder aufgenommenen Leistung wird ein LeiKa-Schlüssel zugeordnet. Für die Leistungen, denen bundesweit einheitliche Regelungen zugrunde liegen, können Stammtexte über den LeiKa zur Verfügung gestellt werden. Nach dem Stammtext- und Ergänzungsmodell können LeiKa-Leistungen, soweit sie bundesrechtlich normiert sind, durch zuständige Landes- und/oder Kommunalverwaltungen ergänzt oder ersetzt werden. Die Leistungsberichte erhalten so einen einheitlichen Aufbau und unterliegen einheitlichen Qualitätskriterien. Hierdurch wird ein hoher öffentlich 14

15 Standardisierungsgrad über alle Verwaltungsebenen hinweg erreicht und letztendlich die Nutzung erheblich erleichtert. Eine LeiKa-Leistung ist wie folgt aufgebaut: Abbildung 5: LeiKa Modulebene (Quelle: GK-LeiKa) Eine Leistungsbeschreibung ist die Summe aller Module eines Leistungsberichtes, welche die Leistung inhaltlich vollständig beschreiben (Module 2-21). Der LeiKa-Schlüssel wird im Modul 1 abgebildet. Die Zuständigkeit ist die Summe aller Module eines Leistungsberichtes, welche die Zuständigkeit und Ansprechpunkte vollständig beschreiben (Module 22-23). Ein Modul besteht aus Stamm-, Ergänzungs- und Ersatzfeld. Folgende Module definiert LeiKa: Nr. Modulbezeichnung Beschreibung 1 LeiKa-Schlüssel Leistungsnummer gemäß LeiKa 2 Leistungsbezeichnung Bezeichnung gemäß LeiKa 3 Leistungsbezeichnung II (Leistungsname) Bürgerorientierte Leistungsbezeichnung 4 Begriffe im Kontext Synonyme, Schlagworte 5 Kurztext Kurzbeschreibung der Leistung 6 Volltext Ausführliche Beschreibung der Leistung 7 Rechtsgrundlagen Verweise (Links) auf Rechtsquellen 8 erforderliche Unterlagen Auflistung der regelmäßig erforderlichen Unterlagen öffentlich 15

16 9 Voraussetzungen Voraussetzungen sind Tatbestandsmerkmale der gesetzlichen Regelung des Leistungsobjektes. Es handelt sich somit um Voraussetzungen, die einzeln erfüllt sein müssen, damit der Tatbestand zutrifft und die Rechtsfolge eintritt. 10 Kosten (Gebühren, Auslagen etc.) soweit zutreffend: konkreter Betrag oder Gebührenspanne von/bis 11 Verfahrensablauf Skizze zum Ablauf des Verwaltungsverfahrens (Prozess) 12 Bearbeitungsdauer Angaben zur durchschnittlichen Bearbeitungsdauer 13 Fristen Angaben zu Fristen, die der Bürger einhalten muss, um die Leistung in Anspruch nehmen zu können 14 Formulare Zusammenstellung benötigter Formulare, ggf. als Verweis 15 weiterführende Informationen z. B. Links auf Publikationen (Broschüren, Datenträger) 16 Hinweise (Besonderheiten) Hinweise, die im Zusammenhang mit der Leistung beachtet werden sollten 17 letzte Aktualisierung Datum der letzten Veröffentlichung 18 Urheber Urheber der letzten Veröffentlichung 19 fachlich freigegeben durch freigebende Stelle, z. B. Ressort/Fachreferat 20 fachlich freigegeben am Datum der fachlichen Freigabe 21 Typisierung Regelungs- und Vollzugszuständigkeit der Leistung 22 zuständige Stelle Angabe der örtlich und sachlich zuständigen Stelle 23 Ansprechpunkt Angabe des/der Ansprechpunkte(s) für den Bürger Tabelle 3: LeiKa-Module (Quelle: GK-LeiKa) LeiKa definiert weiterhin Stammfelder, die standardisierte Beschreibungen innerhalb eines Moduls enthalten. Laut LeiKa gilt dies in der Regel für einheitlich geregelte Sachverhalte, bei denen auf nachgeordneten Ebenen (Landes- und/oder Kommunalverwaltungen) im Rahmen ihrer Ausgestaltungskompetenzen keine Abweichungen auftreten können. Liegt die abschließende Beschreibung des Moduls nicht in der Hoheit des Bundes, beschreibt dieser nur die Rahmenregelungen für dieses Modul (z. B. ein Gebührenrahmen von 5 bis 50 Euro auf Bundesebene). Die konkrete inhaltliche Ausgestaltung des Moduls erfolgt laut LeiKa auf der nachgeordneten, gesetzesausführenden Ebene. Für Stammfelder auf Länderebene gilt grundsätzlich das öffentlich 16

17 Gleiche. Mit dem Ergänzungsfeld erhält die Gesetzesausführung zuständige Stelle die Möglichkeit, Inhalte dem Stammfeld hinzuzufügen. Die Ergänzung eines Stammfeldes kann mehrstufig auf Landes- und Kommunalebene erfolgen. Ein Ergänzungsfeld enthält konkrete Ausführungsregelungen und regionale Spezifika zu einem Stammfeld. Das Ersatzfeld ermöglicht auf Landes- und Kommunalebene das Abwählen eines oder mehrerer Stamm- und Ergänzungsfelder ohne die Aufgabe der modularen Gesamtstruktur. Hat eine nachgeordnete Ebene ein Ausführungsermessen, so kann der Stammtext von der nachgeordneten Ebene durch die konkretere Regelung ersetzt werden. Diese Regelung kann ebenfalls für Modellprojekte / -regionen gelten, wenn von bestehenden Regelungen abgewichen wird GK-LeiKa Das E-Government-Vorhaben LeiKa wird durch die Geschäfts- und Koordinierungsstelle Leistungskatalog (GK LeiKa) geführt. Die Stelle wurde auf Grundlage von Beschlüssen des KoopA ADV Ende 2008 eingerichtet und seit dem Übergang als Anwendung im IT-Planungsrat weitergeführt. Ihr Arbeitsspektrum und ihre Finanzierung werden jährlich durch Beschlüsse der Fachgruppe LeiKa-plus und des IT-Planungsrates über die Arbeits- und Ressourcenplanung festgelegt. Die GK nimmt sowohl inhaltlich-redaktionelle als auch organisatorisch-koordinierende Aufgaben wahr und dient als Ansprechpartner für Portalbetreiber und weitere Interessenten. Zugleich betreibt sie ein aktives Schnittstellenmanagement zu den Projekten Föderatives Informationsmanagement (FIM) und 115 sowie zu weiteren verwandten Vorhaben. GK-LeiKa und das Projekt D115 erarbeiten aktuell einen gemeinsamen Maßnahmenplan zur Bereitstellung von Leistungsbeschreibungen nach dem Stammtext- und Ergänzungsmodell. Somit wurde der LeiKa-Standards für die Anwendung im Projekt D115 gesetzt. Inhalte aus: Prozesse Das FIM-Vorhaben setzt sich auch mit dem Thema Prozesse verstärkt auseinander. Der entsprechende FIM-Standardisierungsrahmen soll zukünftig seine Anwendung im Koordinierungsprojekt NPB finden. Laut FIM ist die Aufgabenstellung dieses Projektes zwar prinzipiell nicht deckungsgleich mit den Inhalten des Standardisierungsrahmens, es gibt aber viele Überschneidungen und Anknüpfungspunkte. Laut FIM sind folgende Ergebnisse zu erwarten: Klassifikation und eindeutige Identifikation von Prozessen Integration von bereits existierenden fachlichen Standards Verweise auf Leistungsbeschreibungen und Formulare Pflegeprozess für die Klassifikation und für die Spezifikation und Implementierung von fachlichen und technischen Standards Qualitätskriterien für Prozesse öffentlich 17

18 Redaktionsmodell mit Prozessen zur Erstellung, Qualitätskontrolle und Pflege von Referenzprozessen NPB integriert FIM-Erweiterungen Im FIM-Baustein Prozesse wurde aktuell ein Feinkonzept zur Bereitstellung einer FIM- Prozessbibliothek erstellt. Dieses enthält eine Beschreibung des Ordnungsrahmens zur Erfassung von Prozessinformationen auf drei Detaillierungsebenen. In der nachfolgenden Abbildung werden diese grob dargestellt. Abbildung 6: Prozessbibliothek des FIM-Bausteins Prozesse (Quelle: FIM-Ordnungsrahmen Feinkonzept) Die erste Detaillierungsebene befasst sich mit den Prozesssteckbriefen, die allgemeingültige Informationen zum Prozess, jedoch keine detaillierten Angaben zum Prozessablauf beinhaltet. Die Summe aller Prozesssteckbriefe bildet den FIM-Prozesskatalog. In der zweiten Detaillierungsebene werden die Prozesssteckbriefe mit Stammprozessen ergänzt. Je Prozesssteckbrief entsteht genau ein Stammprozess. Der Stammprozess beschreibt allgemeingültige Zusammenhänge eines Verwaltungsprozesses und greift dabei auf standardisierte Referenzaktivitätengruppen zurück. Eine detaillierte Ausprägung der Prozessabläufe einer Verwaltung erfolgt auf der dritten Detaillierungsebene, der Ebene der Referenzprozesse. Dabei werden Prozessabläufe mit detaillierten Aktivitäten für Verwaltungen beschrieben. Bei der Prozessmodellierung mit Aktivitäten wird vom jeweiligen Stammprozess ausgegangen. Im Gegensatz zu Stammprozessen können pro Stammprozess mehrere Referenzprozesse entstehen. Während ein Stammprozess auf einem höheren Abstraktionsniveau beschrieben wird, werden die Verwaltungsgröße, die Organisationsstruktur sowie bestimmte Rahmenbedingungen bei der Beschreibung der Referenzprozesse herangezogen. öffentlich 18

19 Analog der LeiKa-Systematik wird die sukzessive Befüllung der Prozessbibliothek über die verschiedenen Detaillierungsstufen unterstützt FIM-Prozesssteckbrief als Detaillierungsstufe 1 Für die Erfassung der Prozesssteckbriefe wurde ein Ordnungsrahmen im FIM-Feinkonzept entwickelt. Die Grundlage hierfür bildeten der bestehende XProzess-Standard sowie die existierenden Prozessregister bei Bund, Ländern und Kommunen. Informationen zu einem konkreten Verwaltungsprozess (Verwaltungssicht) werden anhand von klassifizierenden und strukturgebenden Attributen in einem Prozesssteckbrief erfasst. Als Identifizierungsmerkmal wird die LeiKa-ID aus dem FIM-Baustein Leistungen herangezogen. Hierbei ist eine Prozesszuordnung bis auf die Ebene der Verrichtungsdetails des LeiKa vorgesehen. Die in einem Prozesssteckbrief zu erfassenden Attribute werden in der nachfolgenden Tabelle aufgeführt und kurz erläutert. Attribut Beschreibung ID* Bezeichnet eindeutig einen Prozess und leitet sich durch die 1:1- Zuordnung zwischen Prozess und Leistung aus der LeiKa-ID ab. Versionsnummer* Erstelldatum* Autor* Letztes Änderungsdatum* Letzter Bearbeiter* Name* Beschreibung Gültigkeitsinformatio n Wird FIM-intern verwaltet, um die Existenz unterschiedlicher Versionen von Prozesssteckbriefen zu ermöglichen (siehe auch Umgang mit Versionsnummern in der Spezifikation des Redaktionsmodells). Datum der Erstellung. Wird vom FIM-System automatisch gepflegt. Ersteller oder erstellende Institution des Prozesssteckbriefes. Wird im besten Fall vom FIM-System automatisch gepflegt. Datum der letzten Änderung. Wird vom FIM-System automatisch gepflegt. Der letzte Bearbeiter des Prozesssteckbriefes. Wird im besten Fall vom FIM-System automatisch gepflegt. Beinhaltet eine Bezeichnung für einen Prozess nach dem Schema Objekt + Verrichtung + Verrichtungsdetails, z. B.: Waffenbesitzkarte + Erteilung + für Sportschützen. Beinhaltet eine kurze textuelle Beschreibung der wesentlichen Arbeitsschritte und Beteiligungen und soll einen prozessfremden Nutzer in die Lage versetzen, den wesentlichen Inhalt eines Prozesses nachvollziehen zu können. Die Beschreibung entspricht einer um interne Abläufe erweiterten Darstellung des LeiKa-Moduls 11 Verfahrensablauf. Sofern es eine Beschränkung der Gültigkeit gibt, ist der Gültigkeitszeitraum zu erfassen (z. B. bei befristeten Verordnungen sind auch die darauf basierenden öffentlich 19

20 Prozesssteckbriefe in ihrer Gültigkeit zu befristen). Status Prozesssteckbriefe, die noch nicht oder nicht mehr verwendet werden dürfen, werden mit Inaktiv gekennzeichnet 3. Aktuelle Prozesssteckbriefe, die zur Verwendung freigegeben sind, sind mit Aktiv gekennzeichnet. Die Aktivsetzung erfolgt automatisch mit der Freigabe. Veraltete Prozesssteckbriefe werden mit Veraltet gekennzeichnet. Standardmäßig ist jeder Prozesssteckbrief zunächst als In Vorbereitung gekennzeichnet. Typisierung Dieses Attribut entspricht weitestgehend dem LeiKa-Modul 21 Typisierung. Es beschreibt die Regelungs- und Vollzugszuständigkeit der Leistung, der der Prozess zugeordnet ist. Regelungs- und Vollzugskompetenz auf Bundesebene Regelungskompetenz auf Bundesebene, Vollzug durch Landesebene Ausführungsvorschriften durch Landesebene, Vollzug durch kommunale Ebene Regelungskompetenz auf Bundesebene (Abweichungsrecht bzw. ehemals Rahmengesetzgebung) Vollzug durch Landesebene Ausführungsvorschriften durch Landesebene, Vollzug durch kommunale Ebene Regelungskompetenz auf Landesebene Vollzug auf Landesebene Vollzug durch kommunale Ebene Regelungskompetenz auf kommunaler Ebene Prozess außerhalb der Verwaltung Die oben beschriebene Typisierung wird über eine Codeliste realisiert. Prozessart Produktkatalog KGSt Auslöser Bezeichnet die Art eines Prozesses. Es wird zwischen Kern-, Führungs- und Unterstützungsprozessen unterschieden. Bezeichnet das zugeordnete Produkt aus dem Produktkatalog der KGSt bis zur Ebene der Produkte. Nennung des konkreten Auslösers für einen Prozess. Es werden zwei Typen von Auslösern unterschieden; (1.) dokumentenbasierte und (2.) prozessbasierte Auslöser. Beispielsweise kann ein Prozess durch einen Antrag ausgelöst werden oder durch das Ergebnis eines anderen Prozesses. Die Auslöser können durch Verweise auf FIM-Stammformulare 3 In der NPB existiert als vergleichbares Merkmal der Status privat/öffentlich. öffentlich 20

21 oder FIM-Stammprozesse angegeben werden. Neben den Verweisen können Auslöser auch in textueller Form angegeben werden, falls die anzugebenen Formulare oder Prozesse noch nicht in den FIM-Bibliotheken enthalten sind und somit noch keine ID zugewiesen haben. Ergebnis Formulare Partnerprozess Initiator Ergebnisempfänger Rechtsgrundlage Nennung konkreter Ergebnisse eines Prozesses durch Verweise auf ein oder mehrere FIM-Stammformulare und deren Unterelemente (Formularfeldgruppen, Formularfelder) sowie Verweise auf FIM-Stammprozesse. Neben den Verweisen können Ergebnisse auch in textueller Form angegeben werden, falls die anzugebenen Formulare oder Prozesse noch nicht in den FIM-Bibliotheken enthalten sind und somit noch keine ID zugewiesen haben. Nennung der für den Prozess relevanten Formulare. Dies betrifft sowohl eingehende als auch ausgehende Informationen. Die Formulare können durch Verweise auf ein oder mehrere FIM- Stammformulare und deren Unterelemente (Formularfeldgruppen, Formularfelder) angegeben werden. Neben den Verweisen können Formulare auch in textueller Form angegeben werden, falls die anzugebenen Formulare noch nicht in der Formularbibliothek enthalten sind und somit noch keine ID zugewiesen haben. Nennung der Prozesse, die bei der Ausführung des Prozesses als Partnerprozess hinzugezogen werden durch Verweise auf FIM- Stammprozesse. Neben den Verweisen können Partnerprozesse auch in textueller Form angegeben werden, falls die anzugebenen Prozesse noch nicht in den Prozessbibliotheken enthalten sind und somit noch keine ID zugewiesen haben. Bezeichnet den Auftraggeber eines Prozesses, z. B: Bürger, Unternehmen oder andere Verwaltungsebene. Bezeichnet den Ergebnisempfänger eines Prozesse, z. B: Bürger, Unternehmen oder andere Verwaltungsebenen. Bezeichnet die Rechtsgrundlage, die als Auftragsgrundlage für diesen Prozess dient. IT-Fachverfahren Bezeichnet die für die Prozessausführung relevanten E- Government Komponenten, z. B. Kfz-Steuer-Fachverfahren, De- Mail, NWR, VEMAGS usw. Freies Tag Dieses Attribut beinhaltet eine Liste an frei wählbaren Tags (Stichworten), die das Feld ggf. hinsichtlich weiterer, unstrukturierter Eigenschaften beschreiben. Die Nutzung dieser freien Tags ist freiwillig und kann ggf. durch entsprechende Nutzungsbedingungen organisiert werden. öffentlich 21

22 Bezug zu XÖV- Vorhaben Dieses Attribut ermöglicht es, Bezüge zu in anderen Vorhaben, wie den XÖV-Vorhaben (z. B. XWaffe) oder Vorhaben wie P23R, gleich oder ähnlich definierten Elementen zu erstellen und diese Verbindung zu dokumentieren. Tabelle 4: Attribute für FIM-Prozesssteckbriefe (Quelle: FIM-Ordnungsrahmen Feinkonzept) Stammprozesse als Detaillierungsstufe 2 Auf der zweiten Detaillierungsebene werden Stammprozesse abgebildet. Ein Stammprozess beschreibt auf abstraktem Niveau den Prozessablauf und stellt die zentralen Beteiligten dar. Um die Verwaltung von Stammprozessen in der FIM-Bibliothek zu unterstützen, wurden allgemeine Attribute für Stammprozesse definiert. Diese werden in der nachfolgenden Tabelle dargestellt: Attribut Erstelldatum* Autor* Letztes Änderungsdatum* Letzter Bearbeiter* Freigabedatum* Status Beschreibung Datum der Erstellung. Wird vom FIM-System automatisch gepflegt. Ersteller oder erstellende Institution des Prozesssteckbriefes. Wird im besten Fall vom FIM-System automatisch gepflegt. Datum der letzten Änderung. Wird vom FIM-System automatisch gepflegt. Der letzte Bearbeiter des Prozesssteckbriefes. Wird im besten Fall vom FIM-System automatisch gepflegt. Datum der Freigabe durch die Freigabeinstanz. Wird im besten Fall vom FIM-System automatisch gepflegt. Prozesssteckbriefe, die noch nicht oder nicht mehr verwendet werden dürfen, werden mit Inaktiv gekennzeichnet4. Aktuelle Prozesssteckbriefe, die zur Verwendung freigegeben sind, sind mit Aktiv gekennzeichnet. Die Aktivsetzung erfolgt automatisch mit der Freigabe. Veraltete Prozesssteckbriefe werden mit Veraltet gekennzeichnet. Standardmäßig ist jeder Prozesssteckbrief zunächst als In Vorbereitung gekennzeichnet. Tabelle 5: Attribute für FIM-Stammprozesse (Quelle: FIM-Ordnungsrahmen Feinkonzept) Der FIM-Prozessbaukasten enthält neben den allgemeinen Attributen eine Reihe von Referenzaktivitätengruppen und anderer Elemente, um die grafische Abbildung der Stammprozesse zu ermöglichen. Hierfür wird die von der Object Management Group (OMG) entwickelte Methode Business Process Modell and Notation (BPMN) an die im FIM definierten Anforderungen angepasst. Dabei spricht man von FIM-BPMN. 4 In der NPB existiert als vergleichbares Merkmal der Status privat/öffentlich. öffentlich 22

23 FIM-BPMN besteht im Kern aus sieben Referenzaktivitätengruppen, die eine verwaltungsspezifische Tätigkeit aufgreifen, die durch weitere Informationen (Attribute) detailliert werden kann. Für Aktivitäten, die sich nicht durch die zur Verfügung gestellten Aktivitätengruppen abbilden lassen, wurde eine universelle Referenzaktivitätengruppe geschaffen. Diese soll aber nur in Ausnahmefällen eingesetzt werden. Die identifizierten Referenzaktivitätengruppen und die zusätzlich für die Erstellung der Stammprozesse zur Verfügung stehenden FIM-BPMN-Elemente werden im Folgenden beschrieben. Element Bezeichnung Notation (Symbol) Ereignis Verzweigung Kontrollfluss Nachrichtenfluss Ausführende Behörde Ausführende Stelle Ein Ereignis steht am Anfang (als Auslöser) und Ende (als Ergebnis) eines Prozesses. Ein Prozess kann mehrere Anfangs- und Endereignisse haben. Der Kontrollfluss in einem Prozess kann durch eine Verzweigung aufgeteilt oder wieder zusammengeführt werden. Ein Kontrollfluss verbindet die Aktivitätengruppen untereinander, um zu zeigen, in welcher Reihenfolge diese ausgeführt werden. Ein Nachrichtenfluss wird verwendet, um einen Informationsaustausch mit einer anderen ausführenden Behörde zu veranschaulichen. Eine ausführende Behörde wird verwendet, um zu veranschaulichen, dass bestimmte Aktivitätengruppen dieser Behörde zugeordnet sind. Die Aktivitätengruppen in einem Prozess können auf mehrere ausführende Behörden aufgeteilt sein. Eine ausführende Stelle kann verwendet werden, um die ausführende Behörde zu detaillieren. Aktivitätengruppe: Information empfangen Aktivitätengruppe: Information bereitstellen Information empfangen beschreibt den Eingang von Informationen oder Dokumenten. Dies kann beispielsweise in einem Genehmigungsprozess der Eingang eines Antragsformulars oder die telefonische Anfrage durch einen Bürger zu Beginn eines Erklärungsprozesses sein. Information bereitstellen beschreibt den Ausgang von Informationen oder Dokumenten. Dies kann beispielsweise in einem Genehmigungsprozess die Zustellung eines Bescheides beschreiben oder die telefonische Auskunft durch die Verwaltung in einem Erklärungsprozess. öffentlich 23

24 Aktivitätengruppe: Sachverhalt formell prüfen Aktivitätengruppe: Sachverhalt fachlich entscheiden Aktivitätengruppe: Sachverhaltsunt erlagen erstellen Aktivitätengruppe: Sachverhalt abrechnen Aktivitätengruppe: Mitwirkungsverfa hren durchführen Aktivitätengruppe: Sonstige Tätigkeit durchführen Sachverhalt formell prüfen beschreibt einen formellen Prüfungsschritt im Rahmen des Prozesses. Beispielsweise kann es sich hierbei um die Prüfung auf Zuständigkeit, Vollständigkeit oder Fristeinhaltung handeln. Sachverhalt fachlich entscheiden beschreibt keine formelle, sondern eine fachliche Prüfung des Sachverhalts, die zu einer konkreten Entscheidung führt und einen Einfluss auf den weiteren Prozessablauf nimmt. Sachverhaltsunterlagen erstellen fasst Aktivitäten eines Prozesse zusammen, in denen Dokumente erstellt werden. Beispielsweise ist dies die Erstellung eines Genehmigungsbescheids. Sachverhalt abrechnen beschreibt die Aktivtäten, in denen Gebühren abgerechnet werden. Dazu zählen neben der Berechnung der Gebühren auch die Erstellung des Gebührenbescheids und der eigentliche Zahlungsvorgang. Mitwirkungsverfahren durchführen beschreibt die Beteiligung von anderen Behörden im Rahmen der Durchführung zur Abstimmung von Informationen oder Dokumenten, wie beispielsweise die Beteiligung im Rahmen einer Stellungnahme. Die Aktivitätengruppe Sonstige Tätigkeit durchführen darf nur dann genutzt werden, wenn eine Aktivitätengruppe in den Stammprozess aufgenommen werden soll, die nicht über die anderen Aktivitätengruppen abgebildet werden kann. Eine Auswertung der Verwendung dieser Aktivitätengruppe kann ggf. zur Identifikation und Definition von neuen Aktivitätengruppen führen. Tabelle 6: Elemente der FIM-BPMN zur Modellierung von Stammprozessen (Quelle: FIM- Ordnungsrahmen Feinkonzept) Bei der Erstellung der Stammprozesse werden die Referenzaktivitätengruppen zu Aktivitätengruppen instanziiert und fachlich benannt. Die fachliche Modellierung eines Stammprozesses erfolgt also mittels Aktivitätengruppen. Die Verwendung der instanziierten Aktivitätengruppen erleichtert später die Erstellung der Referenzprozesse und trägt zu ihrer Vereinheitlichung bei. Aktivitätengruppen werden mithilfe des einfachen BPMN-Notationssatzes zur Abbildung eines Stammprozesses herangezogen. öffentlich 24

25 Abbildung 7: Erteilung einer Waffenbesitzkarte für Sportschützen als Stammprozess (Quelle: FIM- Ordnungsrahmen Feinkonzept) Erstellung von Referenzprozessen Die dritte Detaillierungsebene wird über die Referenzprozesse in FIM dargestellt. Wie die Stammprozesse werden die Referenzprozesse in Form von Prozessmodellen dokumentiert. Bei der Erstellung der Referenzprozesse entstehen konkrete Prozessmodelle auf Basis des vorhandenen Stammprozesses (der zweiten Detaillierungsstufe). Die Modellierung von Referenzprozessen wird durch die Stammprozesse, deren Aktivitätengruppen sowie Metadaten unterstützt. Eine detaillierte Abbildung der Einzelaktivitäten in den Referenzprozessen kann auf Basis der Aktivitätengruppen erfolgen. Bei der Erstellung von Referenzprozessen werden die Aktivitäten den einzelnen Aktivitätengruppen zugeordnet. Im Gegensatz zu Prozesssteckbriefen und Stammprozessen werden die Referenzprozesse aufgrund der n-fach möglichen Ausprägungen nicht Top-Down, sondern Bottom-Up modelliert. Dieses Vorgehen kann aktuell schon durch die Nationale Prozessbibliothek unterstützt werden. Die Erarbeitung von Referenzprozessen kann von mehreren Verwaltungen auch mit Unterstützung eines externen Experten z. B. im Rahmen einer Projektwerkstatt durchgeführt öffentlich 25

26 werden. Für diese Zwecke stehen den Verwaltungsmitarbeitern auch weitere Community- Funktionen, wie Wiki, Forum, Tutorien in der NPB zur Verfügung. Inhalte aus: FIM-Ordnungsrahmen Feinkonzept Formulare Der dritte FIM-Baustein setzt sich mit dem Thema Formulare auseinander und legt den Schwerpunkt auf den standardisierten Austausch von formular- und dokumentenbasierten Informationen. Analog zu den Bausteinen Leistungen und Prozesse entsteht hier ein Feinkonzept, das die Beschreibung des FIM-Ordnungsrahmens sowie verschiedener Detaillierungsstufen bei der Erstellung von Formularen beinhaltet. Dabei wird die FIM- Systematik angewendet und die Zusammenhänge zwischen den Formularfeldern, Formularfeldgruppen, Regeln und Stammformularen beschrieben. Formulare ermöglichen der Verwaltung strukturiert und standardisiert Informationen zu erfassen (Antragsformulare) sowie bereitzustellen (Bescheide). FIM unterscheidet zwischen den Inputund Output-Dokumenten, die einen verwaltungsinternen oder verwaltungsexternen Ursprungs haben. In der FIM-Bibliothek werden Formulare in Form von Formularsteckbriefen erfasst und katalogisiert. Richtung Ursprung Beispiel Bemerkung Input- Dokument Verwaltung Antrag, Meldeformular Wird als Steckbrief erfasst (Identifizierungsschlüssel leitet sich aus der LeiKa-ID ab) und kann durch Stammformulare detailliert werden verwaltungs extern Foto, Zeugnis, Bauplan Wird als Steckbrief erfasst (Identifizierungsschlüssel wird als Sonder- ID generiert) Output- Dokument Verwaltung Bescheid, Urkunde (Ausweis) Wird als Steckbrief erfasst (Identifizierungsschlüssel leitet sich aus der LeiKa-ID ab) und kann durch Stammformulare detailliert werden verwaltungs extern Kommt nicht vor. Verwaltungsexterne Dokumente entstehen ausschließlich außerhalb der Verwaltung. Sie spielen nur als Input-Dokumente eine Rolle. Tabelle 7: Input- und Output-Dokumente im Überblick (Quelle: FIM-Ordnungsrahmen Feinkonzept) Formularsteckbriefe zu verwaltungsinternen Formularen können durch Stammformulare detailliert beschrieben werden. Diese Beschreibung erfolgt durch die Zusammenstellung eines Stammformulars aus Bauelementen des FIM-Formularbaukastens. Für die Erstellung von Stammformularen werden die drei FIM-Elemente Formularfeld, Formularfeldgruppe und Regeln im FIM-Baukasten konzeptioniert: öffentlich 26

27 Das Formularfeld bildet die kleinste Einheit des FIM-Baukastens aus Sicht des Bausteins Formulare. Eine Formularfeldgruppe besteht aus einer Sammlung von Formularfeldern und/oder Formularfeldgruppen und weiteren feldgruppenspezifischen Informationen. Formularfeldgruppen können dabei wiederum Teil von anderen Formularfeldgruppen sein. Formularfelder und Formularfeldgruppen können wiederverwendet und durch Instanziierung angepasst werden. Logische Abhängigkeiten zwischen Formularfeldern sowie zwischen Formularfeld und Formularfeldgruppe können durch Regeln ausgestaltet werden. Abbildung 8: Konstruktion von Stammformularen aus Elementen des Formularbaukastens (Quelle: FIM- Ordnungsrahmen Feinkonzept) Ziel von FIM ist der stetige Ausbau des Formularbaukastens. Die dafür notwendige Harmonisierung von Formularfeldern und Formularfeldgruppen erfolgt sowohl fachübergreifend als auch fachspezifisch. Auf Basis der so gewonnenen Bauelemente sollen kontinuierlich Stammformulare erstellt und zur Nutzung bereitgestellt werden. Sowohl für den Ausbau des Formularbaukastens als auch für die Befüllung der Stammformularbibliothek sind Redaktionsprozesse definiert. öffentlich 27

28 Abbildung 9: Wiederverwendung und Instanziierung von Elementen des Formularbaukastens (Quelle: FIM-Ordnungsrahmen Feinkonzept) Zur Unterstützung der Auf- und Ausbauprozesse stehen im Formularbereich folgende FIM- Werkzeuge zur Verfügung: Das Klassifikationsschema unterstützt zukünftige Anwender bei der Klassifizierung von Formularen, um bereits vor der Standardisierung von Formularen eindeutige Zuordnungen zwischen Formularen und Leistungen herzustellen. Leitfäden sind Handlungsempfehlungen bzw. Ausführungsvorschriften, die den FIM- Nutzer bei der Analyse, Klassifizierung sowie der Harmonisierung von Formularen unterstützen. Im Bereich der FIM-Werkzeuge können verschiedene Arten von Leitfäden vorgehalten werden. Begriffstaxonomien im FIM-Kontext werden Begriffe und deren Erläuterungen umfassen, die zum Einen als Hilfestellung für die Bezeichnung von Formularfeldern und Formularfeldgruppen relevant sind und zum Anderen zur Beschriftung von Stammformularen und deren Metadaten herangezogen werden können. 5 Inhalte aus: FIM-Ordnungsrahmen Feinkonzept 5 Vgl. FIM-Ordnungsrahmen Feinkonzept, 2014 öffentlich 28

29 5.4 Weiterführende Betrachtungen zu FIM Das FIM-Feinkonzept beschreibt nicht nur die einzelnen Bausteine Leistungen, Prozesse und Formulare und deren unterschiedlich ausgeprägten Stamminformationen, sondern eine sinnvolle Verknüpfung dieser Stamminformationen über alle drei Bausteine hinweg. Bei der Herstellung der Verknüpfung der FIM-Bausteine wird von den drei schon bekannten Detaillierungsstufen ausgegangen Erste Detaillierungsstufe In der ersten Detaillierungsstufe erfolgt die Verknüpfung der einzelnen Bausteine über die IDs des LeiKa, der Formulare und Prozesse. Abbildung 10: Zusammenspiel der FIM-Bausteine in der ersten Detaillierungsstufe (Quelle: FIM- Ordnungsrahmen Feinkonzept) Die LeiKa-Metadaten werden um drei neue Module zur Referenzierung von Prozessen sowie der Input- und Output-Formulare ergänzt. So enthält der Steckbrief der Leistung nach der ersten Detaillierungsstufe eine Referenz auf alle erforderlichen Unterlagen und alle erstellten Unterlagen in Form von Formular-IDs. Ebenso verweist die Leistung mittels der betreffenden Prozess-ID auf den zugehörigen Prozess. Der Bezug wird auch in der Gegenrichtung nachvollziehbar sein, da die Metadaten des Prozesssteckbriefs einen Verweis auf die zugehörige LeiKa-ID sowie auf die betreffenden Formular-IDs der Input- und Output-Formulare enthält. Unterscheidet die Leistung verschiedene öffentlich 29

30 Verrichtungsdetails, können auch auf dieser Detailebene spezifische Formular- und Prozess- IDs zugeordnet werden Zweite Detaillierungsstufe des Zusammenspiels der FIM-Bausteine Die zweite Detaillierungsstufe sieht die Verknüpfungen zwischen den Bausteinen Prozesse und Formulare auf der Ebene der Feldgruppen-ID und Aktivitätengruppen-ID vor. Abbildung 11: Zusammenspiel der FIM-Bausteine in der zweiten Detaillierungsstufe (Quelle: FIM- Ordnungsrahmen Feinkonzept) Einer Aktivitätengruppe können in der zweiten Detaillierungsstufe eine oder mehrere Formularfeldgruppen zugeordnet werden. Dies wird über das Hinterlegen der Feldgruppen-IDs der zugeordneten Feldgruppen in den Metadaten der Aktivitätengruppe erreicht. Die zugeordneten Feldgruppen erfassen im Fall von Input-Dokumenten die für die Bearbeitung der Aktivitätengruppe erforderlichen Informationen oder stellen das Ergebnis einer Aktivitätengruppe dar (im Fall eines Output-Dokuments). Die Zuordnung zwischen Feldgruppen und Aktivitätengruppen erfolgt spezifisch für einen bestimmten Prozesskontext. 7 6 Vgl. FIM-Ordnungsrahmen Feinkonzept, Vgl. FIM-Ordnungsrahmen Feinkonzept, 2014 öffentlich 30

31 5.4.3 Dritte Detaillierungsstufe des Zusammenspiels der FIM-Bausteine Die Verknüpfungen in der dritten Detaillierungsstufe werden auf der Feldebene hergestellt. Die Sinnhaftigkeit dieser Verknüpfungen muss im Einzelfall geprüft und bewertet werden. Abbildung 12: Zusammenspiel der FIM-Bausteine in der dritten Detaillierungsstufe (Quelle: FIM- Ordnungsrahmen Feinkonzept) Ähnlich wie die Zuordnung zwischen Aktivitätengruppen und Formularfeldgruppen erfolgt die Zuordnung zwischen Aktivitäten und Formularfeldern jeweils im Kontext eines spezifischen Formulars. Die Metadaten einer Aktivität innerhalb einer Aktivitätengruppe werden um die Referenz auf eine Formularfeld-ID ergänzt, um die dort erfassten oder dokumentierten Daten präzise dieser Aktivität zuordnen zu können FIM-Wirkprinzip Wie bereits aus den FIM-Zielen ersichtlich, beschreibt das FIM-Grundprinzip die Regelungsund Vollzugskaskade über die verschiedenen Verwaltungsebenen von der Gesetzgebung bis hin zum Vollzug und stellt in diesem Kontext optimierte Redaktionsabläufe zur Informationsentstehung, -abbildung und -bereitstellung dar. Die Optimierung erfolgt über die Standardisierung von Inhalten, die Bündelung von Aufgaben (EfA-Prinzip) und über qualitätssichernde Maßnahmen (siehe Konzept Fachliche und ). Das EfA-Prinzip wirkt gezielt im Bereich der gemeinsamen Stamminformationen, die über zentrale Redaktionen bereitgestellt werden. Folgende Abbildung zeigt das Prinzip der Regelungs- und Vollzugskaskade. 8 Vgl. FIM-Ordnungsrahmen Feinkonzept, 2014 öffentlich 31

32 Abbildung 13: FIM-Wirkprinzip (Quelle: FIM) Die heutige Regelungs- und Vollzugskaskade findet isoliert zwischen Bundesressorts, zwischen den Ländern und zwischen den Kommunen statt. Im Zweifel werden notwendige Regelungen zum Vollzug einer Leistung in jeder Kommunalverwaltung neu interpretiert und beschrieben. Abbildung 14: Regelungs- und Vollzugskaskade ohne FIM (Quelle: FIM) öffentlich 32

33 Die Regelung- und Vollzugskaskade mit FIM sieht die Errichtung von übergreifenden Redaktionen auf den unterschiedlichen Verwaltungsebenen vor. Sie koordinieren, erstellen und sichern die Inhalte der FIM-Bausteine mit dem Ziel die Pflegeaufwände via Bündelung zu reduzieren. Abbildung 15: Regelungs- und Vollzugskaskade mit FIM (Quelle: FIM) 5.5 Doppischer Produktplan Der Produktplan ist das zentrale Element im doppischen Haushalts- und Rechnungswesen. Der doppische Haushalt löst nach und nach das traditionelle Rechnungswesen der Kameralistik in der ÖV ab. Folgende Nachteile sind u. a. mit der Kameralistik verbunden: Keine betriebswirtschaftliche Betrachtung der ÖV möglich Beruht auf Annahme, dass die Einnahmen ausreichen Buchführung auf Wirtschaftszeitraum fixiert; Übertrag nicht möglich Doppische geführte Verwaltungen arbeiten Output-orientiert. Die Ergebnisse der kommunalen Arbeit und der Ressourcenverbrauch stehen in Beziehung und werden über die Produktbuchungen transparent dargestellt. Mit diesen Erkenntnissen lassen sich die Arbeitsprozesse wirtschaftlicher gestalten. So sind im Produktplan alle Verwaltungsvorgänge über definierte Produkte und Leistungen beschrieben. Die Produkte sind voneinander abgegrenzt und systematisch dargestellt, damit die entsprechenden Aufwendungen und Erträge bzw. Einzahlungen und Auszahlungen genau zugeordnet werden können. Der Produktplan für die Verwaltung leitet sich aus dem landeseinheitlichen Produktrahmenplan ab. Über den Produktrahmenplan können interkommunale Statistiken zum Kostenaufkommen in der Verwaltung gefahren werden. Der einheitliche Produktrahmenplan in M-V umfasst die: Hauptproduktbereiche, öffentlich 33

34 Produktbereiche, Produktgruppen, Produkte und Leistungen. Unter einem Produkt ist eine Leistung oder eine Gruppe von Leistungen zu verstehen, für die von Stellen innerhalb oder außerhalb der Verwaltung eine Nachfrage besteht und für die prinzipiell ein Entgelt entrichtet werden müsste. Leistungen sind die konkreten Arbeitsergebnisse einer Kommune, wie z. B. amtliche Bekanntmachungen, Medienarbeit oder Veranstaltungen und Aktionen, die zu dem Produkt Öffentlichkeitsarbeit zusammengefasst werden. Die Leistungen können innerhalb der Kommune (z. B. Personalvertretung) oder von Dritten (z. B. Gutachten) erbracht werden. Der Produktrahmenplan gibt die Produktbeschreibungen bis zur Ebene der Produktgruppen vor. Inhalte aus dem Produktrahmenplan M-V: Produktrahmenplan und LeiKa Die KGSt hat einen Abgleich zwischen dem Leistungskatalog (LeiKa) und dem KGSt - Produktplan realisiert 9. Die Erarbeitung wurde mit der kommunalen Arbeitsgruppe, die 2011 den KGSt -Produktplan entwickelt hat, durchgeführt. Die Einstufung der Leistungen erfolgte auf Grundlage der Vollzugskompetenz der Verwaltungsebenen. Wenn eine Leistung in mindestens einem Flächenland von Kommunen vollzogen wird, wurde diese als kommunal eingestuft. Im nächsten Schritt erfolgte die Zuordnung der LeiKa-Leistungen zu den KGSt -Produkten. Mit der Zuordnung zum KGSt -Produktplan wurde ein Schritt zur verwaltungs-(ebenen) übergreifenden Überleitung von Produkt- und Leistungsbeschreibungen vollzogen. Diese Zuordnung wird kontinuierlich fortgeführt Produkte, Prozesse und Leistungen Die Idee der Verknüpfung zwischen dem Produktplan der Kommune und den zugehörigen Prozessen ist nicht neu. Im Rahmen des Projektes Produkt-Prozess-Referenzierung wurde die Verknüpfung von Prozessen und Produkten von b.i.t.consult vorgenommen. Dabei ging es um den Abgleich des Produktplanes der Kommunen mit einem von b.i.t.consult entwickelten und fortlaufend gepflegten Referenzplan. Dieser Referenzplan enthält Angaben zu Top-Produkten, die aufgrund von Fallzahlen und/oder ihrer Ressourcenbindung von besonderer Bedeutung sind; ordnet den einzelnen Produkten die zugehörigen Geschäftsprozesse zu und 9 öffentlich 34

35 verbindet Produkte mit dem im Rahmen der Initiative Deutschland-Online entstandenen Leistungskatalog (LeiKa) und weiteren Systematiken, die zur Umsetzung der EU- Dienstleistungsrichtlinie, zur Realisierung der einheitlichen Servicenummer 115 und zur Entwicklung von Zuständigkeitsfindern für die Online-Angebote von Verwaltungen entwickelt wurden bzw. werden. Die Verknüpfung von Produkten und Prozessen ermöglicht den Kommunalverwaltungen einerseits die Ausrichtung der Geschäftsprozessoptimierung an Wirtschaftlichkeitskriterien. Andererseits wird dadurch eine Basis für interkommunale Vernetzungen geschaffen, da die Produktpläne unterschiedlicher Kommunen über die gemeinsame Referenzierung vergleichbar werden. Zudem können die zahlreichen Informationen aus dem Referenzplan zur Ergänzung und Konsolidierung des vorhandenen Produkthaushalts genutzt werden (z. B. Informationen zu Prozessen oder Leistungen, die den Produkten zuzuordnen sind). Inhalte aus: Koordinierungsstelle für IT-Standards Die Koordinierungsstelle für IT-Standards (KoSIT) verantwortet das XÖV-Rahmenwerk und koordiniert die Entwicklung und den Betrieb von IT-Standards für den Datenaustausch in der ÖV. Die Errichtung der KoSIT ist eine Folge der Ergänzung des Grundgesetzes um den Artikel 91c sowie des zugehörigen IT-Staatsvertrages. Die KoSIT unterstützt den IT-Planungsrat in dessen Aufgabe, fachunabhängige und fachübergreifende IT-Interoperabilitäts- und IT- Sicherheitsstandards zu beschließen und Bund-Länder-übergreifende E-Government-Projekte zu steuern. Das hieraus resultierende Aufgabenspektrum umfasst unter anderem auch den Betrieb der Standardisierungsagenda und des XÖV-Rahmenwerks. Im 3 des Staatsvertrages werden die grundsätzlichen Ziele und Verfahren zur Festlegung von gemeinsamen IT-Interoperabilitäts- und IT-Sicherheitsstandards geregelt. Gemäß Abs. 1 kann der IT-Planungsrat für den im Rahmen ihrer Aufgabenerfüllung notwendigen Austausch von Daten zwischen dem Bund und den Ländern gemeinsame Standards für die auszutauschenden Datenobjekte, Datenformate und Standards für Verfahren, die zur Datenübertragung erforderlich sind, sowie IT-Sicherheitsstandards festlegen. Bei diesen Festlegungen ist vorrangig auf bestehende Marktstandards abzustellen. Beschlüsse über Standards im Sinne des Absatz 1 sollen dabei gemäß 3 Abs. 2 vom IT-Planungsrat [...] gefasst werden, soweit dies zum Bund-Länder-übergreifenden Datenaustausch oder zur Vereinheitlichung des Datenaustauschs der ÖV mit Bürgern und Wirtschaft notwendig ist XÖV XÖV steht für XML in der ÖV. Ziel von XÖV ist es, den Datenaustausch innerhalb und mit der ÖV zu standardisieren. Dadurch sollen elektronische Prozesse effizienter und einheitlicher gestaltet und die Interoperabilität wird verbessert. 10 Errichtungskonzept für den Aufbau der Koordinierungsstelle für IT-Standards, Beschluss des IT-Planungsrats vom 3. März 2011 öffentlich 35

36 Im Mittelpunkt der XÖV-Standardisierung steht die Erarbeitung von fachlichen/semantischen Standards. Semantische Standards beschreiben, welche Informationen beispielsweise zu einer "Person", "Anschrift" oder "Gewerbeanmeldung" elektronisch übermittelt werden sollen und dürfen. Sie basieren auf XML und werden deshalb als sogenannte XÖV-Standards bezeichnet. Außerdem sind (wie OSCI-Transport) für den Datenaustausch erforderlich. In den Fachverfahren gibt es XÖV-Projekte wie beispielsweise XMeld, XAusländer, XJustiz, XPersonenstand und XDomea. Hier werden die Anforderungen eruiert, zusammengetragen und in den XÖV-Abstimmungsgremien als XÖV-Standards gemeinschaftlich entwickelt und verabschiedet. Danach werden die Standards im XRepository bereitgestellt und für jeden Interessenten zugänglich gemacht. Zusätzlich werden gemeinsame Methoden, Werkzeuge und Infrastruktur erarbeitet und für alle zur Verfügung gestellt, so auch das XÖV-Handbuch. Mit Hilfe dessen, wird Standardisierungs-Projekten eine vollständige und praxisorientierte Unterstützung mit an die Hand gegeben, um einen XÖV-Standard zu entwickeln. Des Weiteren sind im XÖV-Handbuch Kriterien zur Prüfung einer XÖV-Konformität festgelegt. Die jeweils aktuellste Version des XÖV-Handbuches erhalten Sie auf dem Internetangebot der Koordinierungsstelle für IT-Standards Service der Bundesstelle für Informationstechnik (BIT) Die BIT unterstützt bei der Organisation und Koordination von Vorhaben und berät XÖV-Projekte. Im Rahmen der XÖV-Zertifizierungsstelle prüft die BIT zudem die XÖV-Konformität von Spezifikationen. Damit leistet die BIT einen elementaren Beitrag, um elektronische Verwaltungsprozesse in Deutschland medienbruchfrei und dadurch effizienter zu gestalten XÖV-Konformitätskriterien Die sogenannten XÖV-Konformitätskriterien sind im XÖV-Handbuch beschrieben. Es handelt sich dabei um festgelegte Prüfkriterien, die ein Standard erfüllen muss, um die XÖV-Konformität zu erlangen. Die Kriterien sind den Bereichen Bereitstellungspflichten, Auskunftspflichten der Standardentwickler und -Betreiber sowie technische Kriterien zugeordnet und werden in den Verbindlichkeitsstufen "Muss", "Soll" und "Empfehlung" unterschieden. Die Prüfung der XÖV-Konformität von Standards für den elektronischen Datenaustausch soll die Interoperabilität der XÖV-Standards untereinander verbessern. Durch die angestrebte XÖV- Konformität kann für XÖV-Vorhaben bei der Entwicklung eines Standards ein höherer Aufwand resultieren. Sobald jedoch unterschiedliche Fachgebiete miteinander kommunizieren, bietet die Verwendung fachunabhängiger (XÖV-Codelisten) und fachübergreifender Bausteine (XÖV- Kernkomponenten) erhebliche Vorteile bei der Entwicklung und der Pflege von fachspezifischen Standards für den elektronischen Datenaustausch. Ein XÖV-Projekt, dessen Standard die XÖV-Konformitätskriterien erfüllt, kann zusätzlich von folgenden Nebeneffekten profitieren: gesteigerte Wirtschaftlichkeit und reduzierte Risiken bei der Entwicklung sowie eine hohe Qualität des entwickelten Standards. Die XÖV-Konformitätskriterien wurden nach folgenden Grundsätzen gestaltet: Sie verbessern die Interoperabilität aller XÖV-Standards. Sie sind adressatengerecht dargestellt, transparent und handhabbar. Sie behindern nicht die Umsetzung von fachspezifischer Anforderungen in einen XÖV- Standard. Sie lassen weitgehende Freiheiten bezüglich des Vorgehens und der Organisation eines XÖV-Projektes. öffentlich 36

37 Sie treffen Aussagen über die formale Beschaffenheit eines Standards für den elektronischen Datenaustausch und seine Eignung für technische Interoperabilität. Sie treffen keine Aussagen über die fachliche Qualität sowie den Nutzen des XÖV- Vorhabens, in dessen Rahmen der Standard entwickelt wird. Die Grundlage für die Prüfung der XÖV-Konformität eines Standards sind die XÖV- Konformitätskriterien. Sie sind als Muss-, Soll- und Kann-Regeln definiert und in drei Gruppen unterteilt: Informationspflichten (XÖV-Steckbrief) und Bereitstellungspflichten (XÖV-UML- Modell, XML Schema, Dokumentation) sowie technische Anforderungen. Der Schwerpunkt der Prüfung von Standards auf XÖV-Konformität liegt bei der Prüfung der Erfüllung der technischen Anforderungen. Die Muss- und Soll-Regeln der technischen Anforderungen sind in das XÖV-Produktionszubehör integriert. Daher kann die Prüfung der Erfüllung der technischen Anforderungen weitgehend automatisiert erfolgen. Die XÖV- Konformitätskriterien regeln auch, in welcher Form ein Standard erstellt und vorgelegt werden muss, damit dieser auf die Erfüllung der technischen Anforderungen überprüft werden kann. Darüber hinaus legen die XÖV-Konformitätskriterien die Nutzung von bereits vorhandenen fachübergreifenden und fachunabhängigen Bausteinen fest. 11 Inhalte aus: XÖV-Standards Die XÖV" -Standards beschreiben den elektronischen Datenaustausch zwischen den Kommunikationspartnern der ÖV. Wie oben beschrieben, sollen XÖV-Standards durchgängige elektronische Geschäftsprozesse ermöglichen. In den folgenden Kapiteln werden die projektrelevanten XÖV-Standards und Standardisierungsbemühungen beschrieben Vorhaben XLeistung Das XÖV-Vorhaben XLeistung standardisiert die Leistungsbeschreibung der ÖV. Diese Standardisierung erfolgte in Anlehnung an die bereits im Kontext LeiKa definierten Strukturen XZufi Die Spezifikation XÖV-Standards XZufi 1.0 beschreibt den produkt- und herstellerunabhängigen Austausch von Zuständigkeitsfinderdaten 13. XZufi untergliedert sich in vier wesentliche Grundpakete: Leistungen (Verwaltungsleistungen) 11 Vgl. Handbuch zur Entwicklung XÖV-konformer IT-Standards, öffentlich 37

38 Organisationseinheiten (zuständige Stellen) Gebiete Formulare Der XÖV-zertifizierte Schnittstellenstandard XZufi 1.0 wurde unter der Federführung des Landes Sachsen-Anhalt entwickelt und bereitgestellt. Mit der Weiterentwicklung des Standards hin zu XZufi 2.0 wird der LeiKa-konformer Standard XLeistung integriert Projekt XD115 Das XÖV-Vorhaben XD115 beschreibt den formalen Aufbau von D115-konformen Leistungsberichten. Die Leistungsbereitstellung für D115 Services erfolgt über dieses Datenformat. Die jeweiligen Leistungsberichte werden im Regelfall auf Basis einer lokal vorhandenen und stetig aktualisierten Datenquelle erstellt. Das Format beschreibt den Aufbau eines Leistungsberichtes und spezifiziert dazu insbesondere die Inhalte und Reihenfolge der Felder, mit denen eine Leistungsbeschreibung erfolgt, insbesondere: Ersteller des Leistungsberichts Details der Leistung, wie z. B. Leistungsname, Beschreibungstext oder mitzubringende Unterlagen Ansprechpunkte, die ein Bürger oder Unternehmen kontaktieren kann, wenn die Leistung abgerufen oder wenn detailliertere Fragen geklärt werden sollen. Mit diesem Aufbau wird die einheitliche Darstellung aller Informationen sowie deren hoher Ergebnisqualität im D115-Wissenspool sichergestellt: homogene Leistungsberichte über verschiedene Verrichtungen und Orte ermöglichen eine Ebenen übergreifende Wissenssuche. Folgende Abbildung stellt den schematischen Aufbau des Leistungsprozesses dar. Das Projekt ist aktuell inaktiv. Die im Projekt erarbeiteten Anforderungen und Ergebnisse fließen in das XZufi-Vorhaben ein Vorhaben XProzess Das XÖV-Vorhaben XProzess 14 wurde im Rahmen des Koordinierungsprojektes "Nationale Prozessbibliothek" (NPB) vom Hasso Plattner Institut ins Leben gerufen. In seiner aktuellen Version wird das XÖV-Projekt bei der KoSIT eingereicht. In einem weiteren Schritt sind dann die fachlichen Inhalte mit Vertretern aus Bund, Land und Kommune abzustimmen. Der XÖV-Standard XProzess wurde mit dem Ziel entwickelt, den Austausch und Kollaboration zwischen den verschiedenen Prozessprojekten im Rahmen der Nationalen Prozessbibliothek zu ermöglichen und Prozessmodellierungswerkzeuge sowie externe Prozessregister an die NPB anzubinden. XProzess wurde XÖV konform in XML spezifiziert und beschreibt die Metadaten und Prozessmodelldateien, die über die XProzess Schnittstelle ausgetauscht werden. XProzess erleichtert den Verwaltungsmitarbeitern, ihre Prozessmodelle in der NPB zu veröffentlichen und mit anderen Kollegen diese zu diskutieren und zu teilen. Zugleich kann so mit wenig Aufwand die Konsistenz der Prozessmodelle und ihre Metadaten in der NPB und den externen 14 öffentlich 38

39 Prozessregistern sowie Prozessmodellierungswerkzeugen gewahrt und der Pflegeaufwand minimal gehalten werden. XProzess besteht aus einer fachlichen Komponente, dem Ordnungsrahmen und einer technischen Komponente, der technischen Umsetzung. Der Ordnungsrahmen stellt das theoretische Grundgerüst der NPB dar. Sämtliche Informationen, die in der Bibliothek hinterlegt werden, sind in dieser Systematik verankert. Er bildet auch die Grundlage für den Datenaustausch mit den anzubindenden Bibliotheken bzw. Registern Dritter. Der Ordnungsrahmen beschreibt eine Vielzahl an Metadaten, die den Prozesssteckbrief abbilden und das Auffinden von Prozessen in der NPB erleichtern. Import und Exportfunktion über den XProzess-Standard in der NPB wurden per Webinterface und als Webservice implementiert. Die XProzess-Schnittstelle soll es den Nutzern erleichtern, sowohl Prozessmodelle in der NPB zu veröffentlichen und sie zu pflegen, als auch die Synchronisation der Prozessmodelversionen im Modellierungswerkzeug und NPB zu vereinfachen. XProzess bestimmt ein fachliches Rahmenwerk für die Beschreibung von Prozessmodellen durch die Festlegung von Pflicht- und optionalen Metadaten, die für jedes Prozessmodell in der NPB angegeben werden müssen Interaktion mit der Nationalen Prozessbibliothek Die Schnittstelle XProzess ermöglicht den direkten Import und Export eines Prozesses, d. h., Prozessmodell und seine Metadaten in einem einheitlichen standardisierten XÖV-konformen XML-Format (XProzess- XML-Datei), wobei der Import und Export sowohl über einen Webservice als auch per Browser möglich ist. Folgende Abbildung beschreibt diese Anwendungsfälle. öffentlich 39

40 Abbildung 16: XProzess UseCase-Diagramm Ein Nutzer soll Prozessmodelle, die er in seinem Modellierungswerkzeug modelliert hat, in der NPB veröffentlichen können und umgekehrt für ihn relevante Prozesse aus der NPB als XProzess-XML-Datei exportieren und in sein Modellierungswerkzeug importieren können. Ein Nutzer kann in der Nationalen Prozessbibliothek nur die Metadaten eines Prozessmodells bearbeiten oder auch zu einem Prozess veränderte Prozessmodelldiagramme hinzufügen. Um ein Prozessmodelldiagramm zu bearbeiten, muss er dieses jedoch in sein Werkzeug importieren und dort die gewünschten Veränderungen vornehmen. Die veränderte Version des Prozessmodells in seinem Werkzeug kann er dann wieder in die NPB über eine XProzess-XML Datei importieren. Das UseCase-Diagramm stellt die beiden Wege zur Durchführung des Exund Imports eines Prozessmodells und seinen Metadaten in die NPB vor. Der Import und Export über Webservice setzt weitere mögliche Interaktionen mit der NPB voraus, wie z. B. die Prozesssuche oder die Statusabfrage eines Prozesses. Diese Anwendungsfälle werden ebenfalls in dem UseCase dargestellt. Der Einsatz des XProzess-Standards für den Austausch von Prozessen zwischen NPB, Prozessmodellierungswerkzeug oder dritten Prozessregistern soll die Nutzung der Nationalen Prozessbibliothek erleichtern, da der Nutzer die Metadaten und die dazugehörigen Prozessmodelldateien nicht mehr eigenhändig in die NPB oder auch umgekehrt in seinem Prozessmodellierungswerkzeug eintippen muss Vorhaben XFormular Mit dem FIM-Baustein Formulare 15 wird ein künftiges Datenaustauschformat XFormular beschrieben. Eine entsprechende Umsetzung wird vom FIM-Projekt angestrebt. 5.9 Amtlicher Gemeindeschlüssel Für alle Gemeinden der Bundesrepublik Deutschland gilt seit Jahren eine einheitlich strukturierte Gemeindeschlüsselnummer. Sie findet bei allen statistischen Erhebungen Anwendung und ändert sich auch dann nicht, wenn eine Gemeinde z. B. durch Namensänderung ihren Platz in der alphabetischen Reihenfolge wechselt. Die Gemeindeschlüsselnummer ist achtstellig. Die ersten beiden Stellen kennzeichnen das Land. Mecklenburg-Vorpommern hat die Schlüsselnummer 13. In der dritten Stelle ist der Regierungsbezirk enthalten. Die vierte und fünfte Stelle der Nummer beinhaltet die Kreisnummer und die sechste bis achte Stelle kennzeichnen die Gemeinden. Kreisfreie Städte haben an den drei letzten Stellen Nullen (000). Beispiel: Die Gemeindenummer der Hansestadt Wismar lautet = Land Mecklenburg-Vorpommern 0 = Regierungsbezirk (0 = keine Regierungsbezirke) 74 = Landkreis Nordwestmecklenburg 087 = Gemeinden und amtsfreie Gemeinde (z. B. Hansestadt Wismar) 15 Siehe FIM-Ordnungsrahmen Feinkonzept, 2014 öffentlich 40

41 Durch Eingemeindungen, Zusammenschlüsse von Gemeinden etc. ändern sich neben den Gemeindegrenzen auch die Schlüsselnummern. Auch können Änderungen bei der Zugehörigkeit von Gemeinden zu Verwaltungsgemeinschaften auftreten. Eine entsprechende Codeliste wird im XRepository vorgehalten e0-bcdabc67d5e5, öffentlich 41

42 6 TECHNISCHE STANDARDS Technische Standards erleichtern die Konzeption und Entwicklung von IT-Architekturen. Im Kontext der ÖV benennt SAGA auf Ebene des Technology Viewpoint. In den folgenden Unterkapiteln werden nur die relevanten SAGA-Themenfelder Datenmodell, Applikationsarchitektur und Kommunikation beleuchtet, da Sie maßgebliche die Interoperabilität prägen 17. In diesen Umfeld werden die für das Projekt relevanten Standards benannt und beschrieben. 6.1 Datenmodell Folgende Kapitel beschreiben die relevanten Austauschformate zum Datentransfer zwischen Datenmodellen verschiedener Applikationen XML Der Datenaustausch zwischen den IT-Komponenten sollte auf XML-basierte Datenstrukturen erfolgen. Nur so lassen sich komplexe Datenstrukturen standardisiert aufbauen und IT-seitig effizient verarbeiten. XML (englisch Extensible Markup Language) ist eine Sprache zur Darstellung von strukturierten Daten in Textdateien. Mit der Formulierung eines speziellen XML- Formates werden die TAG-Namen und ihre Reihenfolge und Strukturierung vorgeschrieben. XML wird primär zum Datenaustausch, teilweise auch zur Datenspeicherung genutzt. Der besondere Vorteil von XML ist, dass man XML-Dateien formal beschreiben und so automatisiert validieren kann. Für diese formale Beschreibung stehen sogenannte Schemasprachen zur Verfügung (z. B. XSD). Schemasprachen unterscheiden sich in der Mächtigkeit ihrer Beschreibungsmöglichkeiten 18. In der Rubrik "Datenmodelle" definiert SAGA diesen Standard als obligatorisch XML-Schema XML-basierte Austauschformate können über XML-Schema (XSD XML-Schema Definition) entworfen und validiert werden. Zu jedem Datenkontext sollte ein XML-Schema vorhanden sein. Das XML-Schema ist eine Empfehlung des W3C zur Definition von XML-Datenstrukturen. Anders als bei den klassischen XML-DTDs wird die Struktur in Form eines XML-Dokuments beschrieben. Der Standard unterstützt eine große Anzahl von Datentypen. Das XML-Schema unterscheidet zwischen einfachen und komplexen Datentypen. Die Datentypen in XML-Schema werden klassifiziert in eingebaute bzw. vordefinierte (built-in) und benutzerdefinierte (user defined) Datentypen. In der Spezifikation des W3C für XML-Schema sind 19 voreingestellte primitive Datentypen (z. B. boolean, string, float, date und NOTATION) und weitere 25 davon abgeleitete primitive Datentypen (wie ID und integer) definiert. Mit der Nutzung von XML- Schema können eingehende XML-Datenstrukturen syntaktisch geprüft werden (umfangreiche 17 Standards/SAGA/saga_modul_tech_spez_de_bund_5_0_download.pdf? blob=publicationfile, Standards/SAGA/saga_modul_tech_spez_de_bund_5_0_download.pdf? blob=publicationfile, öffentlich 42

43 Datenprüfung) 20. In der Rubrik "Datenmodelle & Austauschformate für Datenmodelle" definiert SAGA diesen Standard als obligatorisch Kommunikation Folgende Kapitel stellen die projektrelevanten Standards im Bereich der Kommunikation zwischen verschiedenen Applikationen dar SOAP Das Simple Object Access Protocol (SOAP) ist ein Netzwerkprotokoll, mit dessen Hilfe Daten zwischen Applikationen ausgetauscht und Remote Procedure Calls durchgeführt werden können. SOAP stützt sich auf XML zur Repräsentation der Daten und auf Internet-Protokolle der Transport- und Anwendungsschicht (vgl. TCP/IP-Referenzmodell) zur Übertragung der Nachrichten 22. Die gängigste Kombination ist SOAP über HTTP und TCP. SAGA definiert diesen Standard als obligatorisch WS-Security Die Organisation Organization for the Advancement of Structured Information Standards (OASIS) liefert die Spezifikation für das heute allgemein akzeptiertes Verfahren zur Verschlüsselung und Sicherstellung der Integrität von SOAP-Nachrichten 24. SAGA empfiehlt diesen Standard für die verwaltungsexterne Kommunikation Web Map Services Die Web Map Service Spezifikation verantwortet das Open Geospatial Consortium (OGC). Darin sind Parameter beschrieben, die bei einer Anfrage benannt werden müssen oder können. Weiter ist beschrieben, wie der WMS-Server aus einer solchen Anfrage den Ausschnitt und gegebenenfalls die inhaltliche Aufbereitung der Karte erzeugen soll. So werden Kartendarstellungen von Amtsadressen und Zuständigkeitsbereichen möglich. Gemäß der Spezifikationen des OGC kann ein WMS-Server die angeforderten Karten aus Rasterdaten oder Vektordaten visualisieren. Im Sinne eines verteilten Geoinformationssystems (GIS) besitzt ein WMS nur die Fähigkeit zur Auskunft der notwendigen Metainformation, zur Visualisierung dieser Geodaten und für eine allgemeine Abfrage der zugrundeliegenden Sachdaten. Das Standards/SAGA/saga_modul_tech_spez_de_bund_5_0_download.pdf? blob=publicationfile, Standards/SAGA/saga_modul_tech_spez_de_bund_5_0_download.pdf? blob=publicationfile, Standards/SAGA/saga_modul_tech_spez_de_bund_5_0_download.pdf? blob=publicationfile, öffentlich 43

44 Ergebnis, also die Karte, wird vom WMS in der Regel in einem einfachen Raster-Grafikformat zurückgegeben, je nach Aufbau können aber auch verschiedene andere Dateiformate wie Scalable Vector Graphics (SVG) oder Web Computer Graphics Metafile (WebCGM) erstellt werden, wie es z. B. bei temporären Daten mit Zeitbezug als Film notwendig wird. Daher kann der Nutzer einen Web Map Service grundlegend über seinen Webbrowser ansprechen, in dem die Karte dann angezeigt werden kann. Somit ist der Web Map Service Bestandteil eines Web GIS Web Feature Services Die Web Feature Service (WFS) Spezifikation verantwortet die Open Geospatial Consortium (OGC). Im Rahmen der Open Geospatial Consortium (OGC) Spezifikationen ermöglicht ein WFS den Zugriff auf geographische Features in Datenbanken und gibt das Ergebnis mindestens als unabhängiges Dateiformat Geography Markup Language (GML) zurück 27. Unter einem Feature versteht man laut Definition die allgemeine Abstraktion eines realen Faktums ("real world phenomenon"). Ein Feature Type ist die Darstellung mithilfe eines Namens, weiteren Attributen und bei geographischen Feature Types mit einer Geometrie. Beispielsweise enthält eine Datenbank Feature Types des Typs "Amt". Eine Instanz eines Features (eine Feature Instance) ist damit dann ein konkretes Amt. So können über semantische Zuordnungen Suchanfragen Typen interpretiert werden: "Suche Ämter". 6.3 Applikationsarchitektur Die Wahl des Architekturstils wird stark von den nicht-funktionalen Anforderungen beeinflusst. Er regelt grundlegend die Organisation und Interaktion zwischen Softwarekomponenten. Ein Architekturmuster offeriert Wissen über den Softwareentwurf und unterliegt der stetigen Weiterentwicklung. So kann ein Muster auf Basis von gesammelten Erkenntnissen neu entstehen, in ein vollständigeres Architekturmuster übergehen oder in separate Architekturstile zerfallen. Ziel ist es, dem Entwickler dezidiertes Wissen über den Softwareentwurf bereitzustellen, damit dieser effektiv Software gestalteten und die jeweiligen Vorteile im Entwurf nutzen kann. Folgende nicht-funktionalen Anforderungen bestimmen u. a. das Architekturmuster: Erweiterbarkeit Wiederverwendbarkeit Flexibilität Interoperabilität Skalierbarkeit In den folgenden Kapiteln wird das gängigste Architektur-Framework Java EE und das Architekturmuster SOA beschrieben öffentlich 44

45 6.3.1 Java Platform Enterprise Edition Unbestritten haben Java EE-basierte Architekturen die größte Verbreitung. Die Spezifikation Java EE definiert eine Reihe von Programmierschnittstellen maßgeblich zur Entwicklung von Webanwendungen. Die Spezifikation beschreibt eine Architektur, die wesentliche Aspekte geschäftskritischer Funktionen von Anwendungen berücksichtigt und unterstützt Service Oriented Architecture Für eine serviceorientierte Architektur (SOA) gibt es bis heute noch keine einheitliche Definition. Jedoch kann anhand verschiedener Definitionen grundlegend gesagt werden, dass es sich bei der SOA um ein umfassendes Architekturmuster handelt. Hierbei kombiniert und erweitert der Architekturstil Ansätze aus dem Geschäftsprozessmanagement (GPM), der Enterprise Application Integration (EAI), dem World Wide Web (WWW) und des komponentenorientierten Softwareentwurf zu einem umfänglichen Architekturkonzept SOA-Schichten Die Umsetzung von Geschäftsprozessen im SOA-Umfeld ist komplex. Damit die Komplexität beherrschbar bleibt, ist laut Enterprise-BPM eine fachliche Komponentenbildung und Schichtung von SOA-Komponenten notwendig: Eine SOA-Komponente bietet nach außen eine Menge von öffentlichen Schnittstellen an (sie fungiert damit als Servicegeber). Diese Schnittstellen bieten fachliche Funktionen ( Services ) an. SOA-Schichten gruppieren SOA-Komponenten und die von ihnen angebotenen Services. Heute sind weitgehend vier Schichten etabliert: Frontends, Prozess-, Orchestrierungs- und Basiskomponenten. Die folgende Abbildung zeigt die vier SOA-Schichten und die Eigenschaften der jeweils dort eingruppierten Frontends und Services öffentlich 45

46 Abbildung 17: SOA-Schichten (Quelle: Enterprise-BPM) Services Ein wesentlicher Bestandteil dieses Architekturstils ist, dass Geschäftsprozesslogiken in semantisch getrennten und technisch gekapselten Services vorliegen. Dabei wird laut Enterprise-BPM in verschiedenen Serviceschichten unterschieden: Prozessservices Orchestrierte Services Basisservices Die Wiederverwendbarkeit von Services ist in der untersten Serviceschicht am höchsten. Mit jeder weiteren Schicht nimmt die Wiederverwendbarkeit der Services ab und deren Komplexität zu. In der Orchestrierungsschicht lassen sich höherwertige Services über die Aggregation und Komposition von Basisservices erstellen. So bezeichnet der Begriff Service ein Konzept, das für eine wiederholbare Ausführung von Geschäftsaktivitäten steht. Basis- und orchestrierte Services sollten folgende Attribute aufweisen: bieten Anwendungsdaten an sind zustandslos sind in sich abgeschlossen können eigenständig genutzt werden müssen eine veröffentlichte Schnittstelle haben müssen Pattformunabhängig sein müssen in einem Verzeichnis registriert sein Webservice Ein Webservice ist ein Dienst, der heterogen in Websystemen verteilt und in beliebigen Anwendungen benutzbar ist. Dabei wird der Zugriff auf Webservices durch das Middleware- öffentlich 46