It-Planungsrat
Page tree
Skip to end of metadata
Go to start of metadata

Ausgehend von den Lebens-/Geschäftslagen Journeys in einem Themenfeld werden für ausgewählte weitere Leistungen Umsetzungskonzepte in Form von Leistungssteckbriefen erarbeitet. Auf Basis der übergeordneten Nutzer:innenführung wird für diese Leistungen in einem ersten Schritt anhand des Nutzer:innenprozesses der wesentliche Funktionsumfang skizziert. Anschließend werden die dafür geeigneten Umsetzungsvarianten erarbeitet. Für diese Umsetzungsvarianten werden auf Basis der bereits bestehenden relevanten Vorarbeiten die Umsetzungsanforderungen abgeleitet, insbesondere die Anforderungen an Basiskomponenten, Registerschnittstellen und Rechtsänderungsbedarfe.


7.4.1 Wesentlicher Funktionsumfang entlang des Nutzer:innenprozesses

In einem ersten Schritt wird anhand des Nutzer:innenprozesses, insbesondere der Nutzer:innenkontakte und Leistungskategorien, der wesentliche Funktionsumfang skizziert. Hierfür werden auf Basis von typischen Merkmalen von Nutzerinnen und Nutzern der Leistung Personas entwickelt. Für diese werden anhand der idealtypischen Phasen bzw. Leistungskategorien (1) Orientierung und Anliegensklärung, (2) Antragstellung, (3) Statusinformationen und Kontakt, (4) Bescheidzustellung, (5) Leistungsbezug, Veränderung und Überprüfung die Nutzerkontakte und -bedürfnisse identifiziert. Je nach Charakter der Leistung sind einzelne Phasen nicht relevant.

Phase/Leistungskategorie

Typische Nutzerkontakte und -bedürfnisse

Funktionsumfang

Orientierung und Anliegensklärung

Welche Leistungen helfen in meiner Situation? Ist die Leistung für mich einschlägig? Wie hoch ist der voraussichtliche Anspruch?

„Quick check", Test-Rechner anhand von KO-Kriterien; Lebenslagenassistenten; Benachrichtigungen

Antragstellung

Welches Formular ist für mich einschlägig? Sind diese Datenfelder für mich relevant? Wo erhalte ich diesen Nachweis?

Antragsassistent; Datenübernahme aus Nutzer:innen- oder Systemen der Verwaltung

Statusinformationen und Kontakt

Wie lange dauert die Bearbeitung noch? Habe ich alle notwendigen Angaben erbracht?

Status-Tracker

Bescheidzustellung

Ich möchte Widerspruch einlegen.

Rechtssicherer Rückkanal zur Behörde.

Leistungsbezug, Veränderung und Überprüfung

Ich muss/möchte Veränderungen meiner persönlichen Situation übermitteln. Der Bewilligungszeitraum läuft ab und ich möchte eine Verlängerung beantragen Wie lange habe ich noch Anspruch?

Wiederverwendung von Antragsdaten

Grundlage hierfür können insbesondere Experten:inneninterviews mit Behördenvertreter:innen, Befragungen von Nutzerinnen und Nutzern, rechtliche Vorgaben, Prozessmodelle, Leistungsbeschreibungen sein. Die dafür erforderlichen Zugänge stellen die in einem Themenfeld beteiligten Verwaltungspartner sicher.
Anhand der Nutzer:innenkontakte und des erforderlichen Funktionsumfangs werden Anforderungen an den digitalen Service definiert und die zwischen Nutzerinnen, Nutzern und Verwaltung auszutauschenden Nachrichten identifiziert.


7.4.2 Umsetzungsvarianten

Umsetzungsvarianten für Leistungen spezifizieren die territoriale Reichweite einer Lösung, die Form der Einbettung in Behörden-, Fach- oder Verwaltungsportale und die Nutzungsform. Grundsätzlich lassen sich drei Nutzungsformen unterscheiden: Webbrowser, App und Maschine-zu-Maschine-Schnittstelle. Je nach Nutzungsmuster einer Leistung weisen die Nutzungsformen gewisse Vorzüge auf. So haben Apps den Vorteil, dass Daten auf den Geräten der Nutzerinnen und Nutzer gespeichert werden können, was datenschutzrechtlich vorteilhaft ist, da sie in der Nutzer:innensphäre liegen. Dadurch eignen sich Apps insbesondere für Leistungen mit mehrfachen Verwaltungskontakten, in deren Rahmen identische oder ähnliche Daten erforderlich sind, wie beispielsweise bei Verlängerungs- oder Weiterleistungsanträgen.

