Implementazione Salesforce: Costi, Tempi E Rischi

Una implementazione Salesforce viene approvata come una voce di licenza e consegnata come un programma. La voce di licenza è pubblica, per utente, per mese, e facile da difendere in un documento per il consiglio. Tutto ciò che trasforma quelle licenze in un sistema che qualcuno usa davvero sta fuori da quella voce, ed è la parte che decide se il numero del business case sopravvive al primo trimestre.

Salesforce pubblica i prezzi britannici in sterline. Sales Cloud Enterprise costa £140 per utente al mese con fatturazione annuale e Unlimited costa £280. Cinquanta utenti Enterprise fanno £84.000 all’anno prima che qualcuno abbia configurato un solo campo. La nostra stima interna per i servizi che portano quell’org in produzione va da una a tre volte la spesa di licenza del primo anno, e la posizione dentro quella forbice non è casuale. Quattro cose la spostano, e una sola è tecnica.

La parola che conta di più in ciò che segue è adozione, perché un sistema tecnicamente corretto che nessuno usa non è un successo parziale. È una perdita totale con allegata una fattura di manutenzione.

Quanto costa una implementazione Salesforce? La licenza di solito è la metà più piccola. Salesforce indica Sales Cloud Enterprise a £140 per utente al mese nel Regno Unito, quindi cinquanta utenti fanno £84.000 all’anno, e la nostra stima interna per i servizi di implementazione sopra a quella cifra va da una a tre volte la spesa di licenza del primo anno. Il moltiplicatore dipende dal numero di sistemi integrati, dallo stato dei dati di origine, dal grado di personalizzazione dei processi e dalla volontà dell’organizzazione di adattare il proprio processo al prodotto.

Che cosa comprende davvero una implementazione Salesforce

Un programma Salesforce ha sei voci di costo e una sola compare su una pagina di listino.

La prima è la licenza, per utente e per mese, pubblicata. La seconda sono i servizi di implementazione: i consulenti e gli sviluppatori che configurano l’org, costruiscono ciò che la configurazione non copre e conducono il progetto. La terza è la migrazione dei dati, stimata come attività interna all’implementazione e che si comporta come un progetto a sé. La quarta è l’integrazione, cioè il collegamento di Salesforce ai sistemi che già custodiscono i vostri dati. La quinta sono formazione e gestione del cambiamento. La sesta è l’amministrazione continuativa, che non compare mai in un business case perché comincia dopo che ogni altra fattura è stata pagata.

Un business case che nomina solo la licenza non sbaglia di poco. Sbaglia di solito di un fattore da due a quattro, e lo scarto sta quasi tutto nelle voci tre, cinque e sei.

La licenza è il numero piccolo

Il listino Sales Cloud di Salesforce per il Regno Unito è pubblico e indicato in sterline.

La Starter Suite costa £20 per utente al mese. Pro Suite costa £80 con fatturazione annuale. Enterprise, l’edizione su cui atterra la maggior parte dei compratori britannici del mercato intermedio perché è il primo livello con una API web, costa £140. Unlimited costa £280 e include una sandbox Full e il Premier Success Plan. Agentforce 1 Sales sta a £440. Comprato separatamente, il Premier Success Plan viene fatturato al 30% delle tariffe nette di licenza.

Ne seguono due cose. Il salto da Pro Suite a Enterprise vale £60 per utente al mese, cioè £36.000 all’anno per 50 utenti, ed è spesso imposto da un singolo requisito di integrazione più che da una funzione richiesta dalla forza vendita. E il piano di supporto è una percentuale, quindi cresce con la bolletta delle licenze e non con il supporto che consumate.

Il rapporto tra servizi e licenze, e che cosa lo sposta

Il numero utile per pianificare non è la tariffa giornaliera. È il rapporto tra i servizi del primo anno e la spesa di licenza del primo anno, perché quel rapporto è abbastanza stabile da poterci discutere sopra.

Le nostre fasce interne, dal lavoro sul mercato intermedio britannico, sono queste. Un rollout quasi standard su un solo cloud, con dati puliti e senza integrazioni, si colloca intorno a 0,5 a 1 volta la spesa di licenza del primo anno. Una implementazione tipica, con due o tre integrazioni e una quantità moderata di oggetti personalizzati e automazione, si colloca da 1 a 3 volte. Un programma multi cloud con dati storici, cinque o più integrazioni e forte personalizzazione dei processi corre da 3 a 5 volte e a volte oltre. Sono nostre stime, non cifre pubblicate, e a un partner che cita un rapporto di settore fisso conviene chiedere da dove arriva.

