Un’app aziendale non deve conquistare l’utente: l’utente è obbligato a usarla. Questo cambia completamente i criteri di progettazione, e spiega perché molte app interne vengono compilate male o aggirate. Ecco le decisioni che contano davvero.
In un’app rivolta al pubblico il rischio è la disinstallazione: se non piace, l’utente se ne va. In un’app aziendale il rischio è diverso e più insidioso, perché l’utente non può andarsene. Se lo strumento è scomodo, non lo abbandona: lo aggira. Compila i campi obbligatori con valori qualsiasi, rimanda l’inserimento a fine giornata e lo fa a memoria, oppure continua a usare il blocco note e trasferisce i dati dopo.
Il risultato è peggiore dell’assenza dell’app: si producono dati che sembrano affidabili e non lo sono. Per questo la progettazione di un’app aziendale parte sempre dall’osservazione del lavoro reale, non dall’elenco delle funzioni richieste dalla direzione.
Un tecnico con i guanti in impianto, un agente fra due appuntamenti e un magazziniere con lo scanner in mano hanno esigenze opposte. Il contesto d’uso determina la dimensione dei comandi, il numero di campi per schermata e quanto l’app deve tollerare interruzioni.
È la scelta architetturale più impattante. Il funzionamento offline non è una funzione da aggiungere dopo: cambia il modo in cui i dati vengono salvati, sincronizzati e riconciliati. Va decisa all’inizio.
Un’app aziendale è quasi sempre il terminale mobile di sistemi esistenti. La qualità delle interfacce che quei sistemi espongono incide sul costo più della complessità dell’app stessa.
Credenziali aziendali esistenti, accesso a più fattori, gestione dei dispositivi smarriti e revoca degli accessi. Su un dispositivo che esce dall’azienda ogni giorno queste scelte contano più che su un computer in ufficio.
È l’aspetto più sottovalutato nei preventivi e quello che causa più problemi in esercizio. Consentire di lavorare senza rete significa che i dati vengono scritti sul dispositivo e sincronizzati più tardi; nel frattempo qualcun altro potrebbe aver modificato le stesse informazioni sul server.
Serve quindi una regola esplicita per i conflitti: chi vince, se prevale l’ultima modifica o quella del server, e cosa vede l’utente quando il suo inserimento non può essere accettato. Serve inoltre una coda di invio che sopravviva alla chiusura dell’app e al riavvio del telefono, e un’indicazione chiara e sempre visibile di che cosa è stato effettivamente trasmesso. Senza quest’ultima, gli utenti perdono fiducia nello strumento alla prima anomalia e ricominciano a tenere appunti paralleli.
Un’app non è un progetto che si chiude al rilascio. I sistemi operativi mobili evolvono ogni anno, gli store cambiano i requisiti di pubblicazione e le librerie richiedono aggiornamenti di sicurezza. Va previsto un budget di manutenzione ricorrente fin dall’inizio: un’app ferma per due anni spesso non è più pubblicabile senza un intervento significativo.
C’è poi il tema della convivenza delle versioni. Sui dispositivi dei collaboratori restano installate versioni diverse per lungo tempo: le interfacce lato server vanno progettate per continuare a funzionare con le versioni precedenti, altrimenti ogni aggiornamento obbliga a raggiungere fisicamente ogni dispositivo.
Per la maggior parte delle app aziendali una base di codice condivisa fra iOS e Android è la scelta più efficiente: riduce il costo di sviluppo e soprattutto quello di manutenzione, che è ricorrente. Il nativo puro resta preferibile quando servono prestazioni grafiche elevate, uso intensivo di funzioni hardware specifiche o integrazione profonda con il sistema operativo.
Se le funzioni richieste sono consultazione e compilazione di moduli con connessione disponibile, un’applicazione web ben fatta costa meno, si aggiorna senza passare dagli store e non richiede installazione. L’app diventa necessaria quando servono funzionamento offline, notifiche push affidabili, accesso a fotocamera, GPS o lettori di codici, oppure prestazioni che il browser non garantisce.
Un’app con poche funzioni ben definite e un’integrazione singola si realizza in poche settimane. I tempi crescono con il numero di flussi coperti, con la gestione offline e con la quantità di sistemi da collegare. La pubblicazione sugli store aggiunge qualche giorno per il processo di revisione.
Esistono canali di distribuzione aziendale che evitano gli store pubblici, oppure si può pubblicare in forma non elencata. Per parchi dispositivi gestiti, i sistemi di mobile device management permettono di installare e aggiornare l’app da remoto senza intervento dell’utente.
Va messa a budget una manutenzione ricorrente. Ogni anno i sistemi operativi introducono cambiamenti su permessi, notifiche o requisiti di pubblicazione che possono richiedere adeguamenti. Un’app non aggiornata per due o tre anni rischia di smettere di funzionare o di essere rimossa dagli store.