Mobile Apps sind hingegen aufgrund des kleinen Bildschirms und der kleinen Tastatur nur bedingt geeignet für umfangreiche Anträge die eine hohe Zahl von Nutzer:inneneingaben erfordern. Maschine-zu-Maschine (M2M)-Schnittstellen, ermöglichen intermediäre Geschäftsmodelle, indem Drittanbieter Programme entwickeln können, insbesondere mobile Apps, Desktop-Anwendungen und Webbrowser-Applikationen, aber auch smarte Devices, die diese Schnittstellen zum Datenaustausch mit den Behörden verwenden. M2M-Schnittstellen eignen sich dementsprechend insbesondere dann, wenn Verwaltungsleistungen im engen Zusammenhang mit privatwirtschaftlichen Leistungen stehen, sodass Dritte Services anbieten können, die sowohl private als auch öffentliche Dienstleistungen abdecken (z.B. Umzug, Sterbefall, Export, Kfz-Erwerb), und wenn Daten in der Nutzer:innensphäre bereits digital vorliegen und für Verwaltungskontakte wiederverwendet werden können. Letzteres ist häufig bei Leistungen für Unternehmen der Fall, bei denen relevante Daten für Kontakte u.a. mit der Steuerverwaltung, Sozialversicherungen und Statistikbehörden in der Unternehmens-IT vorliegen und dafür in großem Umfang bereits heute über Schnittstellen weitgehend automatisiert verwendet werden.

Je nach Verwaltungsleistung kann es aufgrund heterogener Nutzer:innengruppen und unterschiedlicher Nutzungsvoraussetzungen der Fall sein, dass mehrere Nutzungsformen parallel notwendig sind. Allerdings wirkt sich die Gestaltung der digitalen Lösung auch auf die Eignung der unterschiedlichen Nutzungsformen aus: Werden Daten nicht länger umfangreich im Front-End bei den Nutzerinnen und Nutzern erhoben, sondern aus Registern der Verwaltung abgerufen, können selbst umfangreiche Anträge mobil genutzt werden, da die Eingaben von Nutzerinnen und Nutzern erheblich reduziert werden.

In Bezug auf die territoriale Reichweite lassen sich grundsätzlich die drei föderalen Ebenen bundesweit, landesweit, kommunal unterscheiden. Davon weichen Leistungen ab, die beispielweise von Krankenkassen erbracht werden. Für die Erbringung eines großen Teils der Leistungen sind im deutschen föderalen System die Kommunen zuständig, sodass grundsätzlich auch hier die digitalen Services umgesetzt und angeboten würden. Allerdings vervielfachen sich dadurch unter Umständen auch die Umsetzungsaufgaben, da auf kommunaler Ebene oft eine hohe Zahl von Behörden für bestimmte Leistungen zuständig ist. Aus Effizienz- und Nutzer:innenfreundlichkeitsgesichtspunkten kann es deshalb sinnvoll sein, Services gebündelt umzusetzen.

Eine solche Bündelung kann auf unterschiedlichen Wegen erzielt werden, beispielsweise indem Services flächendeckend für ein Land oder bundesweit in einem Antragsmanagement umgesetzt und die Daten zur Bearbeitung der Leistungen an die zuständigen Behörden übermittelt werden oder indem die Services von den Herstellern der jeweiligen Fachverfahren umgesetzt werden. Für eine solche gebündelte Umsetzung gelten allerdings gewisse Voraussetzungen: So ist die technische Komplexität solcher Lösungen nur schwer zu beherrschen, wenn das zugrundeliegende Recht stark unterschiedlich ist. Günstige Grundvoraussetzungen liegen dementsprechend immer dann vor, wenn bundes- bzw. landesweit einheitliches Recht angewendet werden muss. Günstig sind die Voraussetzungen auch dann, wenn die Datenaustausche zwischen Front-End und Back-Ends oder zwischen Back-Ends verschiedener Behörden bereits in großem Umfang standardisiert sind.