Sull’esempio da £84.000 significa £42.000 in basso, da £84.000 a £252.000 al centro e da £252.000 in su in alto. La forbice è tutta la storia. Chi ha sentito soltanto che costa più o meno quanto la licenza si è ancorato al centro di un intervallo dieci volte più ampio agli estremi.

Le quattro variabili che spostano il rapporto

Solo quattro cose spostano davvero un progetto Salesforce da una fascia a quella successiva, e ogni conversazione di scoping dovrebbe stabilirle tutte e quattro prima che qualcuno produca un numero.

La prima è il numero di sistemi integrati. Ognuno è una progettazione a sé, un set di credenziali a sé, un percorso di errore a sé e una cosa in più che si rompe quando l’altro fornitore rilascia una versione. Il costo delle integrazioni non è additivo, è leggermente peggio che additivo, perché i modi di guasto si moltiplicano.

La seconda è la qualità dei dati alla sorgente. Non il volume. La qualità. È trattata a fondo più avanti perché è la voce più costantemente sottostimata del programma.

La terza è il grado di personalizzazione dei processi, cioè quanto il disegno di destinazione si allontana da ciò che il prodotto fa appena lo installate.

La quarta è se l’organizzazione cambierà il proprio processo per adattarlo al prodotto. È il maggiore singolo predittore sia del costo sia del successo, e quasi nessuno lo mette nello scope, perché è una domanda sulle persone posta durante una valutazione tecnica.

La disponibilità a cambiare è una domanda di scoping

Una organizzazione che adatta il proprio processo di vendita al modello di opportunity di Salesforce ottiene un sistema economico, aggiornabile e ben supportato. Una che pretende che Salesforce riproduca il foglio di calcolo esistente ottiene un sistema costoso che combatte contro ogni rilascio.

Il segnale durante la discovery è il linguaggio. Quando uno stakeholder dice che il sistema deve funzionare come lavoriamo noi, il budget di personalizzazione sta per raddoppiare. Quando dice mostratemi come dovrebbe funzionare e spiegatemi perché, sta per dimezzarsi. Entrambe le frasi sono ragionevoli. Solo una è economica.

Il modo onesto di gestirlo è metterlo a prezzo. Mettete due numeri nella proposta, uno per il modello standard e uno per quello su misura, e lasciate che sia la differenza a fare l’argomento. Chi vede che una convenzione di denominazione delle fasi costa £18.000 di automazione personalizzata e un rischio permanente a ogni aggiornamento di solito cambia la convenzione. Chi si sente rispondere che si può fare non la cambia.

La discovery, e che cosa produce una buona discovery

La discovery è la fase più spesso tagliata per vincere una gara e più spesso accusata dopo. Una discovery che produce una presentazione era un esercizio di vendita. Una che produce quattro artefatti era un esercizio di ingegneria.

Il primo è una mappa di processo: la sequenza reale dei passi con cui un lead diventa fatturato, con i punti di decisione e le persone che li presidiano, ricavata guardando il lavoro invece che chiedendo ai manager di descriverlo.

Il secondo è un modello dei dati: oggetti, campi, relazioni, valori di picklist e, per ogni campo, una persona nominata che lo manterrà. I campi senza proprietario diventano i campi che nessuno compila.

Il terzo è un inventario delle integrazioni: ogni sistema che manda dati a Salesforce o ne riceve, con direzione, volume, frequenza, l’identificatore che unisce i record e che cosa succede quando la connessione cade.

Il quarto è una definizione di fatto che sia misurabile. Non che la forza vendita usi Salesforce, ma per esempio che il 90% delle opportunity chiuse nel trimestre abbia una data di chiusura, un importo e una fase impostata dal proprietario, e che la riunione settimanale di pipeline si tenga dalla dashboard Salesforce senza alcun foglio di calcolo in sala.

In una gara competitiva la nostra guida alle richieste di offerta software si applica direttamente: chiedete a ogni offerente che cosa produce la sua discovery ed escludete chi non sa nominare gli artefatti.

La migrazione dei dati è dove se ne va il calendario

La migrazione viene quotata come una percentuale della costruzione e consumata come un suo multiplo, per un solo equivoco: i team stimano sul numero di record, mentre lo sforzo di migrazione scala con la qualità della sorgente.

