ID#62

25.05.2023

FAQ: Low Code in der Industrieversicherung – #ID62

Diese FAQ beantwortet häufig gestellte Fragen zum Thema Low Code in der Industrieversicherung. Was bedeutet der Begriff? Warum sollten Versicherer, Makler und Assekuradeure in der Industrieversicherung sich damit auseinandersetzen?

00:31 Was bedeutet Low Code?
02:33 Unterschied Low Code und Enterprise Low Code
06:38 Warum sollte sich ein Industrieversicherer oder Industriemakler mit dem Thema Low Code beschäftigen?
10:54 Welche ersten Schritte, wenn Enterprise Low Code eingesetzt werden soll?

Im Gespräch: Ansgar Knipschild, Toni Klein
Länge: 15 Minuten

Transkript

TONI KLEIN: Hallo, herzlich willkommen zum Podcast Industrieversicherung Digital. Mein Name ist Toni Klein. Heute sind wir wieder in einer FAQ-Session. Ich begrüße ganz herzlich dazu meinen Kollegen Ansgar Knipschild.

ANSGAR KNIPSCHILD: Hallo Toni.

TONI KLEIN: Es geht heute um das Thema Low-Code beziehungsweise Enterprise Low-Code. Wir werden auch klären, was das eigentlich mit Industrieversicherung allgemein zu tun hat. Wir starten gleich los mit der ersten Frage. Ansgar, was bedeutet Low-Code eigentlich?

ANSGAR KNIPSCHILD: Das Thema hat gerade auch in den letzten Monaten oder Jahren wieder viel Fahrt aufgenommen. Das Thema gibt es in der Tat schon seit 2014. Ich habe noch einmal nachschaut, da hat es Forrester als Erster offiziell so benannt. Was verbirgt sich dahinter? Wie der Name verrät, Low-Code bedeutet wenig Code. Wie kann man Software erstellen, ohne dass man alles programmieren muss? Wir alle, ich vermute, auch der eine oder andere Zuhörer, oder Zuhörerin, kennt das Thema. Man kann Software auch als Anwender einstellen und konfigurieren. Man kennt das unter Settings, den Einstellungen oder auch etwas komplexer, dass man die Software, ein Maklerverwaltungsprogramm, zum Teil auch komplexere Versicherungssoftware, einstellen kann. Aber das ist stark limitiert. Letztendlich bestimmt der Softwarehersteller, wie die Freiheitsgrade sind und an welchen Ecken und Kanten man diese Software einstellen kann.

Und Low-Code, häufig auch mit einem ähnlichen Begriff wie modellbasierte Softwareentwicklung, sagt, wenn ich diese Konfigurationsoptionen erweitere und die Möglichkeit schaffe, das Programm nach meinen Bedürfnissen anzupassen, aber ohne Code. Dann habe ich eine Möglichkeit geschaffen, die Software für mich zu gestalten, ohne dass ich programmieren muss. Ich vergleiche das immer mit Excel. Während Excel gut ist und auch komplexere Datenauswertungen und Charts machen kann. Der programmiert nicht, aber er macht mehr als nur in Zahlen, Nummern und Fakten in Excel hinein. Sondern er verknüpft, er macht vielleicht auch die eine oder andere kleine Formel, was ich auch noch nicht als Programmieren definieren würde. Irgendwann kippt es auch bei Excel, wenn dann die echten Cracks kommen und den Visual Basic-Editor aufmachen. Dann kodieren sie aber auch wirklich. Genau dazwischen bewegt sich Low-Code.
Das bedeutet, man versucht, Software, die bis jetzt relativ geschlossen und maximal konfigurierbar war, für Ansätze zu öffnen, wo man auch mit Nicht-Programmier-Möglichkeiten deutlich mehr an der Software verändern kann.

TONI KLEIN: Was ist der Unterschied zwischen Low-Code und Enterprise Low-Code? 02:38

