7 errori delle PMI che acquistano un software su misura
Un software su misura può essere il denaro più intelligente che una piccola impresa spende, o il più doloroso. La differenza non sta quasi mai nel codice. Sta in sette errori evitabili che le persone commettono prima ancora che venga scritta una riga.

La maggior parte delle piccole imprese che si scotta con un progetto di software su misura non si scotta a causa di cattivi programmatori. Si scotta settimane prima che inizi qualsiasi sviluppo: in una riunione di avvio, in uno scambio di e-mail, in una stretta di mano, per una decisione che allora sembrava da poco. Quando arriva il codice, l'errore è già cotto dentro. La buona notizia è che questi errori si ripetono in modo noiosamente prevedibile, il che significa che sono evitabili se sai riconoscerli.
Ho osservato molti di questi progetti dall'interno, da entrambi i lati del tavolo. Alcuni sono diventati strumenti senza i quali un'azienda non si immaginava più di lavorare. Altri sono finiti in una schermata di accesso a metà, in una tesa disputa su una fattura e in un titolare che giura di non rifare mai più nulla su misura. La parte frustrante è quanto poco separasse i due esiti. La tecnologia raramente era il problema. Le decisioni intorno alla tecnologia quasi sempre lo erano.
Ecco quindi i sette errori che vedo ripetersi quando una piccola impresa commissiona un software su misura. Nessuno richiede competenze tecniche per essere evitato. Basta sapere che esistono prima di firmare qualcosa.
Errore 1: comprare una soluzione prima di capire il problema
L'errore più costoso avviene per primo, e suona innocuo: «Ci serve un'app che faccia X». Quando qualcuno lo dice ad alta voce, di solito ha già deciso la forma della soluzione — una dashboard, un portale, un'app mobile — senza che nessuno abbia messo per iscritto il vero problema in parole chiare. Lo sviluppo consegna allora fedelmente la cosa sbagliata, e ben rifinita.
Un buon software parte da un enunciato del problema, non da un elenco di funzioni. «Il nostro ufficio ridigita ogni ordine dalle e-mail nel gestionale di contabilità, e impegna due persone per mezza giornata» è un problema. «Ci serve un CRM su misura» è un'ipotesi di soluzione a un problema che nessuno si è preso la briga di nominare. Il primo si può risolvere a basso costo e misurare. Il secondo è un invito aperto a spendere denaro.

