One Click Away Web – Web ohne Hürden

One Click Away Web – Oder wenn das Web instantan wird

Das Web hat viele Vorteile. Vorteile, die es groß gemacht haben.

Aber etwas, was die native App, vor allem auf dem Smartphone, zu einem “Killer-Software-Event” hat werden lassen, hat das Web nicht. Noch nicht bzw. nicht vergleichbar: Den ‘One Click Away’-Aufruf.
Gerade auf einem mobilen Device ist die “Entfernung” zum Nutzer “konversiv” und entscheidend.

Anzeige eines Installationshinweises in der PVA App, nachdem der Nutzer den Installationsbutton geclickt hat (Chrome unter OSX)

Instantanes Web

Die native App ist heute deutlich instantaner, als das (Mobile) Web. Ein Grund dafür ist der einfache und schnelle, wenig disruptive Zugriff.

Dieser “One Klick Away-Vorteil” hat, neben anderen Aspekten, dem Web die Vormachtstellung auf dem Smartphone gekostet. Nachdem nun auch die Nutzung des Smartphones seit längerer Zeit die Nutzung aller anderen Devices überflügelt, hat damit die native App das Web generell überholt.

Mit dem neuen, alten progressiven App-Ansatz des Webs könnte dieser Nachteil einer ansonsten so überzeugenden, fast konkurrenzlosen Technologie unter Umständen wieder kompensiert werden. Die Vorteile des Web und der nativen Anwendung werden “fusioniert” (wenn die GAFAS ‘mitspielen’ und/oder der Regulator vorgibt, wie gespielt wird).

Studien über progressive Web Apps stützen meine/diese Hypothese. Wenn das Web wieder näher zum Kunden rückt, dann steigt auch die Nutzung und Conversion Rate, so die Hypothese einiger Experten.

Auch wenn die Entwicklung von Progessiven Webapps (langsame) Fortschritte macht (wie auch in meinen letzten Posts dokumentiert), wichtige Fragen bleiben offen; unter anderem:

Wie bringe ich den Kunden/Nutzer dazu, meine Webseite als Web App zu installieren?

Dafür habe ich heute eine interessante, kleine Komponente mitgebracht – Die PWA Install Komponente des durchaus interessanten Microsoft PWA Builder Programms.

Wie man dem Screenshot zu Beginn des Posts entnehmen kann, können mit dieser Komponente und wenig Code informative und attraktive Installationsbuttons- und Hinweise in Web Anwendungen eingebunden und angezeigt werden.

Die PWA Install Komponente als Web Component eingebunden in die PVA App:

<pwa-install
        installbuttontext="Installation"
        explainer="Die PVA Demo App vereinigt und testet neue PVA Features."
        iosinstallinfotext="Öffnen Sie PVA im Safari Browser. Clicken Sie den 'Share Button'. Mit '+ Zum Homebildschirm hinzufügen' installieren Sie die PVA."
        descriptionheader="Die PVA Demo App vereinigt und testet neue PVA Features. Diese arbeitet im Offline Modus. Bietet Installationsroutinen/hinweise an und optimiert das native Aussehen und 'Feeling'. Zur PVA App existiert auch ein gleichnamige Github Projekt."
      ></pwa-install>

Apple wird sich nicht ewig dem Druck der PWAs widersetzen

Die PWA Komponente unterstützt dabei die meisten gängigen Browser und funktioniert auch unter oder mit iOS, wie der nachfolgende Screenshot dokumentiert.

Sicherlich ist das Installationserlebnis noch nicht vergleichbar mit Android, OSX oder Windows, aber der Nutzer wird auch hier einen Schritt näher zur Installation heran geführt.

Ist die Anwendung erstmal auf den Homeschirm des iPhones installiert, unterscheidet sich das Erlebnis kaum von Android oder anderen Betriebssystemen.

Wie immer findet ihr den Beispielcode im entsprechenden Github Projekt bzw. ist die PVA App auch online aufrufbar.

Links

PVA App – https://pva.mobinauten.de/

PVA Github Projekt – https://github.com/mobinauten/pva (gerne mitmachen!)

“We always overestimate the change that will occur in the short term and underestimate the change that will occur in the long term.” (Bill Gates)

Wie das Web verschwindet!

Wie das Web – wie wir es kennen – verschwindet

Mit meinem ersten Blog Post habe ich über die grundsätzlichen Möglichkeiten von PWAs berichtet. Der zweite Eintrag beschreibt dann einige, konkrete optische Möglichkeiten unter iOS. Gerade Apple wird ja “vorgeworfen”, PWAs nicht ausreichend zu unterstützen. Individueller Code hilft hier aber oft.

In diesem Kontext gehe ich heute auf PWAs auf dem Desktop ein, am Bespiel einer PWA unter OSX. Hier verhält sich Apple, anders als unter iOS, weitestgehend standard-konform (solange nicht Safari genutzt wird).

Installieren, starten, suchen und finden

