# La nostra specialità: far parlare tra loro i sistemi che già usi

> Quando ci chiamano, quasi mai manca un software: ne esistono già cinque o sei. Manca il filo che li tiene insieme. La differenza fra fare un sito e integrare sistemi, con tre esempi reali.

- **URL**: https://www.spsproject.net/software-house-integrazione-sistemi-aziendali/
- **Autore**: Anna De Carolis
- **Pubblicato**: 08/09/2026
- **Categorie**: Sviluppo Software

---

Lo stesso ordine esiste in tre posti diversi: nel CRM del commerciale, nel gestionale dell’amministrazione, nel file che chi prepara le spedizioni tiene aperto sul secondo monitor. Tre versioni, tre numeri che non coincidono mai del tutto, e la mattina in cui serve sapere qual è quello giusto si scopre che non lo sa nessuno.

Quando un’azienda ci chiama, quasi mai le manca un software. Ne ha già cinque, sei, a volte otto. Quello che manca è il filo che li tiene insieme. È il motivo per cui ci presentiamo come una **software house full-stack con una specializzazione precisa: l’integrazione dei sistemi** che l’azienda usa già, senza buttare niente e senza ricominciare da capo.

## Fare un sito e integrare sistemi sono due mestieri diversi

Sembra una distinzione da addetti ai lavori. Non lo è, e si vede subito quando un progetto va storto.

Un sito è un progetto con confini netti. Si parte da una pagina bianca, si decide come deve apparire, si scelgono i testi, si pubblica. Chi lo commissiona controlla praticamente tutto: design, contenuti, tempi. Quando è online, il lavoro è finito e si vede a occhio se funziona.

Un’integrazione no. Si lavora dentro casa d’altri, e la casa l’hanno costruita persone che spesso non ci sono più. Il gestionale ha quindici anni e le API non le ha mai avute. Il database esiste, ma lo schema non l’ha documentato nessuno. Il fornitore del software di magazzino risponde alle mail il martedì. E soprattutto: la parola “cliente” nel CRM significa una cosa, nel gestionale ne significa un’altra, e prima di scrivere una riga di codice bisogna decidere quale delle due vince.

> Un sito lo giudichi guardandolo. Un’integrazione la giudichi da quello che smetti di fare a mano il venerdì pomeriggio.

Questo è il lavoro vero: capire i dati prima di muoverli. Il codice, alla fine, è la parte più breve.

## Tre modi diversi di far parlare i sistemi

