Transcript

Einführung und Vorstellung der Gäste

Torsten:
[0:35] Ja, hallo und herzlich willkommen zur 157. Ausgabe des E-Government Podcast.
Ich bin Thorsten Frenzel und heute habe ich gleich mal drei Gäste in meinem virtuellen Studio.
Und bevor einer von den Gästen wieder spoilert, ich sage direkt, worum es geht. Wir sprechen heute über das Thema Low-Code in der öffentlichen Verwaltung.
Und ich denke, wir werden auch ein bisschen diskutieren. Aber fangen wir gleich mal an mit meinen Gästen. Hallo, Sarah.

Zehra:
[1:00] Hi, Thorsten.

Torsten:
[1:01] Vielleicht stellst du dich mal ganz kurz vor.

Zehra:
[1:03] Ja, ich bin Sarah Özdürk. Ich arbeite in der Senatskanzlei der Hamburger Verwaltung, und dort bin ich zuständig für diverse Projekte.

Torsten:
[1:14] Ja, schön, dass du dabei bist. Wir sehen uns ja quasi alle naselang irgendwo auf irgendwelchen Veranstaltungen.

Zehra:
[1:19] Ja, ich bin so selten unterwegs, aber man trifft sich zwischendurch mal.

Torsten:
[1:22] Aber schön, dass du bei mir im Podcast bist. Und dann machen wir direkt weiter mit Hannes. Ich grüße dich Hannes.

Hannes:
[1:30] Hallo Thorsten. Ja.

Torsten:
[1:32] Vielleicht stellst du dich auch noch mal kurz vor.

Hannes:
[1:34] Ja, gerne doch. Hannes, ich bin der Verratsleiter im ITZ Bund, dort zuständig für das Projektmanagement. Und danke, dass ich hier sein darf.

Torsten:
[1:42] Ja, schön, dass du da bist. Auch wir kennen uns schon länger dienstlich.

Hannes:
[1:47] In der Tat. Das Nutzerkonto Bund lässt grüßen.

Torsten:
[1:49] Genau, so ist es. Und last but not least haben wir auch noch die Nina da.
Hallo Nina, ich grüße dich.

Nina:
[1:55] Hallo, Thorsten.

Torsten:
[1:56] Vielleicht stellst auch du dich kurz vor.

Nina:
[1:58] Ja, ich bin Nina Ferreira da Costa, bei Schiff Digital Produktmanagerin für ein No-Code-Nicht-Low-Code-Tool, zur eigenständigen Prozessdigitalisierung. Und vor kurzem, muss kurz Eigenwerbung machen, ist mein Buch Prozessmodernisierung in der öffentlichen Verwaltung bei Springer Gabler erschienen. Schön, dass ich da sein darf.

Torsten:
[2:18] Das Buch werden wir natürlich auch in den Show Notes verlinken. Schön, dass du da bist.

Nina:
[2:22] Sehr dank.

Torsten:
[2:23] Genau, und da wir jetzt schon beide Worte gesagt haben, sowohl No-Code als auch Low-Code, fangen wir doch direkt mal an.
Was ist denn überhaupt dieses Low-Code, von dem immer alle reden?

Hannes:
[2:33] Wenn keiner was sagen will, dann grätsche ich mal kurz rein. Also was ist Low-Code?
Low-Code ist per se nichts Neues. Das Konzept geht zurück in die 70er Jahre.
Du hast dann in den 4GL-Sprachen etwas abgebildet, und das hat sich jetzt dann im Laufe der Jahrzehnte tatsächlich weiterentwickelt zum Konstrukt, in dem man sagt, man schreibt gar keinen bis wenig Code.
Das ist dann der No-Code, mit keinem Code mehr schreiben, bis wenig Code, wo ich noch die Möglichkeit habe, ein bisschen Code eigenständig zu schreiben. Das ist dann Low-Code.
Und wir können es, glaube ich, den Hörerinnen und Hörern so erklären, dass man Modulbaukasten hat, ähnlich wie Lego.
Und aus diesem Kasten setzen sich die einzelnen Bausteine zusammen, sodass man daraus dann dementsprechend ein Fachverfahren, einen Online-Dienst, oder auch einfach nur einen Prozess digital abbildet.

Torsten:
[3:24] Okay. Und No-Code ist das Ganze nur noch mit Lego-Bausteinen?

Nina:
[3:28] Genau. NoCode ist letztlich die Idee, die Anpassbarkeit ist natürlich geringer, weil ich bei NoCode meistens nochmal die Möglichkeit habe, kleinere Dinge anzupassen, je nach Bedarf.
Und NoCode basiert auf der Idee, ich habe eigentlich alle Bausteine fertig.
Letztlich, wenn wir beim Lego bleiben, die Farben liegen auch schon fest und kann damit aber mir dann meine Prozesse oder letztlich kleinen Fachverfahren zusammenstöpseln.

Torsten:
[3:51] Ja, vielen Dank. Und dann gehen wir doch direkt mal los. Und jetzt frage ich

Diskussion über den Nutzen von Low-Code und No-Code

[3:56] mich, Also ich komme auch aus der Welt des Programmierens.
Da frage ich, warum brauchen wir denn Low-Code und No-Code?
Oder brauchen wir nur eins von beiden?

Zehra:
[4:05] Ich glaube, man braucht beides, weil man nicht immer sagen kann, für das setze ich jetzt immer das ein und für dieses, was ich da brauche, muss ich immer das einsetzen.
Sondern wir haben unterschiedliche Probleme und darauf gibt es unterschiedliche Lösungen. Aber No-Code als auch Low-Code bieten sich überall da an, wo wir immer wieder mit ähnlichen Herausforderungen konfrontiert sind.
Denn wir haben hier dann den Vorteil, dass wir immens an Geschwindigkeit bei der Entwicklung zulegen können, dass wir Kosten, Entwicklungskosten reduzieren können, dass wir aber auch dadurch, dass wir auf standardisierte Plattformen, weil in der Regel einen Low-Code, oder No-Code Denn erstellte Anwendung läuft auch auf derselben Plattform.
Und dadurch habe ich auch eine gewisse Standardisierung beim Betrieb und kann auch entsprechend Betriebskosten sparen.
Das heißt, neben dem Aspekt des Kostensparens ist es vor allem die Geschwindigkeit und die Qualitätszunahme, die ich habe, weil ich eben mit kleinen Aspekten, sorry, nicht mit kleinen Aspekten, sondern weil ich eben schon vordefinierte Elemente habe, die schon gewisse Standards erfüllen und die ich dann entsprechend zusammenfügen kann.
Ich hab dann aber auch weniger Flexibilität und auf das ganze Thema Citizen Developer gehen wir bestimmt auch noch mal ein.
Das lasse ich mal außen vor, damit die anderen auch ein bisschen dazusagen können.

Nina:
[5:26] Ja, ich hätte auch gerne einen Haken direkt. Das Thema Standardisierung ist, denke ich, ein wichtiges, gerade wenn es letztlich um Prozesse geht.
Meistens, wenn wir von Low-Code-Lösungen sprechen, will man irgendwelche Tätigkeiten damit abbilden.
Dann haben wir eigentlich Tätigkeiten, die immer wieder dieselben sind.
Die weichen inhaltlich ab, aber in der Verwaltung ist es meistens, ich möchte Daten annehmen, ich möchte die prüfen, ich möchte Unterschriften tätigen, ich möchte Daten abgleichen, ich möchte sie ergänzen.
Letztlich sind es Tätigkeiten, die auch fachbereichsübergreifend immer wieder dieselben sind, nur inhaltlich weicht es ab.
Und deshalb können wir eben so einen Baukasten an Fertigteilen bereitstellen über Low-Code und No-Code und damit eben auch die Ermächtigung der Beschäftigten voranbringen, weil mehr Leute in der Lage sind, ihr Fachwissen einzubringen in eine Software und damit dann ihre eigenen Prozesse zu digitalisieren und Vorgänge.

Hannes:
[6:19] Dem kann ich eigentlich grundsätzlich nur mehr zustimmen und ich glaube, wir haben hier bereits eines der wichtigsten Themen im Kontext von Low-Code-Plattformen, oder No-Code-Plattformen angerissen. Das ist nämlich diese Standardisierung.
Wir können es jetzt vielleicht als Quasi-Standardisierung irgendwo bezeichnen, weil wir jetzt, wenn wir auf diesen Plattformen Software entwickeln, also Anwendungen entwickeln auf diesen Low-Code-Plattformen, Diese Anwendungen sind weiterverwendbar im Sinne, dass sie auf derselben Plattform natürlicherweise dann auch woanders eingesetzt werden kann.
Das ist ein wahnsinniger Fortschritt im Sinne der Standardisierung, den wir so glaube ich noch nicht haben.
Es gibt andere Möglichkeiten der Standardisierung. Könnt ihr mal die Java Virtual Machine angucken.

Low-Code-Plattformen vs. Java Virtual Machine

[7:02] Write once, run anywhere oder everywhere.
Das geht, ja. Es hat aber, sag ich mal, gewisse Einschränkungen, Wenn wir dann tatsächlich in Infrastrukturen kommen, die dann groß sind, wenn ich dann hier.

