La decisione che precede la tecnica
Prima di collegare qualsiasi cosa va risposta una domanda per ciascun tipo di dato: chi comanda? Se il prezzo di un prodotto può essere modificato sia nel gestionale sia nell'e-commerce, prima o poi divergeranno, e nessuna integrazione può risolvere un conflitto che nasce da un'ambiguità organizzativa.
| Dato | Fonte | Chi lo riceve |
|---|---|---|
| Anagrafica prodotto e prezzo di listino | Gestionale | E-commerce, CRM |
| Giacenza | Gestionale | E-commerce |
| Anagrafica cliente | Dipende: gestionale per i clienti fatturati, CRM per i potenziali | Reciproca, con regole |
| Opportunità e trattative | CRM | Nessuno, finché non diventano ordini |
| Ordine web | E-commerce | Gestionale |
| Stato spedizione | Gestionale o corriere | E-commerce, cliente |
| Fatture e pagamenti | Gestionale | CRM, per lo storico cliente |
La riga dell'anagrafica cliente è quella che genera più problemi: un contatto nel CRM che diventa cliente deve trasformarsi in anagrafica nel gestionale senza duplicarsi, e serve una regola su cosa fare quando i dati differiscono.
Da quale collegamento partire
Tre sistemi generano sei possibili direzioni di collegamento. Farli tutti insieme è il modo più comune di trasformare un'integrazione in un progetto lungo che non arriva mai in produzione.
- 01
Giacenze dal gestionale all'e-commerce
È quasi sempre il primo: risolve il problema più costoso, che è vendere prodotti esauriti, e tecnicamente è il più semplice perché va in una sola direzione.
- 02
Ordini dall'e-commerce al gestionale
Elimina la ribattitura, che è il lavoro manuale più pesante. Richiede una mappatura dei prodotti e delle modalità di pagamento.
- 03
Anagrafiche tra CRM e gestionale
Più delicato perché è bidirezionale. Va affrontato dopo, quando i primi due funzionano e c'è fiducia nel sistema.
- 04
Fatture e storico verso il CRM
Utile ma non urgente: serve al commerciale per avere il quadro, non a far funzionare l'operatività.
Il vincolo che decide il progetto
Non è la complessità della logica: è quanto sono aperti i sistemi. Un gestionale con API documentate rende l'integrazione lineare; uno che espone solo esportazioni su file richiede un livello intermedio e accetta un ritardo. Entrambi funzionano, ma il preventivo cambia molto.
| Apertura del sistema | Cosa comporta | Freschezza dei dati |
|---|---|---|
| API documentate | Integrazione diretta | Tempo reale o quasi |
| Accesso al database | Livello intermedio da costruire | Buona, con sincronizzazioni frequenti |
| Esportazione su file programmata | Ponte con importazioni periodiche | Minuti o ore di ritardo |
| Nessun accesso | Va valutato se cambiare il sistema | Non integrabile |
Per le giacenze un ritardo di qualche minuto è irrilevante; per gli ordini di solito anche. È il motivo per cui la terza riga copre bene la maggior parte dei casi reali, ed è una notizia migliore di quanto sembri.
Gli errori: la parte che si taglia sempre
Un'integrazione funziona finché non smette, e quando smette lo fa in silenzio. Il caso tipico: un prodotto nuovo senza corrispondenza, un ordine con un metodo di pagamento non mappato, una connessione che cade di notte. Se nessuno se ne accorge, i due sistemi divergono per giorni.
Cosa pretendere in qualsiasi integrazione
- Un registro di cosa è stato sincronizzato e quando.
- Una notifica a una persona quando qualcosa fallisce, non solo una riga in un log.
- Il ritentativo automatico per gli errori temporanei, come una connessione caduta.
- Una coda visibile di ciò che non è passato, con il motivo.
- La possibilità di rilanciare manualmente un elemento fallito, senza rifare tutto.
- Un controllo periodico di coerenza: i due sistemi hanno gli stessi numeri?