Integrazione CRM e gestionale: dati, responsabilità e brief da preparare prima del preventivo

Parliamo del tuo progetto →

Quando serve davvero questa guida

Se dovete integrare CRM e gestionale, la domanda utile non è “si possono collegare?”, ma che cosa deve passare tra i due sistemi, chi è responsabile di ogni dato e come si gestiscono conflitti, errori e duplicati. Microsoft invita a scegliere il design dell’integrazione in base al risultato operativo atteso, distinguendo il caso d’uso prima ancora della tecnologia. (choose design, guidance product)

Questa guida è pensata per vendite, amministrazione e responsabile IT quando devono preparare un brief da portare a un fornitore. L’obiettivo è arrivare a un preventivo confrontabile, non a una promessa generica di sincronizzazione.

I tre errori più comuni sono questi:

  • chiedere un prezzo senza aver definito l’autorità sui dati;
  • immaginare una sincronizzazione bidirezionale “totale” senza verificare limiti e permessi del prodotto;
  • scoprirе troppo tardi che API, licenze, rate limit, ambienti o regole sui duplicati cambiano il perimetro.

Prima decisione: che problema state risolvendo

Prima di parlare di strumenti, scrivete in una frase il processo che volete migliorare. Per esempio:

  • evitare ricopie manuali tra CRM e gestionale;
  • ridurre errori nelle anagrafiche cliente;
  • allineare stato commerciale e stato amministrativo;
  • automatizzare l’apertura o l’aggiornamento di un record;
  • impedire che due sistemi scrivano lo stesso campo senza regole.

Microsoft distingue tra integrazione di interfaccia, di dati e di processo: la scelta dipende da ciò che deve accadere nel lavoro quotidiano, non dal nome del software coinvolto. (choose design)

Se il problema è soprattutto organizzativo, la parte tecnica viene dopo. Se non sapete chi decide sui dati, nessuna API risolve l’ambiguità.

Cosa preparare prima del primo confronto

Per fare un primo incontro utile con un fornitore, preparate un materiale minimo. Non serve essere già tecnici, ma serve essere specifici.

Materiale da avere pronto

  1. elenco dei sistemi coinvolti: CRM, gestionale/ERP, eventuale middleware o portale;
  2. lista dei campi da scambiare;
  3. direzione del flusso per ogni campo;
  4. responsabile interno di ciascun dato;
  5. esempi di errore o conflitto che oggi risolvete a mano;
  6. vincoli di sicurezza e dati da non inviare fuori ambiente;
  7. criteri di successo del pilota.

Se manca uno di questi elementi, il preventivo rischia di essere troppo generico o, peggio, preciso solo in apparenza.

Chi comanda sui dati

Il punto più delicato è stabilire una sola autorità per ogni campo, oppure una regola di conflitto chiarissima. Trattare ogni dato come modificabile da entrambi i sistemi crea quasi sempre eccezioni difficili da governare.

Una regola pratica è questa:

  • un sistema è autorevole per il valore;
  • l’altro può leggere o proporre;
  • ogni eccezione viene tracciata.

Microsoft documenta la Web API di Dataverse come strumento per operare sui dati e richiama controlli e comportamenti specifici del prodotto, inclusa la gestione dei duplicati tramite intestazioni dedicate. Questo significa che l’esistenza dell’API non basta: bisogna verificare se copre davvero gli oggetti e i comportamenti di business che servono. (perform operations Web API)

Domande di governance da fare internamente

Per ogni campo chiedete:

  • chi lo crea per primo;
  • chi può modificarlo;
  • chi approva la modifica;
  • cosa succede se i due sistemi si contraddicono;
  • dove finisce il log;
  • chi legge il log e con quale frequenza.

Se queste risposte non sono esplicite, l’integrazione sarà fragile già in esercizio.

Esempio simulato completo: cliente C-001

Nota: l’esempio seguente è simulato e serve solo a mostrare come compilare un brief comparabile. Non descrive un cliente reale né una soluzione già verificata.

Scenario

  • Sistema A: CRM vendite
  • Sistema B: gestionale/ERP
  • Obiettivo: allineare alcune anagrafiche cliente e poche regole operative essenziali
  • Campi nel perimetro: identificativo cliente, ragione sociale, stato cliente, indirizzo di fatturazione

Tabella di autorità dei dati