Due milioni di righe pulite da un unico sistema ben tenuto, con una chiave primaria affidabile, sono una settimana di lavoro attento. Quarantamila righe sparse tra un vecchio CRM, tre fogli di calcolo regionali e un pacchetto di contabilità, senza identificatore condiviso e con undici anni di testo libero nel campo note, sono due mesi e saranno ancora sbagliate al go live. Il secondo lavoro ha un cinquantesimo dei record e otto volte lo sforzo.

Profilate la sorgente prima di promettere qualsiasi cosa

Profilare vuol dire contare le cose prima di concordare una data. Fatelo su ogni sorgente, e fatelo prima che la voce di migrazione nella proposta venga firmata.

Contate i valori nulli per campo. Contate i valori distinti in ogni campo che intendete rendere una picklist, perché una colonna paese con 340 valori distinti non è una picklist, è un progetto di pulizia. Contate quanti record condividono una chiave candidata. Misurate la coerenza di formato in date, numeri di telefono e codici postali. Contate i record senza proprietario, senza indirizzo e-mail e senza attività da tre anni, perché nessuno li difenderà quando proporrete di lasciarli indietro.

Profilare costa da due a cinque giorni su un patrimonio di media dimensione. È la riduzione di rischio più economica del programma, e saltarla è il motivo per cui le stime di migrazione sbagliano in una sola direzione.

La deduplica, e le regole che la piattaforma vi dà

Salesforce ha una gestione nativa dei duplicati e i suoi limiti danno forma al progetto. Potete avere fino a cinque duplicate rule attive per oggetto e una matching rule attiva per oggetto, che salgono a cinque matching rule attive per oggetto quando usate più duplicate rule, e ogni duplicate rule può referenziare fino a tre matching rule.

Due comportamenti pesano più dei conteggi. Le match key restringono il confronto ai 100 duplicati più probabili prima che venga applicata l’equazione di corrispondenza, quindi un record con più di 100 quasi corrispondenze reali non viene valutato per intero. E le regole semplicemente non girano su diversi percorsi comuni, fra cui Quick Create e la conversione di un Lead senza Apex lead convert attivo, ed è così che compaiono duplicati in un org che ha le duplicate rule accese.

Perciò la deduplica è una attività di migrazione, fatta sui dati di staging prima del caricamento, non una funzione di runtime da accendere e dimenticare. Le regole native sono la seconda linea di difesa.

Gli external ID, e perché upsert batte insert

Ogni oggetto migrato ha bisogno di un external ID: un campo personalizzato indicizzato che contiene la chiave primaria del sistema di origine. È la singola decisione di maggior valore nel disegno della migrazione e non costa nulla.

Con un external ID potete usare upsert, che si serve di quel campo per decidere se creare o aggiornare un record. Se il valore non trova corrispondenza viene creato un record, se ne trova una il record viene aggiornato, e se ne trova più di una viene restituito un errore invece di un duplicato. Così ogni caricamento è idempotente, il che significa che potete eseguirlo due volte senza raddoppiare i dati, il che significa che potete fare le prove.

Due dettagli mordono. La corrispondenza per external ID ignora le maiuscole solo se il campo ha l’attributo Unique e l’opzione relativa selezionata, altrimenti ABC123 e abc123 sono due record diversi. E se il campo è un external ID senza indice univoco, l’account che carica ha bisogno del permesso View All Data.

Migrare la storia oppure migrare ciò che serve

La richiesta predefinita è portare tutto di là. È quasi sempre sbagliata ed è costosa in tre modi distinti.

Costa sforzo di migrazione, perché i dati più vecchi sono i più sporchi e consumano tempo di pulizia sproporzionato al loro valore. Costa spazio, e lo spazio è una voce reale: gli org Enterprise, Professional e Unlimited hanno una dotazione di 10 GB di data storage più 20 MB per licenza utente, quindi 50 utenti Enterprise fanno 11 GB in totale, non 11 GB per utente. E costa adozione, perché un sistema pieno di record morti insegna agli utenti a non fidarsi dei risultati di ricerca.

La posizione difendibile è migrare per intero i record aperti e recenti, migrare i record chiusi per il periodo su cui l’azienda rendiconta davvero e archiviare il resto in un posto leggibile. Tenere dati personali di cui non avete uso è una responsabilità più che un patrimonio, quindi per una volta l’argomento dello spazio e quello della conformità puntano nella stessa direzione.

Configurazione contro codice

Ogni requisito in Salesforce può essere soddisfatto in modo dichiarativo, con codice o con un misto, e la scelta determina quanto costerà possedere il sistema per il decennio successivo. La distinzione vale la pena di tenerla chiara anche se non aprite mai un editor.

