Jusletter IT

Aufgrund nationaler und internationaler Rechtsnormen sind Unternehmen verpflichtet, staatlichen Informationspflichten nachzukommen. Diese erfordern, dass sie Informationen zum Unternehmen und zu dessen Aktivitäten an staatliche Organe übermitteln oder verfügbar halten. Informationspflichten umfassen u.a. anlassbezogene Meldungen (z.B. an Sozialversicherungsträger), regelmäßige Berichte (z.B. an Umweltbehörden) oder Anträge auf Genehmigung, Registrierung oder Anerkennung.¹ Die Bereitstellung dieser Informationen ist nicht nur mit erheblichen monetären und zeitlichen Aufwänden verbunden, sondern wird insbesondere aufgrund häufiger Gesetzesänderungen und der als zu lang empfundenen Bearbeitungszeiten, subjektiv als «Belästigung» wahrgenommen.^{2, 3}

Zur Reduktion von Bürokratiebelastung hat die EU-Kommission im Jahr 2007 das Aktionsprogramm zur Verringerung der Verwaltungslasten in der Europäischen Union⁴ auf den Weg gebracht, das u.a. die Anwendung des Standardkostenmodells⁵ zur Erfassung und Messung von Bürokratiebelastung vorsieht. In Folge dessen wurden in der Mehrheit der Mitgliedsstaaten die durch Informationspflichten verursachten Kosten unter Anwendung des Standardkostenmodells gemessen und Ziele und Maßnahmen zum Bürokratieabbau in zahlreichen politischen Programmen verankert.⁶ Im Bemühen, die Aufwände zur Erfüllung staatlicher Informationspflichten für die Unternehmen zu reduzieren, wurden, insbesondere in Studien für die Bundesverwaltung und für Länderverwaltungen der Bundesrepublik Deutschland, die Prozesse zur Erbringung von Informationspflichten z.T. detailliert untersucht und Konzepte und Lösungsansätze zur informationstechnischen Unterstützung erarbeitet.^{7, 8, 9, 10} Aus diesen Untersuchungen lassen sich zwei zentrale Problemfelder ableiten:

• Medienbrüche. Es zeigte sich zum einen, dass die Prozesse zwischen den Unternehmen und der Verwaltung nur selten durchgängig automatisiert sind und es somit zu Medienbrüchen kommt. Grund hierfür ist, dass es entweder an Schnittstellen zwischen den beteiligten Systemen fehlt oder die Prozessakteure Daten in Papierform bearbeiten bzw. erwarten.
• Vielzahl an Einzelsystemen. Zur Automatisierung von Informationspflichten werden zahlreiche Einzellösungen (im Folgenden: Fachanwendungen) eingesetzt. Diese beziehen sich entweder auf eine einzelne Informationspflicht oder bestenfalls auf eine Menge verwandter Informationspflichten wie z.B. Statistik- oder Sozialversicherungsmeldungen.

Bei genauerer Betrachtung der Prozesse lassen sich einige gravierende Aufwandstreiber für die Unternehmen, die Verwaltung, aber auch für die IT-Anbieter der Fachanwendungen identifizieren.

