Perché l'integrazione ERP con Salesforce fallisce e come risolverla

Le integrazioni SAP-Salesforce di solito falliscono per ragioni di business, non tecniche. La sincronizzazione gira, ma i dati sono troppo vecchi per la decisione che l'utente deve prendere, i due sistemi non concordano su quale record cliente sia quello giusto, oppure nessuno è responsabile del flusso quando un aggiornamento lo rompe. La soluzione è progettare partendo dalla decisione dell'utente, pulire prima i dati, scegliere un middleware adatto alla propria scala e dare a ogni flusso un responsabile e un piano per i guasti.

Questo articolo è per CIO, responsabili di sales operations e integration lead che collegano Salesforce a SAP. Tratta i quattro modelli di fallimento, le opzioni di integrazione, ciò che serve a un'integrazione affidabile e un template di specifica.

Ho lavorato con aziende in cui anche un ritardo di un'ora tra i sistemi causava errori di quotazione che portavano a trattative perse. La causa abituale è che nessuno si era chiesto quanto dovessero essere freschi i dati di giacenza perché un commerciale potesse basarci un'offerta.

Un'integrazione può funzionare tecnicamente ed essere rotta sul piano commerciale. È da questa distinzione che si parte.

Frequenza di sincronizzazione sbagliata per la decisione

La sincronizzazione batch va bene per alcuni dati. Non va bene per le scorte available-to-promise, per i prezzi o per lo stato degli ordini, dove i clienti si aspettano una risposta subito.

Lo schema del fallimento è questo: il team di integrazione costruisce ciò che è tecnicamente comodo per i volumi e imposta gli intervalli dei batch su basi tecniche. Nessuno lato business verifica se quella frequenza regge la decisione che l'utente deve prendere.

Prima di specificare qualsiasi cosa, faccia una domanda sola: quanto può essere vecchio il dato per restare utile? Un aggiornamento giornaliero può andare bene per le modifiche all'anagrafica clienti. Per la disponibilità di magazzino nelle vendite B2B, qualsiasi cosa oltre i quindici minuti è un problema.

1. 01Anagrafica clientiDa SAP a Salesforce, 24 ore
2. 02Listini prezziDa SAP a Salesforce, 1 ora
3. 03Disponibilità di magazzinoDa SAP a Salesforce, 15 minuti
4. 04Opportunità vintaDa Salesforce a SAP, immediato
5. 05Stato dell'ordineDa SAP a Salesforce, 15 minuti
6. 06Fattura e pagamentoDa SAP a Salesforce, 24 ore

Offerta, ordine e fattura coincidono

Qualità dei dati non allineata

Se il nome dell'azienda in Salesforce è formattato in modo diverso rispetto all'anagrafica clienti in SAP, ogni sincronizzazione crea disallineamenti da correggere a mano.

Ho lavorato con team che ogni settimana passavano ore a riconciliare le informazioni di base sui clienti tra Salesforce e l'ERP, e ho visto progetti in cui la sola mappatura delle gerarchie dei clienti ha richiesto settimane, perché i due sistemi definivano in modo diverso che cosa fosse un «account». I sistemi erano stati gestiti separatamente per anni e si erano allontanati in modi che nessuno aveva mappato.

Pulisca i dati prima di integrare. Sembra ovvio. È il passaggio che viene saltato con più regolarità.

Architettura sbagliata per la scala

L'integrazione point-to-point funziona con due sistemi, pochi flussi e processi stabili. È il modo più economico per iniziare.

Non scala. Basta aggiungere un modulo SAP, una nuova business unit in Salesforce o un terzo sistema, e le connessioni si moltiplicano. Ognuna va mantenuta, testata e diagnosticata separatamente.

Un middleware (SAP Integration Suite, MuleSoft, Boomi o simili) offre un unico livello governato, con monitoraggio centrale e gestione degli errori. Il prezzo è un investimento iniziale in architettura e governance. Le aziende che adottano un middleware senza dargli un responsabile con nome e cognome finiscono con gli stessi problemi del point-to-point, più una piattaforma che nessuno capisce.

Nessuna governance dell'integrazione

Ogni release di Salesforce e ogni support package SAP può rompere un flusso: modifiche alle API, nuove regole di validazione, campi cambiati, nuovi requisiti di autenticazione. Le integrazioni costruite e poi dimenticate falliscono al primo aggiornamento che nessuno ha sottoposto a test di regressione. È il guasto post go-live più comune che vedo.