[7:16] Infrastrukturen, infrastrukturelle Voraussetzungen betrachten muss, wie Sicherheit, wie Zonentrennung, etc., wie eine Firewall, wie eine WAF, da habe ich dann für jedes Verfahren, das ich hier als Java-Code irgendwo hinbringe, dann muss ich das alles wieder selbst oder zum Großteil eigenständig wieder einrichten.
Während ich bei Low-Code-Plattformen, da ist der Abstrahierungsgrad tatsächlich so hoch, dass ich die Anwendung, die ja dann als XML im Regelfall daherkommt, einfach in der Low-Code-Plattform entpacke, über vorgefertigte Mechanismen und dann läuft das.
Also Low-Code-Plattformen und No-Code-Plattformen sind für mich das, was tatsächlich in Windows der Hardware Extraction Layer ist.
Etwas total Tolles, was man so wahrscheinlich bis jetzt noch nicht hatte, auch wenn jetzt jemand argumentieren könnte, mit Containern ist das ähnlich.
Es stimmt Container können auch ähnliche Sachen oder gleiche Sachen wie Low-Code-Plattformen auf der, Virtualisierungsebene. Aber deswegen sind die Low-Code-Plattformen auch Plattformen, und nicht nur eine reine Orchestrierung, wie das bei Containern ist.

Torsten:
[8:18] Okay, das heißt zu meinem Verständnis, ich installiere mir so eine Low-Code-Plattform, bei mir in meiner Verwaltung und alle Anwendungen laufen da drauf.
Und ich muss quasi nur einmal eine Installation machen und die Anwendungen, die da drauf laufen, die kann ich mir mit anderen Anwendern austauschen.

Hannes:
[8:35] Wenn du das so einfach ausdrücken magst, ja. Der Teufel sitzt natürlich im Detail.
Also diese Installation von so einer Low-Code-Plattform, das ist nicht etwas, was jetzt einfacher ist als jede andere Installation.
Das muss vorbereitet werden, das muss sich in die Infrastruktur der Behörde, der Verwaltung, von wem auch immer einfügen. Und natürlich muss ich dann darauf auch die Anwendung entwickeln.
Und wenn ich die Anwendung entwickle, dann habe ich natürlich auch gewisse Rahmenbedingungen, an die ich mich halten muss.
Aber die Low-Code-Plattformen, dadurch, dass der Freiheitsgrad an der Entwicklung, bei Low-Code und No-Code einfach eingeschränkter ist, habe ich einfach einen vorgezeichneten Weg, auf dem ich mich bewegen kann.
Und ich laufe nicht mehr über das ganze Feld.
Also ich habe eine Straße, während ich vielleicht bei individualer Entwicklung über das Feld laufe. da gibt's vielleicht eine Straße, die nehme ich auch, aber dann weiche ich wieder irgendwo ab.
Also da opfert man Freiheitsgrade für eine schnellere Fortbewegung bei Low-Code-Plattformen.

Bedienung von Low-Code- oder No-Code-Plattformen

Torsten:
[9:31] A. Und die Sarah hatte vorhin schon mal was von Citizen-Developern gesagt.
Das bringt mich auf die Frage, wer soll denn jetzt so eine Low-Code- oder No-Code-Plattform bedienen?
B.

Zehra:
[9:43] Also die meisten Hersteller werden sagen, man kann jeden dazu ausbilden.
Und das stimmt Und auch wenn man Zeit, Geld und Geduld hat.
Praktisch, die Erfahrung, die wir gemacht haben, ist, dass es schon Personen sein sollten, die eine gewisse IT-Affinität mitbringen, die Lust dazu haben und das auch mit einer gewissen Regelmäßigkeit machen.
Denn wie bei jeder Software, die man bedient, wie bei jeder Entwicklungssprache, mit der man Code schreibt, ist es auch bei Low-Code so, dass eigentlich die Erfahrung dann am Ende die Geschwindigkeit bringt und die Kenntnis mit dem Tool selber.
Deshalb ist es eher so, dass wir empfehlen aus Hamburg heraus zu sagen, wir sollten jetzt nicht gucken, dass jeder in Verwaltung versucht, mit Low-Code selber Anwendungen zu erstellen oder mit No-Code, sondern eher Personen, die sowas auch häufiger machen, immer mal wieder da etwas tun, aber eben nicht nur einmalig.
Denn durch diese Einmaligkeit habe ich nicht die Geschwindigkeit, ich habe nicht die Kostenreduktion, weil jede Person dann doch irgendwie nochmal ausgebildet werden muss, um überhaupt mit dem Locode-Tool arbeiten zu können.
Und dann gibt es viel Unterstützung, die am Anfang notwendig ist.
Und deshalb, Citizen Developer zielt eher so ein bisschen darauf ab, ja, es müssen nicht Fullstack-Entwickler sein, die ich vielleicht für Normal-Code-Erstellung benötige.

Erweiterte Zielgruppenbildung mit Locode- oder No-Code-Anwendungen

[11:06] Ich habe hier die Chance, auch andere Zielgruppen auszubilden, mit Locode- oder No-Code-Anwendungen zu designen.

No-Code-Plattformen: Zusammenstellen statt Entwickeln

[11:15] Ich ich würde es auch nicht mal entwickeln nennen, weil es ist eigentlich kein Entwickeln, sondern eher so ein Zusammenstellen, Designen und an der einen oder anderen Stelle vielleicht mal noch ein bisschen Code hinzufügen, wenn die entsprechende Plattform das zulässt.

Nina:
[11:29] Ja, wir haben dort tatsächlich einen ähnlichen Ansatz oder auch ähnliche Erfahrungen gemacht.
Letztlich geht es darum, zu überlegen, wer braucht welche Kompetenzen.
Wenn ich jetzt sage, jeder Beschäftigte, jeder Beschäftigte soll innerhalb einer Verwaltung lernen, mit einer No-Code- oder einer No-Code-Plattform umzugehen.

[11:47] Dann haben wir diejenigen, die letztlich die fachliche Expertise haben und doppeln obendrauf noch, jetzt musst du das hier auch noch lernen, weil der gehört ja mit dazu, sich mit dem Tool auskennen.
Und dann aber natürlich auch noch das, sagen wir mal, das prozessspezifische Wissen, wie nutze ich jetzt die verschiedenen Funktionen, um daraus nicht nur einen Prozess eins zu eins umzusetzen, sondern die Vorteile von diesem Tool zu nutzen.
Da gehört also auch noch Expertise über Prozessmanagement mit dazu.
Und stattdessen empfehlen wir auch, baut euch quasi ein Kernteam auf, dass affin ist, das Lust darauf hat, sowas zu lernen.
Und dass dann quasi die Fachbereiche oder die anderen Beschäftigten darin unterstützt, ihre Prozesse damit umzusetzen.
Weil so haben wir in den Fachbereichen die fachliche Kompetenz, die müssen nicht zusätzlich zu ihrem Alltagsgeschäft und der Umsetzung auch noch lernen, das zu bedienen.
Und sie werden aber quasi zentral unterstützt von Leuten, die sich extrem gut mit dem Tool auskennen und dadurch auch sehr, sehr schnell und effektiv helfen können.
Und die dann die Erkenntnisse, die sie zum Beispiel aus dem einen Fachbereich mitnehmen über. Wie geht es am schnellsten? Wie geht es am besten?
Welche Schwachstellen haben wir identifiziert, die wir jetzt verbessern konnten?
Dieses Wissen nehmen Sie dann wieder mit in die anderen Fachbereiche.
Das heißt, es fängt nicht jeder von Null an mit Best Practices und Learnings aus der Arbeit mit dem Tool, sondern das kann quasi geteilt werden innerhalb der Verwaltung.

Torsten:
[13:11] Ich habe so ein bisschen Angst. In den letzten Jahren habe ich einige Kommunalverwaltungen speziell kennengelernt.
Und da kamen immer wieder ähnliche Aussagen wie, da hat der Klaus mal was in Access gebaut.
Laufen wir wieder in diese Gefahr, dass wir uns hier mit Low-Code und No-Code, Legacy-Systeme in den einzelnen Verwaltungen schaffen, die dann halt nur vom Klaus gepflegt werden können?

Hannes:
[13:37] Das, was du ansprichst, ist die berühmte Schatten-IT. Und ich glaube tatsächlich, dass Low-Code-Plattformen hier ein privates Mittel sind und diese Schatten-IT nicht überall.

Low-Code-Plattform zur Erleichterung von Prozessen

[13:46] Aber in einem doch erheblichen Maße einzugrenzen. Und was passiert?
Ich baue mir hier mein Tool, dass ich jetzt dafür die Erledigung von irgendeinem Prozess brauche oder glaube zu brauchen, eben nicht mehr in Access oder von mir aus in Excel oder mit einem Word-Template, sondern kann das tatsächlich versuchen, über eine Low-Code-Plattform umzusetzen.
Und natürlich ist es dann so, dass wenn diese Low-Code-Plattform bei mir eine Plattform ist, die ich in meiner Behörde oder meiner Verwaltung im Einsatz habe, Untertitel im Auftrag des ZDF für funk, 2017, Dann habe ich diese Anwendungen zentral auf dieser Plattform laufen.
Und dann ist dieses Thema Schatten-IT viel weniger präsent, als das vielleicht jetzt ist.
Weil wenn der Klaus jetzt kündigt und ein Excel-Tool hier niemand mehr erweitern, kann oder bedienen kann, muss ich irgendjemanden holen, der mir das tatsächlich wieder erweitert, beziehungsweise auf irgendwas anderes umbaut.
Schlimmste Fall wäre sogar, dass ich das Excel-Tool komplett verliere, weil der Klaus nicht mehr da ist. Da bieten Low-Code-Plattformen tatsächlich eine Möglichkeit, das abzuschwächen, beziehungsweise auch diese Schatten-IT dann in eine etwas, hellere IT umzuwandeln.
Das wird nicht komplett weggehen, das geht gar nicht. Das ist auch nicht der Anspruch von Low-Code-Plattformen, aber sie können einen Beitrag dazu leisten.
Also ich glaube, da ist die Angst unbegründet, dass wir da dann wieder zusätzliche Schatten-IT mit Low-Code-Plattformen aufbauen.