Non esiste una tecnica sola. Il punto di contatto giusto dipende da cosa c’è già in azienda, e cambia da caso a caso. Tre esempi dal nostro [portfolio](https://www.spsproject.net/portfolio/), risolti in tre modi differenti.

**Il componente che fa da intermediario.** In Aranea, la piattaforma per la gestione delle affiliazioni, l’architettura è divisa in tre pezzi: l’interfaccia in Angular, il backend in Node e TypeScript, e un client intermediario che orchestra la comunicazione fra i due. Non è un semplice ponte che passa messaggi. È il componente che decide chi parla, in che ordine, e cosa succede quando uno dei due lati non risponde. Su questo si regge il rilascio senza interruzioni di servizio: le parti si aggiornano una per volta, e chi sta usando la piattaforma non se ne accorge.

**Il plugin che collega il sito al motore.** Nel sistema di prenotazione multi-tenant che seguiamo dal 2023 ci sono quattro pezzi che si scambiano dati: un backoffice in Laravel con Filament, un’API in NestJS e TypeORM, Stripe per i pagamenti e un [plugin WordPress su misura](https://www.spsproject.net/sviluppo-plugin-wordpress/) installato sul sito pubblico. Il cliente finale vede solo un calendario dentro il proprio sito, con la sua grafica. Sotto, ogni disponibilità e ogni incasso passano da tre sistemi diversi e restano allineati.

**Dal macchinario alla dashboard.** Nel progetto IoT che seguiamo dal 2021 i macchinari industriali in campo comunicano via GSM con protocollo MQTT verso un backend Node e NestJS, che alimenta una dashboard Angular e un microservizio dedicato ai report automatici. Il dato nasce in officina e arriva a chi deve decidere senza che nessuno lo trascriva. È lo stesso principio delle [soluzioni IoT per l’Industria 4.0](https://www.spsproject.net/soluzioni-iot/): il valore non è il sensore, è il percorso che il dato fa dopo.

Tre progetti, tre tecnologie, un solo problema di fondo: due o più sistemi che devono restare d’accordo su cosa è vero.

![Integrazione dei sistemi: il dato del macchinario arriva alla dashboard](https://www.spsproject.net/wp-content/uploads/2026/09/integrazione-sistemi-macchinario-dashboard-1.jpg)

## Per quali aziende una software house di integrazione ha senso

Non è per tutti, e preferiamo dirlo prima.

Il nostro lavoro rende quando l’azienda ha **più software che non si parlano** e almeno una persona che ogni settimana fa da traduttore fra loro. Di solito i sistemi sono questi: un CRM per i commerciali, un gestionale o un ERP per amministrazione e magazzino, un e-commerce o un portale ordini, a volte macchinari che producono dati. Ognuno funziona bene per conto suo. Insieme, no.

I segnali sono sempre gli stessi. Qualcuno esporta un file da un programma e lo importa in un altro, con cadenza fissa. I numeri della riunione del lunedì vengono ricostruiti a mano il venerdì. Un cliente storico viene trattato come uno sconosciuto perchè il suo passato sta in un sistema che il commerciale non apre. Nessuna di queste cose, presa da sola, è un disastro; messe insieme sono un lavoro a tempo pieno che nessuno ha mai assunto.

Lavoriamo bene con le PMI strutturate del Nord Italia dove esiste una persona che conosce davvero i processi e ha voglia di raccontarli. Lavoriamo male con chi cerca solo il preventivo più basso, e con chi vuole sostituire tutto da zero: quasi sempre l’infrastruttura che c’è è migliore della sua reputazione, e va collegata, non rottamata.

## Come ci arriviamo, in pratica

Prima si guarda. Quali sistemi ci sono, chi li usa ogni giorno, quali dati devono muoversi e in che direzione. Questa parte si fa parlando con le persone, non leggendo la documentazione, che nella maggior parte dei casi non esiste.

Poi si sceglie il punto di contatto. A volte c’è un’API già pronta. Più spesso serve un [middleware che faccia da traduttore fra gestionale, CRM ed e-commerce](https://www.spsproject.net/integrazione-api-middleware-gestionali-crm-ecommerce/), perché i due lati parlano lingue diverse e nessuno dei due ha intenzione di cambiare. Quando le API mancano del tutto si lavora su quello che c’è: viste sul database, esportazioni schedulate, file su cartelle condivise. Meno elegante, stessa utilità.

Poi si costruisce il pezzo più piccolo che porta un beneficio visibile, e lo si mette in produzione. Prima quello. Il resto viene dopo, e viene meglio, perché a quel punto si è capito come si comportano davvero i due sistemi sotto carico.

È qui che l’essere full-stack conta. Chi integra deve poter mettere le mani sul front-end, sul backend, sul database e a volte sul dispositivo in officina, nella stessa settimana. Se ogni strato ha un fornitore diverso, il tempo se ne va nelle riunioni fra fornitori.

## Il filo che tiene insieme tutto il resto

Facciamo anche siti, applicazioni mobile, software gestionali. Ma il filo che attraversa i progetti degli ultimi anni è sempre lo stesso: togliere attriti fra sistemi che dovrebbero collaborare e non lo fanno.

Se mentre leggevi ti sono venuti in mente i nomi di due programmi che nella tua azienda non si parlano, quella è già metà dell’analisi. Scrivici quali sono: ti diciamo se si possono collegare, come, e da quale pezzo conviene partire. Prima di qualsiasi preventivo, e senza impegno.

## Domande frequenti

### Che differenza c'è tra fare un sito e integrare due software?

Un sito parte da una pagina bianca e ha confini chiari: design, contenuti, pubblicazione. Un'integrazione si lavora dentro sistemi che esistono già, spesso senza documentazione e senza API. Il lavoro principale non è scrivere codice, ma capire cosa significa lo stesso dato nei due sistemi e decidere quale versione vince.

### Si può integrare un gestionale che non ha le API?

Quasi sempre sì. Quando le API non ci sono si lavora su quello che il sistema mette a disposizione: viste sul database, esportazioni schedulate, file su cartelle condivise, a volte un middleware che fa da traduttore. È meno elegante di un'API, ma il risultato per chi lavora è lo stesso.

### Devo sostituire i software che ho già?

Nella maggior parte dei casi no. L'infrastruttura che c'è in azienda è quasi sempre migliore della sua reputazione: il problema non è la qualità dei singoli programmi, è che non si scambiano dati. Prima si prova a collegarli; sostituire è l'ultima opzione, non la prima.

### Come capisco se la mia azienda ha un problema di integrazione?

I segnali sono concreti: qualcuno esporta un file da un programma per importarlo in un altro, i numeri della riunione si ricostruiscono a mano, un cliente storico viene trattato come sconosciuto perché il suo passato sta in un sistema che nessuno apre. Se succede ogni settimana, è un problema di integrazione.

### Da dove conviene partire con un progetto di integrazione?

Dal pezzo più piccolo che porta un beneficio visibile, messo in produzione presto. Prima si guarda quali sistemi ci sono e quali dati devono muoversi, poi si sceglie il punto di contatto, poi si collega un flusso solo. Il resto viene dopo e viene meglio, perché nel frattempo si è capito come i sistemi si comportano davvero.

---

Fonte: https://www.spsproject.net/software-house-integrazione-sistemi-aziendali/ — SpsProject