• Hoher Aufwand für die Unternehmen. Prinzipiell sind Unternehmen selbst dafür verantwortlich, die für sie relevanten Rechtsnormen zu identifizieren, korrekt zu interpretieren und umzusetzen. Dies erfordert die kontinuierliche Beobachtung des Rechtsraums im Hinblick auf Änderungen und Neuerungen und die Bereitstellung der hierfür erforderlichen Personalressourcen. Die vielen unterschiedlichen Fachanwendungen erfordern zudem jeweils einen eigenen Wartungs-, Schulungs- und Betriebsaufwand. Hinzu kommt, dass sich unterschiedliche Informationspflichten bzgl. ihrer Inhalte oftmals überschneiden (z.B. Statistik- und Sozialversicherungsmeldungen) und es aufgrund unterschiedlicher unternehmensinterner Zuständigkeiten zu einer Redundanz an Bearbeitungsschritten bezogen auf das Gesamtunternehmen kommt, z.B. weil gleiche Daten durch unterschiedliche Abteilungen wiederholt eingesammelt, qualitätsgesichert und aufbereitet werden.
• Hoher Aufwand für die Verwaltung. Aber auch für die Verwaltung entstehen vermeidbare Aufwände: So sind in Papierform gelieferte Daten neu zu erfassen; im Falle nicht plausibler Daten ist eine Klärung mit den Unternehmen herbeizuführen; und schließlich kommt es mangels Automatisierung zu Fristverletzungen, so dass die Verwaltung nachhaken und im Extremfall Bußgeldverfahren einleiten muss. Die Folge sind erhöhte Arbeitsaufwände auf beiden Seiten, ggf. Bußgelder wg. Fristverletzung und in jedem Fall längere Prozessdurchlaufzeiten.
• Aufwände für die Anbieter von Fachanwendungen und für die Unternehmen. Wann immer sich Rechtsnormen ändern, entstehen schließlich erhebliche Änderungsaufwände für IT-Anbieter und Unternehmen, da in diesem Fall die Einzelsysteme an die neue Gesetzeslage anzupassen sind.

Um die beschriebenen Aufwände zu reduzieren, muss eine Digitalisierung staatlicher Informationspflichten vier grundlegende Herausforderungen adressieren:^{11, 12}

• Sie muss die heutige Systemvielfalt reduzieren.
• Sie muss eine aufwandsarme Umsetzung von Normänderungen ermöglichen.
• Sie muss eine Integration heterogener Daten und Systeme leisten.
• Und schließlich, und dies ist ein kritischer Akzeptanzfaktor, muss sie die Datenhoheit der Unternehmen wahren, d.h. die zu übermittelnden Informationen müssen bis zu ihrer zweckgebundenen Übergabe in der Kontrolle der Unternehmen verbleiben.

In der Tradition der aus dem Software Engineering bekannten Patterns¹³ beschreibt Steffens ein Analysemuster, das die primären und zum Teil gegenläufigen Anforderungen beschreibt und für diese einen informationstechnischen Lösungsansatz, den «Regelbasierten Mediator» vorschlägt.¹⁴ Dieser zeichnet sich durch folgende zentralen Eigenschaften aus:

• Generizität. Um es den Unternehmen zu ersparen, eine Vielzahl insulärer Fachanwendungen einzusetzen, basiert er auf einer generischen, regelbasierten Komponente, die für beliebige Informationspflichten und Fachdomänen eingesetzt werden kann.
• Entwurf für Veränderung. Um die Anpassungsaufwände im Falle von Vorschriftenänderungen möglichst zu begrenzen, werden die Normen in eine formale Regeldarstellung überführt. Im Falle von Normänderungen sind lediglich die Regeln, nicht die verarbeitende Komponente selbst zu ändern.
• Verteilung von Verantwortung. Um die Unternehmen und auch die IT-Anbieter bei der Umsetzung der Vorschriften zu entlasten, besteht die Möglichkeit, Verantwortung zu verteilen, d.h. die Interpretation und Umsetzung der Normen in Form von Regeln auf kompetente Fachleute zu übertragen.
• Integration heterogener Daten und Systeme. Um von der Heterogenität der beteiligten Daten und Systeme zu abstrahieren, bietet a) ein globales Datenmodell eine einheitliche Sicht auf die Quelldaten und werden b) die Quell- und Zielsysteme lose an die verarbeitende Komponente gekoppelt.
• Autonomie. Zur Wahrung der Unternehmensautonomie können Unternehmen frei entscheiden, in welchen Systemen die Daten gehalten werden und wann, in welcher Form und zu welchem Zweck Informationen, ggf. nach manueller Ergänzung und Kommentierung, an die Verwaltung übergeben werden.

Beispiele für die Verwendung und architektonische Ausgestaltung des Regelbasierten Mediators sind die Software-Architektur von FRESKO¹⁵ und die Architektur des darauf basierenden Prozess-Daten-Beschleunigers (kurz: P23R-Architektur)¹⁶, der im nächsten Abschnitt kurz dargelegt wird.

