Alle otto del mattino un agente di commercio parcheggia davanti a un cliente, apre il tablet e mostra il catalogo aggiornato alla sera prima, con le giacenze reali del magazzino. Un’ora dopo l’ordine è già in ufficio, senza una telefonata né un foglio da ricopiare. Nessuno ha scaricato quell’app da uno store e nessuno la recensirà mai, eppure è una delle più usate dell’azienda. Chi si avvicina allo sviluppo di app per aziende pensando alle classifiche dei download rischia di guardare nel posto sbagliato: il valore di un’app interna si misura nel lavoro di tutti i giorni.
Dal tablet dell’agente al rapportino di cantiere: dove lavorano davvero le app aziendali
L’agente che sfoglia il catalogo dal tablet davanti al cliente, il tecnico che compila il rapportino in cantiere e lo manda in ufficio prima di rientrare, il commerciale che fa firmare un contratto senza stampare un foglio: un’app aziendale pesa qui, molto più che nella classifica degli store. Molti progetti però partono dalla direzione opposta, con un’idea pensata per i download e una lista di funzioni scritta prima di sapere da quale gestionale arriveranno i dati. Nello sviluppo di app per aziende che reggono nel tempo l’ordine si rovescia: prima la mappa dei processi e dei sistemi già in uso, ERP e CRM in testa, poi le schermate, e solo alla fine la scelta tra iOS, Android o entrambe.
Sviluppo di app per aziende: perché il gestionale viene prima del design
Un’app che non dialoga con il magazzino o con l’anagrafica clienti costringe i dipendenti a inserire due volte gli stessi dati. Dopo poche settimane qualcuno riapre il foglio Excel, e l’app finisce in una cartella del telefono insieme alle altre dimenticate. Il collegamento con e-commerce, CRM ed ERP è la parte meno visibile del progetto, ed è quella che decide se l’app verrà aperta ogni mattina. Un’interfaccia curata non compensa un dato sbagliato o arrivato in ritardo. Chi lavora sul campo perdona una grafica essenziale, non un ordine registrato due volte.
App native o multipiattaforma: decide chi la userà ogni giorno
iOS è più diffuso nella fascia alta del mercato, Android ha una base di utenti più ampia, ma per un’app interna la questione si semplifica: spesso è l’azienda a scegliere i dispositivi da dare in dotazione. Contano piuttosto le funzioni che servono sul campo: la fotocamera per scansionare i codici, il GPS per le visite sul territorio, la consultazione offline nelle zone senza copertura. Sono queste esigenze a far pendere la scelta verso lo sviluppo nativo.
Un caso concreto viene dal metalmeccanico. Franco Greco Job App, presentata come la prima app in Italia dedicata alle offerte di lavoro per i professionisti del settore, è stata sviluppata da Web Domus in ambiente nativo per iPhone e Android, con un back-end da cui l’azienda pubblica e aggiorna gli annunci. Il punto non è il numero di installazioni ma lo strumento di gestione che sta dietro, quello che permette di tenere l’app viva senza dipendere ogni volta da uno sviluppatore.
Dall’analisi alla pubblicazione: fasi e tempi di un progetto reale
Il percorso è sempre lo stesso: analisi e progettazione, prototipo dell’interfaccia, sviluppo, test sui dispositivi e pubblicazione su App Store e Google Play. I tempi variano molto: un’app con poche funzioni si chiude in tempi contenuti, mentre un progetto con integrazioni e più profili utente può richiedere diversi mesi. Il prototipo cliccabile mostrato a chi userà l’app sul campo è il passaggio che fa risparmiare di più, perché porta alla luce in anticipo le correzioni che, scoperte a sviluppo concluso, costano il doppio.
Accessi, profili e dati sensibili: il capitolo che si scopre tardi
Un’app usata da dipendenti con ruoli diversi deve sapere chi vede cosa. I listini riservati alla rete vendita non vanno mostrati al magazzino, i dati dei clienti vanno protetti e un telefono smarrito deve poter essere disconnesso da remoto. Sono scelte da prendere in fase di analisi, non dopo il primo incidente, anche perché toccano gli obblighi del GDPR sui dati personali trattati in mobilità. Aggiungerle a progetto finito significa spesso rimettere mano alla struttura dell’intera applicazione.
Sviluppo di app per aziende: cosa succede dopo il rilascio
Apple e Google rilasciano ogni anno una nuova versione dei propri sistemi operativi, e un’app lasciata senza manutenzione comincia a mostrare problemi già alla prima tornata di aggiornamenti. Il rilascio è l’inizio della vita di un’app aziendale, non la fine del progetto.
Per le app riservate ai dipendenti esistono canali di distribuzione privati. La distribuzione delle app personalizzate per uso interno prevista da Apple passa da Apple Business, il servizio che fino a poco tempo fa si chiamava Apple Business Manager: l’app viene resa visibile solo all’organizzazione indicata e distribuita tramite un sistema di gestione dei dispositivi o codici dedicati. Google prevede un canale analogo per Android con Managed Google Play. Per le app pubbliche, invece, entra in gioco l’ottimizzazione negli store, con titolo, descrizione e parole chiave scelte con cura.
Le domande da farsi prima di chiedere un preventivo
Chi userà l’app e su quali dispositivi, con quali sistemi deve parlare, se deve funzionare anche senza connessione, chi resterà proprietario del codice sorgente e se aggiornamenti e assistenza sono inclusi o vanno pagati a parte. La questione della proprietà merita attenzione particolare, perché decide quanto l’azienda sarà libera di cambiare fornitore in futuro. Arrivare al primo incontro con queste risposte rende i preventivi confrontabili e sposta la conversazione dal prezzo a ciò che l’app dovrà fare davvero, ogni mattina, nelle mani di chi lavora fuori dall’ufficio.