La decisione diventa più chiara se la si scompone in alcune domande concrete.
Domanda 1: questa funzione vi distingue dai concorrenti?
Il primo passo è separare ciò che rende diversa la vostra azienda da ciò che fanno tutte le aziende.
- Le funzioni standard (contabilità, paghe, posta elettronica, un CRM classico, la firma dei documenti) funzionano allo stesso modo ovunque. Comprare è quasi sempre la scelta giusta: non c'è alcun vantaggio nell'avere un proprio motore delle paghe.
- Le funzioni distintive (il modo in cui fate i prezzi, pianificate la produzione, configurate i prodotti, servite un certo segmento di clienti) sono quelle in cui vive il vostro know-how. Costringerle dentro un pacchetto generico può voler dire costringere l'azienda a lavorare come tutte le altre.
La maggior parte delle aziende ha bisogno di entrambe le cose: pacchetti standard per le funzioni comuni e software su misura mirato dove l'azienda è davvero diversa, collegati tra loro da integrazioni ben progettate.
Domanda 2: quanto aderisce il pacchetto ai vostri processi?
Quando si valuta un prodotto, l'aderenza va misurata sui processi reali, non su una demo:
- scrivete i dieci o quindici scenari che contano di più, con dati veri, e chiedete ai fornitori di eseguirli;
- distinguete la configurazione (impostazioni che il prodotto prevede) dalla personalizzazione (modifiche al codice del prodotto). La configurazione costa poco da mantenere; una personalizzazione pesante trasforma ogni aggiornamento in un progetto;
- chiedete che cosa succede alle personalizzazioni alla prossima versione principale.
Se gli scenari più importanti richiedono personalizzazioni significative, il pacchetto non è adatto, per quanto lunga sia la sua lista di funzioni.
Domanda 3: quanto costa davvero, nel tempo?
Confrontare un preventivo di licenze con una stima di sviluppo è fuorviante. Va confrontato il costo totale di possesso su un periodo realistico, ad esempio cinque anni, da entrambe le parti:
| Voce di costo | Comprare | Sviluppare |
|---|---|---|
| Iniziale | Licenze o abbonamento, implementazione, configurazione | Progettazione e sviluppo |
| Ricorrente | Abbonamento, contratto di assistenza, aumenti di prezzo | Hosting, manutenzione, aggiornamenti di sicurezza |
| Evoluzione | Personalizzazioni, nuovi test a ogni aggiornamento | Ulteriore sviluppo con i vostri tempi |
| Integrazione | Connettori verso gli altri sistemi | Idem: è sempre parte del costo |
| Impegno interno | Formazione, cambi di processo, amministrazione | Responsabilità di prodotto, requisiti, collaudo |
| Uscita | Export dei dati, migrazione, eventuali penali | Di solito minore, se codice e dati sono vostri |
Nessuna delle due colonne è automaticamente più economica. Il punto è vedere tutte le righe prima di decidere.
Domanda 4: di chi sono i dati e chi decide l'evoluzione?
Con un prodotto SaaS è il fornitore a decidere l'evoluzione del prodotto, i prezzi e, in parte, dove vengono trattati i vostri dati. Con il software su misura decidete voi, e ve ne assumete la responsabilità. Chiedetevi in particolare:
- Potete esportare tutti i vostri dati in un formato utilizzabile, in qualsiasi momento?
- Dove vengono conservati e trattati i dati, e sotto quale giurisdizione? Ne parliamo nell'articolo sul cloud sovrano.
- Che cosa succede se il fornitore viene acquisito, cambia i prezzi o dismette il prodotto?
Domanda 5: siete in grado di mantenere ciò che sviluppate?
Il software su misura non è un acquisto una tantum. Ha bisogno di manutenzione, aggiornamenti di sicurezza ed evoluzione per tutto il tempo in cui resta in uso. Prima di decidere di sviluppare, assicuratevi che:
- codice, documentazione e definizioni dell'infrastruttura siano di vostra proprietà;
- la tecnologia sia abbastanza diffusa da trovare persone in grado di lavorarci;
- esista una pipeline di rilascio con test automatici, perché le modifiche restino economiche e sicure nel tempo;
- qualcuno, un team interno o un partner con livelli di servizio chiari, sia responsabile della gestione.
La via di mezzo
La scelta raramente è secca. Gli approcci ibridi più comuni:
- Comprare il nucleo, sviluppare attorno: un ERP standard, con applicazioni su misura per i processi distintivi, integrate tramite API.
- Piattaforme low-code per strumenti interni con logica semplice, con limiti chiari su che cosa ci va.
- Estendere tramite le API del prodotto invece di modificarlo, così gli aggiornamenti restano possibili.
- Interfacce su misura sopra sistemi standard, ad esempio un'app mobile per il personale sul campo che lavora sull'ERP.
Da dove partire
Elencate le funzioni in discussione, classificate ciascuna come standard o distintiva e mettete alla prova i pacchetti migliori sui vostri scenari reali. Dove la risposta giusta è sviluppare, il nostro servizio di software engineering realizza applicazioni su misura trasferendovi codice, documentazione e pipeline: ciò che costruiamo resta un bene sotto il vostro controllo, non una dipendenza da noi.