USERS-PROJECTIONS Milano-Comune
7 LINEE GUIDA PER LO SVILUPPO TECNICO DEI SISTEM
In questo capitolo verranno elencate e descritte le caratteristiche che i sottosistemi della soluzione devono necessariamente avere affinché la soluzione performi nella maniera corretta. Queste indicazioni fungeranno da linee guida per il futuro sviluppo tecnico della soluzione e per la corretta scelta dell’elemento da includere più adeguato.
7.1 Servizi di Intelligenza Artificiale
I servizi di Intelligenza Artificiale da considerare per l’erogazione della soluzione sono il Sistema IoT, per permettere a più dispositivi di essere collegati, il Sistema di Storage, per conservare grandi quantità di dati, il Sistema di Image Analysis, per poter analizzare le immagini dei sinistri e capirne l’ammontare dei danni in maniera rapida, il Sistema Voice to Text per permettere di conservare la conversazione tra il sistema e lo user ai fini dell’analisi, il Sistema Text to Speech, per permettere la naturale conversazione tra il sistema e lo user a seguito di un incidente e il Sistema di Deep Learning per ottimizzare continuamente l’algoritmo di riconoscimento della gravità dell’incidente e di analisi dati post-sinistro. In generale comunque il sistema deve essere in grado di:
• Analizzare diversi tipi di dati, sia strutturati che non => necessario capire quali tipi di dati è più opportuno includere nel modello predittivo e soprattutto quali tipi di dati le assicurazioni considerano nelle perizie dei sinistri.
• Fornire una deduzione in base al tipo di dato ricevuto => per ogni categoria di dati deve essere fatta una interpretazione di quello che può essere avvenuto in base a quanto registrato dai sensori
• Fornire una interpretazione sistemica => il sistema deve essere in grado di sistematizzare e coniugare le varie interpretazioni dei dati in un singolo report riassuntivo. E’ richiesta una grande capacità di analisi da parte del sistema per poter unire le varie interpretazioni in un unico contesto contenente una logica ben strutturata.
La capacità interpretativa del sistema deve essere in grado di fornire le cause sistemiche, dedotte dalle singole interpretazioni, che possono aver portato all’incidente.
• Inviare e ricevere dati => il sistema deve essere ben collegato, attraverso la rete, con il sistema di Front-end, per ricevere i dati, e con il portale per i clienti (Assicurazioni, Car Sharing, Car Rental, …) per poter inviare la reportistica.
7.2 App su smartphone
Qui non sono richieste grandissime capacità cognitive da parte del sistema, il quale deve limitarsi a capire se è necessario avviare la procedura di compilazione del CID oppure se è opportuno chiamare i soccorsi, attraverso il modello predittivo sviluppato nel Back-end. L’App deve essere dotata di una serie di caratteristiche basilari per il corretto funzionamento:
• Essere flessibile => la modalità di navigazione deve essere flessibile, poiché se il sistema dovesse mal “interpretare” quanto accaduto, l’utilizzatore deve avere la possibilità di correggere il percorso intrapreso. Deve essere possibile “switchare” le varie caratteristiche dell’incidente avvenuto, ovviamente il sistema deve essere in grado di capire che è stato commesso un errore ed inviare tale segnalazione al sistema di Back- end.
• Consentire di accedere con email => l’utente deve essere in grado di accedere con la propria email. Tale indirizzo potrebbe essere lo stesso fornito alla società di assicurazione/rental/cliente in modo tale da avere univocità dei dati tra il sistema informativo del provider del servizio e l’assicurazione/rental/cliente.
• Consentire all’utilizzatore di avere accesso ad una propria area personale => tramite l’accesso per email, l’utilizzatore deve avere a disposizione una pagina personale, nella quale è in grado di visualizzare tutte le informazioni relative alle pratiche aperte, alla sua polizza assicurativa, allo storico, …
• Consentire la geolocalizzazione => deve essere in grado di avere accesso ai dati inerenti la geolocalizzazione, sia per fornire immediatamente la posizione ai mezzi di soccorso in caso di incidente grave sia per inviare questo tipo di dato al sistema centrale.
da seguire durante la compilazione del CID prevede che l’utilizzatore scatti fotografie prima dei singoli veicoli e poi dell’intera dinamica dell’incidente. Una volta inviate al sistema centrale, queste vengono analizzate e interpretate dal Back-end, e ovviamente inserite nella reportistica finale.
• Essere molto reattivo nel riconoscere un incidente per stimare la gravità dell’evento e agire secondo le logiche predisposte dalla soluzione.
• Consentire una naturale conversazione con l’utente => il sistema, entrando in funzione in un momento critico come un post-incidente, deve poter essere il più user friendly possibile.
• Capacità di risposta => il sistema deve essere abile nel riconoscere immediatamente l’avvenuto incidente. La tempestività nell’erogazione di questo tipo di servizio è la caratteristica fondamentale.
La soluzione, nell’immediato nel Front-end e successivamente nel Back-end deve essere in grado di usufruire di tutti i dati provenienti dai sensori presenti nello smartphone. Per quanto riguarda il Front-end questi sono necessari per capire immediatamente la gravità dell’incidente, nel Back-end invece subiranno un analisi più approfondita. I sensori, e quindi di conseguenza i tipi di dati considerati sono:
• Accelerometro => necessario per capire l’accelerazione subita dallo smartphone e quindi verificare ed analizzare i fenomeni fisici accaduti.
• Giroscopio => congiuntamente all’accelerometro permette di rilevare in maniera più precisa i movimenti a cui è sottoposto lo smartphone.
• Sensore di prossimità => necessario per capire la vicinanza di un utente
• Localizzatore posizione => dato fondamentale per conoscere le coordinate della posizione istantanea, ma risalendo allo storico delle posizioni è possibile anche tracciare il percorso fatto dal dispositivo. Se il sistema è in grado di rilevare la posizione con una precisione molto elevata, risulta essere determinante per la ricostruzione della dinamica dell’incidente.
• Barometro => con la registrazione delle variazioni delle altitudini, grazie alla misurazione della pressione atmosferica, è possibile migliorare il posizionamento geografico.
• Magnetometro => per quanto riguarda il dato sul campo di ricezione.
7.3 Sensori auto
I dati provenienti da questi sensori costituiscono il cuore dell’analisi che viene fatta nel Back- end, al fine di fornire una reportistica accurata di quanto avvenuto, andando a individuare le possibili cause. Non solo, i dati provenienti da questi sensori sono necessari per affinare il modello predittivo che viene periodicamente inviato ai dispositivi di Front-end. Per questo i sensori dell’auto devono:
• Essere utili a capire le condizioni in cui versa l’auto => attraverso lo studio e l’interpretazione dei dati provenienti dai sensori deve essere possibile risalire alle condizioni del veicolo al momento dell’incidente.
• Essere utili a risalire alle cause dell’incidente => i dati estratti devono poter indicare se è avvenuta una brusca frenata o comunque se è avvenuto qualche tipo di failure nei sottosistemi del veicolo (questo poi integrato con la ricostruzione della dinamica può portare alla definizione delle cause).
• Essere utili all’identificazione dei danni => i danni devono poter essere identificati dal sistema attraverso l’analisi dei dati dei sensori, in più il sistema dovrebbe anche poter quantificarli.
• Essere accessibili continuamente => per poter garantire un certo livello di prestazione del modello predittivo è necessario avere un approfondito monitoraggio dei sensori del veicolo.
I sensori considerati potrebbero essere:
• Sensori di parcheggio => per lo più sensori di prossimità in grado di rilevare la distanza da un veicolo o da infrastruttura. Per quanto riguarda i sistemi di visione invece questi possono fornire filmati o istantanee che il sistema, con adeguate capacità di visual recognition, può utilizzare nelle sue interpretazioni.
• Pressione olio
• Temperatura liquido raffreddamento motore • Inserimento freno a mano
• Usura pastiglie dei freni • Carica delle batterie
• Avaria luci • ABS • ESP • Azionamento airbag • Avaria motore • Luci/abbaglianti • Spie cinture • Avaria sterzo
• Interruttore inerziale => utile perché si attiva in caso di urto
• Pericolo ghiaccio => per capire anche le condizioni del manto stradale • Limite di velocità
• Pressione pneumatici • Avaria generica
7.4 Comunicazione tra smartphone e Sistema Centrale
Lo smartphone e il sistema cognitive devono essere in continuo collegamento per permettere lo scambio di dati in entrambe le direzioni. Lo smartphone deve inviare i dati registrati dai suoi sensori al sistema centrale per permetterne un’analisi più approfondita, vice versa periodicamente il sistema centrale deve inviare allo smartphone la nuova release degli algoritmi predittivi di machine learning. La rete di comunicazione quindi deve:
• Supportare grandi quantità di dati => la mole di dati che viene inviata al sistema centrale è costituita sia da dati strutturati che da dati non strutturati. È necessario che la rete permetta lo scambio di informazioni senza creare rallentamenti nel sistema. Allo stesso modo anche le nuove release del sistema devono poter essere immediatamente fruibili dagli utenti per permettere loro di avere la versione più aggiornata.
• Scambiare velocemente i dati => è necessario che la latenza di trasmissione sia ridotta al minimo per riuscire a mettere in moto il sistema il più velocemente possibile e con la massima accuratezza.
• Essere accessibile => essendo fondamentale per il funzionamento del sistema e quindi di conseguenza per l’erogazione del servizio, la trasmissione dei dati deve poter avvenire continuamente. È importante quindi predisporre una rete di collegamento
performante cercando di limitare il più possibile le “zone d’ombra”, in modo da non avere dei “buchi” all’interno della cronologia di dati.
• Essere sicura => ovviamente la rete deve garantire un altissimo livello di sicurezza per garantire che i dati vengano trasmessi soltanto al server centrale del service provider, nel modo più sicuro possibile.
7.5 Device di collegamento
È necessario riuscire a estrapolare le informazioni dai sensori del veicolo e inviarli al sistema cognitive centrale per includerli nell’analisi del modello predittivo e per utilizzarli ai fini dell’interpretazione. Il device di collegamento da utilizzare deve:
• Prevedere l’uso dello smartphone per il collegamento => lo smartphone essendo sempre in comunicazione con il server centrale deve costituire il mezzo con il quale i dati transitano verso lo spazio di repository. Inoltre utilizzando lo smartphone, un device portatile, l’infrastruttura non viene modificata in maniera significativa.
• Supportare grandi quantità di dati => vale quanto detto sopra nella rete di comunicazione tra smartphone e sistema cognitive. In aggiunta deve essere presa in considerazione la moltitudine di sensori presenti sull’autovettura, che corrispondono ad un numero significativo di dati da trasmettere.
• Scambiare velocemente i dati => è necessario che la latenza di trasmissione sia ridotta al minimo per riuscire a mettere in moto il sistema il più velocemente possibile e con la massima accuratezza.
• Essere accessibile => vale quanto detto sopra nella comunicazione tra smartphone e sistema cognitive.
•
Essere sicuro => vale quanto detto sopra nella comunicazione tra smartphone e sistema cognitive. In più, i device utilizzati, devono essere certificati e devono rispondere a tutti i requisiti qui sopra descritti.7.6 Portale clienti
Per poter permettere alle società clienti di interagire con il service provider e di visionare/scaricare tutta la documentazione a loro disposizione è necessario predisporre un portale online. Esso deve:
• avere degli accessi riservati per le società clienti => rivolgendosi il service provider ad una moltitudine di società clienti è necessario fornire a queste delle aree private, dove potranno trovare tutta la documentazione relativa alle loro “pratiche”.
• Fornire la possibilità di visionare/scaricare il materiale prodotto
• Essere connesso alla rete => i clienti devono poter accedere tramite la rete internet al portale per usufruire delle sue funzionalità. (Per le società partner potrebbe essere predisposto collegamento diretto con il loro sistema ERP)
• Essere user-friendly => non deve risultare troppo complicato per i clienti navigare sul portale, in modo da non scoraggiarne l’uso. L’anagrafica dei dati dovrebbe essere molto semplice considerando una scala simile: società, utente, sinistro. Importante che il sistema non richieda troppe operazioni per trovare i documenti desiderati, essendo questo il punto di contatto con i clienti.
8 CONCLUSIONI
Obiettivo del lavoro è stato analizzare le fasi preliminari di un progetto d’innovazione di un servizio, per capire come è possibile applicare in un contesto aziendale la Service Innovation. Partendo dallo studio dei settori d’interesse, suddivisi nelle componenti Business e Consumer, sono state analizzate le principali dinamiche e caratteristiche di questi mercati in modo da capire l’esistenza di bisogni da parte dei soggetti analizzati. Dopo una descrizione della soluzione ideata, cercando di descrivere architettura di sistema e principali caratteristiche, si è passato alla stima della domanda e alla definizione di un Business Plan. Sono state analizzate diverse voci di costo, dalle spese operative, agli investimenti necessari per iniziare l’erogazione fino a delineare una vera e propria struttura di HR necessaria alla messa in opera. In fine dopo aver quantificato le potenzialità economiche della soluzione si è voluto delineare delle linee guida per indirizzare lo sviluppo tecnico di tutti i sottosistemi che fanno parte della soluzione. La soluzione porta con se grandi potenzialità di sviluppo, in un settore quello dell’Insurtech che è agli albori e che con i nuovi modelli di mobilità che si stanno delineando, ha bisogno di nuovi strumenti per gestire i business che stanno nascendo e per fornire agli user le condizioni più favorevoli.
BIBILIOGRAFIA
Associazione Nazionale Industria dell’Autonoleggio e Servizi Automobilistici. 2017. “17° Rapporto ANIASA Sul Noleggio Veicoli.”
Audiweb. 2018. “Total Digital Audience.”
Baines, Tim S, Howard Lightfoot, and Ornella Benedettini. 2009. “The Servitization of Manufacturing : A Review of Literature and Reflection on Future Challenges,” no. January 2015. https://doi.org/10.1108/17410380910960984.
Bryce Space and Technology. 2017. “Global Space Industry Dynamics.” Deloitte University Press. 2017. “Insuring the Future of Mobility.” Europcar. 2017. “Annual Financial Report.”
Generali Group. 2018. “Dossier Assicurazioni 2018.”
Kindström, Daniel, and Christian Kowalkowski. 2014. “Service Innovation in Product-Centric Firms: A Multidimensional Business Model Perspective.” Journal of Business and
Industrial Marketing 29 (2): 96–111. https://doi.org/10.1108/JBIM-08-2013-0165.
Kowalkowsky, Christian, Ulaga Wolfgang, and Mario Rapaccini. 2018. Service Strategy.
Guida Pratica per Crescere Con i Servizi. Edited by Franco Angeli. 1° edizion.
Ministero dello Sviluppo Economico. 2016. “Piano Strategico Space Economy.”
Mobility, Osservatorio Nazionale sulla Sharing. 2017. “2° Rapporto Nazionale Sulla Sharing Mobility.”
Monitor Deloitte. 2017. “Car Sharing in Europe.”
Strandvik, Tore, and Maria Holmlund. 2012. “Customer Needing : A Challenge for the Seller Offering,” no. September 2016. https://doi.org/10.1108/08858621211196994.
Telespazio S.p.A. 2018. “Company Presentation.”
Ulaga, Wolfgang, and Werner J Reinartz. 2011. “Hybrid Offerings : How Manufacturing Firms Combine Goods and Services Successfully” 75 (November): 5–23.