Der P23R-Ansatz beschreibt keine Einzellösung, sondern eine domänenübergreifende technische Infrastruktur zur medienbruchfreien Erbringung staatlicher Informationspflichten, die sog. «P23R-Infrastruktur». Der Ansatz beruht auf den aus der EAI bekannten Konzepten der Daten- und Funktionsintegration und sieht, analog zum Geschäftsregelansatz, die Überführung von Rechtsnormen in formale, technisch ausführbare Regeln vor. Dabei orientiert sich die P23R-Architektur am Paradigma ereignisgesteuerter Service-orientierter Architekturen. Eine architekturkonforme P23R-Infrastruktur (siehe Abb. 1) stellt ein Verteiltes System von Teilsystemen und Komponenten dar, die in verschiedenen Kontrollsphären angesiedelt sind (Unternehmen, Verwaltung, hoheitliche Sphäre des Normgebers).

Abbildung 1: Zentrale Elemente der P23R-Infrastruktur

Die zentrale Komponente, der P23R-Prozessor, umfasst eine Regeln verarbeitende Komponente (Rule Engine) zur Generierung der zu übermittelnden Informationen (Benachrichtigungen), und ist über Quelldatenkonnektoren mit den Quelldatensystemen der Unternehmen (Benachrichtigungssender) und über Kommunikationskonnektoren mit den Eingangsschnittstellen bzw. direkt mit den Fachverfahren der Verwaltung (Benachrichtigungsempfänger) lose gekoppelt. Nach Generierung einer Benachrichtigung wird diese zur Freigabe durch einen autorisierten Unternehmensvertreter bereitgestellt und schließlich nach Freigabe über einen Konnektor an die zuständige Behörde ausgeliefert. Um die durchgeführten Meldungen rechtssicher nachweisen zu können, werden alle relevanten Aktionen protokolliert, insbesondere der Übermittlungszeitpunkt, die ausgelieferte Benachrichtigung und die angewendete Regel.

Das dem P23R-Ansatz zugrunde liegende Ökosystem sieht vor, dass Regel- und Modellartefakte in Verantwortung des Normgebers in einem Depot von einer oder mehreren öffentlichen P23R-Leitstellen bereitgestellt werden. Gleichwohl lässt die P23R-Architektur in technischer Hinsicht auch andere Realisierungsszenarien zu: So können im P23R-Prozessor beliebige P23R-Leitstellen konfiguriert werden, die bspw. vom Informationspflichtigen selbst betrieben werden und eigene Datenmodelle und Regeln bereitstellen. In der P23R-Leitstelle findet sich auch ein Verzeichnis mit Zuständigkeitsinformationen, d.h. mit Angaben zur empfangenden Behörde und deren Kommunikationskanal, sowie ein Verzeichnis mit Informationen zu vertrauenswürdigen Diensten, in dem Sicherheitszertifikate und Diensteadressen der Prozessakteure publiziert werden.

Die P23R-Architektur ist so ausgelegt, dass Teilsysteme einer P23R-Infrastruktur von verschiedenen Anbietern entwickelt und in verschiedenen Hardware- und Software-Umgebungen betrieben werden können. Um den Einsatz von P23R-Komponenten auf unterschiedlichen Plattformen zu ermöglichen und die Interoperabilität von Komponenten unterschiedlicher Hersteller zu gewährleisten, werden alle Schnittstellen zwischen dem P23R-Prozessor und den umgebenden Systemen in Form von Web Services normativ festgelegt. Es wird weiterhin gefordert, dass jeder P23R-Prozessor die Regeln korrekt verarbeiten kann. Der P23R-Prozessor eines Herstellers kann so jederzeit gegen den P23R-Prozesor eines anderen Herstellers ausgetauscht werden; ein Vendor-Lock-in wird damit verhindert. Ergänzt wird die P23R-Architektur durch Dienste der P23R-Sicherheitsarchitektur, die Mechanismen zur Sicherung von schutzwürdigen System- und Informationsobjekten sowie zur Absicherung von Kommunikationsverbindungen umfasst.¹⁷