ANSGAR KNIPSCHILD: Der Bereich Low-Code unterteilt sich in mehrere Unterkategorien. Das Thema ist ein bisschen älter, wie ich in der ersten Frage gesagt habe. Der klassische Bereich von Low-Code ist der, dass Plattformen oder Hersteller kleine Ökosysteme bereitstellen, indem man sich mit relativ wenig Aufwand kleine Anwendungen zusammenklicken kann. Ohne zu programmieren, ohne zu coden. Häufig kleine Anwendungen, die als Excel-Ersatz durchaus dienen oder vielleicht sogar eine kleine App darstellen können. Ich habe zwei bis vier Buttons, vier oder fünf Eingabefelder und das sehr, sehr komfortabel mit Drag-and-drop und Point und Klick. Da gibt es gerade viele amerikanische Anbieter, die das wirklich sehr, sehr gut machen können, wo ich mir im Webbrowser Anwendungen zusammenbasteln kann. Das ist klassisches Low-Code, häufig aber auch limitiert.

Denn wenn ich komplexere Enterprise-Anwendungen mache, denken wir an eine ERP-Software, Verwaltung von Produkten, von Einkaufsvorgängen und -prozessen. Ich habe vielfältige Schnittstellen in bestehende IT herein, dann wird es auch für eine Low-Code-Plattform manchmal eng, denn die ist nicht dafür gedacht. Sie ist dafür gedacht, kleine, schlanke Anwendungen sehr schnell zusammenzubauen. Genauso wenig, wie Excel dafür gedacht ist, eine komplexe Datenbank abzulösen. Das hat mit Datenmenge und auch mit Datenkomplexität zu tun. Dann kippt das irgendwann.

Dort gibt es die Nische der sogenannten Enterprise Low-Code-Plattform. Die zeichnet sich dadurch aus, dass dort eben auch komplexe Anwendungen mit gebaut werden können. Das heißt naturgemäß, dass der Low-Code-Ansatz hier auch ein bisschen komplexer ist, als bei einer normalen, simplen Low-Code-Anwendung, weil ich mehr Anforderungen habe, auch im Enterprise-Bereich. Ich habe komplexere Eingabeformulare, komplexere Listen, Filterungen, komplexere Datenmodelle, während ich bei einer kleinen Low-Code-Anwendung vielleicht nur, ich nehme wieder ein simples Beispiel, Name, Straße, Postleitzahl, speichern möchte. Ich möchte eine kleine Kontaktverwaltung machen, dann habe ich im Enterprise-Bereich Beziehungen von Unternehmen mit Mitarbeitern, komplexe Produktstrukturen, Hauptgruppen, Untergruppen. Dafür brauche ich Werkzeuge, auch im Low-Code-Bereich. Das bezeichnet man das Enterprise Low-Code-Bereich.
Das heißt Anwendungen, die ganz häufig firmen-intern genutzt werden, zum Teil auch extern, B2B könnte man das sehr vereinfachend sagen, das ist eigentlich die klassische Domäne von Enterprise Low-Code. Ein anderer Aspekt, der hier mit hineinspielt, ist der, dass man auch bei Enterprise Low-Code-Systemen immer an Grenzen stoßen wird, wo Low-Code einfach nicht mehr funktioniert. Wieder das Bild der Exceltabelle. Wenn ich in Excel irgendwann bei Spalte 12000 bin und bei Zeile 65000, solche Excel-Tabellen gibt es, dann ist es das falsche Werkzeug. Dann muss ich trotzdem codieren und coden.