Errore 2: provare a costruire tutto in una volta
Un software su misura sembra un acquisto che si fa una volta ogni dieci anni, così si cerca di stipare un decennio di desideri nella versione uno. Ogni reparto aggiunge una richiesta. A ogni «già che ci siamo» si dice sì. Il perimetro si gonfia, i tempi triplicano e il progetto crolla sotto la propria ambizione molto prima che qualcuno riesca a usarlo.
Le imprese che hanno successo fanno l'opposto. Scelgono la fetta più dolorosa del problema e costruiscono prima quella: una cosa reale, funzionante, in produzione nel giro di un paio di mesi. Poi lasciano che l'uso reale dica cosa viene dopo. Non è solo più economico; è più sicuro. Scopri se l'idea funziona mentre la posta è ancora piccola, invece di scoprire dopo sei mesi e una grossa fattura di aver progettato la cosa sbagliata.
“Una piccola cosa finita e usata ogni giorno batte una grande cosa all'80 % che muore in silenzio su un server di test.”
Sotto a tutto questo c'è una verità scomoda: non sai ancora davvero di cosa hai bisogno. Nessuno lo sa, all'inizio. La tua comprensione del problema cambierà nel momento in cui persone reali toccheranno uno strumento reale. Costruire tutto in anticipo fissa le tue ipotesi più precoci e meno informate. Costruire a fette ti mantiene flessibile, e tiene il budget sotto controllo mentre stai ancora imparando.
Errore 3: scegliere solo in base al prezzo
Chiedi tre preventivi. Uno è nettamente più basso degli altri. Sollievo: prendi quello. È uno dei modi più affidabili per trasformare un piccolo progetto in uno costoso, perché il preventivo basso non significa quasi mai che il lavoro costi meno. Di solito significa che le due parti hanno inteso l'incarico in modo diverso.
Un numero basso spesso segnala una di poche cose: il fornitore ha sottostimato il perimetro perché non ha fatto abbastanza domande, ha intenzione di fare il margine più avanti sulle richieste di modifica, oppure è inesperto e non sa ancora ciò che non sa. Nessuna di queste finisce bene per te. Il prezzo in copertina è il numero meno utile della proposta. Ciò che conta è se il fornitore capisce chiaramente il tuo problema, pone domande scomode ed è onesto su ciò che non è incluso.
Errore 4: dimenticare che il software non è un acquisto unico
Il software su misura viene spesso proposto, e comprato, come un mobile: paghi una volta, è tuo per sempre. Non è così. Il software vive in un mondo in movimento: i sistemi operativi si aggiornano, i browser cambiano, arrivano le patch di sicurezza, la tua attività si trasforma, gli strumenti a cui ti colleghi cambiano le regole. Uno strumento che nessuno manutiene smette pian piano di funzionare, poi si rompe nel momento peggiore possibile.
Questo colpisce duramente le piccole imprese perché il costo di manutenzione è invisibile alla firma. Confronti due preventivi sul prezzo di costruzione e non poni mai la domanda che conta di più: quanto costa tenerlo vivo e in salute ogni anno? Hosting, aggiornamenti, piccole correzioni, la modifica occasionale man mano che l'attività evolve: pianificalo come una voce normale e ricorrente, come fai per l'assicurazione o la contabilità. Di solito è contenuto, ma solo se te lo aspetti.
| Costo | Evidente alla firma? | Pianificalo |
|---|---|---|
| Costruzione iniziale | Sì | Ovviamente |
| Hosting e infrastruttura | A volte | Mensile, continuativo |
| Aggiornamenti di sicurezza e correzioni | Raramente | Mettere a budget ogni anno |
| Modifiche con la crescita | Raramente | Mettile in conto |
| Avviamento e formazione | Quasi mai | Previsto fin dal primo giorno |
| Proprietà di codice e dati | Quasi mai | Definito prima di iniziare |
Errore 5: lasciare i requisiti vaghi e senza un responsabile
«Siete voi gli esperti, costruite qualcosa di buono» suona generoso. In realtà è così che i progetti vanno alla deriva. Le persone che capiscono meglio la tua attività siete tu e il tuo team, non gli sviluppatori. Se consegni un brief sfocato e sparisci, il fornitore riempie i vuoti con le sue ipotesi migliori, e scoprirai quelle ipotesi nel momento peggiore: alla consegna, quando cambiarle costa di più.
Due ruoli vanno coperti dalla tua parte, e le piccole imprese spesso non ne coprono nessuno. Il primo è un unico decisore: una persona che può dire sì, dirimere i disaccordi tra reparti e non è troppo impegnata per rispondere alle domande per settimane. Il secondo è la disponibilità a essere precisi su ciò che conta: i casi limite, la strana eccezione che la tua attività ha sempre gestito a mano, la regola che tutti conoscono ma nessuno ha scritto. È esattamente la materia che il software deve azzeccare.