Campo Sistema autorevole Direzione del flusso Responsabile decisione Regola di conflitto
Identificativo cliente Gestionale ERP → CRM Amministrazione non sovrascrivere un ID già assegnato
Ragione sociale Gestionale ERP → CRM Amministrazione il CRM può proporre, l’ERP decide
Stato cliente CRM CRM → ERP Vendite prevale l’ultimo aggiornamento approvato
Indirizzo di fatturazione Gestionale ERP → CRM Amministrazione il CRM può solo leggere, salvo eccezioni tracciate

Dati di partenza simulati

Anagrafica C-001 nel CRM
- identificativo cliente: non presente
- ragione sociale: Alfa Srl
- stato cliente: attivo
- indirizzo: Via Roma 10, Firenze

Anagrafica C-001 nel gestionale
- identificativo cliente: IT-000184
- ragione sociale: Alfa S.r.l.
- stato cliente: sospeso
- indirizzo di fatturazione: Via Roma 10, Firenze

Cosa deve accadere

Il brief non deve chiedere solo “sincronizzazione”, ma risultati verificabili:

  • il CRM riceve l’ID dal gestionale e non lo rigenera;
  • la ragione sociale segue la fonte autorevole stabilita;
  • lo stato cliente resta sotto il controllo del reparto vendite;
  • ogni eccezione viene registrata con origine, data e operatore.

Quattro casi di prova da includere nel preventivo

Questi casi non sono test reali eseguiti: sono scenari simulati che il fornitore dovrebbe tradurre in logica tecnica e criteri di accettazione.

1. Creazione iniziale

Input simulato: il gestionale invia al CRM un cliente nuovo con identificativo IT-000184, ragione sociale e indirizzo.

Risultato atteso:

  • il CRM crea il record;
  • l’identificativo non viene rigenerato;
  • i campi esclusi restano invariati;
  • il log registra origine, orario e ID del record.

2. Modifica concorrente

Input simulato: il commerciale cambia lo stato cliente nel CRM da attivo a da richiamare, mentre l’amministrazione corregge la ragione sociale nel gestionale.

Risultato atteso:

  • il CRM accetta la modifica sul campo di sua competenza;
  • la ragione sociale viene allineata dal gestionale secondo la regola definita;
  • il conflitto non viene risolto “a caso” dal sistema;
  • il log segnala che due sistemi hanno toccato campi diversi ma collegati.

3. Duplicato

Input simulato: arriva un nuovo record con nome simile, senza ID esterno, ma con dati che suggeriscono una possibile duplicazione.

Risultato atteso:

  • il flusso non crea automaticamente un secondo cliente;
  • il record va in revisione;
  • un operatore decide se collegare, fondere o scartare;
  • la regola di gestione duplicati è esplicita.

Qui è utile ricordare che Dataverse documenta controlli di rilevamento duplicati nell’uso della Web API, ma il comportamento reale va verificato sul prodotto in uso e nel setup effettivo. (perform operations Web API)

4. Sistema indisponibile

Input simulato: il gestionale non risponde durante una sincronizzazione notturna.

Risultato atteso:

  • il record non si perde;
  • l’evento va in coda o in retry secondo la regola concordata;
  • il team riceve un alert;
  • il recupero usa un identificativo idempotente per evitare doppie scritture.

Come impostare un pilota senza allargare troppo il perimetro

Microsoft raccomanda di scegliere il design dell’integrazione in funzione del processo, delle capacità del prodotto e delle limitazioni effettive. In pratica: non progettate subito tutto il dominio aziendale, ma un sottoinsieme controllabile. (choose design, guidance product)

Fase 1 — Definizione del perimetro

  • scegliete un solo oggetto principale, per esempio cliente;
  • scegliete pochi campi davvero utili;
  • fissate chi è proprietario di ogni campo;
  • scrivete la direzione del flusso.

Fase 2 — Verifica tecnica minima

  • controllate le API realmente esposte;
  • verificate autenticazione e permessi;
  • chiedete come vengono trattati errori e retry;
  • chiarite se l’integrazione è nativa, custom o mediata da servizi intermedi.

Fase 3 — Pilota ristretto

  • usate pochi record o un solo reparto;
  • osservate duplicati, conflitti e ritardi;
  • misurate il lavoro manuale residuo;
  • estendete solo dopo approvazione congiunta di IT e business.

Le guide Microsoft sulle integrazioni richiamano anche l’importanza di distinguere flussi inbound/outbound e scenari sincroni o asincroni: questa scelta cambia monitoraggio, gestione errori e carico operativo. (integrate general guidance)

Cosa non inviare via email

