Um einen Militärkonflikt zwischen der Ukraine und Russland abzuwenden, wird damit gedroht, Russland vom globalen Finanzkommunikationssystem SWIFT auszuschließen. Die USA sind dabei, ein Gesetz zu konkreten Finanzsanktionen auf den Weg zu bringen. Aber warum hat die USA überhaupt so einen Einfluss auf SWIFT? Wie hart würde diese Sanktion Russland tatsächlich treffen? Und was würde das für Europa bedeuten?
Als Cyber Security- und SWIFT-Experte war Jan Oetting vom Consulting-Unternehmen Consileon in den letzten Wochen ein viel zitierter Interviewpartner in den Medien zu diesem Thema. So wurde seine Expertise zum Beispiel vom Spiegel, der WiWo der Tagesschau sowie vom Schweizer Rundfunk und Hessischen Rundfunk angefragt.
Hier erklärt er noch mal die wichtigsten Hintergründe und Zusammenhänge, um das Ausmaß der geplanten Sanktionen zu begreifen.
Entstanden als digitale Variante des schwarzen Bretts, bieten Mitarbeiter- oder Intranetportale heute einen zentralen, geschützten, einheitlich gestalteten Zugang zu unternehmensinternen Informationen und IT-Anwendungen. Die Einrichtung eines solchen Portals ist alles andere als trivial. Neben der Wahl der Informationen und Apps, die den Mitarbeitern zentral zur Verfügung stehen sollen, ist zu klären, wie das Portal technisch umgesetzt wird. Als Entscheidungshilfe stellen wir hier alternative Portalbaustile in ihrer historischen Entwicklung vor.
In der Frühzeit des Internets baute der Webserver die im Browser angezeigte Seite nach jeder Eingabe komplett neu auf. Dies trieb die Netzlast in die Höhe, führte zu Wartezeiten, die Interaktion verlief holprig. Abhilfe schuf das in den Nullerjahren entwickelte Datenübertragungsmodell AJAX (Asynchronous Javascript and XML), das nur geänderte oder zusätzlich aufgerufene Seitenelemente vom Server nachlädt. Dadurch verhalten sich moderne Webapps ähnlich wie lokale Desktop-Software. Mit Technologien wie AJAX wurden Intranetportale ohne spezielle Frameworks als eigenständige Webanwendungen (single web applications, SWA) entwickelt. Die Portalanwendung bildet dabei mit Benutzeroberfläche, Logik und Datenzugriffsschicht eine separate, in sich abgeschlossene Umgebung:
Die SWA vereint Funktionen und Informationen aus Verwaltungs- und Fachabteilungen in einer monolithischen Architektur. Entwickler haben dadurch bei der technischen Umsetzung freie Hand und unterliegen keinerlei architektonischen Vorgaben. Dem stehen jedoch einige Nachteile gegenüber. So fällt beispielsweise ein hoher Implementierungsaufwand an, da jede Funktion von Grund auf realisiert wird. Dabei sind in Absprache mit den Fachverantwortlichen auch ressortspezifische Anwendungsfälle abzubilden. Zudem hängen die Funktionen voneinander ab. Das macht Entwicklung, Wartung und Ausbau gleichermaßen aufwendig. Ist eine Funktion wegen Wartung abgeschaltet, fallen alle anderen Funktionen ebenfalls aus.
Um diese Nachteile zu entschärfen, entwickelte man sogenannte Portalcontainer, große Serversysteme, in deren Infrastruktur sich die Apps für die Mitarbeiter implementieren ließen. Außer etwaigen externen Datenquellen laufen dabei alle Apps auf dem Portalserver. Auch die Benutzeroberfläche wird komplett serverseitig berechnet und von dort zum Browser gesendet.
Oberfläche und Anwendungs- oder Businesslogik der am Portal angebotenen Apps werden getrennt voneinander auf dem Softwarestack des Portalservers entwickelt: Elemente der Benutzeroberfläche als wiederverwendbare Portlets, Datenzugriffs- und Logikkomponenten in Form ebenfalls mehrfach nutzbarer, über Standardschnittstellen eingebundener Javabeans. Große Portalserver wie IBM Web-Sphere basieren meist auf der Enterprise-Edition der Java-Plattform (JavaEE).
Den nächsten Evolutionsschritt des Portalcontainers markiert der Einbau einer SOA(= service-oriented-architecture/dienste-orientierte Architektur)-Schicht. Businesslogik und externer Datenzugriff sind hier nicht mehr im Container realisiert, sondern in eine Dienste-Architektur ausgelagert. Aufgerufen werden sie über einen Messagebus oder -broker. Die Portlets greifen nur noch über die standardisierte Schnittstelle des Busses oder Brokers auf die Businesslogik zu. Dieser verteilt die Nachrichten auf die Komponenten der Businesslogik oder speichert sie zwischen, falls eine Zielkomponente nicht erreichbar ist.
Gegenüber einer SWA weisen Portalcontainer mehrere Vorteile auf. Der Portalserver bietet eine Infrastruktur mit Standardfunktionen, darunter Single-Sign-On und Single-Sign-Out beim Portal sowie ein Rollen- und Rechtesystem. Der Server lässt auch die Einrichtung einer einheitlichen Benutzeroberfläche und eines Dashboards zu. In der SOA werden Funktionen aus Backend-Systemen zu operativen Diensten verknüpft. Diese lassen sich per Lastverteilung skalieren und vom einzelnen System ein
Stück weit entkoppeln. Zudem sind sie wiederverwendbar. Mehrere Apps oder komplexere Dienste können sich auf dieselbe SOA-Ressource stützen. Durch ihre Abstraktion in der SOA-Schicht werden Businesslogik und Backend-Funktionen plattformneutral. Dadurch ist es möglich, die SOA-Dienste in verschiedenen Sprachen zu programmieren. Die Kommunikation mit und unter den Diensten läuft über Schnittstellen.
Doch auch Portalcontainer haben Schwächen. Fällt der Container aus, geht das ganze Portal vom Netz/offline. Ausfallsicherheit und Skalierung sind nur durch Vorhalten mehrerer Instanzen des gesamten Servers zu leisten. Vor Zwangspausen schützt die Modularisierung der Apps also nicht. Zwar erleichtert sie die Arbeitsteilung unter den Entwicklern, das Grundgerüst der Portalarchitektur bleibt jedoch monolithisch und damit wenig wartungsfreundlich. Überdies besteht eine starke Abhängigkeit vom Hersteller des Portalservers (Lock-In-Effekt). Dies betrifft zum einen (Sicherheits-)Updates, zum anderen die zwangsläufige Festlegung auf die Programmiersprache der proprietären Schnittstellen des Servers. Die Migration der Apps auf Portalserver anderer Anbieter wird dadurch riskant und äußerst aufwendig. Aus demselben Grund lassen sich bereits vorhandene Anwendungen/Altanwendungen ebenfalls nur mit hohem Aufwand in den Portalcontainer migrieren.
Um die Nachteile der immer noch recht monolithischen Portalserver auszugleichen, tendiert man heute zu einer leichteren Architektur auf Basis sogenannter Microservices. Ein Microservice ist eine autarke Software, die einen monofunktionalen Dienst leistet. Durch Verknüpfung beliebig vieler Microservices entstehen multifunktionale Apps. Einmal implementiert, lässt sich ein Service in mehreren Apps einsetzen.
Die Kunst liegt bei der Microservice-Architektur darin, die Services so zuzuschneiden, dass die daraus aufgebauten Apps nicht zu komplex werden. Insbesondere darf die Funktion eines solchen Bausteins nicht zu eng gefasst sein. Vielmehr sollte jeweils ein Service eine abgrenzbare Funktion realisieren. Das Frontend des Portals kann dabei wahlweise auf dem Server oder am Client gerendert werden.
In beiden Fällen werden das Portal, die dort angebotenen Apps und die jeweiligen Oberflächen als eigenständige Module entwickelt. Beim serverseitigen Rendern kommen Webframeworks wie Apache Wicket, JSF oder Spring MVC zum Einsatz. Zum clientseitigen Rendern verwendet man Frameworks auf ECMAScript-Basis wie Angular, React oder Vue. Rendern am Client führt zu einer durchweg schnellen Reaktionszeit der Seiten.
Zu den Stärken der Microservice-Architektur zählen ihre Modularität, Skalierbarkeit, Wartungsfreundlichkeit und Resilienz: Weil Microservices schnell programmiert und wiederverwendbar sind, lassen sich daraus mit geringem Aufwand Apps komponieren, erweitern oder umbauen. Dieser Baustil verträgt sich gut mit einem agilen Vorgehensmodell. Die Services sind unabhängig voneinander skalierbar. In mehreren Apps verwendete oder besonders häufig aufgerufene Bausteine können in mehr Instanzen bereitgestellt werden als selten eingesetzte. Und weil jeder Micro-service nur eine Funktion abbildet, ist er klein genug, um von Entwicklern verstanden, gewartet oder ersetzt zu werden. Die Resilienz der Microservice-Architektur zeigt sich als hohe Verfügbarkeit und Ausfallsicherheit durch Verteilung der Instanzen auf mehrere Server. Das Ausfallrisiko wird bei der Implementierung berücksichtigt. Bei seinem Eintritt springt eine andere Instanz ein, die App läuft weiter. Dank seiner Kapselung kann man theoretisch jeden Microservice in einer anderen Sprache programmieren. Der Datenaustausch unter den Services läuft über standardisierte, sprachneutrale Schnittstellen.
Wie die älteren Portalmodelle, so hat auch die Micro-service-Architektur ihre Schattenseiten. Diese ergeben sich aus der großen Zahl der Services. Gegenüber einem Portalcontainer steigt wegen der Kommunikation zwischen den Services die Netzlast und -latenz. Außerdem nimmt die Komplexität jedes Systems mit der Zahl seiner Komponenten zu. Auch wenn Micro-services separat nutzbare Softwarebausteine bilden, ist es trotzdem erforderlich, sie funktional aufeinander abzustimmen und ihr Zusammenspiel über Schnittstelen zu steuern, eine Interdependenz, die es schon bei der Formulierung der Usecases zu beachten gilt. Der Schnitt der geplanten Apps in Microservices sollte so gewählt sein, dass er die Komplexität des Gesamtsystems minimiert.
Beim Testen, im Echtbetrieb und in der Wartung bereiten auf mehrere Maschinen oder Rechenzentren verteilte Softwareblöcke ebenfalls mehr Aufwand als ein Monolith, der auf einem einzelnen Server läuft.
Unter anderem muss das Zusammenspiel der Micro-services ausgiebig getestet und die Last nach mehreren Parametern auf die Instanzen verteilt werden. Schwierig gestaltet sich auch das Logging und Monitoring: Da jeder Microservice seine Nutzung selbst protokolliert, brauchen die Administratoren Spezialtools wie den ELK-Stack (Elasticsearch, Logstash, Kibana), um sich einen Gesamtüberblick zu verschaffen.
Obwohl sich die hier vorgestellten Portalarchitekturen (SWA, Container, Microservices) als Stufen einer Evolution verstehen lassen, sind alle drei noch aktuell. Die Entscheidung für eines dieser Modelle bedarf gründlicher Abwägung, zumal Intranet-Angebote nicht nur immer größer und komplexer werden, sondern auch mehr externe Webressourcen einbinden. Zunächst ist zu klären, welche Informationen und Apps den Mitarbeitern bereitgestellt werden sollen. Danach geht es um die technischen Anforderungen: Mit welcher Grundlast und welchen Lastspitzen ist zu rechnen? Für welche Ausfallrisiken sorgen wir wie vor? Wie weit und wie schnell muss sich die Portallösung skalieren lassen? Wie gut kennt unser IT-Personal einschlägige Modelle, Systeme, Tools? Die Antworten auf solche Fragen sollten sich nicht nur am Status quo orientieren, sondern auch am künftigen Bedarf.
Einsatzplaner teilen das Personal zeitlich und örtlich auf anstehende Arbeiten auf. Dabei handelt es sich um eine operative Aufgabe mit kurz- bis mittelfristigem Zeithorizont. Zahlreiche Randbedingungen fließen in den Einsatzplan ein, darunter:
Ein Einsatzplan, der alle diese Faktoren berücksichtigt, ist hochkomplex, der Aufwand nimmt mit der Zahl der Mitarbeiter und Restriktionen zu. Nur mit Papier und Bleistift oder per Tabellenkalkulation lässt sich diese Aufgabe in mittelständischen bis großen Unternehmen nicht stemmen.
Zunächst gilt es, die unternehmensintern relevanten Faktoren zu bestimmen und zu priorisieren. Manche Restriktionen sind „hart“, das heißt, zwingend wie ein Gesetz, andere „weich“, also optional wie die Einsatzwünsche der Mitarbeiter. Die Mengengerüste zu diesen Randbedingungen erfordern zumal in größeren Unternehmen den Einsatz intelligenter, idealerweise mitdenkender IT-Systeme. Der Mensch kommt hier an seine Grenzen. Allerdings sollte er die Kontrolle über die Pläne behalten und stets das letzte Wort haben.
Spötter sehen Großprojekte als Beispiel der Entropie, der inhärenten Tendenz des Universums zum Chaos. Demnach gliedern sich solche Vorhaben in sechs Phasen: Enthusiasmus, Desillusion, Panik plus Überstunden, Jagd auf die Schuldigen, Sanktionierung Unschuldiger, Lob für Unbeteiligte. Dass es auch anders geht, zeigt sich selten, kommt aber durchaus vor – vorausgesetzt, man bläst die Jagd auf die Schuldigen zugunsten produktiver Schritte ab. Doch der Reihe nach.
Unser Projekt bei einer Einzelhandelskette begann in der Tat enthusiastisch. Das Unternehmen wollte ein Loyalty-Programm inklusive Kundenkarte, Werbekampagne und Mehrwertangeboten einführen, dass sich von den Programmen der Konkurrenz abhob und die Verbraucher stärker an die Marke band. Consileon hat das Vorhaben von der Strategieplanung über die Softwareentwicklung bis zum Piloteinsatz der Kundenkarte begleitet. Doch auf halbem Weg wich der Elan des Projektteams zusehends der Desillusion. Die Konkurrenz schlief nicht, ihre Bonusprogramme legten unerwartet stark an Mitgliedern zu. Der Mehrwert einer weiteren Kundenkarte im Geldbeutel ließ sich kaum noch vermitteln. Angesichts der bis dahin aufgelaufenen Kosten war es nur ein Katzensprung zu Phase drei: Panik!
Statt zur Jagd auf die Schuldigen entschloss sich unser Klient indes zu einer konstruktiveren vierten Phase: einem strategischen Kurswechsel in Form der Abkehr von der Entwicklung einer Individuallösung hin zur Zusammenarbeit mit einem spezialisierten Loyalty-Programmanbieter. Dies eröffnete zudem die Chance, das Loyalty-Programm auf weitere Kanäle auszudehnen. Der Multikanalansatz umfasst die Website, Online-Auftritte, Mobilapps sowie interaktive Endgeräte an den Marktstandorten. Damit hatten sich auch die Projektphasen fünf und sechs erledigt: Unschuldige blieben unbehelligt, Unbeteiligte mussten ihr Lob an anderer Stelle verdienen. Dafür begann nun die wahre Erfolgsgeschichte des Großprojekts.
Wie viele Roggenmischbrote soll eine Bäckereikette nächsten Montag backen? Im Idealfall bekommt jeder Kunde das Brot seiner Wahl, ohne dass ein Laib übrig bleibt. Viele Faktoren fließen in die Kalkulation ein, darunter der Absatz in der Vorwoche, ob der nächste Montag in den Ferien liegt oder ob das Brot gerade beworben wird. Übersetzt man sie in Eingabewerte für ein Computerprogramm, kann dieses die Nachfrage auf mehrere Arten berechnen, zum Beispiel:
Die Vorhersage wird umso genauer, je mehr Daten einfließen, also etwa auch die montägliche Roggenmischbrot- Absatzkurve der letzten Jahre. Aus solchen Daten lernt das Programm – daher der Ausdruck maschinelles Lernen (ML).
Der stationäre Einzelhandel zeigt zunehmendes Interesse an Indoor-Navigation und den damit verbundenen Herausforderungen und Chancen. Für den Kunden bedeutet es ein positiveres Einkaufserlebnis, während es für den Betreiber ein Alleinstellungsmerkmal darstellt und ihm die Möglichkeit eröffnet, wertvolle Daten über das Verhalten der Einkaufenden zu sammeln.
Ein Indoor Positioning System (IPS) ist ein Netz aus Geräten, das Personen oder Dinge in Räumen ohne GPS-Empfang orten kann. Über eine IPS-Verbindung lassen sich Navigationsgeräte auch in geschlossenen Räumen wie Messehallen, Einkaufszentren, Kaufhäusern oder Supermärkten einsetzen.
Die Chancen, die eine Indoor- oder Innennavigation dem stationären Handel eröffnet, reichen weit über das Auffinden eines Artikels im Regal hinaus. Das Handy als Helfer beim Abarbeiten der Einkaufsliste markiert nur die erste Stufe einer digitalen Nachrüstung der Verkaufsfläche.
IPS bedienen sich der (Tri-) Lateration: Kennt man die Lage zweier Punkte im Raum, so lässt sich daraus nach den Regeln der Dreiecksgeometrie der Ort eines dritten Punktes errechnen, zum Beispiel der sich laufend ändernde Standort eines Mobilgeräts in einem Gebäude. Diesen ambulanten Punkt verfolgen kommerzielle IPS entweder mit ortsfesten Peilsendern (Bluetooth, WLAN, RFID, Breitband), hier Funkfeuer oder Beacon genannt, oder mithilfe optischer Lösungen.
Zu den optischen Verfahren zählt die Visible Light Communication (VLC). Statt mit Funkbeacon ortet sie das Mobilgerät über Leuchtstofflampen oder Leuchtdioden (LED) der Innenbeleuchtung. Den Standort einer Leuchte meldet ein individueller, im Lichtstrahl enthaltener Code, den das menschliche Auge nicht wahrnimmt. Weitere Möglichkeiten der optischen Standortbestimmung sind beispielsweise das Scannen von QR-Codes mit Standortinformationen oder optische Trilateration markanter Navigationspunkte über die Kamera.
Am gängigsten ist die Lateration mit stromsparenden Bluetooth-Beacons (Bluetooth Low Energy, BLE). Wie beim GPS (Global Positioning System) wird auch hier die Entfernung an der Laufzeit des Peilsignals vom Sender zum Empfänger gemessen. Sind in einem Ladenlokal genügend Beacons verteilt, lässt sich damit der Weg des Kunden durch das Sortiment verfolgen. Je nach Verhalten oder momentanem Standort kann man ihm/ihr beispielsweise per Pushnachricht einen Rabatt anbieten, andere interessante Artikel vorschlagen oder weiterführende Beratung bereitstellen.
Die Hardware moderner Smartphones ist vollkommen ausreichend, um verschiedene Arten der IPS zu unterstützen. Sowohl Bluetooth-Lateration, als auch verschiedene optische Navigationsmethoden können genutzt werden. Es muss nur die geeignete Software in Form einer benutzerfreundlichen App bereitgestellt werden.
Mit der Erfassung und Auswertung der Navigation des Kunden durch das Ladenlokal schließen stationäre Händler methodisch zum Onlinehandel auf. Schon seit Mitte der Neunzigerjahre setzen insbesondere die Betreiber kommerzieller Websites Tracking- und Analysetools wie Google Analytics ein, mit denen sie ein breites Spektrum an Kennzahlen (KPIs) zum Nutzerverhalten erheben und zur Optimierung der Interaktion auswerten. Solche Werkzeuge fehlten im stationären Handel bislang. Interessen und Vorlieben der Kundschaft ließen sich nur aufwendig und auf schmaler Datenbasis ermitteln, etwa per Panelstudie oder Beobachtung einzelner Kunden im Laden. Dabei lassen sich viele der im Web erhobenen Kennzahlen mit entsprechender Hard- und Software auf den stationären Handel übertragen.
Unser Leben wird zunehmend digitaler. Die exponentiellen Wachstumsraten im Onlinehandel und Mobile-Banking sind ein klares Zeichen dafür, dass die Kunden von digitalen Angeboten begeistert sind. Nun erwarten sie auch von ihrem Versicherer einen hohen Digitalisierungsgrad, bessere Customer Experience und einfachere Produte.
Ein Blick auf das Thema Assekuranz verdeutlicht klar, dass nur diejenigen Versicherungsunternehmen florieren werden, die sich der Digitalisierung stellen und dadurch die Kundenbedürfnisse besser als die Konkurrenz erfüllen können. Der technische Fortschritt bietet der Versicherungsbranche große Chancen, effizienter zu werden und ihren Fokus auf individuelle, maßgeschneiderte Produkte zu legen. Gleichzeitig schafft der digitale Wandel Hürden bei der Digitalisierung von Versicherungsangeboten und -Prozessen.
Die Welt der Versicherer wandelt sich, denn 78% der Deutschen wünschen sich digital mit ihrem Versicherer zu interagieren.
Als Folge nehmen Neugründungen, die ihr Know-how über Versicherungsprodukte mit innovativen technischen Lösungen kombinieren können, einen bedeutenden Platz in der Versicherungswelt ein. Die Anzahl der sogenannten InsurTechs wächst weiter, die globalen Investitionen in solche Unternehmen überschreiten heute 10 Mrd. USD. Daneben fordern die multinationalen Technologiekonzerne wie Google, Apple, Facebook, Amazon und Microsoft die Versicherungsbranche heraus, indem sie selbst als Anbieter auftreten.
In unserem Whitepaper Digitalisierung in der Assekuranz beantworten wir verschiedene Fragen rund um das Thema. Hier eine kleine Auswahl:
Bestellen Sie hier kostenlos das gesamte Whitepaper.
Zwischen dem 12. und 19. Juli 2021 machten schwere Niederschläge dem Westen Deutschlands erheblich zu schaffen. Besonders stark betroffen war dabei der Landkreis Ahrweiler in Rheinlandpfalz.
In der Nacht vom 14. auf den 15. Juli 2021 brach dann über das Ahrtal eine Flutkatastrophe von nahezu biblischem Ausmaß herein. Städte, Dörfer, ganze Landstriche wurden massiv von den Fluten zerstört. Insgesamt kamen nach bisherigen Erkenntnissen 134 Menschen in den Wassermassen ums Leben, zwei Personen werden noch vermisst.
Direkt, nachdem das ganze Ausmaß der Katastrophe klar war, rief die Geschäftsleitung der Consileon alle Kolleginnen und Kollegen dazu auf, Initiativen aus dem betroffenen Großraum bekannt zu geben, die dringend Unterstützung benötigten. Da eine ganze Anzahl unserer Mitarbeitenden in der Nähe der verwüsteten Gebiete wohnen, erreichten uns einige Vorschläge. Besonders wichtig war dabei dem geschäftsführenden Gesellschafter Dr. Joachim Schü, dass die Hilfen direkt und unmittelbar bei den Bedürftigen ankommen.
Schon nach kurzer Zeit beschloss die Geschäftsleitung der IT- und Managementberatung, diesen beiden Initiativen schnell und unbürokratisch mit erheblichen Geldmitteln zu helfen.
Da es so unglaublich viele Betroffene gab, beschlossen wir einen Großteil der Summe an die Bürgerstiftung der Volksbank RheinAhrEifel eG hilft Hochwasseropfern zu spenden, da man vor Ort am besten entscheiden kann, wo am dringendsten Geldmittel benötigt werden. Die Stiftung unterstützt „Menschen und gemeinnützige Institutionen in den von der Hochwasserkatastrophe betroffenen Regionen“.
Und dann gab es da noch ein Herzensprojekt unseres Kollegen Horst Schwarz, das er auch schon vor der Flut unterstützt hat. Die IFAK e. V. – Verein für multikulturelle Kinder- und Jungendhilfe – Migrationsarbeit und hier ganz konkret das Mehrgenerationenhaus im Bochumer Stadtteil Dahlhausen. Hier hat das Wasser sowohl am Gebäude als auch am Inventar, besonders im Kinder- und Jugendbereich, schwere Schäden hinterlassen. Nach den Sommerferien wollte man den Kindern und Jugendlichen, die sowieso schon unter den Einschränkungen der Corona-Krise leiden, mit neuen, ansprechenden Angeboten, wie beispielsweise einem Kicker und einem Billardtisch, eine Freude machen. Doch das machten die Wassermassen zunichte. Jetzt musste die IFAK die ganze Einrichtung entsorgen. Auch hier unterstützen wir den Wiederaufbau mit einer Spende, die unmittelbar helfen konnte.
Hochwasserschäden bei der IFAK
Wir hoffen, dass wir damit wenigstens ein kleines bisschen dazu beitragen konnten, das Leid der Menschen in den Überflutungsgebieten zu mindern.
Aktionäre würden wohl antworten: am Gewinn, am Vorsprung vor der Konkurrenz, an Testnoten. Doch das sind alles Sekundäreffekte. Ihre gemeinsame Bedingung ist, dass die Nutzer des Produkts von dessen Design und Handhabung überzeugt sind. Die User-Experience (UX) muss stimmen. Was genau damit gemeint ist, erfahren Sie in diesem Artikel.
1 Quelle: http://www.mcrinc.com/Documents/Newsletters/201110_why_web_performance_matters.pdf
2 Quelle: https://www.thinkwithgoogle.com/consumer-insights/consumer-trends/mobile-site-load-time-statistics/
3 Quelle: https://www.forrester.com/report/The-Six-Steps-For-Justifying-Better-UX/RES117708
4 Quelle: https://think.storage.googleapis.com/docs/au-what-mobile-users-want.pdf
Hey Siri, wie wird morgen das Wetter? Alexa, führe mich zum nächsten Sushi-Restaurant!
Viele Besitzer smarter Handys, Lautsprecher oder Fernseher schätzen die Möglichkeit, Sprachassistenten nach Informationen suchen zu lassen oder über das Internet Einkäufe zu tätigen. Galt die Sprachsteuerung deutschen Unternehmen lange als Spielerei, als kurzlebige Mode, deren vermeintlich schmaler Mehrwert den Entwicklungs- und Integrationsaufwand nicht lohnte, so erobert sie heute einen Anwendungs- und Gerätetyp nach dem anderen.
Auch im Auto leistet der Sprachassistent gute Dienste, indem er auf Zuruf etwa eine Telefonnummer wählt oder das Lieblingslied des Fahrers abspielt. Dieser behält dabei den Blick auf der Straße und die Hände am Lenkrad.