Che cosa dovrebbe essere dichiarativo

Dichiarativo vuol dire costruito con la configurazione: oggetti, campi, page layout, regole di validazione e Flow, il costruttore visuale di automazione di Salesforce. Lo cambia un amministratore, sopravvive agli aggiornamenti di piattaforma perché il runtime è di Salesforce, ed è visibile a chiunque abbia il permesso giusto.

La guida alle decisioni sull’automazione attivata da record pubblicata da Salesforce dà una soglia utilizzabile. Misura la densità di automazione su tre dimensioni: il numero di automazioni che scattano su un singolo cambiamento di dato, il volume di record per transazione e quanto lontano gli aggiornamenti a valle si propagano sugli oggetti collegati. Densità bassa, cioè meno di quindici automazioni, lotti da 1 a 200 record e al massimo una scrittura a valle, va fatta in Flow attivato da record.

La stessa guida dà una regola che fa risparmiare più di ogni altra di questo elenco: un solo punto di ingresso per oggetto. Mescolare Flow e trigger Apex sullo stesso oggetto è il modo in cui i bug di ordinamento diventano permanenti.

Quando il codice su misura è la scelta giusta

La densità media va a un ibrido, con Flow che orchestra e Apex invocabile che fa il lavoro pesante, così la sequenza resta visibile mentre il calcolo sta in qualcosa di testabile. La densità alta va ai trigger Apex senza mezze misure, perché a quel punto si sta usando lo strumento dichiarativo per costruire un sistema per cui non è stato pensato.

Il codice è giusto anche quando la logica è davvero complessa, quando deve essere sottoposta a test unitari seri e quando la stessa operazione viene chiamata da più punti di ingresso e dovrebbe esistere una volta sola. Se quel lavoro lo commissionate invece di assumerlo, i nostri servizi di sviluppo software esistono esattamente per questo confine, dove la piattaforma finisce e comincia l’ingegneria su misura.

La terminologia si sposta, e i termini vecchi sono un campanello

Salesforce ritira strumenti, e una proposta scritta contro strumenti ritirati dice quando è stata davvero redatta. Salesforce ha smesso di supportare Workflow Rules e Process Builder il 31 dicembre 2025. Le regole esistenti continuano a girare, ma non c’è supporto clienti né correzione di difetti, e il percorso consigliato è la migrazione a Flow Builder con lo strumento Migrate to Flow.

Il costo di lungo periodo di ciascuna scelta

Il lavoro dichiarativo è più economico da costruire e da cambiare, e il suo costo è la diluizione: cento flow non documentati diventano un sistema in cui nessuno sa prevedere che cosa farà il salvataggio di un record.

Il codice è più costoso da costruire e molto più economico da capire su scala, perché si può leggere, versionare e testare. Il suo costo è che richiede sviluppatori, e una organizzazione senza uno sviluppatore Salesforce e senza un contratto continuativo prima o poi non riuscirà più a cambiare il proprio sistema.

Il fallimento che costa di più non è nessuno dei due. È un sistema costruito interamente in modo dichiarativo da un partner che poi se ne va, in un org senza documentazione e senza un proprietario nominato. Tutto funziona e niente si può cambiare in sicurezza, che è la stessa posizione del software su misura non manutenuto, descritta a lungo nel nostro pezzo su quanto costa davvero la manutenzione del software.

Integrazione, e perché i limiti cambiano l’architettura

L’integrazione ha una trattazione a sé nel nostro articolo sui limiti di integrazione Salesforce e i costi reali. Quello che sta qui è che i limiti di piattaforma sono un dato di architettura, non un dettaglio operativo scoperto alla nona settimana.

Due limiti fanno quasi tutta la forma. Le dotazioni totali di richieste API per un org di Enterprise Edition sono 100.000 chiamate ogni 24 ore più il numero di licenze moltiplicato per le chiamate che ciascun tipo di licenza porta con sé, cioè 1.000 per una licenza Salesforce, più eventuali add-on acquistati. L’esempio calcolato da Salesforce è un org Enterprise con 15 licenze Salesforce che ottiene 115.000 richieste. La dotazione vale per tutto l’org e non per utente, e le richieste in ingresso concorrenti che durano 20 secondi o più sono limitate a 25 in produzione.

Il secondo sono gli Apex governor limit, applicati per transazione: 100 query SOQL in modo sincrono e 200 in asincrono, 50.000 record recuperati da SOQL, 150 istruzioni DML, 10.000 record processati da DML, 6 MB di heap in sincrono e 12 MB in asincrono, e 10.000 millisecondi di tempo CPU in sincrono contro 60.000 in asincrono.