Zehra:
[15:08] Und der Vorteil hier ist auch, dass sich in der Regel, also es sind ja gängige Produkte, die da eingesetzt werden, wenn es um die großen Low-Code-Entwicklungsplattformen geht.
Und dort gibt es auch immer eine große Community. Das heißt, die Möglichkeit, hier dann nochmal Expertise, Austausch zu bekommen, ist nochmal ganz anders, als jemand hat dann ein spezifisches Makro gebaut und nur die Person weiß, wie das anzuwenden ist.
Und die Gefahr haben wir, glaube ich, in dem Maße nicht.
Allerdings, glaube ich, braucht man auch beim Einsatz von Low-Code und von Low-Code-Plattformen, gewisse Regeln und hat aber eben dadurch, dass es eine Plattform ist, auch die Chance, das nochmal ganz anders zu denken, anders aufzubauen.
Das heißt, wo man auch als Kommune nicht hin sollte, ist einfach zu sagen, jetzt kaufe ich mir mal ein neues Tool und mache alles so wie bisher.
Sondern wenn man schon sagt, ich steige jetzt auf was Neues um und habe die Chance nochmal meine Prozesse ein bisschen anders zu denken, zu gestalten.

Nachhaltigkeit und Expertise bei Low-Code-Anwendungen

[16:10] Nachhaltigere Software zu erstellen, weil das tut man ja auch, wenn man mit Low-Code etwas macht, als wenn man Makro etwas gebaut hat oder, mit sonstiger Schatten-IT.
Dann sollte man wirklich auch nochmal kurz überdenken, wie möchte ich das einsetzen, wie möchte ich das gestalten, worauf muss ich achten, was brauche ich, weil Nina hat es ja eben auch gesagt, ein kleines Team, was dann die Expertise hat, unterstützen kann bei der Einführung, bei der Erstellung von Anwendungen.
Das heißt, man sollte schon noch mal überlegen, auch als kleinere Kommune, möchte ich das wirklich selber machen, möchte ich mir das nicht über einen Dienstleister noch mal einkaufen.
Wenn ich es selber machen möchte, was für Prozesse brauche ich auch dahinter, damit das bei mir auch richtig und gut laufen kann und damit es wirklich eine effektive Unterstützung wird und nicht einfach nur ein Tool, von dem ich jetzt glaube, dass es die Heilung für meine Probleme bringt.
Das tun wir ja leider zu oft, dass wir sagen, ah, guck mal, ein neuer Trend, Blockchain, war es vor ein paar Jahren, ist es phasenweise immer mal wieder.
Und Blockchain hat immer noch nicht alle Probleme gelöst. Und jetzt haben wir halt Low-Code und KI. Und insofern, am Ende muss ich ein Problembewusstsein haben, wissen, wie ich es einsetzen möchte.
Und dann, glaube ich, nicht, dass man in dieselbe Gefahr läuft, Schatten-IT aufzubauen, sondern er hier, wie es Hannes auch schon gesagt hat, wirklich die Chance hat, noch bessere IT-Landschaft aufzubauen und zu unterstützen, als ich es dann vorher mit Schatten-IT.

Torsten:
[17:39] Mein Traum ist ja immer noch eine Low-Code-Blockchain-KI.
Aber Schatz beiseite.

Zehra:
[17:44] Lass uns das mal privat machen und mal gucken, was wir da aufgebaut bekommen.
Und ich denke, alle werden sich dann drum reißen, wenn wir nur richtig, wir müssen nur die Buzzwords immer wieder nennen und dann läuft das Ding.

Nina:
[17:55] Sie muss auch agil sein.

Torsten:
[17:57] Genau, eine agile, low-code Blockchain-KI.

Zehra:
[18:00] Und zukunftsgerichtet.

Torsten:
[18:03] Aber lass mal wieder zurückkommen zum Thema.
Ihr habt alle gesagt, das geht um Plattformen. Und wenn man einfach mal googelt nach Low-Code und No-Code Plattformen, dann kriegt man ja Hunderttausende.
Da kriegt ihr zig Open-Source, Closed-Source, super coole, duper Businesslösungen.
Kann man zwischen diesen Plattformen die Anwendungen austauschen?
Also ist es so, dass eine Verwaltung sich jetzt eine kleine Anwendung baut, für einen Online-Dienst zum Beispiel, und die Nachbarverwaltung sagt, hey, das habt ihr cool gemacht, hätte ich auch gern.
Kann das die Verwaltung an die andere Verwaltung weitergeben?

Zehra:
[18:39] Nicht, wenn es nicht auf demselben System läuft, machen wir uns nichts vor.
Das können die Plattformen in der Regel nicht, wollen sie auch in der Regel nicht.
Aber man muss auch sagen, Plattform ist nicht gleich Plattform.
Heutzutage, weil eben Low-Code ein Trend ist, tituliert sich fast alles wieder als Low-Code, was nicht unbedingt eine Low-Code-Entwicklungsumgebung ist, sondern eben nur für ein spezifisches Thema da ist und eben nur einen Teilbereich dessen abdeckt.
Und, also, ich würde jetzt sagen, I have a dream, weil ich auf jeder Bühne, auf der ich bin, immer wieder an die Hersteller appelliere.
Wir müssen es irgendwie hinbekommen, dass diese Plattformen miteinander sprechen und auch mal Teile austauschen können. aber es ist technisch tatsächlich nicht so einfach, wie man sich das vorstellt, weil es meist auch einfach eine unterschiedliche Basis hat.

Hannes:
[19:28] Also vielleicht müssen wir da noch ein bisschen klarstellen selber, wenn zwei Kommunen dieselbe Plattform in Einsatz haben, dann können sie natürlich die Anwendung austauschen.
Allerdings ganz klar, so wie die Serie es auch sagt, die Plattformen untereinander sind nicht kompatibel.
Es gibt keinen Standard, mit dem man da irgendwie eine Anwendung von Plattform A zu Plattform B transportieren kann oder könnte.
Das wäre jetzt tatsächlich etwas, wo man sagt, das wäre ein Traum, wenn das irgendwann mal gehen könnte. Ich wage zu bezweifeln, dass der tatsächlich irgendwann mal Realität wird, aber man muss ja mit dem Träumen nicht unbedingt aufhören.

Nina:
[20:01] Ich denke auch, die Problematik ist, sobald es mehr als einen Standard gibt, kann man eigentlich kaum noch von Standards sprechen und das ist was gerade auch in der Low-Code-Branche, der Fall ist. Also ist das jetzt irgendwie XML oder bzw. XUV oder JSON oder in welchen Datenformaten könnte man miteinander sprechen.
Es gibt nicht den einen Standard und aktuell, nur wie du sagst, man findet irgendwie hunderte, tausende Ergebnisse.
Die müssten schon auch alle miteinander sprechen. Vielleicht müsste es auch eine Vorgabe geben oder zumindest eine Empfehlung.
Ich glaube aber, daran erkennt man auch, warum das Thema digitale Souveränität und Open Source und Open Data gerade so groß ist.
Die Hoffnung, dahin zu kommen, dass wir das irgendwann schaffen.
Ich halte das jetzt gerade oder für die nächsten Jahre auch für unwahrscheinlich, auch weil diese Branche gerade noch so sehr im Wachsen und Ansteigen ist und die Verwaltung auch gerade erst sich wirklich intensiv damit auseinandersetzt.
Wir sind so ein bisschen vielleicht am Peak-Low-Code.
Ich, glaube, der Begriff Allheilmittel war, glaube ich, auch schon gefallen.
Letztlich das, was alle paar Jahre passiert mit dem neuen Thema Blockchain, Bestes Beispiel, es kommt das neue Thema auf und dann stürzen sich alle drauf, aber es ist nicht immer durchdacht und es ist auch nie wirklich groß geplant.
Definitiv nicht von den ganzen Anbietern, weil die ja selten auf diese Art miteinander sprechen.

Zehra:
[21:27] Wobei aus meiner Sicht, die gar nicht, also was ich immer wieder versuche zu sagen ist, der Markt ist eigentlich groß genug, dass auch diverse Anbieter hier genug Raum finden werden und vor allem jede Low-Code-Plattform hat auch so ein bisschen ihre eigene Spezialität, was sie besonders gut kann.
Und wir haben ja, wie gesagt, auch unterschiedliche Probleme, sodass sich nur auf ein Low-Code-Tool zu verlassen nicht unbedingt die beste Strategie ist, sondern dass man eh gucken sollte, was sind so die Herausforderungen, die ich habe, was möchte ich lösen und welche Plattformen gibt es auf dem Markt.
Und wahrscheinlich wird die Zukunft eher so aussehen, dass wir mehrere Plattformen parallel einsetzen werden. Und die meisten setzen übrigens auch schon sogenannte Low-Code-Lösungen ein.
Also jeder, der so einen Antrags- und Fallmanagement schon hat, jede größere Verwaltung setzt sowas schon ein. Das ist auch mehr oder weniger Low-Code.

Torsten:
[22:21] Ja, ich habe neulich gelesen, dass auch Wordpress als Low-Code-Plattform inzwischen verkauft wird.

