Documento di analisi
Mappa dei processi da coprire, attori coinvolti, dati in ingresso e in uscita, casi limite. È il documento su cui si fonda tutto il resto e resta al cliente anche se il progetto non prosegue.
Un software su misura nasce da un problema preciso: un processo che funziona a meta, dati che vengono reinseriti tre volte, decisioni prese su report che arrivano sempre in ritardo. Progettiamo applicativi costruiti su come lavora davvero la tua organizzazione, integrati con i sistemi che hai già e mantenuti nel tempo insieme a te.
È la prima domanda da affrontare, e la risposta corretta non è sempre "su misura". Un fornitore serio lo dice prima di fare il preventivo, non dopo. Questo confronto riassume i criteri che usiamo con i clienti nella fase di valutazione iniziale.
| Criterio | Prodotto standard | Software su misura |
|---|---|---|
| Aderenza ai processi | Adatti i processi al software; le eccezioni finiscono in Excel. | Il software segue il processo esistente, comprese le eccezioni. |
| Costo iniziale | Basso o nullo: si parte con licenza o abbonamento. | Più alto: comprende analisi, progettazione e sviluppo. |
| Costo nel tempo | Canone per utente, cresce con il team e con i moduli. | Nessun canone per utente; costa la manutenzione evolutiva. |
| Tempi di attivazione | Rapidi, se non servono personalizzazioni. | Più lunghi, ma con rilasci parziali già utilizzabili. |
| Integrazioni | Limitate a quelle previste dal fornitore. | Progettate sui sistemi realmente presenti in azienda. |
| Dipendenza dal fornitore | Alta: roadmap, prezzi e fine vita decisi da altri. | Bassa: codice di proprietà, manutenibile anche da terzi. |
La regola pratica che usiamo: se un processo è identico a quello di tutti i tuoi concorrenti, compralo già fatto. Se invece è uno dei motivi per cui i clienti scelgono te, difficilmente troverai un prodotto che lo rispetti senza costringerti a snaturarlo.
Un progetto di sviluppo non produce solo software funzionante. Produce anche gli strumenti che permettono all’azienda di restare autonoma nel tempo.
Mappa dei processi da coprire, attori coinvolti, dati in ingresso e in uscita, casi limite. È il documento su cui si fonda tutto il resto e resta al cliente anche se il progetto non prosegue.
Scelta dello stack, modello dei dati, disegno delle integrazioni, gestione di ruoli e permessi, strategia di backup e di aggiornamento.
Codice sorgente, test funzionali, ambiente di collaudo separato dalla produzione e procedura di rilascio ripetibile.
Documentazione tecnica per chi manutiene, materiale operativo per chi usa il software ogni giorno e sessioni di affiancamento agli utenti.
Nella maggior parte dei casi non è una decisione strategica presa a tavolino: è l’accumularsi di sintomi che a un certo punto diventano insostenibili. I più ricorrenti sono questi.
Software di produzione, tracciabilità lotti, controllo qualità e integrazione con macchine e PLC.
Gestione ordini, magazzino, spedizioni e tracciamento con flussi collegati a corrieri e vettori.
Applicativi per referti, prenotazioni e flussi clinici con attenzione a privacy e conservazione dei dati.
Portali per il cittadino, gestione pratiche e piattaforme di monitoraggio urbano per comuni e utility.
Integrazione tra vendita online, gestionale, listini, magazzino e automazioni post-vendita.
Gestione commesse, timesheet, fatturazione e reportistica per studi e società di servizi.
Non abbiamo uno stack unico da applicare a ogni progetto. La scelta dipende dalle integrazioni richieste, dalle competenze già presenti nel reparto IT del cliente e dalla vita attesa del sistema: un applicativo che deve durare dieci anni richiede scelte più conservative di un prototipo.
Si intende la realizzazione di un applicativo progettato sui processi specifici di un’organizzazione, invece dell’adozione di un prodotto già confezionato. Il punto di partenza non è un catalogo di funzionalità ma l’analisi di come l’azienda lavora: il software viene costruito attorno a quel flusso, non il contrario.
Conviene quando il processo da coprire è una parte del vostro vantaggio competitivo, quando nessun prodotto standard lo copre senza forzature, o quando i canoni per utente di una soluzione in abbonamento superano nel giro di pochi anni il costo di uno sviluppo dedicato. Non conviene per funzioni completamente standardizzate come contabilità, paghe o posta elettronica: lì il prodotto pronto è più economico e più sicuro.
Il costo dipende dal numero di processi coperti, dalle integrazioni con i sistemi esistenti e dal livello di affidabilità richiesto. Un modulo verticale singolo si colloca su un ordine di grandezza; una piattaforma gestionale che sostituisce più strumenti si colloca su un ordine di grandezza superiore. La variabile che pesa di più non è quasi mai il numero di schermate, ma il numero di sistemi con cui il software deve dialogare.
Con un approccio incrementale i primi moduli entrano in uso molto prima della fine del progetto. Un’integrazione fra due sistemi si misura in settimane, una piattaforma completa in mesi. Rilasciare per moduli permette di iniziare a ottenere valore mentre lo sviluppo prosegue e di correggere le scelte quando cambiarle costa ancora poco.
Del cliente. Consegniamo codice e documentazione tecnica: chi ha commissionato il software deve poterlo far manutenere anche da altri, se un domani lo decide. È una condizione di trasparenza che consigliamo di verificare con qualsiasi fornitore.
Sì, ed è normalmente il requisito principale. Ci colleghiamo a ERP, CRM, gestionali di magazzino, e-commerce e sistemi legacy tramite API, scambio di file strutturati o accesso diretto alla base dati, a seconda di cosa il sistema esistente rende disponibile. Nei casi in cui il gestionale è chiuso, si lavora sui punti di scambio che espone.
È l’ipotesi normale, non l’eccezione. Il metodo incrementale esiste proprio per questo: a ogni rilascio si verifica ciò che è stato consegnato e si riordina la coda delle priorità. Cambiare un requisito su un modulo non ancora sviluppato non costa quasi nulla; cambiarlo su un sistema consegnato in blocco dopo un anno costa moltissimo.