SAP Integration Suite. La piattaforma di integrazione di SAP su SAP BTP e la scelta naturale negli ambienti centrati su SAP. Gestisce bene IDoc, BAPI, OData e i formati di messaggio SAP e ha contenuti predefiniti per gli scenari SAP più comuni. I processi di business complessi richiedono comunque flussi di integrazione personalizzati e competenze di integrazione reali. Se è ancora su SAP PI/PO, tenga presente che la manutenzione mainstream termina a fine 2027, quindi i nuovi flussi Salesforce non vanno costruiti lì. Su RISE, verifichi quale entitlement SAP BTP include già il suo contratto prima di acquistarne altri.

MuleSoft. Di proprietà di Salesforce dal 2018, con un'ampia libreria di connettori, un connettore ufficiale per SAP S/4HANA e template acceleratori per l'order-to-cash SAP. Una buona scelta se ce l'ha già. Il problema per le organizzazioni molto centrate su SAP: MuleSoft richiede competenze distinte, e il team che gestisce il suo programma SAP probabilmente non è quello che dovrebbe progettare la sua architettura MuleSoft.

Boomi. Una piattaforma di integrazione cloud (indipendente da Dell dal 2021) con connettori SAP e Salesforce e una barriera d'ingresso più bassa di MuleSoft. Ragionevole per le organizzazioni del mid-market che vogliono un middleware governato senza il costo o la complessità di MuleSoft.

API point-to-point. Chiamate REST o SOAP dirette tra Salesforce e SAP evitano il costo del middleware. Richiedono un versioning delle API disciplinato, test di regressione a ogni release e un team che conosca entrambi i sistemi. Vanno bene per casi semplici e stabili. Per qualsiasi cosa complessa sono un accumulatore di debito.

La mia guida a SAP CPI e Integration Suite approfondisce la piattaforma lato SAP, e le cinque opzioni CRM per SAP mettono a confronto i CRM stessi.

1. Una specifica di ogni flusso: campi, direzione, frequenza, mappatura delle chiavi e che cosa succede quando i due sistemi non concordano.
2. Una progettazione esplicita dei guasti. Quando una sincronizzazione fallisce, che fine fanno i dati in transito? Quanti tentativi? Chi riceve l'avviso? Qual è il recupero manuale? Su questo punto la maggior parte delle integrazioni è sotto-progettata.
3. Test di regressione prima di ogni aggiornamento. Salesforce rilascia tre release importanti all'anno, e SAP ha i propri support package e aggiornamenti. Prima di ciascuno dovrebbe girare una suite automatizzata che copra i flussi critici.
4. Monitoraggio con alert. Un guasto silenzioso è peggio di uno rumoroso. Gli errori che si accumulano per giorni sono molto più difficili da risolvere di quelli intercettati in pochi minuti.
5. Un responsabile. Una persona che sa che cosa fa l'integrazione, vede quando si rompe e ha l'accesso e l'autorità per sistemarla.

Compili una riga per flusso prima che qualcuno scriva un documento di specifica. Se una cella è vuota, il flusso non è pronto per essere costruito. I valori qui sotto sono esempi; concordi i suoi con le persone che usano i dati.

Flusso	Direzione	Trigger e frequenza	Dato più vecchio accettabile	Sistema di riferimento	In caso di errore	Responsabile
Anagrafica clienti	Da SAP a Salesforce	Alla modifica	24 ore	SAP	Nuovo tentativo, poi avviso al data steward	Responsabile dell'anagrafica clienti
Disponibilità di magazzino	Da SAP a Salesforce	A richiesta o quasi in tempo reale	15 minuti	SAP	Mostra il flag «verificare con le operations»	Responsabile dei sistemi di supply chain
Listini prezzi e condizioni	Da SAP a Salesforce	Alla modifica	1 ora	SAP	Blocca l'offerta se il prezzo è obsoleto	Responsabile pricing
Dall'opportunità vinta all'ordine di vendita	Da Salesforce a SAP	Alla chiusura	Immediato	Salesforce fino alla creazione dell'ordine, poi SAP	Accoda e avvisa le sales operations	Responsabile sales operations
Stato di ordine e consegna	Da SAP a Salesforce	A ogni milestone	15 minuti	SAP	Nuovo tentativo, poi avviso al supporto integrazione	Integration lead
Stato di fatture e pagamenti	Da SAP a Salesforce	Giornaliero	24 ore	SAP	Avviso ai sistemi finance	Responsabile dei sistemi finance