Die technologische Umsetzung der Komponenten erfolgt in Form von Web Services; die Schnittstellen der Web Services werden mithilfe der XML-basierten Schnittstellenbeschreibungssprache WSDL spezifiziert. Datenstrukturen werden als XML-Schemata mit Hilfe der Spezifikationssprache XML Schema Definition spezifiziert. Die Regeln sind in einem XML- und XSLT-basierten, speziell entwickelten Regelformalismus, der Technischen Benachrichtigungssprache T-BRS, definiert.¹⁸

In Pilotprojekten wurde die P23R-Architektur musterhaft umgesetzt und P23R-Lösungen ab dem Jahr 2011 in den Domänen Umwelt, Arbeitgeber und Transport pilotiert. Schließlich wurden im Jahr 2015 die ersten Umwelt-Meldepflichten im Unternehmen BASF SE in den Wirkbetrieb überführt. Im Rahmen der Pilotprojekte wurde untersucht, welche Wirtschaftlichkeitseffekte sich insbesondere für die Unternehmen realisieren lassen. Dabei erwies es sich als ausgesprochen schwierig, mögliche monetäre Einsparpotenziale abzuschätzen. Grund hierfür ist zum einen, dass die aktuellen Prozesse zur Erbringung von Informationspflichten häufig nicht bekannt sind, ebenso wenig wie die Kosten für Entwicklung und Betrieb der eingesetzten IT-Verfahren; zum anderen stellt eGovernment generell kein zentrales Anliegen für Unternehmen dar, so dass mögliche Skaleneffekte, die sich durch einen domänenübergreifenden Infrastrukturansatz ergeben, in der Praxis nur schwer zu ermitteln sind.¹⁹ Gleichwohl konnten in den Pilotprojekten einige quantitative Daten erhoben werden, so z.B. folgende:

• Bei BASF SE konnte durch die Bereitstellung von Regeln der Entwicklungsaufwand für zwei Informationspflichten aus dem Bereich Umwelt, für die es noch keine informationstechnische Umsetzung gab, um 50% reduziert werden. Die Übertragungszeiten der Daten konnten im Falle einer Meldepflicht weiterhin von 14–18 auf eine Stunde gesenkt werden.²⁰
• In Workshops und in Einzelgesprächen mit klein- und mittelständische Unternehmen wurde deren Einschätzung der zu erwartenden Einspareffekte erhoben. Dabei zeigte sich, dass sich vor allem klein- und mittelständische Unternehmen erhebliche Entlastungen versprechen, so z.B. bei der Einarbeitung in die Informationspflicht (bis zu 100%), bei der Befüllung der Formulare (bis zu 100%) und bei der Berechnung der Daten (bis zu 50%).²¹
• Im Pilotprojekt x-trans.eu zur digitalen Umsetzung der Beantragung grenzüberschreitender Großraum- und Schwerlasttransporte, konnten rund 90% der zu prüfenden Konformitäten und Plausibilitäten bereits vor der Bearbeitung durch die Informationsempfänger automatisiert geprüft und so der Prüfaufwand in den Genehmigungsbehörden reduziert werden.²²

Praktisch seit Beginn der Entwicklungen erzielte der P23R-Ansatz eine hohe Sichtbarkeit und erfuhr von Seiten der Politik beträchtliche Zustimmung. So gab es bereits im Jahr 2011 einen Beschluss des bundesdeutschen Kabinetts, eine Rechtsgrundlage für P23R zu schaffen.²³ In den Folgejahren wurde P23R zu einem Koordinierungsprojekt des IT-Planungsrats, dem zentralen bundesdeutschen Steuerungsgremium von Bund, Ländern und Kommunen für Informationstechnik und eGovernment.²⁴