Un progetto che li ignora supera il collaudo su venti record e cade al primo caricamento notturno vero. Non è un difetto. È una decisione di architettura presa per omissione.

Gli ambienti, e che cosa distrugge un refresh di sandbox

Salesforce vi dà quattro tipi di sandbox con spazio e intervalli di refresh diversi, e scegliere male è un errore di pianificazione che emerge tardi.

Le sandbox Developer tengono 200 MB e si aggiornano una volta al giorno. Developer Pro tiene 1 GB, anch’essa ogni giorno. Partial Copy tiene 5 GB, copia un campione dei dati di produzione definito da un template e si aggiorna ogni cinque giorni. Full replica la produzione e si aggiorna ogni 29 giorni. La Enterprise Edition include 25 sandbox Developer e una Partial Copy; le Full arrivano con Unlimited e Performance oppure si comprano come add-on.

L’intervallo di 29 giorni delle sandbox Full è il vincolo attorno a cui si pianifica troppo tardi. L’unico ambiente realistico per provare la migrazione si aggiorna una volta al mese, quindi una prova che rivela un problema costa un mese prima di poter riprovare puliti. Due prove in una sandbox Full sono una finestra di nove settimane, non di due.

Le sandbox Developer e Developer Pro copiano solo i metadati, quindi tutto ciò che uno sviluppatore vi ha caricato per provare sparisce dopo un refresh. I dati di test devono essere uno script rieseguibile tenuto nel controllo di versione, altrimenti il team perde un giorno per refresh a ricrearli a mano.

Gestione dei rilasci: change set contro pipeline

Non potete sviluppare Apex in un org di produzione, quindi ogni modifica nasce altrove e va spostata. Come si sposta è una decisione con una coda lunga.

I change set sono il meccanismo integrato. Portano solo ciò che potete cambiare da Setup, mai i record, richiedono una connessione di deployment tra org collegati allo stesso org di produzione, e un change set in ingresso si distribuisce per intero e non componente per componente. Si assemblano cliccando, quindi non sono confrontabili, non sono revisionabili e non sono ripetibili, e lo stesso change set assemblato due volte da due persone risulterà diverso.

Funziona per un org piccolo con un solo amministratore e rilasci mensili. Smette di funzionare nel momento in cui due persone cambiano lo stesso org, perché non c’è merge e non c’è storia, e la traccia di che cosa è andato in produzione vive nella memoria di qualcuno.

L’alternativa è una pipeline guidata dalla sorgente: metadati in Git, modifiche riviste come diff, deployment lanciati da un ramo. Costa qualche giorno di allestimento e trasforma la gestione dei rilasci da esercizio di memoria a esercizio ripetibile. Con più di una persona che costruisce, trattatela come parte della costruzione e non come un miglioramento per dopo.

La regola del 75% di copertura non è una soglia di qualità

Per portare Apex in produzione serve che i test unitari coprano almeno il 75% del vostro codice Apex e che quei test passino. Salesforce dice esplicitamente che la copertura indica l’efficacia dei test senza garantirla, e che i test dovrebbero verificare il comportamento.

Leggete che cosa significa sul piano commerciale. Il 75% è un cancello, e i cancelli si aggirano. Classi di test scritte per colpire il numero invece che per verificare qualcosa passeranno, andranno in produzione e non prenderanno nulla. Quando revisionate il lavoro di un partner, non chiedete la percentuale di copertura. Chiedete di vedere tre metodi di test e contate le assertion.

Una implementazione Salesforce fallisce sull’adozione, non al go live

Il sistema va in produzione, il progetto si chiude, la fattura viene pagata, e otto mesi dopo il direttore vendite fa ancora il forecast da un foglio di calcolo. Non si è rotto niente. È l’esito più comune di un programma Salesforce fallito ed è invisibile a ogni misura tecnica.

L’economia è brutale perché il costo di licenza continua comunque. Cinquanta utenti Enterprise a £140 al mese fanno £84.000 all’anno, che il sistema si usi o no, quindi un tasso di adozione del 40% è grossomodo £50.000 all’anno di puro spreco sulla sola licenza, prima ancora di ammortizzare il costo di implementazione su qualcosa.

L’adozione è anche l’unico modo di guasto che il team tecnico non può risolvere. Un partner può costruire esattamente ciò che è stato specificato, soddisfare ogni criterio di accettazione e lasciare qualcosa che nessuno apre. Per questo la definizione di fatto nella discovery deve parlare di utilizzo, e per questo il progetto non dovrebbe considerarsi chiuso al go live.