Enterprise Low-Code zeichnet sich vor allen Dingen dadurch aus, zumindest wenn es eine gute Enterprise Low-Code-Plattform ist, dass sie offen ist, auch klassisch mit entwickelt zu werden. Das heißt, sowohl die Kolleginnen und Kollegen, die per Low-Code diese Software bearbeiten, als auch klassische Softwareentwickler, können Hand in Hand auf einer Plattform arbeiten und teilen sich die Arbeit sinnvoll auf. Die einfacheren Anpassungen werden per Low-Code gemacht, aber auf dem gleichen System und Methodik wird auch der klassische Softwareentwickler seinen Code platzieren können, ohne dass er sich verrenken muss. Und die Nicht-Enterprise Low-Code-Plattformen haben genau da häufig ein Problem. Das heißt, sie sind einfach nicht dafür gedacht, dass man klassisch mit Java-Werkzeugen und Java-Entwicklungsprozessen darauf arbeitet, sondern da probiert man dann teilweise mit einigen Verrenkungen den Java-Code hineinzubekommen. Und deshalb sind Enterprise Low-Code-Plattformen eigentlich die bevorzugten Plattformen, wenn man etwas komplexere Geschäftsanwendungen modellieren will, weil man einfach weiß, wir werden sowieso nicht alles nur mit Low-Code-Werkzeugen hinbekommen.

TONI KLEIN: Wir sind in den ersten beiden Fragen eher auf die IT-Technik oder den Hintergrund eingegangen. Was hat das alles mit Industrieversicherungen zu tun? Warum sollte sich ein Industrieversicherungsmakler oder Industrieversicherer mit diesem Thema auseinandersetzen? Was bringt es ihm? 06:54

ANSGAR KNIPSCHILD: Der erste Punkt ist, warum Low-Code und Enterprise Low-Code für Industrieversicherer und Makler interessant ist, dass wir es in dem Geschäftsbereich der Industrieversicherung mit einem sehr hohen Individualisierungsgrad zu tun haben. Die Produkte und Prozesse sind sehr, sehr spezifisch, teilweise sehr auf kundenindividueller Ebene oder auf Geschäftsbeziehungsebene.
Ein Makler arbeitet mit Versicherer A anders zusammen als mit Versicherer B. Wir sind nicht standardisiert wie in Massenendkundenversicherungsgeschäft. Das heißt umgekehrt, wenn ich digitalisiere, habe ich immer wieder Anpassungsaufwand. Ich muss, weil ich einen neuen Maklerpartner an Bord hole oder mit einem neuen Versicherer arbeite, häufig in meinem Maklerverwaltungsprogramm oder Bestandsführungssoftware Anpassungen vornehmen. Weil sich nicht jeder Marktteilnehmer nach „meinen“ Standards richtet. Dort gibt es eigentlich nur zwei Möglichkeiten.

Ich gehe zum Hersteller meiner Software, meinem Maklerverwaltungsprogramm oder Bestandsführung hin und bitte ihn, das anzupassen, mit einer individuellen Softwareentwicklung, vielleicht sogar in Formen des Produktreleases. Ich muss warten, bis die nächste Version der Makler-Wartungssoftware herausgegeben wird. Das kann manchmal ein halbes Jahr oder ein Jahr dauern, je nachdem, welche Priorität der Hersteller diesem Feature einräumt. Oder es wird eben klassisch individuell entwickelt.
Ich glaube, dass es aber im Industrieversicherungsbereich ganz viele Aspekte gibt, die man gar nicht mit klassischer Entwicklung abdecken kann, sondern eben per Low-Code. Denken wir nur einmal daran, dass ich in einem Versicherungsprodukt wie Haftpflicht oder auch einer Transportpolice für einen speziellen Kunden, einen Makler oder Versicherer spezielle Informationen hinterlegen muss. Ich brauche ein neues Feld. Das ist die Sprache, die man im Fachbereich benutzt. Ich brauche ein neues Feld für eine spezielle Nummer, die vielleicht nur mein neuer Maklerpartner braucht. Ich brauche nur für diesen Großkunden spezielle Informationen, wo Maschinen-Seriennummern erfasst werden. Ich brauche für die Verwaltung der Personaldaten, die in der Gruppen-Unfallpolice drinnen sind, spezielle Daten, die in der Police abgedruckt werden sollen. Dann sind das alles vermeintlich kleine Anpassungen, die aber vielleicht in der Standardsoftware nicht drinnen sind. Hier kann Low-Code helfen, bei vermeintlich einfachen Änderungen, einem neuen Feld im Ausgabedruckstück, dem PDF oder dem Word-Dokument, das vielleicht nachher der Endkunde oder Makler, eine Anpassung, die berühmte geänderte Unterschrift, der Vorstand hat gewechselt etc. Das sind alles Paradebeispiele, die man per Low-Code abdecken kann.

