Collegare un CRM a un ERP: quattro approcci e dove ognuno si rompe

Perché è più difficile di quanto sembri

I due sistemi non sono d'accordo su cosa sia un cliente. Nel CRM è un'opportunità di vendita con un contatto collegato. Nell'ERP è un'anagrafica con condizioni di pagamento, un indirizzo di fatturazione e uno di spedizione che possono differire, e un codice fornitore se a sua volta vi vende qualcosa.

Per questo questi progetti raramente si fermano sul collegamento. Si fermano sulla decisione di cosa succede quando i campi non coincidono, chi vince quando entrambe le parti sono cambiate, e cosa fare di un'anagrafica presente due volte.

Approccio 1: il connettore pronto

Molti sistemi offrono un'integrazione già fatta. Se il vostro processo assomiglia a quello che il fornitore ha immaginato, è la risposta economica e giusta, e non c'è motivo di costruire nulla.

Si rompe nel momento in cui una regola è vostra. Uno sconto che dipende sia dalla quantità sia dal cliente, un prodotto venduto in due unità di misura, un'approvazione richiesta solo sopra una certa soglia. Il connettore non ha modo di rappresentarlo, e di solito nemmeno di lasciarvi intervenire.

Approccio 2: una piattaforma di automazione (iPaaS)

Zapier, Make e simili sono ottimi per collegamenti semplici: si crea un'offerta, si crea un'anagrafica. Sono rapidi da configurare e non richiedono uno sviluppatore.

Si sfaldano quando la logica si ramifica. Uno scenario con otto condizioni annidate diventa uno schema che due mesi dopo non capisce più nessuno. Non c'è un vero controllo di versione, testare è scomodo, e quando qualcosa fallisce a metà non esiste un modo pulito di tornare indietro.

Una regola pratica che regge: se il processo richiede più di tre decisioni consecutive, o deve ricordare qualcosa tra un'esecuzione e l'altra, non è più lavoro da iPaaS.

Approccio 3: codice punto a punto

Uno script che legge da un'API e scrive su un'altra. Veloce da scrivere, risolve il problema che avete davanti.

Il guaio arriva con il terzo sistema. Due sistemi fanno un collegamento; quattro ne fanno sei, e nessuno sa dell'esistenza degli altri. Dopo un anno ci sono cinque script su un server che nessuno tocca, con la logica di business sparsa tra loro.

Approccio 4: uno strato intermedio che contiene la logica

Invece di collegare ogni sistema a ogni altro, si costruisce un unico punto che capisce il processo. Legge dalle fonti, mantiene lo stato, sa cosa ha già trattato e decide cosa scrivere e dove.

All'inizio costa di più. La giustificazione sta in tre cose: si può testare, si può vedere perché ha fatto quello che ha fatto, e lo si può fermare per un'approvazione umana prima di qualsiasi passo che tocchi il denaro.

Non serve a tutti. Se il vostro processo è davvero semplice, l'approccio 1 o 2 è migliore e costa meno.

Come scegliere

Quattro domande decidono quasi sempre:

• Quante decisioni ci sono nel processo? Più di tre: lasciate perdere l'iPaaS.
• Un'azione sbagliata costa denaro o arriva al cliente? Se sì, serve un punto di approvazione.
• Quanti sistemi sono coinvolti? Tre o più: uno strato intermedio si ripaga.
• Le vostre regole sono particolari o standard? Standard: non costruite nulla.

La parte che tutti sottovalutano

Non la scrittura. L'abbinamento. Cosa succede quando un cliente esiste nel CRM con un nome e nell'ERP con uno leggermente diverso. Cosa succede quando entrambi sono stati modificati dall'ultima sincronizzazione. Cosa succede quando l'API restituisce un errore dopo che avete già creato metà delle righe.

Nei progetti reali è tra un terzo e la metà del lavoro. Un piano che non gli assegna tempo lo troverà lo stesso, più tardi e sotto pressione.

Domande che tornano sempre

Meglio Zapier o codice su misura per collegare un CRM a un ERP?

Zapier e strumenti simili vanno bene quando il collegamento è un trigger con un'azione e al massimo due o tre decisioni, e non c'è nulla da ricordare tra un'esecuzione e l'altra. Serve codice appena la logica si ramifica, va testata, o deve tornare indietro in modo pulito quando un passo fallisce a metà. Il discrimine è la complessità delle decisioni, non la dimensione dell'azienda.

Cosa va storto di solito in un'integrazione CRM-ERP?

L'abbinamento delle anagrafiche, quasi sempre. Lo stesso cliente esiste nei due sistemi con nomi leggermente diversi, entrambi i lati vengono modificati tra una sincronizzazione e l'altra, e i duplicati si accumulano. Mettete in conto che le regole di abbinamento e di conflitto prendano da un terzo a metà del progetto, e decidetele prima di scrivere codice.

Quanto tempo serve per collegare un CRM a un ERP?

Un singolo flusso ben definito, con dati puliti e API documentate, richiede di solito qualche settimana. Ad allungare i tempi non è il collegamento ma le decisioni intorno: chi vince in caso di conflitto, come si riconosce un cliente, cosa succede a un fallimento parziale. I progetti che rispondono prima a queste domande finiscono più o meno nei tempi.

Serve uno strato intermedio o basta un collegamento diretto?

Il collegamento diretto basta per due sistemi e un flusso. Lo strato intermedio si ripaga da tre sistemi in su, o quando un'azione sbagliata arriva al cliente o tocca il denaro: è lì che serve un unico punto da testare, da ispezionare a posteriori e in cui fermarsi per un'approvazione umana.