|
|
| (143 dazwischenliegende Versionen von 8 Benutzern werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| = Was ist RNext? = | | = Was ist BiPRO = |
| | [[Image:BiPRO-Logo-250x97.png|link=https://bipro.net/]] |
| | |
| | Der BiPRO e.V. ist die neutrale Organisation der Finanzdienstleistungsbranche, in der sich Versicherungen, Vertriebspartner und Dienstleister zusammengeschlossen haben, um unternehmensübergreifende Geschäftsprozesse zu optimieren. Gemeinschaftlich werden in Normvorhaben (Projekten oder Gruppen) fachliche und technische Normen entwickelt. |
|
| |
|
| ''BiPRO-RNext'' oder einfach ''RNext'' ist der Codename für die nächste Release-Generation von BiPRO-Schnittstellen. | | =Was ist RClassic?= |
| | [[RClassic| '''RClassic''']] wird die seit Gründung des Vereins betriebene technische und organisatorische Form der Normentwicklung genannt, nach der Prozesse und Datentransfers zwischen den Unternehmen der Versicherungswirtschaft standardisiert werden. |
|
| |
|
| Powered by
| | Technisch handelt es sich um einen Nachrichtenaustausch basierend auf SOAP und XML. |
| <br>[[Image:BiPRO-Logo-250x97.png]]
| |
| <br>https://bipro.net/
| |
|
| |
|
| RNext stellt die nächste BiPRO Normengeneration dar und wurde in einem ersten Proof Of Concept untersucht. Aktuell gibt es verschiedene Herausforderungen im Bereich BiPRO-Implementierung. Neben einer hohen Komplexität der BiPRO-Datenmodelle, gibt es einige Hürden, die einer reibungslosen Umsetzung der BiPRO-Normen und somit einem flächendeckenden Ausrollen im Wegen stehen.
| | Organisatorisch werden bestimmte Optimierungsbedarfe in der Kommunikation der Marktteilnehmer in zeitlich abgegrenzten Projekten bearbeitet und münden in der Regel in Normdokumenten, einem Daten- und Prozessmodell und ggf. flankierenden Dokumenten. Prozess- und Datenmodell fügen sich dabei in ein Gesamtmodell ein, und die Normdokumente unterliegen sowohl in der Form als auch der Nomenklatur einem selbstdefinierten Standard, der sich an W3C u.a. orientiert. |
| Hier sind einige Lösungsansätze, die im Rahmen der ersten RNext-Labs realisiert werden sollen:
| |
|
| |
|
| == Artefakte als Basiskomponente bereitstellen ==
| | Die Weiterentwicklung erfolgt nach einem reglementierten Verfahren in Change Requests (CRs), die von den Normungsgremien diskutiert und beschlossen werden, Fachgruppen (Begleitung des Markts), Digitalisierungsoffensiven (Fokussierung des Marktes auf die Implementierung bestimmter Prozesse) und ggf. Folgeprojekten. |
|
| |
|
| Bis dato wurden BiPRO-Normen hauptsächlich, als eine Art Richtlinie bereitgestellt. Es gibt zwar Artefakte in Form von *.eap(UML) evtl. sogar WSDL. Allerdings müssen sicht die Implementierter selbst um die Erstellung von Datenmodellen bzw. der Serviceschicht kümmern. Dabei gibt es viele Interpretationsspielräume, sodass eine einhundertprozentige BiPRO-Konformität nicht ohne weiteres zu leisten ist.
| | Die Normen liegen teilweise als „Offizielle Norm“ zur allgemeinen Verwendung vor, sind aber auch teilweise noch in der vereinsinternen Qualitätssicherung („Potentielle Norm“) und werden in sog. Releases nach einem groben zeitlichen Raster herausgegeben. |
| Die Idee von RNext ist vor allem, dass BiPRO-Normen mit konkreten Artefakten ausgeliefert wird. Diese wiederum können sowohl den Implementierungsaufwand reduzieren, als auch die Normenkonformität steigern. Da alle Datenmodelle und die Service Endpoints genormt sind, kann man die Framework spezifischen Basiskomponenten generieren und diese in Public oder Private Package-Repositories veröffentlichen.
| |
| Somit kann der Implementierer eine BiPRO-Basis, als Package für das jeweilige Programmierframework beziehen und muss lediglich die Domainspezifik als Delta implementieren. Der Implementierungsaufwand wird dadurch deutlich reduziert. Und die Norm wird maximal eingehalten.
| |
| Es sollen kleine, atomare Artefakte generiert werden, sodass der Anwender, je nach Zweck, nur den tatsächlich benötigten Funktionsumfang in seiner Anwendung nutzen kann.
| |
|
| |
|
| == WEB API / REST Service == | | == Normen == |
| Auch wenn eine BiPRO-Norm als ein technologieübergreifendes Konstrukt angedacht ist, so ist eine gewisse Nähe zum SOAP-Protokoll unverkennbar. Im Laufe der vergangenen Jahre haben sich allerdings die technischen Rahmenbedingungen massiv verändert. Heute werden immer häufige REST Services als Web-APIs eingesetzt. Diese ermöglichen ein schlankeres Übertragungsformat in Form von JSON Daten. Des Weiteren können die komplexen Datenstrukturen in kleineren atomaren Lese- und Schreibeoperationen verarbeiten. Dabei werden vor allem die SOA Prinzipien durch die Verwendung der Micro Service Patterns ergänzt.
| | Die Ergebnisse der Standardisierung des BiPRO e.V. in RClassic werden in den [https://wiki.bipro.net/index.php/Kategorie:RClassic_Normen '''Normen'''] der BiPRO dokumentiert. Die Normen beschreiben alle Festlegungen, die für die Prozesse und Daten getroffen werden. |
| Eine der wesentlichen Herausforderungen ist es, die BiPRO-Norm für den aktuellen und den zukünftigen Stand der Technik fit zu machen.
| |
| Es gibt immer mehr Clients, vor allem im Mobilen Bereich, die ausschließlich auf REST-Services setzen. Vor allem mit Hilfe der Open API Spezifikationen werden die heutigen Service Schnittstellen definiert:
| |
| https://github.com/OAI/OpenAPI-Specification | |
| https://www.openapis.org/
| |
| Damit wird ermöglicht, die Schnittstellen und die dazugehörigen Datenmodelle deklarativ nach einem technologieübergreifenden Standard zu modellieren. Ein Großteil des anwendungsspezifischen Codes wird dabei durch die Generatoren erzeugt. Die Technologien, wie z.B. RAML oder SWAGGER, haben sich bereits als ein nachhaltiges aktives Ökosystem in diesem Bereich erfolgreich etabliert.
| |
|
| |
|
| == BiPRO Datenmodelle == | | == Release-Pakete == |
| Einen Großteil der BiPRO-Normen stellen die objektorientierten Datenmodelle dar. Genaugenommen besteht das Datenmodell aus einem generischen spartenübergreifenden Teil und aus den jeweiligen spartenspezifischen Ausprägungen.
| | Mitgliedern des BiPRO e.V. stehen sämtliche RClassic Normpakete zur Verfügung. Eine detailliertere Beschreibung der Normpakete sowie der Download dieser findet sich unter den [[Releases_RClassic | '''RClassic Releases''']]. |
| Vor allem auf der Konsumentenseite ist die Anbindung einer BiPRO-Schnittstelle immer noch eine große Herausforderung. Um z.B. fünf Felder an den Service zu schicken, müssen oft komplexe Objektbäume instanziert werden, damit anschließend das hierarchische Konstrukt mit den eigentlichen Daten befüllt werden kann.
| |
| RNext soll die Komplexität solcher hierarchischeren Datenmodelle reduzieren, sodass die Anbindung von BiPRO-Services einfacher und intuitiver werden soll.
| |
|
| |
|
| == BiPRO Datenmodelle == | | = Was ist RNext? = |
| Einen Großteil der BiPRO-Normen stellen die objektorientierten Datenmodelle dar. Genaugenommen besteht das Datenmodell aus einem generischen spartenübergreifenden Teil und aus den jeweiligen spartenspezifischen Ausprägungen.
| |
| Vor allem auf der Konsumentenseite ist die Anbindung einer BiPRO-Schnittstelle immer noch eine große Herausforderung. Um z.B. fünf Felder an den Service zu schicken, müssen oft komplexe Objektbäume instanziert werden, damit anschließend das hierarchische Konstrukt mit den eigentlichen Daten befüllt werden kann.
| |
| RNext soll die Komplexität solcher hierarchischeren Datenmodelle reduzieren, sodass die Anbindung von BiPRO-Services einfacher und intuitiver werden soll.
| |
| | |
| == BiPRO Norm Lifecycle Management ==
| |
| Der Normierungsprozess könnte wie gewohnt mit dem Erstellen des Datenmodells im EA beginnen und mit dem publizieren der Artefakte in die entsprechende Package-Repositories enden.
| |
| Am Ende des Normierungsprozesses stehen alle Normen in Form von verschiedenen Artefakten dem Implementierer zur Verfügung. Der Implementierungsaufwand reduziert sich erheblich, da man die BiPRO-spezifischen Komponenten nicht mehr programmieren muss. Die Norm wird dabei maximal eingehalten, da die äußerste Schicht des Services bzw. des Konsumenten immer gleichbleibt.
| |
| Wenn man die Artefakte in den Public Repositories publiziert, dann hat man den Vorteil, dass ein Ökosystem mit verschiedenen BiPRO Tools entsteht. Dieses Ökosystem sorgt wiederum für eine breite Akzeptanz der BiPRO-Norm und für eine nachhaltige Weiterentwicklung durch die Community.
| |
| | |
| = FAQ zu RNext =
| |
| | |
| Hier gibt es eine lange Liste von FAQs rund um das Thema RNext. Die BiPRO-Geschäftsstelle, sowie die Arbeitsgruppe RNext versuchen diese Sammlung stets up-to-date zu halten: [[faq|FAQs]].
| |
| | |
| | |
| = Tools in RNext =
| |
| | |
| == OpenAPI Specification 3.0 ==
| |
| In früheren Version synonym mit Swagger. Ist eine Spezifikation zur Beschreibung von RESTful Webservices in RAML (RESTful API Modeling Language). Das Tool Swagger kann online verwendet werden oder als Client heruntergeladen werden. Hier der Link zur Online-Version: https://editor.swagger.io
| |
| | |
| == GitLab ==
| |
| | |
| https://gitlab.rnext.org
| |
| | |
| == Jenkins ==
| |
| | |
| https://jenkins.rnext.org
| |
| | |
| == Nexus ==
| |
| | |
| https://nexus.rnext.org
| |
| | |
| | |
| = Onboarding für Mitglieder der Arbeitsgruppe RNext =
| |
| | |
| Hilfe zur Benutzung und Konfiguration der Wiki-Software findest du im [//meta.wikimedia.org/wiki/Help:Contents Benutzerhandbuch].
| |
| | |
| | |
| = Grundlagen =
| |
| | |
| == Design Principles ==
| |
| | |
| === Use before Re-use ===
| |
| Jedes Element eines Normierungsartefaktes (Attribute) muss praktisch eingesetzt und
| |
| verstanden werden, bevor es Teil der Norm wird (Inkubationsphase); kein Front-UpEngineering
| |
| (Overhead, Komplexität, Mismatch mit der Realität).
| |
| | |
| === Ein digitaler Standard ist Software ===
| |
| Die Erzeugung von reinen Papiernormen erzeugt keinen Mehrwert für die Digitalisierung
| |
| unserer Branche.
| |
| Regellogik, die heute in den Normen oder im Datenmodell als Prosa beschrieben ist, kann
| |
| durch Regeln in ausführbaren Code (also Beschreibung durch eine Programmiersprache)
| |
| überführt werden. Diese Logik ist dann interpretationsfrei und kann direkt in den Consumerund
| |
| Provider-Implementierungen genutzt werden.
| |
| Die Wahl der konkreten Beschreibungssprache sollte sich am Markt-Mainstream orientieren,
| |
| ist aber nicht die entscheidende Frage, weil auch heute die Übersetzungsarbeit von Prosa in
| |
| Programmlogik in jeder Implementierung erfolgen muss, d.h. das Konzept führt auf keinen
| |
| Fall zu einer Verschlechterung der Situation.
| |
| === Modularisierung - Domain Driven Design ===
| |
| Normen und ihre Artefakte werden domain-spezifisch beschrieben und ausgerollt. Die
| |
| Artefakte können eigenständig weiterentwickelt werden. Dieses fachliche Design bietet
| |
| demnach die Grundlage für die Entwicklung von Microservices.
| |
| Normierungsartefakte, die tatsächlich in unterschiedlichen Domänen wiederverwendet
| |
| werden können, werden in ein Basismodell verschoben. Dies bedeutet de facto die Aufgabe
| |
| des Prinzips einer vollkommenen Redundanzfreiheit.
| |
| Beispiele für Domänen: Komposit vs. LV/PKV, TAA vs. Bestandsänderungen vs.
| |
| Schadenprozesse.
| |
| === Lokale Erweiterungen (DE-AT) ===
| |
| Für die Ableitung in den lokalen Märkten, werden länderspezifische Normierungsartefakte in
| |
| eine lokale Erweiterung des Standards verschoben.
| |
| Dieses Prinzip kann domänen- und prozessspezifisch angewandt werden (d.h. der
| |
| Schieberegler für Global und Lokal kann unterschiedlich gesetzt werden): Deutschland und
| |
| Österreich haben viele grundlegende Gemeinsamkeiten, aber viele Unterschiede im Detail.
| |
| Zu den Unterschieden gehören andere Datentypen, wie Schlüssellisten, oder andere Regeln,
| |
| wie die Länge einer VSNR. Unterschiedlich sind aber auch gesetzliche Anforderungen
| |
| (anderes VVG) und länderspezifische Produkte (z.B. Riester etc.).
| |
| Daher sollte das Basisdatenmodell kontextlos sein. Das Basis-DM sollte für DE und AT
| |
| identisch sein und durch abgeleitete Datenmodelle mit Kontext ergänzt werden.
| |
| === Trennung von Technik und Fachlichkeit ===
| |
| Die notwendigen technischen Basisstandards orientieren sich an der faktischen Begebenheit
| |
| in der fachlichen Domäne oder dem Prozess (vgl. IoT-Protokolle versus Nutzung von MQ in
| |
| Schadennetzwerken). Eine allgemeine Zukunftsprognose der Formate und Protokolle ist
| |
| herausfordernd (vgl. Trend zu asynchroner Kommunikation in Microservices).
| |
| Das heißt: Wir sehen potentiell unterschiedliche technische Protokoll-Stacks für
| |
| unterschiedliche Domänen vor, wobei wir am Ziel festhalten, die Anzahl der Stacks auf das
| |
| notwendige Mindestmaß zu reduzieren.
| |
| === Technik beschreibt Interoperabilitätsprinzipien eines kompletten Services, nicht nur Standardisierungsprinzipien der Schnittstelle ===
| |
| Wesentliches Merkmal digitaler Standards ist die Fähigkeit, mit anderen Ökosystemen
| |
| interoperabel agieren zu können. Dies bedeutet eine Reduktion auf den absoluten
| |
| Marktmainstream der digitalen Kommunikation und die breite Unterstützung dieser Prinzipien
| |
| durch Open Source Software. Ein wesentliches Grundprinzip für die Service-Implementierung
| |
| ist die Einhaltung von Cloud-native Prinzipien (beispielsweise 12-Factor App). Da davon
| |
| auszugehen ist, dass die Geschwindigkeit der technischen Innovation mindestens die
| |
| Geschwindigkeit hält, ist ein agiler Standard die Voraussetzung, um im Markt bestehen zu
| |
| können.
| |
| === Agiles Normierungs-Setup ===
| |
| Agile Team-Aufstellung = Product Owner, Designer und Entwickler (DevOp) per
| |
| Product
| |
| Wie passt das zu unserem Gremien-Setup des Vereins (vgl. Entwicklungen in der Allianz
| |
| oder Nürnberger die Linienhierarchie aufzugeben)?
| |
| Wir benötigen verstärkt auch nebenläufige Normierungsprozesse, um die
| |
| Marktgeschwindigkeit zu halten (vgl. Open Source Entwicklungsprojekte auf Basis Github)
| |
| “Governance by contribution” -> Mitmachen!
| |
| === Agiles Release-Management ===
| |
| Domain-spezifische Normen können in sehr kleinen Inkrementen (Sprints) ausgerollt werden.
| |
| Durch die agile Software-Entwicklung gibt es die Forderung nach einer sehr kurzfristigen
| |
| Bereitstellung von Sub-Releases mit benötigten Change Requests.
| |
| | |
| Quelle:
| |
| * [[Media:BiPRO-RNext-Design-Principles.pdf|BiPRO-RNext - Design Principles]] (Thesenpapier, April 2017, PDF-Dokument)
| |
| | |
| = Realisierung von RNext =
| |
| Um RNext in der vollen Gänze zu verstehen, ist es sinnvoll dieses in drei Komponenten zu unterteilen.
| |
| | |
| == Organisatorisch ==
| |
| Organisatorische Komponente, die sich vor allem mit folgenden Themenpunkten beschäftigt.
| |
| === Projekt/Lab/DiO-Vorgehen ===
| |
| === Gremien/Teams Koordination ===
| |
| | |
| == Fachlich ==
| |
| FachlicheKomponente, die sich vor allem mit folgenden Themenpunkten beschäftigt.
| |
| === Domänenschnitte ===
| |
| === Migration von RClassic auf RNext ===
| |
| | |
| == Technisch ==
| |
| TechnischeKomponente, die sich vor allem mit folgenden Themenpunkten beschäftigt.
| |
| === Authentifizierung ===
| |
| === Buildpipeline ===
| |
| | |
| = Ergebnisse der Arbeitsgruppe RNext =
| |
| | |
| * [[ag-rnext-ergebnisse-201811|Ergebnisse der Arbeitsgruppe RNext (Stand: November 2018)]]
| |
|
| |
|
| | ''BiPRO RNext'' oder einfach [[RNext| '''RNext''']] ist der Codename für die nächste Release-Generation von BiPRO-Schnittstellen. RNext folgt zum einen dem technologischen Wandel z.B. von SOAP zu JSON/REST und Microservices, zum anderen neuen fachlichen Designprinzipien wie z.B. Domain Driven Design und Event-Storming und auch einer agileren Arbeitsweise, die nach den Prinzipien der Open Source Entwicklung funktioniert. Diese Release-Generation wird von der BiPRO-Community des BiPRO e.V. gemeinsam vorangetrieben, um eine Teilnahme an der API-Economy zu ermöglichen. Das wesentliche Bestreben der BiPRO-Community ist es, die digitale Souveränität der Assekuranz zu fördern. Die Fähigkeit zur digitalen Vernetzung mit der gebotenen Geschwindigkeit und Qualität ist ein wesentlicher Erfolgsfaktor für die Branche, um den technologischen und gesellschaftlichen Wandel mit zu gestalten. RNext ist somit ein entscheidender Schritt, um vor dem Hintergrund der digitalen Transformation auch zukünftig wirtschaftlichen Erfolg zu gewährleisten. |
|
| |
|
| = Starthilfen = | | = Welche Services stellt der BiPRO e.V. seinen Mitgliedern zu Verfügung? = |
| | Nach einer Registrierung im BiPRO e.V. wird den Mitarbeitern der Mitgliedsunternehmen eine gewisse Tool-Landschaft geboten. Einerseits geht es dabei um den direkten Zugang zu normativen sowie nicht-normativen Artefakten und andererseits stellt der BiPRO e.V. Kollaborationstools zu Verfügung, so dass gemeinschaftliche Normierungsvorhaben wie auch begleitende Vorhaben zur Implementierung unterstützt werden können. Das Framework wird abgerundet durch Werkzeuge, die Implementierungen und Upgrades von Normen erleichtern, sowie weitere mediale Angebote. |
| | |
| | == Registrierung/Login == |
| | Es gibt eine zentrale Verwaltung der Teilnehmer durch die BiPRO-Geschäftsstelle. Durch einen SSO-Service wird realisiert, dass alle Teilnehmer die Tools im BiPRO-Kontext möglichst komfortabel verwenden können. Es gibt nur einen Benutzernamen, der die E-Mail-Adresse eines Mitarbeiters des jeweiligen Mitglieds ist, sowie ein Passwort, mit dem man sich an sämtlichen Systemen, die im BiPRO-Umfeld eingesetzt werden, anmelden kann. Eine Registrierung ist nur Mitarbeitern von BiPRO-Mitgliedern vorbehalten und kann eigenständig unter '''https://login.bipro.net''' durchgeführt werden. Das Passwort kann selbstständig [[Login_Passwort|'''vergeben/zurückgesetzt''']] werden. Nur wenige Seiten im Wiki selbst sind öffentlich zugänglich, d.h. um auch die gesamte Einsicht in dieses Wiki zu erhalten, ist ein Login notwendig! |
|
| |
|
| * [//www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Liste der Konfigurationsvariablen]
| | == Onboarding == |
| * [//www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki-FAQ]
| | Eine Seite zum [[Onboarding|'''Onboarding''']] soll es den Mitarbeitern von Mitgliedern des BiPRO e.V. vereinfachen, schnell einen Einstieg und eine Übersicht zu bekommen, auf welche Services man als BiPRO-Mitglied zurückgreifen kann. |
| * [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce Mailingliste neuer MediaWiki-Versionen]
| |
| * [//www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Lokalisiere MediaWiki für deine Sprache]
| |
Was ist BiPRO
Der BiPRO e.V. ist die neutrale Organisation der Finanzdienstleistungsbranche, in der sich Versicherungen, Vertriebspartner und Dienstleister zusammengeschlossen haben, um unternehmensübergreifende Geschäftsprozesse zu optimieren. Gemeinschaftlich werden in Normvorhaben (Projekten oder Gruppen) fachliche und technische Normen entwickelt.
Was ist RClassic?
RClassic wird die seit Gründung des Vereins betriebene technische und organisatorische Form der Normentwicklung genannt, nach der Prozesse und Datentransfers zwischen den Unternehmen der Versicherungswirtschaft standardisiert werden.
Technisch handelt es sich um einen Nachrichtenaustausch basierend auf SOAP und XML.
Organisatorisch werden bestimmte Optimierungsbedarfe in der Kommunikation der Marktteilnehmer in zeitlich abgegrenzten Projekten bearbeitet und münden in der Regel in Normdokumenten, einem Daten- und Prozessmodell und ggf. flankierenden Dokumenten. Prozess- und Datenmodell fügen sich dabei in ein Gesamtmodell ein, und die Normdokumente unterliegen sowohl in der Form als auch der Nomenklatur einem selbstdefinierten Standard, der sich an W3C u.a. orientiert.
Die Weiterentwicklung erfolgt nach einem reglementierten Verfahren in Change Requests (CRs), die von den Normungsgremien diskutiert und beschlossen werden, Fachgruppen (Begleitung des Markts), Digitalisierungsoffensiven (Fokussierung des Marktes auf die Implementierung bestimmter Prozesse) und ggf. Folgeprojekten.
Die Normen liegen teilweise als „Offizielle Norm“ zur allgemeinen Verwendung vor, sind aber auch teilweise noch in der vereinsinternen Qualitätssicherung („Potentielle Norm“) und werden in sog. Releases nach einem groben zeitlichen Raster herausgegeben.
Normen
Die Ergebnisse der Standardisierung des BiPRO e.V. in RClassic werden in den Normen der BiPRO dokumentiert. Die Normen beschreiben alle Festlegungen, die für die Prozesse und Daten getroffen werden.
Release-Pakete
Mitgliedern des BiPRO e.V. stehen sämtliche RClassic Normpakete zur Verfügung. Eine detailliertere Beschreibung der Normpakete sowie der Download dieser findet sich unter den RClassic Releases.
Was ist RNext?
BiPRO RNext oder einfach RNext ist der Codename für die nächste Release-Generation von BiPRO-Schnittstellen. RNext folgt zum einen dem technologischen Wandel z.B. von SOAP zu JSON/REST und Microservices, zum anderen neuen fachlichen Designprinzipien wie z.B. Domain Driven Design und Event-Storming und auch einer agileren Arbeitsweise, die nach den Prinzipien der Open Source Entwicklung funktioniert. Diese Release-Generation wird von der BiPRO-Community des BiPRO e.V. gemeinsam vorangetrieben, um eine Teilnahme an der API-Economy zu ermöglichen. Das wesentliche Bestreben der BiPRO-Community ist es, die digitale Souveränität der Assekuranz zu fördern. Die Fähigkeit zur digitalen Vernetzung mit der gebotenen Geschwindigkeit und Qualität ist ein wesentlicher Erfolgsfaktor für die Branche, um den technologischen und gesellschaftlichen Wandel mit zu gestalten. RNext ist somit ein entscheidender Schritt, um vor dem Hintergrund der digitalen Transformation auch zukünftig wirtschaftlichen Erfolg zu gewährleisten.
Welche Services stellt der BiPRO e.V. seinen Mitgliedern zu Verfügung?
Nach einer Registrierung im BiPRO e.V. wird den Mitarbeitern der Mitgliedsunternehmen eine gewisse Tool-Landschaft geboten. Einerseits geht es dabei um den direkten Zugang zu normativen sowie nicht-normativen Artefakten und andererseits stellt der BiPRO e.V. Kollaborationstools zu Verfügung, so dass gemeinschaftliche Normierungsvorhaben wie auch begleitende Vorhaben zur Implementierung unterstützt werden können. Das Framework wird abgerundet durch Werkzeuge, die Implementierungen und Upgrades von Normen erleichtern, sowie weitere mediale Angebote.
Registrierung/Login
Es gibt eine zentrale Verwaltung der Teilnehmer durch die BiPRO-Geschäftsstelle. Durch einen SSO-Service wird realisiert, dass alle Teilnehmer die Tools im BiPRO-Kontext möglichst komfortabel verwenden können. Es gibt nur einen Benutzernamen, der die E-Mail-Adresse eines Mitarbeiters des jeweiligen Mitglieds ist, sowie ein Passwort, mit dem man sich an sämtlichen Systemen, die im BiPRO-Umfeld eingesetzt werden, anmelden kann. Eine Registrierung ist nur Mitarbeitern von BiPRO-Mitgliedern vorbehalten und kann eigenständig unter https://login.bipro.net durchgeführt werden. Das Passwort kann selbstständig vergeben/zurückgesetzt werden. Nur wenige Seiten im Wiki selbst sind öffentlich zugänglich, d.h. um auch die gesamte Einsicht in dieses Wiki zu erhalten, ist ein Login notwendig!
Onboarding
Eine Seite zum Onboarding soll es den Mitarbeitern von Mitgliedern des BiPRO e.V. vereinfachen, schnell einen Einstieg und eine Übersicht zu bekommen, auf welche Services man als BiPRO-Mitglied zurückgreifen kann.