Trotz dieser politischen Bekenntnisse und durchaus positiver Pilotergebnisse ist allerdings Folgendes festzustellen: Nach Entwicklung und Erstpilotierung des P23R-Ansatzes im Jahr 2011 wurden weitere Pilotprojekte durchgeführt, die bis auf das vom Freistaat Bayern und dem österreichischen Bundesland Oberösterreich durchgeführte Projekt x-trans.eu der Umweltdomäne zuzurechnen sind. Im Jahr 2015 wurde die Projektverantwortung für P23R dem bundesdeutschen Umweltbundesamt übergeben, das die Nutzung des P23R-Ansatzes im Umweltbereich gemeinsam mit der Metropolregion Rhein-Neckar weiter vorantreiben will.²⁵ Gesetzgeberische Maßnahmen zur Schaffung einer domänenübergreifenden Rechtsgrundlage sind derzeit jedoch nicht erkennbar. Im Bericht des bundesdeutschen Gremiums für Bürokratieabbau, dem Normenkontrollrat (kurz: NKR), für das Jahr 2016 heißt es hierzu: Eine Einführung und Nutzung in anderen Verwaltungsbereichen ist jedoch nicht absehbar. Damit wird aus der Sicht des NKR einmal mehr eine große Chance für mehr Verwaltungsvereinfachung und Entlastung der Unternehmen durch E-Government nicht genutzt.²⁶

Weiterhin ist festzustellen, dass auch eine kommerzielle Umsetzung des P23RPrinzips in breitentaugliche P23RLösungen oder Produkte für unterschiedliche Fachdomänen aktuell nicht zu beobachten ist oder sich im Prototypenstadium befindet.²⁷

Vor diesem Hintergrund ist die Frage zu stellen, ob sich am P23R-Ansatz inhärente Faktoren ausmachen lassen, die einer Verbreitung des Ansatzes im Wege stehen. Um mögliche Diffusionshemmnisse zu identifizieren, wird im Folgenden die Diffusionstheorie als Erklärungsmodell herangezogen.

Die ursprünglich in den Sozial- und Kommunikationswissenschaften entwickelte Diffusionstheorie untersucht die Prozesse, nach denen die Verbreitung einer Innovation in einem sozialen System wie dem des Marktes verläuft. Rogers, einer der Pioniere der Diffusionsforschung, definiert fünf zentrale Faktoren, die die Verbreitungsgeschwindigkeit von Innovationen beeinflussen.^{28, 29, 30}

• Relative advantage. Der Grad, in dem eine Innovation im Vergleich zu bisherigen oder alternativen Produkten als besser wahrgenommen wird.
• Compatibility. Der Grad, in dem eine Innovation als vereinbar mit bestehenden Werten, Erfahrungen, Normen und Bedürfnissen des Nachfragers angesehen wird.
• Complexity. Das Ausmaß, in dem eine Innovation ohne großen Lern- und Einarbeitungsaufwand leicht zu verstehen und anzuwenden ist.
• Triability. Der Grad, in dem eine Innovation in geringem Umfang vor dem Kauf getestet und die Erprobungsphase ohne negative Konsequenzen beendet werden kann.
• Observability. Der Grad, in dem Nutzen und Eigenschaften einer Innovation vermittelbar und sichtbar sind.

Steffens hat in ihrer Dissertationsschrift jeden dieser Faktoren für den P23R-Ansatz vor dem Hintergrund der Pilotergebnisse hinterfragt und anhand der Piloterfahrungen reflektiert.³¹ Auf Grundlage dieser Analyse lassen sich einige grundlegende Problemfelder bestimmen:

• Monetäre Vorteile nicht bestimmbar. Für die Anwender erwies es sich generell als schwierig, die Rentabilität der Einführung einer P23R-Lösung einzuschätzen. Zum einen sind die aktuellen Prozess- und IT-Kosten für die Erbringung staatlicher Informationspflichten i.d.R. nicht bekannt; zum anderen ist es für die Unternehmen schwierig, zu bestimmen, was genau erforderlich ist, um ihre Informationspflichten P23R-basiert zu erbringen. Dies betrifft u.a. die folgenden Fragen: Welche Änderungen und Erweiterungen an der vorhandenen IT-Infrastruktur sind für den Einsatz einer P23R-Lösung notwendig? Welche Wechselkosten fallen bei der Ablösung vorhandener Systeme ggf. an? Welche Einarbeitungszeiten und -maßnahmen sind dafür notwendig und welche Einführungs- und Migrationsstrategien sind für die jeweilige Organisation geeignet?
• Wenig kompatibel. Weiterhin zeigte sich, dass der P23R-Ansatz nur wenig kompatibel ist mit vorhandenen Organisations- und Kompetenzstrukturen. Dies hat zweierlei Gründe. Zum einen erfordert eine wirtschaftliche Betrachtung eine ganzheitliche, d.h. themen- und bereichsübergreifende, Sicht auf eGovernment-Prozesse. Eine solche übergreifende eGovernment-Verantwortlichkeit könnte die Aufgabe eines künftigen Chief Digital Officers werden. Stand heute gibt es für eine solche themen- und bereichsübergreifende Betrachtung in den meisten Unternehmen jedoch keine Verantwortlichkeit. Zum anderen erfordert der P23R-Anatz sowohl von Anwendern als auch von Regelentwicklern eine Kombination von fachlicher und technologischer Kompetenz, die oftmals nicht gegeben ist, bzw. erst aufgebaut werden muss. Auf Anwenderseite sind Fachkräfte erforderlich, die über Wissen zur relevanten Rechtssituation, über Kenntnisse von Regularien der eigenen Organisation und schließlich über Kenntnisse der Konzepte und Anwendung einer P23R-Lösung verfügen. Auf Entwicklerseite sind Experten erforderlich, die über fachliches, modellierungstechnisches, P23R-technologisches und (programmier-)technisches Wissen verfügen.
• Unsicherheit bzgl. Regulierung. Ein weiteres Diffusionshemmnis hat mit regulatorischen Aspekten zu tun. Die P23R-Architektur selbst macht zwar keine Vorgaben, in wessen Verantwortung Regeln entwickelt und bereitgestellt werden. In den Pilotprojekten wurde aber deutlich, dass sowohl Anwender als auch Anbieter den Normgeber selbst in der Pflicht sehen, Benachrichtigungsregeln bereitzustellen – was auch in der Philosophie des Ansatzes so angelegt war. Da es bis dato keine Zusage seitens des Normgebers für die flächendeckende Bereitstellung von Regeln gibt, besteht eine große Unsicherheit, ob und in welchem Umfang Regeln mit staatlich bescheinigter Qualität zur Verfügung stehen werden.
• Trägheit. Schließlich ist auch eine gewisse Trägheit zu beobachten, d.h. das Festhalten an bekannten, im Einsatz befindlichen IT-Systemen, die dem Umstieg auf eine neue verallgemeinernde Technologie entgegenstehen. Dies ist nicht so sehr eine technische Frage der Vorwärtskompatibilität vorhandener Lösungen, sondern betrifft die grundsätzliche Bereitschaft, bisher genutzte Einzellösungen durch einen domänenübergreifenden Ansatz abzulösen.

Diese Problemstellungen legen zwei Felder nahe, in denen Maßnahmen zu ergreifen sind:

• Es muss dem Anwender ermöglicht werden, den Nutzen von P23R-Technologie einfach, aufwands- und risikoarm für seine Organisation zu bewerten.
• Die Entwicklung von P23R-Produkten und -Regeln muss weiter ausgestaltet und stimuliert werden.

Im folgenden Abschnitt wird ein Lösungsansatz umrissen, der beiden Zielsetzungen Rechnung tragen soll, indem er a) Leichtgewichtige Regelbasierte Reporting-Services als lokal bewertbare Alternative zu einer voll umfänglichen P23R-Infrastruktur umfasst und b) ein Ökosystem für die Entwicklung und Vermarktung der Reporting-Services vorsieht, das die Entwicklung von Regeln dem freien Markt überlässt und dem Normgeber lediglich eine standardisierende und qualitätsbescheinigende Rolle zuweist.