Per il primo confronto evitate di spedire materiali che aumentano il rischio o confondono il fornitore:

  • credenziali e token;
  • export completi con dati personali;
  • chiavi API;
  • schermate amministrative con informazioni sensibili;
  • file di test non mascherati se non servono davvero.

Molto meglio inviare:

  • un estratto anonimo o mascherato;
  • il dizionario campi;
  • le regole di conflitto;
  • il volume indicativo;
  • i casi di errore più frequenti;
  • i responsabili interni.

Se il fornitore chiede dati reali per il collaudo, il testo del brief dovrebbe specificare che l’invio avviene solo in ambiente di test e con canali approvati.

Domande da fare al fornitore

Queste domande aiutano a capire se il preventivo è solo commerciale o anche progettuale.

  1. Quale sistema è fonte di verità per ciascun campo?
  2. Il flusso è one-way o bidirezionale?
  3. Come gestite duplicati e conflitti?
  4. Le API del prodotto coprono davvero gli oggetti che servono?
  5. Ci sono limiti di chiamata, throttling o finestre di sincronizzazione?
  6. Come viene registrato un errore e come si rigioca?
  7. Servono componenti custom o basta una configurazione?
  8. Quali dati restano fuori dal perimetro standard?
  9. Come gestite permessi e minimo privilegio?
  10. Qual è la parte che resta manuale anche dopo l’integrazione?

Microsoft segnala che il design va scelto in base al caso d’uso e alle capacità del prodotto; una Web API disponibile non equivale a un processo pronto senza verifiche su oggetti, permessi e comportamento reale. (guidance product, perform operations Web API)

Criteri di accettazione: chi controlla cosa e quando

Un preventivo utile dovrebbe già contenere una mini tabella di accettazione. Senza questa parte, il progetto rischia di restare ambiguo fino alla messa in produzione.

Controllo Chi lo verifica Quando Esito atteso
ID cliente non viene rigenerato Amministrazione fine pilota nessuna duplicazione di identità
Stato cliente segue la regola definita Vendite fine pilota nessuna sovrascrittura non autorizzata
Conflitti registrati nel log IT durante il pilota tracciabilità completa
Record duplicati messi in revisione Amministrazione + IT durante il pilota nessun merge automatico non approvato
Errori di sistema recuperabili IT test di indisponibilità retry o coda funzionante

Limiti da verificare caso per caso

Ci sono alcuni aspetti che vanno verificati sul prodotto reale e non presunti in anticipo:

  • la disponibilità di API non equivale a integrazione pronta;
  • un campo condiviso tra CRM e gestionale può richiedere una sola autorità, non due;
  • le integrazioni bidirezionali aumentano la complessità dei conflitti e della riconciliazione;
  • una funzione presente nel prodotto può essere limitata da licenze, permessi, regioni di hosting o modelli di dati.

La documentazione Microsoft sulla disponibilità dei prodotti ricorda che anche copertura geografica e data residency possono incidere sul perimetro del progetto e sulle verifiche da fare prima della firma. (availability)

Dove collocare questa richiesta nel percorso Dedaloop

Se il problema è davvero integrare CRM e gestionale, il punto di partenza più coerente è Sviluppo software su misura e integrazioni. Se volete preparare il primo contatto, la pagina Contatti Dedaloop è il passo successivo naturale: portate con voi il brief compilato, non le credenziali.

Può essere utile anche confrontare il caso con Come scegliere una software house quando servono integrazioni tra sistemi già esistenti e, se il tema dei permessi vi interessa, con Permessi delle integrazioni: una verifica pratica del minimo privilegio.

Cosa consegnare al fornitore dopo questa guida

Alla fine del lavoro interno dovreste avere un brief di una pagina, o poco più, con questi elementi:

  • sistemi coinvolti;
  • obiettivo del collegamento;
  • elenco campi;
  • autorità dei dati;
  • direzione del flusso;
  • regole sui duplicati;
  • gestione errori e retry;
  • dati esclusi;
  • ambienti di test;
  • criteri di accettazione.

Questo è il materiale che rende comparabili i preventivi e consente al fornitore di dire con chiarezza cosa è standard, cosa è custom e cosa va ancora verificato.

Il punto decisivo

L’integrazione CRM–ERP non si decide sul nome del software, ma sulla chiarezza del processo. Se sapete chi è responsabile di ogni campo, come trattare i duplicati, cosa fare in caso di errore e quali limiti del prodotto cambiano il perimetro, il preventivo diventa confrontabile. Se questi elementi mancano, il rischio è comprare una promessa generica invece di una soluzione verificabile.

Fonti