Zehra:
[22:26] Im Moment, wie gesagt, ist es alles Low-Code, wenn es danach geht, aber wenn wir von so einer richtigen Low-Code-Entwicklungsplattform sprechen, dann ist es glaube ich schon nochmal ein bisschen was anderes, aber vielleicht noch eine Sache, was man häufiger von Herstellern hört, ist, dass es durchaus möglich wäre, Lösungen zwischen Plattformen auch auszutauschen, weil das, wenn es auf BPMN basiert, Und dann kann man das ja irgendwie mit BPMN wieder rausgeben und in einer anderen Plattform… Das ist übrigens, das möchte ich auch an der Stelle sagen, weil ich bin ja nicht… komme ja nicht von einem Hersteller.
Das ist auch ein bisschen Humbug, weil das, was man sich da dann in die Plattform reinholt, muss dermaßen überarbeitet werden, dass ich es einfach auch von Anfang an selber schnell hätte zusammenklicken können und eine viel bessere und schnellere Lösung hätte, als wenn ich versuche BPMN modellierte Prozesse von woanders oder einfach selbst erstellt in so eine Plattform reinzubringen.
Wollte ich nur an der Stelle nochmal losgeworden sein.

Wie sieht eine Low-Code-Plattform aus?

[23:30] Weil das wird mir immer erzählt, wenn ich sage, können die nicht miteinander.

Torsten:
[23:34] Okay und wie kann ich mir denn jetzt so eine Low-Code-Plattform oder No-Code-Plattform, vorstellen? Wie sieht denn sowas aus?

Zehra:
[23:42] Ganz hübsch.

Torsten:
[23:43] Ist gut. Dann gekauft?

Nina:
[23:44] Ja, also ich kenne vor allem unsere, aber das Grundprinzip ist ja letztlich, was man vielleicht dann zu programmieren würde.

[23:53] In Bausteine aufzuteilen und zu sagen, wir haben einen Arbeitsschritt.
Auf diesem Arbeitsschritt gibt es Aufgaben. Diese Aufgaben kann ich Leuten zuweisen, ich kann Beschreibungen reinpacken und ich kann auf so einem Arbeitsschritt Datenfelder, Dokumente bereitstellen.
Das heißt letztlich, ich nehme eine Kombination aus Text, Berechtigung und irgendeine Form von Datenfeld, die dann wieder bestimmte Dinge tun kann und kombiniere die über Abzweigung und Pfade miteinander.
Im Grundprinzip BPMN, das ist ja gerade schon genannt, nur ich weiß nicht, wie versiert die Zuhörer in der sind.
Business Process Modeling and Notations nennt sich der Spaß.
Es ist letztlich Flussdiagramme für Prozesse.
Und auch wir haben schon öfter gehört, wollt ihr nicht einen Import bauen?
Aus genau dem Grund, dann ist es quasi fertig. Ist es leider nicht, weil es anders funktioniert.
Aber letztlich ist es die Idee, wir wissen, wir wollen Aufgaben.
In einem Prozess werden Aufgaben abgearbeitet und dabei wird mit Daten gearbeitet.
Dann werden Entscheidungen getroffen, und am Ende gibt es ein Ergebnis.
Runtergebrochen ist das der Prozess, Trigger mit Input, Leistung, Output, und das gebaut aus verschiedenen Komponenten, in unserem Fall über ich klicke mir Datenfelder, Arbeitsschritte, Abzweigungen, andere Prozessbausteine.
Dazu verbinde die miteinander, wie ich es brauche, und dann nehme ich Einstellungen vor über Klicks.
Das ist letztlich runtergebrochen.

Torsten:
[25:16] Also was müssen jetzt dann Klaus und sein Team, weil er macht es ja nicht mehr alleine, weil er nur Access kann und wenn er weg ist, ist auch Access weg, deswegen hat er jetzt ein Team.
Was müssen die jetzt tun, wenn sie sich so eine Local-Plattform eingekauft haben und sie sagen, Mensch, für diesen Online-Dienst, da fehlt uns noch ein Fachverfahren. Lass uns mal eins bauen.

Zehra:
[25:35] Also Clouds und Team, so wie du sie bisher beschrieben hast, werden wahrscheinlich auf die Idee kommen, dass sie einfach die Plattform nehmen und loslegen, ohne vorher irgendwo eine Anleitung gelesen zu haben.
Das sollten sie auf keinen Fall bitte tun.
Es ist schon sowieso, also fast alle Low-Code-Plattformen sind übrigens visuell unterstützt.

[25:53] Das heißt, die Oberflächen sind ganz anders gestaltet. Ich muss nicht klassisch Code eingeben, sondern ich kann mir Sachen zusammenklicken, anders zusammenstellen.
Viele Dinge, Datenfelder sind schon vordefiniert. Das heißt, ich habe ganz andere Möglichkeiten, hier Dinge zusammenzustellen.
Und trotzdem ist es notwendig, dass man einmal sich kurz damit auseinandersetzt, wie funktioniert denn diese spezifische Plattform, mit der ich gerade arbeite?
Was ist das Grundwesen von der?
Wie muss ich diese einzelnen Elemente zusammenfügen, damit daraus eine Anwendung entsteht und das kann dann eine Schulung von, also bei uns geht es auch eher so Richtung No-Code, deshalb kann man nach ein paar Stunden ist man schon befähigt, dann auch in der Lage, selber Anwendungen damit zu erstellen.
Aber es gibt eben auch die Plattformen, die ein bisschen umfangreicher sind, mehr Funktionalitäten haben, mehr Individualität auch in der Erstellung von Anwendungen zulassen und, Also es gibt Hersteller, die sagen, sechs Monate Ausbildung, also auch das gibt es insofern.
Ich glaube, es kommt tatsächlich darauf an, mit was für einer Plattform will ich arbeiten und was will ich damit machen?
Aber so ein paar Stunden sich mal kurz damit auseinandersetzen und je nachdem, wie IT-affin man ist, kommt man schneller rein oder auch langsamer.
Hat man dann nach einer gewissen Zeit schon, ist man in der Lage, so eine Anwendung damit dann auch zu erstellen.

Torsten:
[27:18] Und welche Komplexitäten kann ich abbilden mit so einer Low-Code-Plattform?
Kann ich jetzt sagen, ach Mensch, das Low-Code-Plattformen, da komme ich ganz gut zurecht. Jetzt baue ich mir mal mein eigenes Zulassungsverfahren damit.
Kriege ich das hin oder ist es eher was für einfache Anwendungen mit möglichst wenig Abzweigungen und relativ linearen Prozessen?

Zehra:
[27:39] Ich kann mal die Beraterantwort geben. Das kommt drauf an. Nein, also Zulassungsverfahren, glaube ich, kannst du durchaus damit abbilden.
Ich habe mal so eine Regel vor kurzem gehört.
Wenn das, was du mit Low-Code machen möchtest, mehr als drei Monate Umsetzungszeit, in Anspruch nimmt, ist Low-Code vielleicht nicht die beste Lösung.
In Verwaltung muss man da sicherlich wegen Vorlaufzeiten und, und, und nochmal drei Monate raufpacken.
Da wird wahrscheinlich sechs Monate eine realistische Zeit sein.
Aber das fand ich eigentlich eine ganz gute Regel und das trifft es auch ganz gut, weil je komplizierter es wird, desto mehr muss man sich fragen, ist Low-Code hier wirklich der beste Amt.
Aber Hannes ist da ja auch ganz gut drin. Vielleicht hat der noch eine Meinung dazu.

Unterscheidung zwischen Komplexität und Funktionsumfang bei Low-Code-Plattformen

Hannes:
[28:20] Genau, also ich würde da noch einmal gerne unterscheiden zwischen Komplexität und Funktionsumfang, was ich mit der Low-Code-Plattform umsetze.
Klar, wenn die Komplexität zu groß wird, dann brauche ich Individualentwicklung, weil ich dann die Low-Code-Plattform in Richtungen bringen muss, wo sie nicht hin will, wofür sie auch nicht gemacht ist.
Auf der anderen Seite, wenn ich tatsächlich viele Funktionalitäten umsetze, die in ihrer Komplexität begrenzt sind, dann ist das natürlich etwas, was ich mit einer Low-Code-Plattform auch machen kann und vielleicht auch machen sollte.
Und dann kann ich natürlich auch ein Projekt machen, was länger als drei oder sechs Monate geht.
Aber ja, also Low-Code-Plattformen an sich geben einen Weg vor, wie man die Low-Code-Plattform zu verwenden hat.
Und das definiert dann auch schon in einer gewissen Art und Weise, was ich damit umsetzen sollte und was nicht.
Das ist aber tatsächlich dann ein Lernverfahren, wo ich sehen muss, hat sich die Umsetzung mit der Low-Code-Plattform für das Fachverfahren 1 jetzt ausgezahlt oder nicht?
Und da kommt man vielleicht nochmal ganz auf den Anfang zurück, wo auch immer mitgeteilt wurde oder gesagt wurde, dass man hier ein Team schaffen muss, was hier tatsächlich diesen Einsatz der Low-Code-Plattform in der Organisation auch unterstützt.
Das ist dann ein Center of Excellence für die Low-Code-Plattform, das dann zentral in der Organisation dafür verantwortlich ist, den Einsatz der Low-Code-Plattformen zu moderieren, zu

[29:46] Sagen, oder auch dann den Einsatz abzumoderieren und dann aber auch die anderen Organisationseinheiten, zu beraten.

Die Bedeutung von Kommunikation und Zusammenarbeit

[29:52] Und, auch in der Umsetzung zu unterstützen.

