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.
8.5.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.
8.5.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
72: 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.
8.5.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.
8.5.4 Umsetzungsanforderungen
Zur Vorbereitung der nutzungsfreundlichen 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 Informationen in der Handreichung des IT-Planungsrates, welche aktuell bearbeitet wird und daher nicht zur Verfügung steht)
- 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.
Stand: 06.10.2021