Vereinfacht gesagt, handelt es sich bei einem Leichtgewichtigen Regelbasierten Reporting-Service um eine Anwendung, die nur eine oder wenige Informationspflichten realisiert. Ein solcher Reporting-Service basiert auf einem Programm, das als Kernleistung die Datenvalidierung, Datenfilterung, Datentransformation und die Erzeugung der zu übermittelnden Daten erbringt. Wir nennen dieses Programm daher Service-Kern. Ein Service-Kern wird mithilfe eines Generators aus einer Regel und Konfigurationsdaten erzeugt. Zuständigkeitsinformationen können statisch in der Regel vordefiniert oder zur Laufzeit ermittelt werden. Für einen Standalone-Einsatz ist ein solcher Service-Kern bspw. zu ergänzen um eine graphische Benutzeroberfläche (GUI) zur Eingabe von Daten und / oder um einen Quelldatenkonnektor, eine GUI zur Freigabe der zu übermittelnden Daten sowie einen Kommunikationskonnektor. Ein solchermaßen «veredelter» Service-Kern ist dann ein Reporting-Service, der von Endanwendern zur Durchführung einer Informationspflicht genutzt werden kann. Abbildung 2 zeigt die Erzeugung eines Reporting-Service.

Mit Reporting-Services wird die Universalität einer P23R-Infrastruktur zugunsten einer Minimallösung aufgegeben, die nur eine oder wenige Informationspflichten umsetzt und nur eines oder wenige Datenmodelle verarbeitet. Für den Anwender stellt sich die Nutzung eines Reporting-Services damit relativ einfach dar: Er benötigt keine eigene Rule Engine, muss keine Regeln verwalten und auch keine eigenen Konnektoren bereitstellen. Da Reporting-Services mit den gleichen Regeln arbeiten, wie eine universell einsetzbare P23R-Infrastruktur können sie zugleich zum Katalysator für einen domänenübergreifenden Infrastruktur-Ansatz werden.

Das vorgestellte Modell sieht also zum einen leichtgewichtige Produktvarianten vor, die sich risikoarm erproben lassen und ohne großen Administrationsaufwand eingesetzt werden können; zum anderen bietet das Modell Entwicklern die Möglichkeit Reporting-Services unter Rückgriff auf vorhandene Regeln und Service-Kerne oder komplett in Individualentwicklung auf Basis standardisierter Schnittstellen zu erstellen.

Abbildung 2: Erzeugung Leichtgewichtiger Regelbasierter Reporting-Services

Um den Markt für Reporting-Services und für die dafür erforderlichen Artefakte zu stimulieren und zugleich den Qualitätserwartungen der Anwender gerecht zu werden, erscheint ein Ökosystem und Plattform-Modell geeignet, das einen mehrseitigen Markt von Regel-, System- und Service-Anbietern, sowie qualitätsbescheinigende Strukturen unter hoheitlicher Kontrolle des Normgebers unterstützt:

• Der Normgeber verantwortet nicht mehr die Regelbereitstellung, sondern lediglich wesentliche architektonische Elemente. Dazu zählen: der Regelformalismus, eine Referenzarchitektur des Regelprozessors, ein Referenzsystem des Regelprozessors, Testdatensätze und Kommentare zu den Normen, die die Regelerstellung selbst aber auch die Zertifizierung von Regeln unterstützen. Entsprechende Dokumente und Systeme stellt er auf einer Referenzplattform bereit. Die Entwickler der Regeln können diese auf dem Referenzprozessor zur Ausführung bringen und prüfen; die Entwickler von Rule Engines können deren korrektes Verhalten anhand der Testsätze nachweisen, um so eine Qualitätsbescheinigung der Prüfinstanz zu erlangen.
• Entwickler von Regeln ebenso wie Entwickler von Service-Kernen und Service-Kern-Generatoren nutzen fernerhin eine Entwicklerplattform, auf der sie ihre Produkte bereitstellen. Ggf. werden hier auch weitere Teilsysteme, wie Konnektoren und Regel-Entwicklungswerkzeuge bereitgestellt.
• Um Entwicklern und Anwendern von Reporting-Services Rechtssicherheit zu geben, werden Regeln und Service-Kerne von einer durch den Normgeber akkreditierten Stelle geprüft und ihre Qualität bescheinigt. Der Prüforganisation obliegt es, für eine Informationspflicht die Anforderungen an die sie umsetzende Benachrichtigungsregeln zu spezifizieren, hierfür ggf. eigene Testregeln und Testsätze bereitzustellen und entsprechende Tests durchzuführen. Die genannten Aufgaben erfordern einen regulatorischen Rahmen für die Setzung von Standards (in Bezug auf die P23R-Architektur), für die Etablierung von Verfahren des Konformitätsnachweises und der Qualitätsprüfung (in Bezug auf den Regelprozessoren, Regeln und Reporting-Services) sowie für den Betrieb einer Referenzplattform. Genutzt werden die auf einer Entwicklerplattform angebotenen Artefakte von zwei Gruppen: die Regeln von Anwendern bzw. Anbietern einer P23R-Voll-Lösung und die Service-Kerne von Anbietern von Reporting-Services, die idealerweise bereits einen Zugang zu den von ihnen bedienten Markt haben. Anbieter von Reporting-Services fungieren so einerseits als Konsumenten von Service-Kernen, andererseits als Produzenten von Reporting-Services. Die Reporting-Services werden dann über eine Verteilplattform, eine Service-Plattform, an den Endanwender vermarktet.