Nina:
[29:54] Um jetzt auch noch mal kurz die Anbieterperspektive mit reinzubringen.
Je mehr Komplexitäten man versucht, mit der Software abzubilden, das geht. Man kann immer weitere Funktionen bauen, die Komplexität erhöhen.
Desto komplexer wird das Tool aber auch für diejenigen, die einsteigen.
Und das ist, glaube ich, eine Balance, die man dann versucht zu halten.
Die Zugänglichkeit soll auch ein bisschen Spaß machen, damit zu arbeiten.
Und je mehr Funktionen ich sag jetzt mal, reinballert, desto schwieriger wird es auch, das zu erlernen und damit umzugehen, weil man erschlagen wird von Möglichkeiten, die man in häufigen Fällen dann gar nicht braucht.
Das heißt auch da, je komplexer die Prozesse, und Komplexität heißt ja eben auch, wie viele Beteiligte gibt es zum Beispiel, oder in wie viele andere Tools muss ich letztlich reinspringen.
Wo muss ich einen Datenbankabgleich machen?
Wo muss ich, Beispiel Tiefbauamt, vielleicht ins Geoinformationssystem rein.
Dafür braucht es diese Schnittstellen und Funktionalitäten. Wenn ich die nicht habe, müsste ich die wieder in Auftrag geben. Das Tool wird komplexer.
Und das kann man natürlich machen. Aber wie gesagt, ich glaube, auch die AnwenderInnen wünschen sich, dass möglichst so leicht und zugänglich wie möglich bleibt, dieses Tool zu bedienen und man gleichzeitig möglichst viel damit machen kann.
Und das ist, glaube ich, die Balance, an der man auch als Anbieter arbeitet.

Torsten:
[31:14] Eines der Versprechen ist ja gerade das ganze Thema Komplexitätsverringerung, sodass Klaus und sein Team mit relativ einfachen und wenigen Klicks hier Anwendungen bauen können.
Wie wird das geschafft, dass die Komplexität trotz der großen Plattform für den Anwender verringert wird?

Zehra:
[31:33] Ich glaube, hier muss man unterscheiden, was für eine Plattform ich einsetze.
Wenn ich eine große Plattform a la Mendix oder OutSystems einsetze, die sind halt unfassbar mächtig und da ist die Komplexität nicht wirklich reduziert.
Und die sind auch ein bisschen schwerer zu erlernen.
Und dann gibt es eben Plattformen, die gehen eher so Richtung No-Code und reduzieren, das nochmal, weil sie sagen, wir nehmen hier jetzt einen bestimmten Use Case, auf den fokussieren wir uns und hier ist das Ganze dann ein bisschen einfacher in der Erstellung und es ist tatsächlich ein bisschen runtergebrochen, das Ganze.
Was man aber, glaube ich, unterscheiden muss, ist, das Tool nimmt nicht die Komplexität in dem Sinne raus, sondern es bietet dir die Mittel, mit denen du die weniger komplizierten Aspekte abbilden kannst.
Was eigentlich die Hausaufgabe davor ist, was wir alle auch lernen müssen, ist, uns unseren Prozess anzuschauen.
Und das sollten wir nicht erst machen, während wir versuchen, das alles zusammenzuklickern, sondern wir sollten uns ganz kurz davor einmal die Zeit, dem zu schauen, was möchte ich denn eigentlich machen?
Was ist das, was ich abbilden möchte? Welche Schritte brauche ich dafür?
Und was muss dafür womit irgendwie kommunizieren?
Und idealerweise macht man das auch mal auf dem Whiteboard, visualisiert sich das mal ganz kurz und guckt mal, was womit zusammenhängt.
Weil danach das tatsächlich im System, in so einem Low-Code-System nachzuklicken, und das Ganze dann zusammenzustellen.

Das.

[33:03] Das.

Komplexität durch technologische Lösungen nicht immer gelöst

[33:03] Ist dann der einfachste Part an dem Ganzen. Aber was wir häufig machen, ist, wir legen sofort in einer Lösung los, in einer technologischen Lösung, etwas umsetzen zu wollen.
Meist halten wir uns an den Prozess, wie wir ihn bisher gemacht haben.
Das ist aber nicht der Weg, wie wir Komplexität rauskriegen.
Manchmal schaffen wir sie uns dadurch nur, weil wir versuchen, etwas genauso abzubilden wie es vorher war.
Und dafür ist das Low-Code-Tool im Zweifelsfall auch nicht gemacht, weil bestimmte Schritte, die genauso abzubilden, nochmal individuelle Entwicklungen erfordern oder ein bisschen komplexer oder deutlich komplizierter in der Umsetzung sind, als das Low-Code-Tool es anbieten würde.
Insofern wäre meine Empfehlung, einmal vorher gucken, was möchte ich eigentlich machen, nochmal runterbrechen, dann anfangen in einer ersten Version das mit dem Low-Code-Tool zu erstellen und danach zu gucken, welche Schleifen, also mit Schleifen meine ich jetzt rosa Schleifchen, die das alles besonders schön aussehen lassen, nochmal hinzuzufügen.
Jetzt nicht im Sinne von irgendwelchen Programmierschleifen.

Hannes:
[34:05] Da möchte ich aber kurz einhaken. Also ich gebe dir schon recht, Sarah, dass man da am Anfang sicher das eine oder andere Mal ein bisschen genauer auf den Prozess gucken müsste.
Aber das ist ja jetzt das Faszinierende bei den Low-Code-Plattformen, dass ich tatsächlich die Möglichkeit habe, relativ schnell im Rapid Prototyping mir Sachen zu erarbeiten, anzusehen und dann auch wieder zu ändern.
Weil ich nämlich nicht jetzt zuerst aufwendig Individualentwicklung betreiben muss, die mich vier, sechs Wochen kostet.
Die ersten zwei Sprints oder so, um irgendetwas zu sehen, sondern tatsächlich in den großen Plattformen oder in den in den Local Plattformen, über die wir hier sprechen, kann ich das tatsächlich in einem Tag machen.
Dann habe ich den Prozess prototypisch abgebildet. Ich kann den durchklicken, kann sagen vielleicht nicht den ganzen Prozess, aber ein Teil von dem Prozess kann mir den ansehen und kann dann darüber anfangen zu iterieren.
Also da habe ich tatsächlich große Hoffnungen, dass man mit den Local Plattformen hier zumindest auch in der Prozessanalyse, in der Prozessaufnahme und auch in der Kommunikation mit den Fachbereichen tatsächlich eine Beschleunigung erreichen, einen Verständnisgewinn erreichen, wenn alle hier auf der Low-Code-Plattform sich, diesen Prozess angucken und den dann auch tatsächlich verstehen.
Und vielleicht ist es dann so, dass wir diesen Prozess dann individual umsetzen müssen, weil die Low-Code-Plattform hier tatsächlich an ihre Grenzen stößt.
Aber zumindest beim Rapid Prototyping sind da, glaube ich, Low-Code-Plattformen, ein aproposates Mittel der Wahl.

Low-Code-Plattformen als effektives Mittel für Rapid Prototyping

Zehra:
[35:28] Das möchte ich auch nochmal so unterstreichen. Ich finde, das widerspricht sich auch überhaupt nicht. Ich finde nur, dass man tatsächlich einmal gucken sollte.
Das ist für mich eher so ein ... Hat nicht unbedingt was mit Low-Code zu tun, sondern ist eher so etwas Grundsätzliches, was ich im Moment feststelle, dass wir uns zu selten darüber Gedanken machen, was wir eigentlich umsetzen wollen und was unser Problem ist.
Aber bei dem Aspekt zum Rapid Prototyping, da geb ich dir absolut recht.
Da ist Low-Code wie gemacht für.
Und man kann in kürzester ... Ich find's immer wieder toll, wenn wir in einem Workshop mal in einer halben Stunde so ein ganz rudimentäres Fachverfahren mit den zugerufenen Wünschen erstellen und auf der Basis schon mal zeigen können, schau mal, es bringt wirklich was, es geht ganz flott und man sieht dann auch direkt im Fachbereich, dass da was entsteht und gemacht wird und dann kann man es immer noch ausbauen.
Also da bin ich voll bei dir, das stimmt absolut.

Nina:
[36:22] Ihr sprecht mir auch beide aus der Seele, weil ihr zwei Punkte anspricht, die wir auf jeden Fall letztlich relativ früh gelernt haben.
Das erste ist das Wissen darüber, was in dem Prozess eigentlich noch nicht so gut läuft und wie genau er abläuft und wie er laufen sollte, ist meistens nicht bei der einen Person, die dann den Prozess zusammenklickt, sondern ist in mehreren Köpfen und oft noch gar nicht gut erfasst.
Das heißt, dass man ohnehin erst mal die Leute, die Beteiligten zusammenbringen muss.
Dass es eigentlich keinerlei technische oder Digitalisierungsarbeit, dass es extrem viel Zwischenmenschliches, dass es Kompromisse finden, dass es herausfinden, welche Beteiligten brauchen wir wirklich, wer steuert was zu dem Ziel bei, das dieser Prozess eigentlich erreichen soll.

[37:06] Und dann auf der anderen Seite extrem schnell eine erste Version umsetzen zu können, anstatt letztlich in einem langen Wasserfallprozess, was so eine Individualentwicklung häufig dann auch wird, weil man immer stückchenweise Sachen hinzukommt und dann merkt man, oh, wir brauchen auch noch das und wird dann letztlich irgendwo nie fertig.
Low-Code und No-Code ermöglichen es einem, schnell, ich sage mal, quick and dirty, den ersten Aufschlag zu machen und dann direkt zu testen.
Und das ist was, was die Verwaltung, glaube ich, damit gut lernen kann.
Trial and Error und erst mal die großen 80 Prozent, das Große.
Wir wissen, hier liegt der Prozess ewig. Das ist extrem umständlich und hier beschweren sich immer alle.
Und dann sind das die drei Sachen, die wir als erstes machen.
Die Detailarbeit kommt, wenn wir diese drei Sachen gut umgesetzt haben.
Und dann kann man Versionierung machen.