Mit Hilfe des Chrome Browser, welchen vermeintlich auch jeder Apple Nutzer installiert hat, lassen sich auch PWAs, wie native Anwendungen, installieren, starten, suchen und finden.

Siehe auch dieser Screenshot meiner PWA PVA App auf meinem Macbook.

Dazu reicht es, die notwendige Manifest-Datei entsprechend zu erstellen und pflegen. Die Manifest-Datei der PVA App sieht z.B. wie folgt aus:

{
  "short_name": "PVA App",
  "name": "Progressive Versicherung App",
  "icons": [
    {
      "src": "favicon.ico",
      "sizes": "64x64 32x32 24x24 16x16",
      "type": "image/x-icon"
    },
    {
      "src": "logo192.png",
      "type": "image/png",
      "sizes": "192x192"
    },
    {
      "src": "logo512.png",
      "type": "image/png",
      "sizes": "512x512"
    }
  ],
  "start_url": ".",
  "display": "standalone",
  "theme_color": "#ffffff",
  "background_color": "#ffffff"
}

Mehr zu PWA Manifest Dateien findet man auch hier.

Die Standard-Installation – klein und versteckt

Mit einer validen Manifest Datei (was über die Chrome Developer Tools auch verifiziert werden kann) und einem HTTPS-Aufruf in Chrome erscheint dann auch der entsprechende Installations-Marker in der Browser Zeile.

Wenn meine PVA App aufgerufen wird, sieht das z.B. wie folgt aus:

Die PVA App im Chrome Browser erkennt eine PWA und bietet die Installation an.

Wird das entsprechende “Plus-Icon” vom Anwender geklickt, öffnet sich der Installationsdialog – wie auf nachfolgendem Bild markiert.

Nach der Auswahl der Installation, ist die PVA als native App (PWA) installiert und kann, wie alle anderen nativen OSX Apps, gesucht, gefunden, aufgerufen und entsprechend verwaltet werden.

Die Installations-Hinweise im Chrome Browser sind für Nicht-Kenner/-Wissende nicht wirklich auffällig und gleichzeitig aussagekräftig, so dass der Nicht-Experte wahrscheinlich selten auf die Idee kommen wird, eine PWA über diesen Weg zu installieren.

Die individuelle Installationshilfe – jetzt aber mal richtig und deutlich

Dafür aber existiert eine Abhilfe. Mit ein wenig Code (siehe unten beigefügt) lässt sich ein eigener Button, ein Link oder Ähnliches erstellen und beliebig platzieren . Dieser kann dann Nutzer, prominent oder weniger prominent, auf eine Installation hinweisen.

Das könnte dann wie hier in diesem Screenshot aussehen, aber auch beliebig anders. HTML und CSS sind hier kaum Grenzen gesetzt.

PVA mit eigenem Installationsbutton

Ein Klick auf diesen Installationsbutton aktiviert dann die Standard-Installation (analog zu dem “Browserleisten-Plus-Icon”).