Le pratiche che spostano l’adozione

Quattro cose spostano l’adozione in modo affidabile, e nessuna è un video di formazione.

Formazione per ruolo, erogata separatamente. Un venditore e un responsabile vendite usano parti diverse del sistema per ragioni diverse, e una sessione unica insegna male a entrambi. Formate ogni ruolo sul proprio flusso di lavoro e su nient’altro.

Un piccolo insieme di campi obbligatori. Scegliete i pochissimi campi che fanno funzionare la reportistica, rendete obbligatori quelli e lasciate tutto il resto facoltativo. Ogni campo obbligatorio in più è un motivo per abbandonare un record a metà, e un sistema che punisce l’inserimento dati ne riceve meno.

Reportistica per i responsabili che dipende da quei dati. È la pratica che funziona. Se la riunione settimanale di pipeline si tiene da una dashboard Salesforce senza fogli di calcolo in sala, i dati vengono inseriti, perché l’alternativa è essere assenti dalla conversazione. Se il responsabile tiene un foglio privato, il CRM è facoltativo e lo sanno tutti.

Un proprietario nominato con tempo nella propria settimana. Non un comitato. Una persona che possiede l’org, ha i permessi di amministrazione, viene misurata sull’adozione e ha ore assegnate per farlo. Gli org senza questo decadono dal primo mese.

I modi di guasto e i loro segnali precoci

Sei modi di guasto spiegano quasi tutti i fallimenti di implementazione Salesforce che ci chiedono di riparare, e ciascuno mostra un segnale ben prima del danno.

Replicare un processo rotto. Il segnale è un documento di requisiti che descrive il sistema attuale invece del risultato desiderato, con i nomi dei campi del vecchio sistema. Automatizzare un processo cattivo lo rende più veloce e più difficile da cambiare.

Personalizzazione senza limiti. Il segnale è un registro delle richieste di modifica senza un solo rifiuto. La Enterprise Edition consente 500 campi personalizzati per oggetto e 200 oggetti personalizzati, spazio a sufficienza per costruire qualcosa che nessuno può mantenere molto prima di toccare un limite di piattaforma.

Nessun proprietario unico. Il segnale è che la risposta alla domanda su chi possiede Salesforce contiene la parola e.

Migrare tutto. Il segnale è un perimetro di migrazione definito dal numero di record invece che da una decisione di conservazione.

Nessuna disciplina sugli ambienti di test. Il segnale è qualcuno che dice di fare la modifica direttamente in produzione, tanto è solo un valore di picklist.

Misurare il go live invece dell’utilizzo. Il segnale è un piano di progetto il cui ultimo traguardo è una data e non un numero.

Tempi per implementazioni piccole, medie e complesse

Durata e impegno sono domande diverse, che i compratori confondono. Queste sono le nostre fasce interne dal mercato intermedio britannico, non cifre pubblicate.

Una implementazione piccola, fino a circa 25 utenti su un cloud, con al più una integrazione e una fonte dati pulita, dura da 6 a 10 settimane e da 20 a 45 giornate di consulenza. Una media, da 25 a 150 utenti su uno o due cloud, con da due a quattro integrazioni e una migrazione vera, dura da 4 a 7 mesi e da 90 a 220 giornate. Un programma complesso, oltre 150 utenti, multi cloud, cinque o più integrazioni e più paesi, dura da 9 a 18 mesi e da 400 giornate in su.

Dentro quei totali la discovery pesa dal 10 al 15% dell’impegno, configurazione e sviluppo dal 30 al 40%, la migrazione dati dal 20 al 30% e in forte crescita con sorgenti scadenti, l’integrazione dal 10 al 20%, e test, formazione e hypercare dal 15 al 20%. La voce che si dilata è sempre la migrazione.

La durata supera l’impegno diviso per la dimensione del team per ragioni non imputabili al team: gli intervalli di refresh delle sandbox, la disponibilità degli stakeholder per il collaudo e l’attesa del fornitore terzo dell’API. Chi porta quel rischio lo decide il contratto, per cui la scelta tra prezzo fisso e tempo e materiali pesa sul lavoro CRM più che altrove.

Protezione dei dati britannica in un programma CRM

Un CRM è una banca dati di persone, quindi il UK GDPR si applica praticamente a tutto ciò che contiene, e in ogni implementazione tornano tre domande.

Serve una DPIA?