Bei der Frage nach der geeigneten Form der Einbettung eines Services lassen sich idealtypisch Single Service-Lösungen (z.B. www.bafoegonline.bva.bund.de), Behördenportale (z.B. www.arbeitsagentur.de) und Fach- (www.elster.de) bzw. Lebenslagenportale (z.B. www.familienportal.de) unterscheiden. Die Einbindung in den Portalverbund ist obligatorisch. Bezogen hierauf stellt sich allerdings die Frage der Integrationstiefe, also ob ein Service unmittelbar im Verwaltungsportal umgesetzt werden kann oder ein Absprung auf unmittelbar im Fachportal oder mit geeigneten Unterstützungsinstrumenten (z.B. personalisierter Assistent, der anhand von Nutzer:innenmerkmalen auf verwandte Leistungen verweist; Test-Rechner).

Eine Single Service-Lösung ist grundsätzlich dann geeignet, wenn eine Leistung aus Nutzer:innensicht isoliert von anderen Leistungen genutzt wird. Ist die Leistung hingegen eingebettet in eine komplexere Lebenssituation, eignet sich eine Umsetzung in einem Fach- oder Lebenslagenportal. Auch hier gibt es, ähnlich wie bei allgemeinen Verwaltungsportalen, unterschiedliche Integrationstiefen. Aus Nutzer:innensicht sollte aber in allen Fällen, in denen eine leistungs- bzw. behördenübergreifende Orchestrierung erforderlich ist, eine Schicht zwischen dem Online-Service und dem allgemeinen Verwaltungsportal vorgesehen werden, die Nutzerinnen und Nutzer unterstützt und leitet.

Die folgende Abbildung bietet eine idealtypische Übersicht von territorialer Reichweite und der Einbettung des Services für eine Leistung.


Abbildung 68 Umsetzungsvarianten für digitale Services nach Flächendeckung und Leistungsbreite

Ausschlaggebend für die Konzeption der Umsetzungsvarianten einer Leistung ist der Nutzer:innenprozess und welche einzelnen Nutzer:innenprozessschritte unterstützt werden sollen. Vor diesem Hintergrund sollten folgende Kriterien für die Wahl der Umsetzungsvariante berücksichtigt werden und in die Begründung der Auswahl einfließen:

  • Ist der Nutzer:innenprozess durch wiederkehrende Kontakte im Zeitablauf mit identischen oder ähnlichen Daten gekennzeichnet, legt das eine Umsetzung als App und/oder eine enge Anbindung an die Fachverfahren nahe (z.B. durch Umsetzung Fronst-Ends durch Fachverfahrens-Hersteller).
  • Ist die Leistung Bestandteil einer Lebenssituation mit zahlreichen Bezügen zu anderen Leistungen, bietet sich eine gebündelte Umsetzung in einem Fachportal an. Generell sind alle Verwaltungsleistungen entsprechend den Vorgaben zum Portalverbund in die Verwaltungsportale aufzunehmen.
  • Wird für eine Leistung bundesweit einheitliches Recht angewendet, sollte aus Nutzer:innenperspektive und unter Effizienzgesichtspunkten die Möglichkeit eines bundesweit flächendeckenden Service geprüft werden.
  • Weist die Zielgruppe einen hohen Digitalisierungsgrad auf und die relevanten Daten liegen bereits digital vor (direkt bei den Nutzerinnen und Nutzern oder bei Intermediären), eignet sich eine M2M-Schnittstelle.

Unabhängig von der konkreten Umsetzungsvariante ist immer die anderweitige Nachnutzung auf Basis von FIM vorzusehen.


7.4.3 Relevante Vorarbeiten