Errore 6: non chiedere di chi sono il codice e i dati
Questo è quello silenzioso, ed è quello che fa più male anni dopo. Paghi per un software su misura e dai per scontato che sia tuo. Poi il rapporto con il fornitore si guasta, oppure alza i prezzi, oppure semplicemente sparisce, e scopri che non puoi muoverti. Non hai il codice sorgente. I dati vivono in un sistema a cui accede solo lui. Tutta la tua operatività ora dipende da un'azienda di cui non ti fidi più, e non hai alcuna leva.
Niente di tutto questo richiede un avvocato per essere evitato. Richiede tre semplici domande poste prima di iniziare, mentre hai ancora tutto il potere contrattuale: Di chi è il codice sorgente quando è finito? Posso esportare tutti i miei dati, in un formato utilizzabile, quando voglio? E se ci separiamo, cosa esattamente porto via con me? Un partner serio risponde a queste domande senza battere ciglio. L'esitazione qui è il più grande segnale d'allarme di tutto il processo.
- Ottieni per iscritto che il codice sorgente è tuo, o che ne hai una licenza chiara ed equa.
- Verifica di poter esportare i tuoi dati in un formato standard, a richiesta, senza autorizzazioni.
- Assicurati che il lavoro sia documentato abbastanza bene da permettere a un altro sviluppatore di riprenderlo.
- Evita il lock-in proprietario dove una tecnologia semplice e nota farebbe lo stesso lavoro.
- Concorda in anticipo cosa succede a hosting e account se un giorno cambi fornitore.
Errore 7: trattare il lancio come il traguardo
Il software è consegnato, funziona, tutti tirano un sospiro di sollievo. Il progetto è dichiarato concluso. Sei mesi dopo, metà del team è tornata in silenzio al vecchio foglio di calcolo, e il costoso strumento nuovo è usato da due persone per una sola cosa. La costruzione è riuscita. L'adozione è fallita, e sono due problemi completamente diversi.
Le persone non resistono ai nuovi strumenti perché sono stupide o testarde. Resistono perché il nuovo è sconosciuto e il vecchio funziona ancora, più o meno. Superare questo richiede uno sforzo deliberato che nessuno aveva messo a budget: un po' di formazione, una ragione chiara del perché il cambiamento aiuta loro in particolare, qualcuno che risponda alle domande sciocche senza giudicare nelle prime settimane, e una decisione ferma di mandare in pensione il vecchio così che non ci sia un ripiego in cui rifugiarsi.
- 1Lancia prima a un piccolo gruppoDistribuisci lo strumento a poche persone volenterose prima che a tutto il team. Troveranno le imperfezioni e diventeranno i tuoi sostenitori interni.
- 2Mostra il vantaggio personale, non quello aziendale«Questo fa risparmiare denaro all'azienda» non motiva nessuno. «Questo significa che smetti di digitare gli indirizzi due volte» porta le persone dalla tua parte.
- 3Nomina una persona di riferimento per le domandePer il primo mese, qualcuno si fa carico delle domande sciocche. L'attrito nella prima settimana è ciò che uccide l'adozione per sempre.
- 4Spegni davvero il vecchioFinché il vecchio foglio di calcolo esiste, le persone continueranno a usarlo. Una volta che il nuovo funziona, ritira il ripiego: con gentilezza, ma con chiarezza.

Mettere insieme i pezzi: la mentalità dell'acquirente
Rileggi questi sette punti e un filo unico li attraversa. Quasi nessuno è tecnico. Parlano di chiarezza, proprietà e misura: conoscere il proprio problema prima di comprare, costruire a piccoli passi, giudicare i fornitori sulla comprensione anziché sul prezzo, pianificare per la vita dello strumento e non solo per la sua nascita, restare coinvolti, proteggere la propria uscita e trattare il lancio come l'inizio del vero lavoro.
Il software su misura è davvero uno dei migliori investimenti che una piccola impresa possa fare una volta cresciuta oltre gli strumenti standard che tutti condividono. Un sistema modellato esattamente su come lavori tu, anziché costringere la tua attività a contorcersi attorno al prodotto di qualcun altro, è un vantaggio reale e duraturo. Le imprese che ci arrivano non sono quelle con i budget più grandi. Sono quelle che hanno evitato i sette errori qui sopra, ed è una questione di giudizio, non di denaro.
Stai pensando a un software su misura?
La conversazione più preziosa avviene di solito prima che venga costruito qualcosa, quando capiamo se ti serve davvero un software su misura e, in tal caso, la versione più piccola da cui vale la pena partire. Senza pressioni e senza tecnicismi.
Scopri come sviluppiamo software su misuraDomande frequenti
Quanto costa un software su misura per una piccola impresa?
Un software su misura è meglio degli strumenti standard?
Come faccio a capire se un fornitore di software è valido?
Di chi è il codice in un progetto di software su misura?
Perché tanti progetti di software su misura falliscono?

Have a nice day è uno studio software che aiuta le piccole e medie imprese a digitalizzarsi — automazione, IA e software su misura che funziona nelle operazioni quotidiane, non solo sulle slide.