La guida dell’ICO su quando serve una DPIA espone la regola generale dell’articolo 35(1), per cui una DPIA serve quando il trattamento può comportare un rischio elevato per i diritti e le libertà delle persone, ed elenca l’insieme di operazioni proprio dell’ICO ai sensi dell’articolo 35(4).

Due di quelle cadono in pieno su una migrazione CRM tipica. Il data matching, definito come combinare, confrontare o far corrispondere dati personali ottenuti da più fonti, è esattamente ciò che fa una migrazione di consolidamento. La profilazione su larga scala copre lo scoring di lead e account. L’ICO nota anche che nella maggior parte dei casi la combinazione di due dei criteri europei indica che serve una DPIA, pur senza essere una regola rigida. Notate che questa guida è attualmente in revisione per effetto delle modifiche introdotte dal Data (Use and Access) Act, quindi consultatela invece di affidarvi a un riassunto.

Dove stanno davvero i dati?

Salesforce è una piattaforma globale e l’istanza su cui gira il vostro org è materia di contratto, non una supposizione. La breve guida dell’ICO ai trasferimenti internazionali, aggiornata il 15 gennaio 2026, propone un test in tre passi: il UK GDPR si applica al trattamento, siete voi a dare avvio al trasferimento verso una organizzazione fuori dal Regno Unito, e il destinatario è un soggetto giuridico distinto. Tre sì lo rendono un trasferimento soggetto a restrizione.

I trasferimenti soggetti a restrizione richiedono regolamenti britannici di adeguatezza, garanzie appropriate come l’International Data Transfer Agreement, l’Addendum o norme vincolanti d’impresa, oppure una eccezione. Dove vi appoggiate alle garanzie, l’ICO si aspetta una valutazione del rischio del trasferimento. Questa è una revisione contrattuale, non una attività di ingegneria, e dovrebbe avvenire prima della migrazione e non dopo.

Il vostro partner di implementazione è un responsabile del trattamento

Quando un partner configura il vostro org, carica i vostri dati e detiene le credenziali per accedervi, sta trattando dati personali per vostro conto. La guida dell’ICO su titolari e responsabili del trattamento espone che cosa ne consegue, e le implicazioni pratiche sono contrattuali.

Serve un accordo scritto che copra istruzioni documentate, riservatezza, sicurezza, sub-responsabili, diritti di audit e cancellazione o restituzione dei dati alla fine dell’incarico. Quest’ultima è la clausola che manca più spesso. Un partner che ha tenuto per undici mesi una copia completa del vostro database clienti in una sandbox Full, e il cui contratto non dice nulla sulla cancellazione, è una responsabilità aperta dalla vostra parte della linea, non dalla sua.

Che cosa chiedere a un possibile partner

Sei domande, e le risposte che dovrebbero chiudere la conversazione.

Chiedete che cosa produce la discovery. Se la risposta è una proposta invece di una mappa di processo, un modello dei dati, un inventario delle integrazioni e una definizione di fatto misurabile, stanno vendendo, non stanno definendo.

Chiedete come e quando profileranno i dati di origine. Se il profiling arriva dopo che la stima di migrazione è concordata, la stima è una scommessa.

Chiedete qual è la loro impostazione predefinita per l’automazione e ascoltate se parlano di densità. Un partner che dice sempre Flow o sempre Apex ha un solo strumento. Un partner che nel 2026 prevede Process Builder non legge un avviso di ritiro da tre anni.

Chiedete come le modifiche passano dalla sandbox alla produzione. I change set sono accettabili per un org con un solo amministratore e sono un campanello su qualsiasi cosa più grande.

Chiedete di chi è l’org dopo il go live e quante ore alla settimana significa. Se non sanno rispondere, l’adozione non è problema di nessuno.

Chiedete che fine fanno i vostri dati nelle loro sandbox quando l’incarico finisce, e mettete la risposta nel contratto invece che in una e-mail. La stessa disciplina descritta nella nostra guida alla due diligence tecnica vale anche qui: verificate l’affermazione invece di accettare la rassicurazione.

Quando la risposta non è Salesforce

Se avete meno di una decina di utenti, nessun requisito di integrazione e un processo che sta in una pipeline a cinque fasi, la licenza Enterprise e la sua implementazione sono entrambe più grandi del problema. Un CRM più economico, o la Starter Suite a £20 per utente, fa il lavoro e potrà essere sostituito più avanti a un costo che riuscite ad assorbire.

