Come scegliere una software house quando servono integrazioni tra sistemi già esistenti

Parliamo del tuo progetto →

Quando una PMI cerca una software house, spesso il problema reale non è scrivere nuovo codice, ma far dialogare sistemi già esistenti: gestionale, e-commerce, CRM, portale clienti, contabilità. In questo scenario la scelta del fornitore va fatta su criteri diversi da quelli di un progetto puramente funzionale. La domanda utile è: chi sa definire e mantenere un contratto stabile tra sistemi, senza rompere i flussi quando qualcosa cambia?

Microsoft descrive le API come un contratto tra servizi e sottolinea l’importanza di semantica, compatibilità e versioning per evitare rotture quando un sistema evolve (Microsoft Learn). Google Cloud evidenzia invece che un’API può restare coerente anche se cambia il backend, purché il contratto verso l’esterno resti stabile (Google Cloud). Per chi acquista, questo significa una cosa semplice: una buona software house non vende solo sviluppo, ma governo dell’integrazione nel tempo.

Quando questa guida è utile

Questa guida è adatta se:

  • oggi i dati vengono ricopiati a mano tra due o più sistemi;
  • un processo si interrompe quando cambia un campo, uno stato o una versione;
  • dovete sincronizzare ordini, clienti, listini, ticket o documenti;
  • il fornitore dovrà anche mantenere il connettore dopo il go-live.

Se invece il problema è solo una pagina vetrina o un sito senza scambi con altri applicativi, questi criteri pesano meno.

Cosa preparare prima di chiedere un preventivo

Prima di parlare con una software house conviene arrivare con quattro elementi minimi:

  1. Elenco dei sistemi coinvolti
    Per esempio: gestionale, e-commerce, CRM, magazzino.

  2. Flusso da automatizzare
    Cosa entra, cosa esce, chi crea il dato e chi lo consuma.

  3. Regole di business essenziali
    Quali campi sono obbligatori, quali stati sono ammessi, quando serve un controllo umano.

  4. Vincoli operativi
    Orari, volumi, limiti di sicurezza, dati sensibili, dipendenze da fornitori terzi.

Senza questi elementi è facile ricevere una proposta generica che non regge il lavoro reale.

I criteri di confronto che contano davvero

1) Requisiti e confini

Chiedi al fornitore di riscrivere il problema in modo preciso: quali sistemi parlano, quali dati si scambiano, quali azioni sono in sola lettura e quali modificano i dati. Se questa sintesi non torna, il progetto non è ancora pronto.

2) Contratto e documentazione

Un’integrazione affidabile richiede documentazione leggibile: campi, stati, codici di errore, dipendenze, versioni. Se il fornitore non sa spiegare come documenta il contratto tra sistemi, la manutenzione futura diventa fragile.

3) Versioning e compatibilità

Le API cambiano. La domanda non è se cambiano, ma come. Chiedi come vengono gestite le modifiche non compatibili, per quanto tempo resta supportata una versione precedente e chi decide quando un cambiamento diventa “breaking”. Microsoft insiste proprio su questi aspetti di evoluzione controllata (Microsoft Learn).

4) Errori, timeout e duplicati

Una proposta seria deve spiegare cosa succede se una chiamata fallisce dopo aver creato un record, oppure se il sistema ritenta la stessa operazione. Qui entrano in gioco retry, idempotenza, riconciliazione e log degli errori. Non basta dire “abbiamo gestito le eccezioni”.

5) Test e accettazione

Il test non deve fermarsi al singolo endpoint. Serve verificare il flusso completo: dati in ingresso, trasformazioni, esito nel sistema target e controllo finale lato business. Un fornitore serio distingue tra test tecnico e validazione operativa.

6) Manutenzione

Chiedi chi mantiene il connettore dopo il go-live, come si gestiscono i cambiamenti nei sistemi terzi, se esiste un piano di monitoraggio e quale supporto è previsto nel tempo. L’integrazione non finisce con il primo rilascio.

Segnali di rischio da non ignorare

Diffida se il fornitore:

  • parla solo di velocità di sviluppo;
  • non distingue tra integrazione iniziale e manutenzione;
  • non mostra come gestisce i casi limite;
  • non documenta errori e versioni;
  • non chiarisce chi prende decisioni quando un sistema terzo cambia.

Questi segnali non dicono che il fornitore sia inadeguato in assoluto, ma indicano che il progetto rischia di dipendere troppo da chi lo realizza oggi e troppo poco da un metodo trasferibile domani.

Esempio pratico: un processo manuale da sostituire

Caso tipico: gli ordini arrivano dall’e-commerce e vengono reinseriti a mano nel gestionale. L’operatore copia anagrafica, indirizzo, righe ordine e stato del pagamento. Ogni passaggio manuale aggiunge ritardi e possibilità di errore.

Input concreto da dare al fornitore

  • sistema A: e-commerce;
  • sistema B: gestionale;
  • dati da sincronizzare: ordine, cliente, indirizzo, totale, stato pagamento;
  • eccezioni: cliente già esistente, indirizzo incompleto, pagamento non confermato;
  • obiettivo: eliminare la ricopiatura manuale e lasciare solo le eccezioni da verificare.

Output atteso, in forma esemplificativa

  • ordine creato nel gestionale con ID tracciabile;
  • log di esito per ogni sincronizzazione;
  • blocco del flusso se mancano campi obbligatori;
  • segnalazione chiara quando un duplicato va controllato a mano.

Controlli di accettazione prima del go-live

Prima di firmare l’avvio, chiedi che siano verificabili almeno questi punti:

  • i dati arrivano nel sistema giusto;
  • gli errori sono leggibili da chi li deve risolvere;
  • i retry non creano duplicati;
  • una modifica del backend non rompe il contratto esterno;
  • esiste un responsabile per la manutenzione dopo la consegna.

Google Cloud ricorda che il backend può evolvere senza cambiare la public API, ma solo se il contratto resta coerente (Google Cloud). È un buon criterio anche per valutare un fornitore: l’obiettivo non è solo far funzionare il primo rilascio, ma progettare un’integrazione che resti comprensibile, testabile e mantenibile.

La domanda giusta da fare nella prima call

Una domanda efficace da porre al fornitore è questa: “Come progettate l’integrazione perché resti stabile quando uno dei sistemi cambia versione o comportamento?”

Se la risposta parla di contratto, documentazione, test, versioning e manutenzione, siete sulla strada giusta. Se parla solo di tecnologia o di velocità, mancano ancora i requisiti per decidere.

Se il vostro caso è simile, il passo successivo è descrivere il processo da integrare: sistemi coinvolti, dati scambiati e punti in cui oggi intervenite ancora a mano.

Fonti