Relevante Vorarbeiten können sich auf das Front-End beziehen (z.B. digitale Services, FIM Leistungsbeschreibungen, FIM Datenfelder), IT-Standards sein (z.B. XÖV, Elster usw.), Middleware-Infrastrukturen sein (z.B. DVDV, BRIS) oder im Back-End der Verwaltung liegen (z.B. FIM Prozesse, Register).
Die relevanten Vorarbeiten werden daraufhin analysiert, inwieweit sie bereits den erforderlichen Funktionsumfang abdecken bzw. welche Lücken noch bestehen. Notwendig in diese Betrachtung einzubeziehen und zu berücksichtigen sind:

  • Nutzer:innenfreundliche digitale Services: Sind diese grundsätzlich nachnutzbar bzw. übertragbar? Decken sie die Anforderungen des OZG und die Nutzeranforderungen ab?
  • FIM Leistungsbeschreibungen, Datenfelder und Prozesse: Liegen diese in erforderlichem Umfang und Aktualität vor?
  • Basiskomponenten: Sind die erforderlichen Funktionen in der Road Map der KG Portalverbund bereits vorgesehen?
  • IT-Standards: Inwieweit decken einschlägige und etablierte Standards bereits die auszutauschenden Nachrichten aus?
  • Relevante Register: Weisen die relevanten Register bereits die erforderlichen Schnittstellen auf?
  • Middleware: Existiert eine Infrastruktur, über die Daten zwischen Front-End und Back-End ausgetauscht werden können (falls erforderlich)?
  • Fachverfahrenslandschaft: Weisen die Fachverfahren bereits Schnittstellen für den Datenaustausch zwischen Front-End und Back-End auf?

Aus dem Abgleich der bestehenden Vorarbeiten und dem erforderlichen Funktionsumfang leiten sich die Umsetzungsanforderungen ab.


7.4.4 Umsetzungsanforderungen

Zur Vorbereitung der nutzer:innenfreundlichen Digitalisierung der Leistungen werden abschließend die Umsetzungsanforderungen systematisch erfasst. Das Hauptaugenmerk liegt dabei auf den Anforderungen an:

  • FIM-Stamminformationen: Insbesondere FIM Datenfelder für die Erfassung der erforderlichen Daten bei den Nutzerinnen und Nutzern.
  • Datenaustauschstandards: (Weiter-)Entwicklungsbedarf von Datenaustauschstandards, insbesondere zwischen Front-End und Back-End. Sollte es keine relevanten Datenaustauschstandards geben, ist die Datenübergabe mit XFall vorzusehen.
  • Vertrauensniveau und Schutzbedarf: Feststellung anhand des Praxistools Vertrauensniveau (weitere Informationene in der Handreichung des IT-Planungsrates)
  • Registerschnittstellen: Erforderliche Registerschnittstellen für Standard-Datenfeldgruppen (z.B. Meldeadresse, Kontoverbindung, Familienverhältnisse), damit diese nicht länger von den Nutzerinnen und Nutzern eingegeben werden müssen.
  • Basiskomponenten und Querschnittsdienste: Fachspezifische Anforderungen an bestehende und zusätzlich notwendige Basiskomponenten und Querschnittsdienste (z.B. mglw. für Status-Updates, Push-Notification, doppeltes Schriftformerfordernis)
  • Rechtsänderungen: Diese können sich auf Digitalisierungshürden (u.a. Schriftformerfordernisse, papiergebundene Nachweise) beziehen oder für den Abruf von Daten aus Registern erforderlich sein.

Die Anforderungen an Basiskomponenten, Registerschnittstellen und Rechtsänderungen werden von den Federführern eines Themenfelds in einem Tool für das Anforderungsmanagement erfasst, das im Rahmen des Digitalisierungsprogramms bereitgestellt wird.

Für die Konzeption von Laborkandidaten ist je nach Charakter der Leistung vorzusehen, dass auf Basis der Erhebung & Analyse im Rahmen des Themenfelds Vorschläge für die Umsetzungskonzeption erarbeitet werden, die anschließend im Rahmen von Experteninterviews und je nach Bedarf bis zu zwei Workshops mit zuständigen Behörden, Fachverfahrensherstellern, IT-Dienstleistern, GK FIM, Standardisierungsgremien und Bund-Länder-Arbeitsgruppen zu validieren.

Bei Leistungen mittlerer Priorität werden die Anforderungen an FIM-Stamminformationen (insbesondere FIM Datenfelder) identifiziert, die in der anschließenden Umsetzung erstellt werden müssen. Für depriorisierte Leistungen ist lediglich kurz zu begründen, warum diese nicht weiter betrachtet wurden.

 

  • No labels