Se il vostro requisito reale è un flusso di lavoro che nessun prodotto supporta e tutto il resto è già coperto, state comprando una piattaforma per ospitare una sola applicazione. Di solito è un caso da sistema costruito apposta, e il nostro lavoro di sviluppo software su misura parte da questa premessa. La decisione tra costruire e comprare si gioca sul fatto che il processo differenziante sia il cuore dell’azienda o un dettaglio attorno.

Se nessuno si prenderà il sistema, non compratelo. È la cosa più difficile da dire durante un processo di vendita e il predittore di spreco più affidabile. Un CRM senza proprietario non fallisce in modo rumoroso. Diventa in silenzio una copia del foglio di calcolo che doveva sostituire, a £140 per utente al mese.

E se l’obiettivo è uno strato di agenti IA invece di un CRM, quello si appoggia su una implementazione funzionante invece di sostituirla. L’economia è trattata nel nostro pezzo su quanto costa davvero Agentforce.

Mettere il lavoro in sequenza

L’ordine che funziona è: profilare i dati, condurre la discovery fino a quattro artefatti, concordare il modello standard e mettere a prezzo ogni scostamento, costruire con un solo punto di ingresso di automazione per oggetto, provare la migrazione due volte in una sandbox Full, formare per ruolo e tenere aperto il progetto finché non si raggiunge un numero di utilizzo invece di una data.

L’ordine che fallisce è: firmare, configurare, migrare tardi, formare una volta, andare in produzione alla data, chiudere il progetto.

Mecanik lavora sulle parti di tutto questo che sono ingegneria e non amministrazione di licenze: disegno delle integrazioni contro i limiti reali della piattaforma, profilazione e strumenti per la migrazione, sviluppo su misura dove la configurazione finisce, e il lavoro di front end che mette i dati CRM davanti ai clienti. Le nostre pagine sui servizi di sviluppo software e sull’ingaggio di uno sviluppatore web spiegano come lavoriamo. Se prima di firmare volete un secondo parere sulla stima di un partner, potete ingaggiare uno sviluppatore solo per quella revisione.

Domande frequenti

Quanto costa una implementazione Salesforce nel Regno Unito? Salesforce indica Sales Cloud Enterprise a £140 per utente al mese nel Regno Unito con fatturazione annuale, quindi 50 utenti fanno £84.000 all’anno di sole licenze. La nostra stima interna per i servizi di implementazione sopra a quella cifra va da 0,5 a 1 volta la spesa di licenza del primo anno per un rollout quasi standard, da 1 a 3 volte per un progetto tipico di mercato intermedio e da 3 a 5 volte per un programma multi cloud con dati storici e forte personalizzazione.

Quanto dura una implementazione Salesforce? Le nostre fasce interne sono da 6 a 10 settimane e da 20 a 45 giornate di consulenza fino a 25 utenti su un solo cloud con dati puliti, da 4 a 7 mesi e da 90 a 220 giornate per 25 a 150 utenti con due o quattro integrazioni, e da 9 a 18 mesi e da 400 giornate in su per un programma multi cloud con migrazione di dati storici. La migrazione dati è la fase che si dilata, perché il suo sforzo scala con la qualità dei dati di origine e non con il numero di record.

Perché le implementazioni Salesforce falliscono? Quasi sempre sull’adozione e non al go live. Un sistema tecnicamente corretto che nessuno usa è una perdita totale con una bolletta di licenze che continua a correre. Le cause comuni sono replicare un processo rotto, personalizzazione senza limiti, nessun proprietario unico nominato, migrare tutti i dati storici, nessuna disciplina sugli ambienti di test e misurare il go live invece dell’utilizzo.

Salesforce va costruito con la configurazione o con codice su misura? La guida alle decisioni pubblicata da Salesforce fissa la soglia sulla densità di automazione. Meno di quindici automazioni su un oggetto, lotti da 1 a 200 record e al massimo una scrittura a valle vanno fatti in Flow attivato da record. La densità media si adatta a Flow che orchestra Apex invocabile. La densità alta si adatta ai trigger Apex. Usate un solo punto di ingresso per oggetto invece di mescolare Flow e trigger Apex sullo stesso.

Serve una DPIA per una implementazione Salesforce? Spesso sì. L’ICO elenca il data matching, cioè combinare o confrontare dati personali da più fonti, e la profilazione su larga scala fra le operazioni che indicano che serve una DPIA, e una migrazione di consolidamento con scoring dei lead fa entrambe le cose. La guida è attualmente in revisione dopo il Data (Use and Access) Act, quindi verificate la posizione attuale dell’ICO invece di un riassunto.