La sfida del customer-facing nella rivoluzione mobile.

21/02/2014

Il mobile sta diventando sempre piú pervasivo e sta modificando le nostre abitudini e stili di vita. Questo accade perché sono soprattutto gli smartphone e i tablet i protagonisti di una rivoluzione che opera su tre fronti: personale, sociale e lavorativo. E nel prossimo futuro una serie di tecnologie innovative come il wearable, l’ensamble, l’Internet of Things, la micro-localizzazione e l’allargamento della banda con LTE e LTE-a daranno un ulteriore impulso a questa radicale trasformazione.

In questo contesto, le imprese che utilizzano delle applicazioni mobili per raggiungere e servire i propri clienti, si trovano a fronteggiare progetti di sviluppo che avranno impatti molto importanti sull’acquisizione e il mantenimento dei clienti, sulla trasformazione di processi interni e sul valore percepito rispetto all’identity aziendale. I settori in cui questo accade sono ad esempio le telecomunicazioni, i servizi finanziari, le utilities, il luxury, il retail, il real-estate ma anche la pubblica amministrazione nei confronti del cittadino.

Nelle concitate fasi che i CIO e l’IT aziendale hanno vissuto fino ad oggi, il mobile e’ stato gestito come una estensione del portale web o come una necessaria presenza in un mondo dove l’approccio era “non possiamo non esserci”.

Questo approccio, che ha una valenza nella fase pionieristica, oggi deve necessariamente essere rivisto in modo molto attento con valutazioni necessariamente tattiche e con una determinazione ferma che tenga conto di alcuni fattori che rappresentano una grande opportunitá ma che se sottovalutati si trasformano in altrettanti rischi.

Si parla di valutazioni tattiche perché la scelta delle direzioni da prendere per l’acquisizione di piattaforme di sviluppo mobile ( MADP ) deve consentire di gestire la complessa matrice di nove combinazioni ( android, iOS e windows da un lato e nativo, ibrido e web/html5 dall’altro). In un immediato futuro si dovranno ideare nuove mimiche e nuovi approcci allo sviluppo, mantenendo la massima flessibilitá nella adozione futura di standard o di player diversi. Inoltre oggi esistono oltre 150 MADP differenti sul mercato e molte di queste verranno consolidate in futuro o si specializzeranno in determinate aree di copertura funzionale ( eg. User experience, Interfaccia applicativa, back-end) e quindi ogni azienda puó essere costretta ad adottare MADP diverse in funzione di esigenze allargate ( es. APP customer-facing, employee-facing etc.)

Dal punto di vista delle opportunitá e dei rischi, lo sviluppo di app customer-facing deve tenere in conto una serie di fattori determinanti ( oggi ancora molto sottovalutati):

- user e motivational experience

- identitá aziendale

- performance

- multi-piattaforma

- adattamento al cloud

- sicurezza

- scalabilitá

- aderenza alla rapida evoluzione tecnologica nella matrice a nove

Questi fattori hanno impatto sia lato front-end ( grafica e mimica dell’interfaccia), sia lato back-end ( accesso a funzioni tipiche del mobile e ai sistemi legacy aziendali ) e richiedono di effettuare scelte di campo nell’ambito dello standard di sviluppo ( nativo, ibrido, web/html5), nell’adozione di MADP e/o BAAS per la componente dei servizi mobili multi-piattaforma e di accesso a dati e funzioni disponibili nei sistemi aziendali e in cloud.

La mie personali linee guida per lo sviluppo di app customer facing ( tipicamente caratterizzate da una, due o tre App per milioni di clienti su piattaforme diverse), sono le seguenti:

1) Non tentare di seguire l’approccio di derivazione IT del write once, deploy anywhere. Realizzare l’interfaccia dell’applicazione in nativo consentirá di ottenere le migliori user experience, l’aderenza all’esperienza della piattaforma ( Google vs Apple vs Microsoft), performance di massimo livello, testing ridotto al minimo, migliore gestione del versioning, rapiditá di adeguamento all’evoluzione dei Sistemi operativi mobile.

Di contro richiederá il mantenimento di tre versioni distinte a livello di interfaccia. Ma qui il parallelismo che faccio e’ questo: quando una banca sceglie l’arredamento di una filiale si basa anche sulla corporate identity o no ? Inoltre, in un progetto enterprise la parte di sviluppo del front-end incide in media per il 15/20% dell’intero progetto.

Infine, qualcuno si chiederá perché non adottare l’HTML5. La risposta e’ semplice. HTML5 non e’ uno standard consolidato, ha versioni diverse su ogni piattaforma e anche su versioni diverse installate nell’ambito della stessa piattaforma su smartphone diversi e ha problemi di performance e di frammentazione. E’ una grande tecnologia con un futuro importante pensata come piattaforma per la distribuzione di app in ambito web/mobile e che vede il browser come container. Ma non ha nulla da offrire oggi a chi deve dare il massimo della esperienza ad un cliente che vuole mantenere e fidelizzare. E inoltre rappresenta un problema a livello di overhead di testing, security e performance. Va inoltre considerato che il concetto di write once nelle applicazioni mobile implica l’implementazione di una singola interfaccia per tutti i sistemi operativi. Se si verticalizzano le interfacce per ogni sistema operativo inseguendo la user experience, il paradigma del write once viene meno e riaffiorano i difetti dell’html moltiplicati per ogni interfaccia. A questo punto molto meglio lo sviluppo nativo.

2) Adottare una MADP/BAAS che consenta di isolare e rendere trasparenti tutte le funzionalitá mobile-specific e che quindi riduca l’impatto della scelta nativa effettuata sull’interfaccia. In questo caso gli obiettivi devono essere quelli di ridurre la scrittura di codice di piattaforma solo alla interfaccia grafica e alla mimica e fare in modo di adottare il write once, deploy anywhere quando si tratta di utilizzare funzioni tipiche mobile come il pushing, il versioning o quando si debba accedere ai sistemi legacy o a servizi in cloud pubblici o privati. Inoltre la MADP deve aderire a standard del cloud in modo da garantire il deployment in ambienti misti ( ad esempio il front-end su cloud e i connector ai sistemi legacy su un data center privato in modo da non richiedere l’esposizione di servizi espondendosi a rischi elevati). La MADP inoltre deve garantire standard di sicurezza, di performance e di scalabilitá molto solidi.

Tutt’altra storia, invece, riguarda lo sviluppo di app employee-facing o partner-facing. Ma di questo ne parleremo in un prossimo articolo.