[37:55] Was auch, letzter Punkt dazu, darauf einzahlt, dass ein Prozess nicht einmal digitalisiert und in die Software gebracht werden sollte und dann liegt er wieder zehn Jahre, weil dann sind wir an genau derselben Stelle, an der die Verwaltung jetzt an vielen Stellen ist.
Die Möglichkeiten entwickeln sich weiter, die Funktionen. Man lernt neue Dinge aus anderen Prozessen, die man umsetzt.
Das heißt letztlich dieses Zyklische, wir verbessern, wir probieren aus, wir verbessern wieder, dann auch weiterzumachen über letztlich für immer, damit die Prozesse nicht wieder einstauben und organisch anwachsen mit neuen Schritten, die man vielleicht am Ende gar nicht braucht.

Torsten:
[38:36] Ihr habt jetzt mehrfach angesprochen, dass die Prozesse so nach und nach wachsen oder die Anwendungen so nach und nach wachsen.
Wie sieht es denn generell mit so einer Updatebarkeit aus?
Also ich habe jetzt den Prozess fertig, den habe ich jetzt in einem Status, da kann ich produktiv mitgehen.
Jetzt stelle ich aber in einem halben Jahr fest, oh Mensch, da hat sich was verändert oder es hat sich sogar Software verändert. Es gab Software-Updates, Schildstellen passen nicht mehr.
Wie ist das denn möglich? Wie kann ich so einen Prozess aktuell halten und funktionabel halten?

Zehra:
[39:07] Meinst du jetzt als Besitzer, also als Plattformhersteller oder meinst du als Ersteller eines Fachverfahrens?

Vorteile von Low-Code-Plattformen für Fachverfahrensersteller

Torsten:
[39:16] Ja, schon als Ersteller eines Fachverfahrens, weil das ist ja mein Begehr.
Ich will ja, dass diese Anwendung, die ich gerade gebaut habe, dass ich da nicht jetzt wieder wie früher bei Microsoft Windows regelmäßig irgendwelche DVDs reinschieben musste und das verteilen.
Ich will, dass das funktioniert und dass ich das schnell updaten kann, schnell verändern kann und auch.

Zehra:
[39:37] Aber als Ersteller eines Fachverfahrens kriege ich das im Zweifelsfall gar nicht mit, weil die Plattform im Background upgedatet wird und einzelne Module, die im Zweifelsfall an Funktionalität hinzufügen oder nicht, die sollen nicht das Fachverfahren an sich beeinflussen.
Aber Aber natürlich kann es sein, dass, wenn ein Update für die Plattform oder für einzelne Module dieser Plattform kommt, dass das auch sich auf mein Fachverfahren auswirkt. Aber in der Regel bekomme ich darüber eine Info.
Und in der Regel ist es dann, gerade weil es eben mit Low-Code so einfach ist, das anzupassen, auch relativ unkompliziert, dann das nochmal anzupassen.
Also es ist sicherlich beim Update nicht derselbe Aufwand, wie ich es bei anderen Lösungen, bei klassischem Code oder dergleichen hätte.
Auch was die Schnittstellen anbelangt, auch die müssten deutlich einfacher anzupassen sein.

Nina:
[40:34] Ja, also es gibt letztlich eigentlich zwei Update-Varianten.
Das eine ist, es ändert sich etwas, dadurch sich auch die bestehenden Prozesse ändern oder die kleinen Fachverfahren.
Dann schreibt man eine sogenannte Migration, die dafür sorgt, dass diese weiterhin funktionieren, auch mit der Änderung.
Und die andere Möglichkeit, es gibt Funktionen, die zusätzlich verfügbar sind, wo ich dann eben als Fachverfahrensverantwortliche Verantwortliche in der Verwaltung nochmal reingehen und meine Verfahren eben durch diese Funktionen verbessern, wieder verbessern kann.
Und das passiert normalerweise. Das kriege ich normalerweise mit über Release Notes und ähnliches.
Und ja, Schnittstellenwartung ist eigentlich ja auch Teil der Aufgaben von den Produktanbietern.
Deshalb ist das normalerweise kein Problem. Im Idealfall gibt es dann, wenn neue Funktionen rauskommen, die es mir ermöglichen, meine Prozesse wieder weiter zu verbessern.
Zum Beispiel, wenn neue Automatisierungen rauskommen oder es neue Möglichkeiten in der Hinsicht gibt, dann macht man vielleicht auch ein kleines Webinar dazu oder gibt andere Hinweise, wie kann ich das jetzt so verwenden, dass meine Prozesse wieder besser werden.
Und genau, das funktioniert tatsächlich mit Low-Code und Low-Code.
Das verwandelt mich gut meiner Erfahrung nach.

Torsten:
[41:44] Jetzt haben wir ganz viel über Vorteile gesprochen. Ich bin kurz davor, den Kaufen-Button zu klicken.
Welche Nachteile oder welche Problematiken gibt es denn aktuell mit den Low-Code-Plattformen?
Sarah, ihr habt eine Low-Code-Plattform mitentwickelt. Nina, ihr entwickelt eine Low-Code-Plattform.
Und Hannes, ihr führt gerade eine ein oder wollt eine einführen.
Auf welche Probleme stößt man?

Probleme und Herausforderungen bei der Nutzung von Low-Code-Plattformen

Hannes:
[42:08] Ich glaube grundsätzlich auf das Problem, dass die Broschüren immer den Best Case darstellen und man dann in der Realität doch auf die Probleme stößt, die man woanders auch hat.
Also was wir jetzt gerade haben, wir führen jetzt eine Low-Code-Plattform im, ETC-Bundschutz ein, und da ist natürlich das Thema der Infrastruktur, wie die Low-Code-Plattform in der Infrastruktur betrieben wird, ein großes Thema.
Diese Low-Code-Plattformen bringen Standardsoftware mit, Und diese Standardsoftware muss natürlich dann auch in der einen oder anderen Weise betrieben werden.
Und nicht jede dieser Software hat auch irgendwo einen betrieblichen Service, der bei uns zum Beispiel verfügbar ist.
Also entweder muss man dann die Low-Code-Plattform anpassen, was wahrscheinlich dann die schlechteste Lösung ist, oder aber man muss hier entsprechend betriebliche Services aufbauen, die dann die Software, auf der dann die Low-Code-Plattform beruht, auch dann tatsächlich betreiben können.
Auf der anderen Seite werden wir lernen müssen, wie man diese Low-Code-Plattformen, wirklich richtig nutzt.
Hier sind ja die beiden Damen schon einen deutlichen Schritt weiter, dass sie ja beide ihre eigenen Low-Code-Plattformen entwickeln.
Da wir hier ja Low-Code-Plattformen einsetzen, die wir sozusagen von der Stange kaufen, müssen wir tatsächlich lernen, wie man diese Low-Code-Plattformen für die Applikationsentwicklung, oder die Anwendungsentwicklung dann tatsächlich auch einsetzt, wo deren Grenzen sind, wo sie Mehrwert bieten und wo sie auch eben keine Mehrwert bieten.

Zehra:
[43:35] Also Hannes hat es schon gesagt, die größte Herausforderung bei uns war tatsächlich auch das bei uns zum Laufen zu bekommen.
Wir haben ja unsere Local Plattform bei der Dataport zum Laufen gebracht und auch da mussten entsprechende Strukturen geschaffen werden.
Wir haben ja auch eine Lösung, die eben nicht nur für ein Bundesland, sondern für unterschiedliche zum Einsatz kommen kann in einem so-called Software-as-a-Service-Ansatz.
Und da ist es eben schon eine Herausforderung, diese Betreibbarkeit hinzubekommen, diese Update-Mechanismen hinzubekommen, ohne dass es sich auf die Kunden auswirkt, die damit Anwendungen bauen, es aber auch überhaupt hinzubekommen, dass diese Austauschbarkeit von Lösungen unter den Kunden wirklich gut funktioniert.
Das waren so die Herausforderungen, mit denen wir zu kämpfen hatten.
Und aus einer Betriebssicht und aus einer anderen Brille noch mal, weil wir ja jetzt auch so ein bisschen anders denken mussten und gucken mussten, ich bin ja aus Verwaltung, muss aber quasi ein Low-Code-Produkt jetzt verkaufen, vertrieblich unterwegs sein.
Und da ist es natürlich die Herausforderung, wie macht man eigentlich Verwaltung deutlich, was kannst du damit, was kannst du aber auch nicht?
Denn im Moment ist so eine Erwartungshaltung an Low-Code, dass es alles lösen kann.
Kann es aber nicht. Also nicht jede Plattform ist eben für alles geeignet und es macht auch nicht Sinn, überall Low-Code einzusetzen.