Es geht natürlich noch weiter. Wenn ich in einem Thema etwas firm geworden bin, dass ich Schnittstellen oder Teile von Schnittstellen auch per Low-Code abdecken kann. Wenn ich zum Beispiel Daten, und wenn es CSV-Files oder Excel-Files sind, die ich vom Makler oder vom Versicherer bekomme, auch beim Einlesen in mein Programm anpassen kann und nicht mit ständigen Fehlermeldungen konfrontiert bin. Das heißt unter dem Strich, die Industrieversicherung lebt von der Individualität fast jedes einzelnen Vorgangs. Software hilft, das zu standardisieren, zu automatisieren, und Low-Code bietet gerade dem Fachbereich, wenn er bereit ist, sich den digitalen Herausforderungen zu stellen, die Möglichkeiten, direkt eingreifen zu können, ohne dass programmiert werden muss. Ich brauche auf meiner Police extra Text, in der Berechnung noch einmal einen neuen Zuschlag, X-Prozent. Den habe ich mit dem Mitarbeiter vereinbart. Den brauche ich für alle Policen für das halbe Jahr, nur für diesen Kunden. Das sind Punkte, wo man direkt per Low-Code einsteigen kann. Der Riesenvorteil ist für den Versicherer und Makler, dass er nicht zu seinem Software-Hersteller laufen, den Change Request adressieren, ein Angebot abwarten und wirklich ein halbes Jahr oder Jahr warten muss. Sondern diese kleineren Anpassungen kann er mit einem Klick, manchmal sind es auch ein paar mehr, selbst durchführen. Er kann dann seine Software an die Bedürfnisse des individuellen Geschäftsvorfalls, den er gerade bearbeitet, eine Police, einen Schaden, direkt anpassen.

TONI KLEIN: Aus Sicht eines Maklers oder eines Versicherers, was sind aus deiner Sicht die ersten Schritte, die beachtet werden sollen oder gemacht werden müssen, wenn mit einem Enterprise Low-Code-System gestartet werden soll? 11:08

ANSGAR KNIPSCHILD: Ich glaube, die erste Antwort, die von vielen kommen würde, ist die, dass ich mir eine passende Software heraussuche. Ich würde sagen: Nein. Erst einmal sollte man hinterfragen, warum man eigentlich genau eine Low-Code-Software einsetzen möchte. Das bedeutet vor allen Dingen, dass wir mit den beteiligten Stakeholdern, wie wir im Digital-Business sagen. Das sind die Fachbereiche, von denen ich gerade gesprochen habe. Das können Underwriter oder Sachbearbeiter sein, aber auch die beteiligten IT-Parteien, vielleicht die eigene IT-Abteilung bei einem Versicherer, vielleicht der externe Partner, der Dienstleister, der bei den IT-Vorhaben hilft, vielleicht der Maklerverwaltungsprogramm-Hersteller. Dass man wirklich abklopft, wer hat eigentlich welche Interessen. Wie werden Arbeitsaufgaben untereinander verschoben? Denn Low-Code sagt ganz klar, bestimmte Teile der klassischen Entwicklung werden von der IT … Das kann der Produkthersteller, der externe Softwareentwickler oder -entwicklerin oder der Partner sein in dem Fachbereich.