// Install Button für non-IOS und Mobile 
let deferredPrompt;
const addBtn = document.querySelector('.add-button');
addBtn.style.display = 'none';
window.addEventListener('beforeinstallprompt', (e) => {
  e.preventDefault();
  // Stash the event so it can be triggered later.
  deferredPrompt = e;
  // Update UI to notify the user they can add to home screen
  addBtn.style.display = 'block';

  addBtn.addEventListener('click', (e) => {
    // hide our user interface that shows our A2HS button
    addBtn.style.display = 'none';
    // Show the prompt
    deferredPrompt.prompt();
    // Wait for the user to respond to the prompt
    deferredPrompt.userChoice.then((choiceResult) => {
        if (choiceResult.outcome === 'accepted') {
          console.log('User accepted the A2HS prompt');
        } else {
          console.log('User dismissed the A2HS prompt');
        }
        deferredPrompt = null;
      });
  });

Dieser hier gezeigte Javascript Code aktiviert den oben markierten Button auf den Plattformen, auf welchen dieser Weg möglich ist (OSX, Windows und auch Android – somit eigentlich alle wichtigen Desktop-Systeme).

Der Installations-Button wird auch nur angezeigt, wenn die PVA noch nicht auf der Plattform installiert ist. Auch hier kann man dann mit entsprechenden Mechanismen, ähnlich wie bei dem iOS Installationshinweis aus meinen zweiten Blog Post “spielen”, um User nicht zu häufig zu penetrieren.

Selbstverständlich kann die App dann auch wie eine App im Dock abgelegt werden.

PVA als Icon im Dock

Mit guten Beispiel voran

Obwohl der Weg zu einer PWA für den Nicht-Experten ohne konkrete Installationsunterstützung doch noch etwas versteckt und damit weniger nutzbar erscheint, PWAs als solches auch noch einen experimentellen Status genießen, gibt es schon interessante Beispiele und prominente Anwendungen

Zwei davon sind Twitter und Google Maps. Beide hätte ich als native App wahrscheinlich nie installiert bzw. habe diese immer über einen Browser-Link aufgerufen. Mit dem PWA Ansatz wird die Nutzung von Web-Anwendungen m.E. noch einfacher und unsichtbarer. Ich nutze Twitter und Maps nun nur noch als PWA.

Auf Wikipedia gibt es Hinweise einer 70% besseren Conversion-Rate für PWAs.

Google Maps als PVA
Twitter als PVA

Heute haben wir grundsätzlich nur auf OSX und Apple geschaut, aber ein kurzer Querscheck mit Windows macht deutlich, dass sich PWAs auf Windows unter Chrome und auch EDGE sehr ähnlich, wenn nicht sogar identisch verhalten. Und ohne dass plattform-spezifischer Code verwendet wurde. Das macht Hoffnung.

Windows werden ich mir auch noch separat anschauen.

Der Code ist wie immer in Github zu finden. Die aktuelle PVA Anwendung via Link aufrufbar.

Links

PVA App – https://pva.mobinauten.de/

PVA Github Projekt – https://github.com/mobinauten/pva (gerne mitmachen!)

“We always overestimate the change that will occur in the short term and underestimate the change that will occur in the long term.” (Bill Gates)

Die Schönheit des neuen Mobilen Web

Mit meinen ersten Blogbeitrag zu dem Thema PWA in der Versicherungswelt und dem Start eines entsprechenden Github Projektes (“PVA”) habe ich meine “persönliche Journey” in die neue Welt des “Offline Web”, der PWAs gestartet.

Heute bin dabei ich über zwei Features gestolpert, die PWAs, “meine PVA” m.E. auf einem iPhone ‘richtig gut’ aussehen lassen:

Splashcreens für deine wahre Identität im Web

Splashscreen der PVA App beim Laden

Rechts seht ihr den Splashscreen der upgedateten PVA. Normalerweise zeigen PVAs, anders als auf Android, keinen Splashscreen (gesteuert über die Manifest Datei) an.

Wenn eine PWA im installierten Mode länger laden muss (was sicherlich häufiger vorkommt), entweder aus dem lokalen Cache/Datenbanken oder über das Web, dann zeigt das iPhone einfach nur einen “nackten Bildschirm” in der definierten Hintergrundfarbe an.
Ein unschönes Erlebnis, welches aber mit ein paar Handgriffen “gefixed” werden kann.

Im Header der Startseite, üblichweise in einer index. html, müssen für die verschiedenen Formate des iPhones entsprechende Splashscreens als Image hinterlegt werden.

Nachfolgender Code aktiviert die Spashscreens für iOS, welchen ihr gerne per Copy& Paste kopieren könnt. Da es natürlich ein “Hassle” ist, die vielen entsprechenden Images zu manuell zu erzeugen, gibt es auch hier Abhilfe.

  <link href="%PUBLIC_URL%/splashscreens/iphone5_splash.png"
    media="(device-width: 320px) and (device-height: 568px) and (-webkit-device-pixel-ratio: 2)"
    rel="apple-touch-startup-image" />
  <link href="%PUBLIC_URL%/splashscreens/iphone6_splash.png"
    media="(device-width: 375px) and (device-height: 667px) and (-webkit-device-pixel-ratio: 2)"
    rel="apple-touch-startup-image" />
  <link href="%PUBLIC_URL%/splashscreens/iphoneplus_splash.png"
    media="(device-width: 621px) and (device-height: 1104px) and (-webkit-device-pixel-ratio: 3)"
    rel="apple-touch-startup-image" />
  <link href="%PUBLIC_URL%/splashscreens/iphonex_splash.png"
    media="(device-width: 375px) and (device-height: 812px) and (-webkit-device-pixel-ratio: 3)"
    rel="apple-touch-startup-image" />
  <link href="%PUBLIC_URL%/splashscreens/iphonexr_splash.png"
    media="(device-width: 414px) and (device-height: 896px) and (-webkit-device-pixel-ratio: 2)"
    rel="apple-touch-startup-image" />
  <link href="%PUBLIC_URL%/splashscreens/iphonexsmax_splash.png"
    media="(device-width: 414px) and (device-height: 896px) and (-webkit-device-pixel-ratio: 3)"
    rel="apple-touch-startup-image" />
  <link href="%PUBLIC_URL%/splashscreens/ipad_splash.png"
    media="(device-width: 768px) and (device-height: 1024px) and (-webkit-device-pixel-ratio: 2)"
    rel="apple-touch-startup-image" />
  <link href="%PUBLIC_URL%/splashscreens/ipadpro1_splash.png"
    media="(device-width: 834px) and (device-height: 1112px) and (-webkit-device-pixel-ratio: 2)"
    rel="apple-touch-startup-image" />
  <link href="%PUBLIC_URL%/splashscreens/ipadpro3_splash.png"
    media="(device-width: 834px) and (device-height: 1194px) and (-webkit-device-pixel-ratio: 2)"
    rel="apple-touch-startup-image" />
  <link href="%PUBLIC_URL%/splashscreens/ipadpro2_splash.png"
    media="(device-width: 1024px) and (device-height: 1366px) and (-webkit-device-pixel-ratio: 2)"
    rel="apple-touch-startup-image" />

Auf dieser Webseite könnt Ihr Euch sowohl die passenden Splashscreen-Größen generieren, wie auch das passende HTML für das Head Tag. (https://appsco.pe/developer/splash-screens). Tolles Angebot, funktioniert prima.

Statusbars für die vollendete Schönheit

Ein weiteres, schönes, etwas kompliziertes, weil unter iOS noch nicht vollständig umgesetztes Feature ist der “echte Fullscreen”.

Auch die erste Version der PVA App verfügte auch schon unter iOS über einen Fullscreen.

Neue Version mit Status Bar in App Farbe
Alte Version PVA mit Standard Status Bar

Leider war die Status Bar dabei nicht in der Farbe der App, sondern nur Standard Schwarz (siehe rechter Screen).

Man kann nicht alle Farben für eine Toolbar setzen, aber mit diesem Code Snippet übernimmt (content="black-translucent“) die Status Bar auch die Farbe der App bzw. des im Manifestes gesetzten Hintergrundes (linker Screen).

Und schon ist die PWA wieder ein “weiteres Stückchen an eine “echte native App heran gerückt.

<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">

Der Code ist im Github Projekt eingescheckt bzw. die PVA App auch upgedatet.

Denkt bitte daran, den Safari Cache zu löschen, bevor ihr die neuen Features ausprobiert.

Links

PVA App – https://pva.mobinauten.de/

PVA Github Projekt – https://github.com/mobinauten/pva (gerne mitmachen!)

“We always overestimate the change that will occur in the short term and underestimate the change that will occur in the long term.” (Bill Gates)

Die App ist tot! Es lebe die PVA – Die Progressive Versicherung App

Wie Versicherungen das “verlorene App Jahrzehnt” aufholen können – jetzt!


PVA App als native Anwendung auf einem Macbbook mit Google Chrome und OSX als Trägertechnologien

Versicherungen und ihre digitale Kunden-Anwendungen waren selten, im Gegensatz zu Banking-Apps und Banking-Web-Anwendungen, eine attraktive, eine erste Wahl.

Wenig Funktionalität wurde im Online Bereich angeboten. Ein Grund, warum eine regelmäßige digitale Interaktion wenig interessant erschien, noch heute teilweise ist.

Noch nachteiliger wirkte sich für Versicherungen dann das “Jahrzehnt der App Revolution” aus. Zwar hatten Versicherer inzwischen mit mehr Funktionalität und eigenen Portalen ‘gepunktet’ und damit eine digitale Interaktion mit ihnen attraktiver gemacht. Allerdings reichte dieser Fortschritt nicht aus, um den Verdrängungswettbewerb der Apps auf den mobilen Devices der Kunden zu kompensieren.

Die digitale Kommunikation wurde vom Web auf Apps umgelenkt und nur hoch frequentierte Apps fanden und finden ihren Platz auf dem mobilen Device der Kunden.

Waren die Versicherer schon “spät im Internet und Web unterwegs”, die App und ihr technologischer Vorteil und Komfort verdrängte sie nun fast völlig.

Die Karten werden neu gemischt

Das könnte sich nun ändern.

Mit neuen Web Standards und Technologien und deren Anwendung, nicht nur für Desktop Browser, sondern auch für iOS und Android, lassen sich die Errungenschaften des Web und der Apps kombinieren. Dieser “Mix” kann gerade für seltener frequentierte Anbieter Vorteile bieten – ‘das Web’ nennt diese neue Form der Anwendung und Architektur PWA – Progressive Web App.

Welche Vorteile bieten PWA?

Neben vielen anderen vor allem diese:

  1. Der Kunde kann diese Anwendungen ohne Appstore finden und installieren – ein Browser und ein Link, empfangen via Email, Whatsapp oder SMS ist ausreichend
  2. Der Versicherer kann dem Kunden die Anwendung über diverse Kommunikations-Kanäle einfach zukommen lassen; der Kunde kann diese sowohl im Web, als auch auf dem Handy sofort als Web Anwendung oder dauerhaft mit einem Click als native App installieren und nutzen. Hürden, diese Form von Anwendung zu nutzen, sind vermeintlich gering bis kaum vorhanden
  3. Die App hat eine ähnliche Leistungsfähigkeit wie herkömmliche, native Anwendungen zu deutlich geringeren Entwicklungs- und Bereitstellungskosten mit maximalen Freiheitsgraden (im Gegensatz zu streng kontrollierten App Stores) und einer hohen Plattformunabhängigkeit:
    -> PWAs sind trotz purer und plattform-neutraler Web Technologien “Offline-First Citizen”
    -> PWAs sind, wie native Apps, installierbar und können auf dem Home Bildschirm eines Handys oder eines Desktops hinterlegt werden
    -> PWAs können Push-Nachrichten erhalten, verfügen über Datenbanken und vieles, was wir sonst nur aus der nativen Welt kennen

“Machen ist wie wollen, nur krasser!”

Um die Stärke einer PWA zu verifizieren und zu demonstrieren habe ich ein übersichtliches Github Projekt ins Leben gerufen, welches ich nach und nach erweitern und ergänzen möchte.

Die aktuelle Version der PVA App, die auch über diesen Link aufgerufen bzw. auch über Github “gebaut”, geändert und installiert werden kann, proto-typisiert erste, wesentliche Features.

Diese sind anbei per Screenshot dokumentiert, aber auch direkt über Code und Link verfügbar.

Beim Laden installieren – Yes, please!

Beim Laden der Anwendung über den Browser wird eine native Installation angeboten.

Je nach Device verläuft die Installation unterschiedlich, führt aber im Grunde zu dem gleichen Ergebnis. Die Anwendung ist über den Homebildschirm über ein eigenes Icon verfügbar.

Links ist die Installation über den Safari Browser dargestellt. Der User wird über entsprechende Schritte instruiert, die App zu installieren.

Nach einer Installation erscheint der Hinweis nicht mehr bzw. auch, wenn die der User den Hinweis ignoriert.

Im Chrome Browser auf Android Geräten oder auf anderen Devices ist die Installation weitergehend automatisiert (wird in einem weiteren Beitrag behandelt).

PVA auf dem Home Bildschirm – What else?

Rechts der Screenshot zeigt meinen iPhone Homebildschirm nach der Installation der PVA Anwendung.

Die App ist visuell nicht von anderen, nativen Apps zu unterscheiden.

PVA kann, wie andere native auch, verschoben und gruppiert werden.

Der Aufruf und das Öffnen unterscheidet sich nicht von einer nativen App, vor allem dann, wenn diese grundsätzlich auch für Offline verfügbar ist.

Favicons und App Icons sind so selbstverständlich, wie auch individuelle Splash Screens.

PVA App als Icon auf iPhone Desktop
iPhone mit PVA App standalone

Wie eine App, ist eine App! Offline? Sure!

Linker Screenshot zeigt die PVA Demo App – nach Installation auf dem Device – als eigenständige App geöffnet.

Der Browser und die HTML Technologien sind als solches nicht mehr direkt identifizierbar.

Die App sieht aus (kein Browser-Rahmen, keine Browser Navigation), startet und lässt sich wie eine native App bedienen.

Dabei ist diese auch aufgrund ihrer Offline- und Caching-Fähigkeiten schnell und responsive (siehe auch gelb markierte Offline-Situation meines iPhones).

Links ist die PVA App auf einem iPhone dargestellt, aber ein vergleichbares Verhalten findet man auch auf Desktop Systemen, wie z.b. bei einer Kombination aus Apple OSX und Chrome (oben zu Beginn des Blogpost dargestellt).

PVA App als Github Projekt – der Sandkasten zum “Spielen und Selber-bauen”

“Machen ist wie Wollen, nur krasser” Frei nach diesem Motto habe ich es mir in der Vergangenheit und als “in die Jahre gekommener Entwickler” immer zu eigen gemacht, Neuerungen nicht nur “zu erlesen”, sondern auszuprobieren, zu coden.

Denn nur im Code findet man die Wahrheit!

Auch diesmal werde ich den enstprechenden Code in einen Github Projekt ablegen.

Nicht nur, weil ich glaube, dass dieses “Verifizieren” in Summe länger dauern und auch immer umfangreicher werden könnte. Eventuell wollen andere Zeitgenossen entsprechend partizipieren. “Schwarm-Intelligenz” ist ja bekanntlich die effizienteste. 🙂

Und wo kann man das besser und gemeinsamer, als in und über Github?

Der PVA Sandkasten bei Github

More to come!

Momentan kann die App nur die Hauptnavigation anzeigen. Dafür ist der Code aber übersichtlich und verdeutlich die wesentlichen Features: Installier-barkeit und Offline. Einfach mal ausprobieren.

Aber das ist mit Sicherheit nicht das Ende. Ideen gibt es genug:

-> Wo kann man PWAs einsetzen?

-> Wie, und für welche Prozesse?

-> Offline mit PWAs schreiben, wie, wann, wo?

Links

Die PVA App zum direkten Ausprobieren – https://pva.mobinauten.de/

Das PVA Github Projekt – https://github.com/mobinauten/pva

Das Beste beider (Versicherungs-) Welten

Arbeiten in einem der größten #Insurtech der Welt – Wer die Zukunft gestalten möchte, muss die Geschichte verstehen!

Im Laufe meiner 30 Jahre im Beruf habe ich nicht nur einige Zeit mit Startups verbringen, sondern auch drei mit gründen dürfen.

Während dieser Zeit habe ich mich oft gefragt, wie kann der Spirit, der “Hunger” und die Motivation eines Gründer-Teams mit der Stabilität, dem Wissen, der Sicherheit und Reife eines Cooperates verbunden werden?

Viele Versuche in diese Richtung habe ich beobachten dürfen, erfolgreiche und weniger erfolgreiche, das Netz ist voll mit Ideen und Ansätzen, aber noch keine ähnlich vergleichbare Symbiose, wie die des aktuellen P&C Transformations-Programmes der AXA Deutschland.

Dieses Programm macht (fast) alles neu und anders; bietet somit viele Chancen und Herausforderungen eines #Insurtech, baut aber auf den soliden Wissens-, und Risikosäulen, Fertig- und Fähigkeiten eines erfolgreichen Versicherungsunternehmens auf.

In a Nutshell “baut” Polaris eine neue Versicherung innerhalb einer traditionellen Versicherung und modernisiert dabei nicht nur technologisch, sondern auch organisatorisch und kulturell – alles gleichzeitig und parallel; unmutig kann man das nicht nennen.

Core System Modernisierung

Einführung eines neuen SUH Core Systems neben neuer Produkte und Prozesse, die “Digitale Echtzeitversicherung”.

Ohne die Core System Entwickler Rolle, welche nicht nur moderne Programmiersprachen beherrschen muss, sondern auch Interesse an Fachlichkeit und Versicherungen haben sollte, werden wir langfristig keinen Erfolg haben.

Cloud Native

Alles, was wir tun, machen wir mit der “Cloud im Rücken und im Kopf”. Zum Ende des Projektes wird nicht nur das Moderne Digitale Versicherungssystem unser Ergebnis sein, sondern auch die Art und Weise, wie wir entwickeln und betreiben – die Cloud Engineer Rolle ist und wird damit eine fundamentale.

API First

One Truth – Unsere neuen Services und Produkte wollen wir in Echtzeit überall, gleichzeitig und über alle notwendigen und gewünschten Kanäle zur Verfügung stellen, damit wir andere Ökosysteme, wie z.b. Bank-Ökosysteme unterstützen oder eigene aufbauen können – APIs und modernste API Technologie sind hierbei unsere “Brückenbauer”, die API Entwickler Rolle eine kreativ innovative.

Frontend (R)evolution

Im Kontext der genannten Veränderungen wird auch unsere Frontend- und Channel-Architektur eine neue und bedeutende Aufgabe übernehmen. Die Frontend-Entwickler Rolle ist unser “Türöffner” in eine kundenzentrierte Welt, eine mit gewohnt horizontaler, aber auch neuer, vertikaler Bedeutung und Tiefe. Feature-Entwicklung ist für uns nicht nur ein Buzz-Word.

Agile Everywhere

Nicht nur, dass wir bereits die komplette Delivery-Chain auf Agile umgestellt und erste Erfolge haben verzeichnen dürfen, wir renovieren nun auch das komplette Programm-Management im Rahmen einer ganzheitlichen Agilen Transformation. Einen klassischen Programm-Manager kennen wir fortan nicht mehr.

Das Polaris Programm wird von dem Master Produkt Owner, dem Master Agile Master und einer umfangreichen Anzahl von Lead Produkt Ownern, Produkt Ownern und Scrum Mastern vertreten. Ich habe noch kein Startup oder traditionelles VU gesehen, welches in dieser Größenordnung die Agile Transformation lebt und erprobt. Hierbei bildet die Scrum Master und die Produkt Owner Rolle das Fundament.

Wir reden hier nicht nur über eine Blaupause oder eine Powerpoint Folie. Inzwischen haben wir mit der ersten Hälfte des Programmes erfolgreich beweisen können, dass wir liefern.

Nun beginnt die zweite Halbzeit mit neuen und noch größeren Herausforderungen. Wir würden uns sehr freuen, wenn Du dabei sein möchtest. Einen Auszug möglicher Rollen für Dich hoffe ich durch diesen Beitrag skizziert zu haben.

Schreib mir einfach eine Nachricht bei Interesse und/oder bewerbe Dich unter https://jobs.axa/careersection/1/moresearch.ftl?lang=de&portal=8105020509

Gerne können wir auch mal persönlich quatschen – wir freuen uns auf Dich!

P.S. Und wer mich kennt, weiß, dass ich das auch so meine, wie es hier geschrieben steht. Ich glaube, es gibt kaum einen anderen Ort in der Deutschen Versicherungswelt, wo jemand momentan mehr lernen und trotzdem abends noch nach Hause und das Wochenende auch Wochenende sein lassen kann – ganz im Sinne unserer verbundenen Welten 🙂

Protect with a Double Click

48 Hours with Apple Pay

I agree: In this case I am a Late Follower, but due to some serious tasks I couldn’t play around with gadgets and finance tech innovations I was used to before the last couple of months.

But because I’m longer in the Mobile Banking and Payment space than many of us here I would like to share my first 48h Apple (Watch) Pay experiences:

  1. Apple Pay is here to stay and to win. Within the last 48 hours I could pay everything and everywhere with my Apple Pay ING combination, often at places, where the people even didn’t know, that they could handle and accept Apple Pay.
  2. For nearly 20 years I’m talking about and trying out Mobile Payment, Apple Pay with its watch is the first true one, I can now feel, what we meant years and years ago.
  3. Sadly, but true: For all Apple Ecosystems customers and users I believe there’s no much room for The Second, Apple will very likely get ’em all.
  4. But I also believe Apple doesn’t (completely) hijack the Customer Experience and Interface. In my case ING and VISA are still very visible to me (see image below – I and my watch in the bathtub 🙂 ) and I still feel I’m paying with my bank account; the superb ING Mobile App is still the necessary counterpart for my watch. This is and stays – from my perspective – the chance for all banks!
    Apple will lead them into their app (I was wrong with earlier assumptions).

What if I once could also protect and insure via a Double Click, maybe also integrated into my Banking App and Apple Watch?

Seamlessly – Could be Customer Experience at its best.

I’m lazy I would give it a try.

Instant Delivery follows Instant Thinking

APIs will tell us why and how.

APIs show us the way how to prepare for the future and how to do digitalization right.

I’m often asked: ‘Let’s create some APIs for this system, that function or let us open our business via APIs!’

But developing new APIs on top of ‘something’ without considering all behind is the simplest part of the story.

The challenges are, compared with a huge Iceberg, often not seen (straight away).

And the chances aren’t often recognized either. APIs shouldn’t be just created for easy integration or cool UX.

APIs should been considered as a complete business and technology transformation program for your enterprise.

(Like detailed in the above infographic)

Wie eine 8 Jährige, Programmierende Grundschülerin die Zukunft Deutschlands retten wird

Die Pädagogische Kernschmelze

Nun sind wir schon eine Weile mit unserem Projekt “Programmieren in der Grundschule” unterwegs. Dabei haben wir viele Erfolge und einige Misserfolge für uns verbuchen können und müssen. Es geht weiter.  Auch die nächsten Schritte und Aufgaben sind entschieden, die Ziele weiterhin klar. Sind  wir mit unserem Projekt noch mit der Annahme gestartet, dass es grundsätzlich wichtig und richtig ist, für den Einzelnen und die Gesellschaft,  mehr Technologie in die Grundschule zu bringen, sind unsere Erkenntnisse und die Lage  inzwischen deutlich dramatischer. Wenn wir unsere Mädchen nicht mit Programmieren und Informatik in der 3ten und 4ten Klasse begeistern können, ist unser Land m.E. verloren. Warum meinen wir das? Während unseres Projektfortschrittes haben wir beobachten müssen, dass selbst junge, gerade examinierte Lehrerinnen (und damit ‘Digital Natives’) sowohl wenig Begeisterung, als auch wenig Kenntnisse mitbringen, um einen zukünftigen Ausbildungsauftrag “Programmieren in der Grundschule” erfolgreich umsetzen  zu können.

Ursachen

Woran liegt das unseres Erachtens:? Diese heutigen, jungen Lehrerinnen sind in ihrer frühen Kindheit und Jugend nicht mit einer Begeisterung für Technologie “angezündet” worden.  Als diese das erste Mal mit Informatik und Computern in Berührung kamen (üblicherweise in der 6/7ten Klasse), war es aus heutiger Perspektive bereits zu spät. Die Mädchen waren in der Pubertät. Computer und Programmieren waren als etwas verschrien, was “pickelige Nerds” ihr Eigen nannten,  aber nicht coole Mädchen oder Mädchen, die Jungen auf pubertierender Augenhöhe begegnen wollten.  “Der Zug” war damit bereits mit 13 oder 14 Jahren “abgefahren”.  Und da Frauen, und damit diese Mädchen von früher, den Großteil der Pädagogen in den Grundschulen stellen, “fahren wir alle auf einer tödlichen Rolltreppe abwärts”. Junge Mädchen werden nicht begeistert, werden keine begeisterten Lehrerinnen und begeistern wiederum keine jungen Mädchen und Jungen in der Grundschule. Das einfache Warten auf die jungen ‘Digital Natives’ (unsere Hoffnung bisher) wird nicht viel nutzen, so unser Glaube heute.  Der Zufall und das Engagement Einzelner, welches für den früheren Bedarf ausgereicht hat, wird nicht mehr den Bedarf von heute und morgen bedienen können

Maßnahmen

Was heißt das für uns? Wir müssen zwingend diesen negativen Kreislauf unterbrechen! Und das mit zwei Ansätzen: Langfristig – wir begeistern schon in der Grundschule die Mädchen für Informatik, damit die, die auch Grundschullehrerinnen werden, auch begeisterte Computer-Lehrerinnen werden. Kurzfristig – wir gehen in die Lehrerausbildung und versuchen hier mit Aufklärung und Verständnis, die vorhandene, negative Sog-Wirkung abzuschwächen. Unter Umständen auch damit, dass wir die Informatik-Ausbildung und die Pädagogik-Ausbildung über ausgesuchte, freiwillige Veranstaltungen  vernetzen. (Eine kleine “Gemüseorgel” auf Basis Calliope, die wir bei einem letzten Arbeitsessen in unserer “Programmieren-in-der-Grundschule-Taskforce” entwickelt haben und dabei vorhandene Tools in unser Experiment einbezogen haben 🙂 ) Programmieren in der Grundschule ist damit nicht mehr nur ein Wettbewerbsvorteil gegenüber anderen Schulen, Ländern und Kontinenten, es ist eine Überlebensstrategie. Inzwischen haben wir weitere, interessante Partner gewinnen können, die uns bei unserem Auftrag helfen werden. Gerne jederzeit melden, wenn jemand mit uns zusammen die Menschheit retten will. Wir werden  keine Umweltverschmutzung, keine Mangelernährung, kein Verkehrschaos, keine Flüchtlingskrise in dieser Welt in Zukunft ohne Software verhindern können…wir brauchen diese begeisterten Mädchen!

The PSD2 Shadow Effect

When Regulator says Open Your Data to the Banks, the Insurers have to listen

The new customer, the Digital Native wants to work digitally, wants to compare and wants usually all (basic) financial information in one digital view. His ‘Internet shaped  DNA’ doesn’t understand and in the long run will not tolerate offline traditions and patterns of classical incumbents, I assume. Two of these customer needs have already been the base of a lot of successful inventions and startups in the past years. All of us working in the insurance  sector know and respect the power of digital aggregators.  Since some years the customer can now work digitally and compare. What still wasn’t satisfied is the need of Consolidated Digital Views. Some startups in the last years tried to fulfill this requirement, with more or less average success. Far away from the success of implementing the Digital and Comparing Capability. But times might change now. The ‘Digital Insurance Folder Idea‘ gets a second chance with PSD2, I think.

Gone are the Days

With the PSD2 directive the regulator tells the banks to open their data. But not only open ‘their’ data, but to open a lot of customer data and subsequently also a lot of insurance data. Third Parties, Startups and also traditional incumbents can now satisfy the third basic need of the customer: The one place for all their insurance data. Automatically, with one click.  Gone are the days as  the customer had to manually add his insurance data into web interfaces or activate  long taking, in-transparent and risky manual data and account transportation processes. Gone are the days as the legal situation was unclear and consequences unpredictable. One might say it’s only the header data of the insurance contracts, but it’s an entry, a starting point. The days of the manual, error prone and complicated creation  of The  One View  are over now, if you ask me. With one click and some Machine  Learning in the background! Once the user has established a relationship with the new  or old Third Party (activating the new third capability by linking his bank accounts) the steps to Detail Data, Contract Management, Change and New Business are minor ones, I predict. In some years nobody will remember that one had to handle every insurance contract form different insurers differently. What this means in terms of customer relationship, interactions and loyalty everybody has to find out on his own. I’m just asking myself,  if the regulator really has understood that he also opened implicitly the insurer’s data, when he forced the banks to become more open? Were the insurers allowed to have had an opinion in advance?    

2019 – The Year of PSD2 Insurance

ExcecInsurtech 2018 – In a Nutshell

It was a pity that I couldn’t attend longer the brillant organized and inspiring ExecInsurtech 2018. But even with only the few bits I took with me I predict 2019 will be the year of PSD2 Insurance. I saw a lot of interesting solutions and ideas. On a high level these could be sorted into one of these three categories:
  1. PSD2-Aggregation – Creating Multi-Insurance- and Account-Views with the help of PSD2
  2. PSD2-Contract- and AccountManagement – Comparing and offering Insurance alternatives  with the help of PSD2 and KI
  3. PSD2-Advisor – Full-fledged full-automated Robo Insurance Advisor with the help of customer account- and transaction-information and KI
I am very curious, if these new technical and business capabilities will be accepted by the market and the customers.  And if and how these will then influence traditional  carrier relationships finally. Besides I also discussed Open Insurance compared to and in the context of PSD2. With the help of Friendsurance’s Sebastian we got a first  insight into and  impressions of how PSD2 insurance can work.

Masterclass PSD2 and OpenInsurance

Together with our classroom participants we discussed, if PSD2 derived Open APIs could also be a trend for insurance.  After the exchange of some  controversial views we answered the following polls: These polls and our classroom results are far from being representative. But with the solutions I saw at ExecInsurtech, the feedback I received and  the discussions I led I believe I see a trend. And an interesting question remained in the room: How should/could the existing and traditional world handle and react to it?