[44:59] Deshalb ist so ein bisschen auch Aufklärungsarbeit gerade ganz viel gefordert.
Im Austausch mit Verwaltung immer wieder zu sagen, was kann eigentlich Low-Code, wofür ist es gut geeignet, wofür ist es eben vielleicht nicht geeignet.
Und auch noch mal so bisschen darauf hinzuweisen, dass wir als Verwaltung nicht auf einzelne Technologien setzen sollten, sondern nochmal verstehen sollten, was gibt es für Technologien, meine Probleme zu kennen und dann zu gucken, welche Technologie matcht auf welches Problem.
Und das sind so Herausforderungen, mit denen wir dann eher zu kämpfen haben und wo wir dann auch merken, dass wir noch ganz viel an Aufklärungsarbeit leisten müssen, wofür bestimmt Plattformen gut sind und wofür vielleicht aber auch nicht.
Und eben ganz häufig dieses Thema Citizen-Developer, weil danach werden wir immer gefragt und das müssen wir immer, immer und jedes Mal nochmal erklären.

Torsten:
[45:51] Erstens, jetzt musst du noch ganz kurz sagen, was ist denn ein Citizen-Developer?
Weil Citizen ist ja der Einwohner und werden ja wohl jetzt nicht die Bürgerinnen und Bürger die Fachverfahren für die Verwaltung bauen.

Der Begriff "Low-Code, No-Code" erklärt

Zehra:
[46:01] Nee, das ist aber auch kein Begriff, der nur für die Verwaltung geprägt wurde.
Ich glaube, der Begriff wurde deshalb so gewählt, weil man dann, also die genaue Historie kenne ich gar nicht, aber steht im Grunde dafür, dass eine Person, die nicht klassischer Entwickler ist, also ein Jedermann, eine Jederfrau in die Lage versetzt wird, Developer zu sein, also ein Citizen, also ein...
Beliebige Person kann dann Developer werden. Darum geht's, glaube ich.
Also so würde ich mir den Begriff jetzt herleiten, weil dafür steht es am Ende.

Nina:
[46:34] Ja, dann würde ich auch noch einmal einhaken.
Ich denke, der der Punkt mit Was kann Low-Code, No-Code tatsächlich liefern.

[46:43] Ist sehr wichtig, vor allem, weil was man als als Anbieter versucht, machen ist letztlich ein fachbereichsübergreifend, prozessübergreifend einsetzbares Tool.
Sagen wir mal generisch, dass Digitalisierungslücken füllen kann innerhalb der Verwaltung.

[47:00] Und was dann aber der einzelne Fachbereich damit im Zweifelsfall machen will, ist ein hochspezifisches Fachverfahren zu bauen, das hargenau das tut, was für diesen ein sehr, sehr fachlich tiefgehenden Prozess gebraucht wird.
Und das ist die große Schere, die auch innerhalb einer Kommune möglichst geklärt werden muss, oder dass man eben genau sagt, es geht nicht darum, dass wir ein gigantisches Monstrum an Tool bauen, dass jedes einzelne, jeden einzelnen winzig kleinen oder spezifischen Bedarf in jedem Fachbereich, mein Großstadt hat um die 200 Jobs mit 30 bis 40 letztlich kleinen Konzernen, die alle, Tiefbauamt, Grünflächenpflege, Feuerwehr, Personalamt, dass es geht so über so viele verschiedene Themenbereiche.
Die brauchen alle sehr, sehr spezifische Lösungen.
Das kann aber nicht gleichzeitig ein generisches Tool für eine komplette Verwaltung sein und das hochspezialisierte Fachverfahren.
Und da den Zwischenweg zu finden und auch dafür ist so ein zentrales Team, das die Lösungen, die es gibt, sehr gut kennt, gut geeignet, die dabei helfen können, das einzusortieren.
Eine zweite Grenze, die, denke ich, auch oftmals im Weg steht, ist, dass Low-Code oder No-Code-Software wie einen, Werkzeugkoffer, zu behandeln.

Die Herausforderung der Digitalisierung in der Verwaltung

[48:21] Den man sich einkauft, in der Erwartung, dass er dann von selbst die Bilder aufhängt, jetzt mal dumm gehängt, nicht weiterhelfen wird. Aber denke ich häufig, die Hoffnung ist. Und das ist das, was Sera gerade auch schon meinte mit, das ist letztlich das Allheilmittel.
Ich brauche das einmal und all meine Sorgen sind aus der Welt.
Ich muss eben auch die Zeit investieren, um meine Beschäftigten zu schulen, im Idealfall mit denen anzufangen, die Lust darauf haben, auch ihre Prozesse zu digitalisieren, damit die dann positiv darüber sprechen, so ein bisschen Multiplikatur innen schaffen, die positive Erfahrungen damit gemacht haben, um das dann weiter reinzutragen.
Und da sind wir eigentlich auch schon beim Dritten auch wieder irgendwo Stichwort Citizen Developer oder Lion Entwickler in vielleicht.
Ich brauche Leute, die wollen und die dürfen und die dann noch können.
Letztlich sind das die drei Voraussetzungen. Und am besten fängt man mit denen an, die wollen, weil die können dann auch können lernen sozusagen.
Und das Dürfen muss von der Startspitze kommen. Und das ist letztlich eine Einordnung in der Digitalstrategie, wo da eben dazugehört, das hatten wir vorhin auch schon angesprochen, ich kaufe nicht einfach Low-Code ein und dann schmeiße ich es rein und gucke, was passiert, sondern ich weiß, ich möchte folgende Prozesse oder folgende Prozestypen gerne digitalisieren.
Ich sehe darauf Match Low-Code gut. Ich gucke mir an, was passt jeweils und dann gehe ich das strategisch an.

[49:50] So, aber das ist eine große Herausforderung, das organisiert zu kriegen, weil die Leute, die die Strategie machen und verfolgen, sind meistens nicht diejenigen, die sich dann die Software im Detail angucken können und diejenigen, die die Software tatsächlich benutzen, sind in diesem Prozess oft gar nicht involviert.
Also es ist innerhalb einer Verwaltung gibt es sehr viele Beteiligte, sehr viele, die mitsprechen wollen und auch irgendwo müssen und das sollte man möglichst früh zusammenbekommen, damit das dann strukturiert ablaufen kann und nicht chaotisch wird.

Hannes:
[50:19] Absolut korrekt. Da ist ja jetzt dieser Podcast schon ein tolles Mittel.
Na, wo setzt man denn ursprünglich mal an, damit man hier die Kolleginnen und Kollegen in der Verwaltung tatsächlich ertüchtigt, ein bisschen eine Vorstellung zu kriegen. Was ist denn Low-Code?
Was kann das? Was kann es nicht? Und da sind wir auch gerade dabei, die Sarah und ich auf der Next e.V.
Eine Community zu gründen für Low-Code und vielleicht auch für No-Code, dass man darüber dann auch die Kolleginnen und Kollegen aus der Verwaltung eben mal mit in diesen Prozess einbezieht.
Damit die lernen okay sie hören jetzt ein buzzword es ist logo was verbirgt sich denn überhaupt dahinter was kann ich damit machen und was sollte ich auf keinen fall damit machen es ist wie schon gesagt ist ein prozess da müssen wir aufpassen dass wir nicht sagen so logo diesen hammer und es auf einmal ist jetzt alles nagel oder der werkzeugkasten der automatisch bilder aufhängt das ist das halt einfach nicht und das kann es auch gar nicht sein.

Torsten:
[51:11] Jetzt habe ich noch eine ganz konkrete frage ich bin großer anhänger dieses prinzips exit first.
Also Anhänger des Prinzips, wenn ich was einkaufe, überlege ich mir vorher, wie werde ich es wieder los.
Wie sieht das mit diesen diversen Low-Code-Plattformen aus? Wenn ich mich für eine Low-Code-Plattform entscheide, bin ich dann für immer bei dieser Plattform, habe also einen Login-Effekt, so wie wir es jetzt ganz deutlich bei Microsoft zum Beispiel erleben, oder bin ich flexibel und kann umziehen, kann migrieren oder sonstiges tun?

Zehra:
[51:40] Also du hast wie bei jedem anderen Produkt, wie bei jeder anderen Plattform, hast du natürlich eine Abhängigkeit, die du dir reinholst.
Gerade auch, weil diese Lösungen noch nicht so funktionieren, dass du einfach darauf erstellte Anwendungen auf anderen Plattformen auch zum Laufen bringen kannst.
Insofern, es gibt eine Abhängigkeit und das darf man auch nicht unterschätzen.
Andererseits bin ich in der Lage, wenn ich mir so einmal überlegt habe, was möchte ich da eigentlich haben, das einmal mit einer Low-Code-Plattform, umgesetzt habe, es auch gut mit einer anderen Plattform umsetzbar ist.
Das heißt, dieser Wechsel von Plattform A zu Plattform B ist im Zweifelsfall nicht so groß, wie ich es bei klassischer Software hätte vielleicht oder bei anderen Produkten.
Aber ich lasse mich auf eine Abhängigkeit ein und das muss mir bewusst sein.
Und deshalb empfiehlt es sich ja auch, eine Mehrplattform-Strategie zu fahren und nicht nur mit einem Plattform-Hersteller für meine Lösung, die ich da erstellen möchte, zu arbeiten.
Und idealerweise haben wir irgendwann eine Welt, wo wir vielleicht die ein oder andere Open-Source-Local-Plattform, für, Verwaltung.

Open Source und kommerzielle Lösungen im Vergleich

[52:57] Haben und alle anderen kommerziellen Hersteller, Wir haben verstanden, dass es viel schöner ist, wenn die Plattformen alle gut miteinander können und Lösungen darunter austauschbar sind, weil, wie gesagt, der Markt ist eigentlich groß genug und das ist ja auch ein Stück weit der Kundenwunsch und auch hier kann ein, auch hier kann eine Gewinnmarge für Hersteller liegen, wenn man es geschickt macht.