La colonna «dato più vecchio accettabile» è quella che la maggior parte dei team non compila mai. La concordi con gli utenti che prendono le decisioni, non con il solo team di integrazione. Se è già in ritardo, i ritardi nella delivery di SAP Integration Suite ne descrivono le cause più comuni.

I record cliente non coincidono. Causa: le due anagrafiche clienti non sono mai state allineate. Soluzione: riconciliarle prima del go-live, fare di SAP il sistema di riferimento per i dati cliente e imporre la mappatura nell'integrazione.

Lo stato dell'ordine non si aggiorna in Salesforce. Causa: l'integrazione copre il percorso dall'offerta all'ordine ma non i callback di stato. Soluzione: inviare da SAP SD a Salesforce gli aggiornamenti di stato a ogni milestone dell'ordine.

I prezzi dell'offerta sono diversi da quelli in fattura. Causa: i prezzi sono gestiti a mano in Salesforce e si discostano dalle condizioni di prezzo SAP. Soluzione: fare di SAP l'anagrafica dei prezzi e importare i prezzi in Salesforce tramite l'integrazione.

L'integrazione si rompe dopo un aggiornamento SAP. Causa: nel piano di aggiornamento non ci sono test di regressione dell'integrazione. Soluzione: includere i test di regressione dell'integrazione nel perimetro di ogni aggiornamento SAP.

Salesforce può integrarsi con SAP?

Sì, tramite SAP Integration Suite, MuleSoft, Boomi, altre piattaforme di integrazione o API dirette. I flussi tipici sono la sincronizzazione dell'anagrafica clienti, dall'opportunità vinta all'ordine di vendita, lo stato di ordine e consegna di ritorno verso Salesforce, i prezzi in Salesforce per le offerte e lo stato di fatture e pagamenti. La sincronizzazione dell'anagrafica clienti è semplice. Un quote-to-cash completo, con prezzi complessi, molti company code e scorte in tempo reale, è un progetto importante.

Salesforce è un ERP o un CRM?

Un CRM. Gestisce pipeline, opportunità, interazioni con i clienti, marketing e servizio. Non registra scritture contabili e non gestisce l'inventario. SAP è l'ERP per finanza, acquisti, inventario e produzione. Se l'integrazione è fatta bene, un commerciale vede in Salesforce le scorte e lo stato dei pagamenti, e la finanza vede in SAP il valore delle trattative.

Qual è il motivo principale per cui falliscono le integrazioni ERP-CRM?

Requisiti definiti partendo dalla tecnologia invece che dalla decisione dell'utente. L'integrazione viene costruita correttamente su una specifica sbagliata: dati vecchi di quattro ore, prezzi che non corrispondono alle fatture, aggiornamenti di stato in ritardo. Prima di scrivere una specifica tecnica, documenti le decisioni che ogni gruppo di utenti prende con i dati e quanto freschi devono essere.

Come si mantiene nel tempo un'integrazione ERP-Salesforce?

Esegua test di regressione automatizzati sui flussi critici prima di ogni release di Salesforce e di ogni aggiornamento SAP. Monitori ogni flusso critico con alert che scattano al guasto, non con un report di fine giornata. Nomini un responsabile che abbia accesso al monitoraggio e faccia parte della pianificazione delle modifiche di entrambi i sistemi.

Quando conviene usare SAP Integration Suite per integrare Salesforce?

Quando SAP è il sistema dominante, quando si ha accesso a SAP BTP e quando i flussi coinvolgono contenuti specifici di SAP come IDoc, BAPI o formati di messaggio SAP. È una scelta più debole se si è già investito molto in MuleSoft o Boomi, se il team non ha competenze di integrazione SAP o se SAP è un partecipante marginale in flussi per lo più non SAP. Per i nuovi programmi RISE con Salesforce nel perimetro, è il punto di partenza naturale.

Quanto dura un progetto di integrazione ERP-Salesforce?

Un perimetro standard (sincronizzazione dell'anagrafica clienti, dall'offerta all'ordine e stato di base degli ordini) con contenuti predefiniti richiede in genere da 8 a 16 settimane dalla definizione del perimetro al go-live, ipotizzando dati puliti e uno sviluppatore di integrazione dedicato. Un quote-to-cash completo, con prezzi complessi, più entità, gestione del credito e scorte in tempo reale, richiede in genere da 4 a 9 mesi. I problemi di dati scoperti a metà progetto e i flussi aggiunti durante la build sono le cause abituali degli sforamenti, quindi esegua una valutazione della qualità dei dati prima dell'inizio della build.