Abbildung 3: Plattform-Modell für Leichtgewichtige Regelbasierte Reporting-Services

Mit dem beschriebenen und in Abbildung 3 dargestellten Plattform-Modell soll identifizierten Schwachpunkten des P23R-Ansatzes entgegengewirkt werden:

• So wird die Entwicklung von Regeln, Service-Kernen und Reporting-Services im Wesentlichen dem privaten Markt überlassen.
• Der Normgeber kann sich darauf beschränken, a) die technischen Grundlagen zu verantworten und zu standardisieren und b) Organisationen zu akkreditieren, die die Qualität von Service-Kernen bescheinigen – also Aufgaben, die er auch in anderen Kontexten wahrnimmt.
• Zugleich wird das Produktspektrum geöffnet: Anwender können leichtgewichtige Services einsetzen, um die Technologie risikoarm zu erproben und zu einem späteren Zeitpunkt auf eine Voll-Version zu migrieren; Entwickler können Services in unterschiedlichen Modellen, d.h. basierend auf angebotenen Elementen oder komplett in Eigenentwicklung, entwickeln.

Durch die Leichtgewichtigen Regelbasierten Reporting-Services und das beschriebene Plattform-Modell sollen die Hürden für den Einstieg in den P23R-Ansatz gesenkt und somit die Motivation den P23R-Ansatz zu nutzen erhöht werden, mit dem Ziel, die Diffusion der P23R-Technologie zu realisieren.

Ein prominent diskutierter, regelbasierter Ansatz zur Digitalisierung von Informationspflichten ist P23R. P23R steht für eine fachübergreifende IT-Infrastruktur, die es Unternehmen ermöglicht, Informationspflichten beliebiger Fachdomänen zu automatisieren und damit Bürokratielasten zu reduzieren.

Trotz der in Pilotprojekten nachgewiesenen Vorteile kam es bisher nicht zu einem breitenwirksamen Transfer der P23RTechnologie in die Praxis. Um mögliche Gründe hierfür zu bestimmen, wurde die Diffusionstheorie als Erklärungsmodell herangezogen und diffusionshemmende Faktoren beschrieben: Schwierigkeit, den zu erwartenden Nutzen zu bestimmen; Inkompatibilität mit aktuellen Kompetenz- und Organisationsstrukturen, Unsicherheit bzgl. regulatorischer Maßnahmen, Festhalten an vorhandenen IT-Systemen.

Im Lichte dieser Analyse wird ein schlankes Lösungsmodell vorgestellt: Leichtgewichtige Regelbasierte Reporting-Services, die nur eine oder wenige Informationspflichten realisieren. Die Reporting-Services basieren zwar auch auf P23R-Regeln und -Komponenten; analog zu Micro-Services stellen sie jedoch in sich abgeschlossene ausführbare Programme dar, die vom Anwender nicht den Betrieb einer eigenen P23R-Infrastruktur erfordern.

Um den Markt für Reporting-Services und für die dafür erforderlichen Artefakte zu stimulieren und zugleich eine Qualitätsbescheinigung in staatlicher Hoheit zu bieten, wird ein Ökosystem und Plattform-Modell vorgeschlagen, das einen mehrseitigen Markt von Regel-, System- und Service-Anbietern, sowie qualitätsbescheinigende Strukturen unter hoheitlicher Kontrolle des Normgebers umfasst.