Torsten:
[53:21] Du hast mir die Frage aus dem Mund genommen. Ich wollte eigentlich fragen, gibt es das auch in Open Source? Aber...

Zehra:
[53:26] Wir arbeiten dran, wir arbeiten dran. Es ist nicht so einfach.

Nina:
[53:28] Ja, ist das nicht so einfach, aber auch wir arbeiten dran. Die Schwierigkeit daran ist, dass man eben erstmal jede Menge Geld reinstecken muss, um da hinzukommen.
Und dann muss man gucken, wie können wir zumindest auf schwarze Zahlen kommen, damit wir es weiter betreuen und warten können.
Und dann kann man anfangen zu gucken, was davon können wir irgendwie open source stellen, sodass jeder es benutzen kann.
Und dann gibt es irgendeine Form von Enterprise Edition mit mehr Funktionen.
Das ist so üblicherweise dann die Vorgehensweise. Aber wenn man mal so einen Monolithen gebaut hat, das dann wieder umzusetzen und aufzuteilen in Open Source, das ist aufwendig, aber wünschenswert.

Zehra:
[54:04] Aber der wichtigste Teil ist, glaube ich, selbst wenn man nicht Open Source sofort machen kann, und das ist etwas, woran wir jetzt in den nächsten Monaten arbeiten wollen, ist, dass wir entsprechende APIs definieren, wo alles dazu programmiert werden kann.
Und wir wollen uns nochmal angucken.
Weil wir haben ja so eine hybride Lösung, teils eingekauft, teils selbstentwickelt.

[54:26] Und unser Wunsch ist es aber, irgendwann dahin zu kommen, dass das so eine Entwicklungsgemeinschaft wird, die die Plattform weiterentwickelt.
Und das funktioniert eben nur, wenn wir uns Gedanken machen, wie kann das denn funktionieren?
Was muss dafür passieren? Wie kann daraus schrittweise mehr Open Source werden?
Vielleicht nochmal mit dem Hersteller zu sprechen, wo wir die Lösung eingekauft haben. Also da gibt es unterschiedliche Wege, die man noch mal eruieren muss und gucken muss, wie kann das funktionieren.
Aber ich glaube, der erste und wichtigste Schritt ist es, überhaupt zu erlauben, dass Sachen anprogrammiert werden können.
Dann im nächsten Schritt zu gucken, wie kann mitprogrammiert werden, also an der Plattform selber mitgestaltet werden.
Und schrittweise so den Weg zu gehen und auch zu gucken, was ist denn hier das Sinnvollste. weil wir müssen ja immer noch gucken, wie wir einen sicheren Betrieb hinbekommen.
Und das darf man auch nicht unterschätzen, weil wir entwickeln alle munter gemeinsam an einer Lösung weiter, womit Open Source ja immer gleichgesetzt wird.
Müssen wir dann wiederum gucken, was bedeutet das für die Betreibbarkeit, für die Update-Mechanismen etc.
Etc. Also, so ganz trivial ist das Thema tatsächlich nicht, wenn man auch eine gewisse Form von Produktprofessionalität und Stabilität haben möchte.
Insofern muss man da glaube ich in den nächsten Monaten noch mal ganz ganz viel Intelligenz reingeben und gucken, wie das gestaltet werden könnte.

Torsten:
[55:51] Okay. Gibt es zum Thema Low-Code und No-Code noch Themen, die euch auf dem Herzen liegen?

Austauschbarkeit von Anwendungen auf Low-Code-Plattformen

Hannes:
[55:57] Ein Thema hätte ich vielleicht noch tatsächlich. Wir haben es ganz am Anfang ganz kurz angerissen.
Das ist die Austauschbarkeit oder die Weitergabe von Anwendungen auf einer Low-Code-Plattform, auf die nächste selber Low-Code-Plattform.

[56:10] Das ist etwas, was man in der Verwaltung unter dem Prinzip EVA kennt, also einer für alle.
Das ist ja jetzt nicht unbedingt das, was in den letzten Jahren im OZG total gut funktioniert hat.
Ich glaube tatsächlich, dass Low-Code-Plattformen hier eine Möglichkeit liefern, auch über deren integriertes Toolset.
Die haben Marktplätze zum Beispiel dabei, die großen Plattformen.
Dass wir hier tatsächlich auch einen Schub für EVA-Leistungen bekommen, die auf diesen Plattformen umgesetzt sind, sodass wir...
Das ist keine allgemeingültige Lösung, natürlich nicht, aber dass man tatsächlich viele Leistungen, die hier ein Anbieter, eine Verwalter, eine Verwaltung umsetzt, dann auch anderen Verwaltungen zur Verfügung stellen kann, und zwar auch auf dem Weg, der update-sicher ist, der transparent ist, soweit das hier mit den proprietären Plattformen geht.
Und dass da dann tatsächlich auch die Mehrwerte, die man sich von Eva mal versprochen hat, auch tatsächlich realisiert werden können.
Ich glaube, das ist ein Thema, das ist noch so ein bisschen, vielleicht nicht unbekannt, aber das ist etwas, was man vielleicht hier bei diesen Low-Code-Plattformen noch nicht so sieht.
Aber das bringen die auf jeden Fall mit. Es setzt natürlich voraus, dass da die Verwaltungen dann dementsprechend auch diese Low-Code-Plattformen im Einsatz haben.
Aber da setze ich tatsächlich meine Hoffnungen rein, dass wir da eine Beschleunigung oder eine bessere Verbreitung von EVA-Leistungen hinbekommen.

Nina:
[57:36] Es ist auch tatsächlich ein Ziel, das wir mit unserem Shift-Studio von Anfang an verfolgt haben.
Es ist vielleicht einfacher, weil es No-Code ist, aber diese Prozesse können zwischen Städten, die das Studio nutzen, geteilt werden.
Und dann eben dadurch, dass es so einfach zu verändern ist, kann jede Stadt es wieder anpassen, weil erfahrungsgemäß macht jede Stadt jeden Prozess ein bisschen anders.
Was dafür oder auch für generell für diese Austauschbarkeit, finde ich, extrem wichtig wäre, wäre dieser Schritt davor, eine Möglichkeit zu haben, vielleicht irgendeine Form von Plattform, wo Kommunen ihre dokumentierten Prozesse austauschen können.
Weil was jetzt gerade passiert im Bereich, alle die anfangen mit, oh, wir müssen unsere Prozesse digitalisieren, dafür müssen wir wissen, wie sie ablaufen, dafür müssen wir sie dokumentieren, ist dasselbe wie am Anfang bei UZG, 11.000, Kommunen machen sich jetzt auf den Weg, ihre Prozesse zu erheben, abzubilden, zu gucken, wie sollten sie eigentlich laufen, um sie dann zu digitalisieren.
Das heißt, das passiert gerade wieder, dass alle dieselbe Arbeit immer wieder machen.

Zehra:
[58:39] Da haben wir was in der Mache.

Nina:
[58:41] Wirklich?

Zehra:
[58:42] Ja.

Nina:
[58:42] Das klingt sehr gut. Können wir uns dazu austauschen? Weil ich möchte so eine Plattform so dringend.

Zehra:
[58:48] Also wir wollen die auch nicht selber bauen. Ich weiß nicht, wie oft ich schon dazu sprechen darf, weil das ist alles noch so ein bisschen im Entstehen.
Aber wir sind da im Austausch mit jemandem, der schon so etwas hat, auch aus Verwaltung.

Aufbau einer Verwaltungs-Community

[59:01] So eine Art Community, die wir da ins Leben rufen wollen.
Jetzt nicht das, was Hannes eben meinte mit der Next Community, das ist noch mal was anderes, sondern hier wirklich eine Community aufzubauen für Verwaltung, damit sie eben ihre Fachverfahren und das dann auch nicht nur mit Modul F, sondern idealerweise auch mit anderen Herstellern erstellte Lösungen austauschen können, wo sie sich auch zu Prozessen austauschen können und einfach mal sagen können, guck mal, das habe ich so gemacht, best practices etc.
Das ist so ein bisschen die Idee. Da ist was in der Mache, da ist was in der Entstehung und nächstes Jahr wollen wir das damit auch schon schrittweise loslegen.
Aber der Aspekt, den sowohl Hannes als auch Nina hier noch mal genannt haben, ist super, super wichtig. Und das Potenzial ist so groß.
Dieses «Ich kann etwas, was woanders schon entstanden ist, das muss ich halt nicht noch mal neu machen.
Ich kann es einfach nachnutzen.» Und das bietet Low-Code, glaube ich.
Wenn man immer dieselbe Plattform einsetzt oder mehrere oder ähnliche Plattformen häufiger zum Einsatz kommen, dann glaube ich, ist hier ein ganz ganz großes Potenzial gegeben.
Und selbst wenn nicht, bin ich trotzdem der Meinung, dass hier ein großes Potenzial gegeben ist, weil ich einfach ganz anders an Lösungen herangehe, prozesshafter an Lösungen herangehe.
Und allein dieses Prozesswissen auszutauschen, ist schon super super wichtig.

Nina:
[1:00:23] Städte sind nicht allein. Es gibt viele davon. Sie können einander helfen.

Torsten:
[1:00:28] Ja, das ist doch ein hervorragendes Wort zum Abschluss. Vielen Dank, liebe Sarah, lieber Hannes, liebe Nina, danke, dass ihr da wart und liebe Zuhörerinnen und Zuhörer, an euch vielen Dank fürs Zuhören und bis zum nächsten Mal.

Hannes:
[1:00:42] Dankeschön.