Da merkt man, wir haben es mit der organisatorischen Umstellung zu tun. Obwohl es sehr verlockend und auch sehr plausibel ist, kleine Änderungen selbst durchzuführen, hat es neue Anforderungen für Sachbearbeiterinnen und Sachbearbeiter oder für den Underwriter je nach Skillset. Das muss man auch abklopfen. Was muss ich tun, damit meine Mitarbeiterinnen und Mitarbeiter befähigt werden, hiermit zu arbeiten? Was muss ich tun, damit die Akzeptanz dafür steigt? Wenn ich den Mitarbeitern klarmachen kann: „Höre einmal zu, wenn wir diese Werkzeuge einführen, musst du etwas lernen. Dafür geht es schneller, und du kannst viele Sachen danach einfacher und effizienter umsetzen.“ Dann überwiegen vielleicht die Vorteile, die einer initialen Abwehr gegenüberstehen, wo der Mitarbeiter oder die Mitarbeiterin sagt: „Etwas Neues brauche ich nicht, irgendwie haben wir es vorher auch hinbekommen.“ Genauso bei den Software-Partnern. Klassischerweise finden die das vielleicht auch nicht gut, wenn man ihnen Software-Erstellungsarbeit wegnimmt. Man muss ganz nüchtern festhalten, das Software Geschäft lebt letztendlich von bezahlten Stunden oder Tagen. Das ist das klassische Geschäftsmodell.
Aber es gibt bestimmte Arbeitsbereiche, wo gerade auch bei begrenzten Kapazitäten die Softwarehersteller sagen: „Ich muss nicht alles selbst machen als Softwarehersteller.“ Die hundertste Feldänderung, die 20000. Unterschriftenänderung im Vorlagenformular der Police wird dem Kunden relativ teuer in Rechnung gestellt. Der Kunde ist nicht amused darüber, warum das vermeintlich aufwendig und teuer ist. Auch die Entwicklerinnen und Entwickler beim Softwarehersteller oder Entwicklungspartner haben spannendere Aufgaben zu tun.

Aber diese Interessen zusammenzubringen und letztendlich ein Zielbild zu definieren, diese Bereiche wollen wir per Low-Code umsetzen. Dafür gibt es eine Bereitschaft. Das macht Sinn, auch in einer Effizienzbetrachtung. Dadurch werden wir insgesamt günstiger und schneller, um auf der anderen Seite letztendlich ein Zielbild zu definieren, wo alle beteiligten Parteien, und das sind eben mehrere, wie gerade skizziert, sagen: „Auf dieses Spiel lassen wir uns ein.“ Dann hat man auch die Anforderungen, um danach im Anbietermarkt der Low-Code-Anbieter und vor allen Dingen auf die Enterprise Low-Code-Anbieter hier zu achten, nach den Kriterien durchzugehen und sich dann auch wirklich mit allen Beteiligten anzuschauen, welche Software, welche Anbieter hat hier den besten Fit für die Anforderungen, wie sie gemeinsam definiert wurden.

TONI KLEIN: Vielen Dank Ansgar für diesen kleinen Rundumschlag zum Thema Low-Code und Enterprise Low-Code. Bevor wir uns verabschieden, möchte ich noch einmal einen Hinweis in eigener Sache loswerden. Wer sich für das Thema Low-Code in der Industrieversicherung weiter interessiert, dem befehle ich die Episode ID 39. Da geht es konkret um praktische Beispiele aus der Industrieversicherung in Deutschland, wo mit Low-Code gearbeitet wird. Es ist sicherlich eine schöne Ergänzung. Ich danke dir, Ansgar.

ANSGAR KNIPSCHILD: Danke Toni. Rückmeldungen freuen uns natürlich und wenn Interesse daran besteht, das zu vertiefen, sehr gerne. Wir konnten heute wirklich nur so an der Spitze des Eisbergs kratzen. Das Thema lässt sich natürlich endlos weit vertiefen. Tschüss.