Implementazione di SAP Sales Cloud V2: la guida completa per il 2026

Questa guida descrive come conduciamo i progetti SAP Sales Cloud V2, dal primo workshop di definizione del perimetro fino all’hypercare: le fasi, i ruoli su entrambi i lati, quanto dura ogni tipo di progetto, quanto costa e dove i progetti di solito si inceppano. Ogni progetto è diverso, ma lo schema di ciò che funziona e di ciò che richiede più tempo del previsto si ripete.

Tutte le durate e i costi di questa guida provengono da un’unica tabella dei tempi per perimetro (sezione «Tempistiche realistiche»): sintesi, tabelle e FAQ riportano quindi gli stessi numeri.

In sintesi: Un progetto Sales Cloud V2 segue SAP Activate (Discover, Prepare, Explore, Realize, Deploy, Run). La durata dipende dal perimetro, soprattutto dal numero di integrazioni: 10 giorni per il nostro pacchetto a prezzo fisso CRM in 10 giorni, 4–8 settimane per un perimetro PMI su misura, 8–16 settimane per il mid-market, 3–6 mesi per l’enterprise. I costi di implementazione indicativi vanno da 25.000–50.000 USD (PMI) a 150.000–500.000+ USD (enterprise), licenze escluse. I tre rischi principali sono il lavoro di integrazione sottostimato, la pulizia dei dati saltata e il change management trascurato.

Tutti i prezzi di questa guida sono valori indicativi tratti dai nostri progetti, in USD, IVA esclusa, aggiornati a settembre 2026. Non sono un’offerta: i prezzi delle licenze SAP dipendono da edizione, volume e contratto, i costi di implementazione dal vostro perimetro.

Preferite un partner a una guida fai-da-te? Spadoom è SAP Gold Partner svizzero per Cloud ERP e Customer Experience: lo stesso team implementa SAP Sales Cloud V2 e SAP S/4HANA Public Cloud, ed è proprio su questo punto di giunzione che si decide la maggior parte dei progetti V2. Richiedete un colloquio iniziale gratuito o calcolate il vostro ROI.

Perché l’implementazione V2 è diversa dalla V1

Se avete implementato SAP C4C (Cloud for Customer) o Sales Cloud V1, gran parte dell’approccio tecnico cambia. V2 non è un aggiornamento della V1, ma un prodotto costruito da capo.

Nuova architettura. V2 è una nuova piattaforma cloud-native e le estensioni personalizzate girano side-by-side sulla SAP Business Technology Platform (BTP). Il modello di estensione, il livello API e il framework degli eventi sono nuovi. Le estensioni V1 costruite con PDI (Cloud Applications Studio) non si trasferiscono: i dati dei campi PDI si possono migrare, la logica va ricostruita.

Nuovo modello dati. Il modello entità di V2 è stato ridisegnato completamente. Account, contatti, opportunità, lead: gli oggetti core esistono, ma le loro strutture di campo, relazioni e comportamenti sono diversi. Una migrazione diretta campo-per-campo dalla V1 non è possibile senza logica di trasformazione. Abbiamo scritto separatamente su cosa è cambiato tra V1 e V2 e sulla strategia di migrazione da C4C.

Nuova superficie API. V2 è API-first ed espone API REST in JSON; le integrazioni V1 usavano per lo più OData V2 e SOAP. Ogni integrazione che tocca Sales Cloud deve essere reimplementata contro i nuovi endpoint. Se usate middleware (SAP Integration Suite, MuleSoft, Boomi), gli adapter e i mapping devono essere ricostruiti.

Nuovo framework UI. V2 utilizza una shell moderna a web component con estensioni side-by-side. L’adattamento UI della V1 (HTML mashup, componenti embedded) funziona diversamente in V2. Il lavoro UI personalizzato deve essere rifatto.

La buona notizia: secondo la nostra esperienza V2 è il prodotto migliore, con API più pulite, prestazioni migliori e un modello di estensione più capace. Ma pianificare V2 come un aggiornamento della V1 fa saltare tempi e budget. Anche V2 ha delle lacune, e le elenchiamo apertamente nella nostra valutazione di ciò che Sales Cloud V2 non sa ancora fare.

SAP Activate si applica ancora: la metodologia di implementazione è la stessa. Ma le attività tecniche all’interno di ogni fase sono specifiche per V2. Scoping, configurazione, integrazione, testing e deployment seguono procedure diverse rispetto alla V1.

Aggiornamenti release 2026: cosa cambiano per la vostra implementazione

Aggiunto ad agosto 2026, verificato a settembre 2026. V2 pubblica release trimestrali senza fermo macchina: ciò che implementate oggi passa automaticamente all’ultima release. Le release 2026 hanno cambiato la definizione del perimetro in tre punti. Funzionalità e licenze cambiano da una release all’altra: verificate lo stato attuale nelle informazioni di rilascio SAP e nel SAP Road Map Explorer prima di pianificare.

L’agent builder di Joule Studio è generalmente disponibile. Da inizio 2026 potete costruire agenti AI personalizzati (SAP Discovery Center: Joule Studio agent builder) che orchestrano workflow multi-step tra Sales Cloud V2, S/4HANA e sistemi di terze parti: briefing pre-chiamata, e-mail con i tempi di consegna, arricchimento e scoring automatico dei lead. Questo solleva una domanda di scoping che un anno fa non esisteva: quali workflow giustificano un agente nella Fase 1? Due prerequisiti da pianificare: le autorizzazioni Joule e BTP richieste dal vostro scenario (chiaritele con SAP prima di Explore) e dati anagrafici puliti (un agente che legge un’anagrafica prodotti disordinata produce risultati inutilizzabili). Ne parliamo nella nostra guida pratica a Joule. Un partner di implementazione SAP Sales Cloud V2 esperto pianifica la revisione della qualità dei dati prima dello sviluppo degli agenti, non dopo.

La deal intelligence valuta il rischio in base alle attività (stato Q1 2026; verificate la roadmap SAP attuale). Il sistema segnala lacune concrete di engagement (nessun contatto con il cliente da 14 giorni su un’opportunità in chiusura nel trimestre, un solo interlocutore presso il cliente, velocità del deal in stallo) e le porta nelle viste pipeline e nel forecast. La conseguenza per l’implementazione: i segnali di rischio valgono quanto la registrazione delle attività. Progettate il vostro modello di attività (registrazione visite, chiamate, sync e-mail) già nella fase Explore pensando al risk scoring.

Il forecasting è stato rivisto (stato Q1 2026). Drill-down per territorio, linea di prodotto e periodo; rollup multilivello con aggiustamenti tracciati; audit trail su ogni modifica. Se una fit-gap analysis del 2025 aveva segnalato il forecasting come lacuna da colmare con fogli di calcolo: rivalutatela. Quella lacuna è in gran parte chiusa.

Le nostre note sulla prima release del 2026 sono in Novità di SAP Sales Cloud V2: Q1 2026, scritte dall’esperienza di progetto e non dalle note di rilascio.

Fasi del progetto (SAP Activate per V2)

SAP Activate è la metodologia di implementazione di SAP. Fornisce un quadro strutturato e funziona, se lo si segue davvero. La usiamo in ogni progetto, con adattamenti specifici per V2 tratti dai nostri progetti.

Le durate delle fasi qui sotto valgono per un progetto mid-market (8–16 settimane in totale), la riga centrale della tabella dei tempi. Un progetto PMI comprime le stesse fasi; un rollout enterprise le allunga e spesso ripete Realize e Deploy per ogni paese.

Discover (1–2 settimane)

Qui si determina se V2 è la scelta giusta e si definiscono i confini del progetto.

Cosa succede:

• Valutazione dei processi di business: mappatura dei flussi di lavoro commerciali attuali (lead-to-quote, gestione opportunità, pianificazione territoriale, forecasting)
• Analisi fit-gap rispetto alle funzionalità standard di V2
• Valutazione dei sistemi da integrare (ERP, marketing, servizio, sistemi terzi)
• Dimensionamento di alto livello del progetto e stima del budget
• Allineamento degli stakeholder esecutivi

Deliverable chiave:

• Documento di business case con proiezioni ROI (il nostro calcolatore ROI offre un punto di partenza)
• Definizione dell’ambito della soluzione (cosa è dentro, cosa è fuori per la Fase 1)
• Architettura di integrazione di alto livello
• Timeline preliminare e piano risorse

Insidie comuni:

• Saltare completamente il fit-gap e passare direttamente alla configurazione. Scoprirete lacune a metà progetto che deragliano la timeline.
• Sovraccaricare la Fase 1. Ogni funzionalità che il vostro team vendite ha mai desiderato non è un requisito della Fase 1. Prioritizzate in modo rigoroso.
• Non coinvolgere i leader commerciali in anticipo. Se il vostro VP Sales vede il sistema per la prima volta durante lo UAT, avete un problema di change management.

Prepare (1–2 settimane)

Il progetto viene formalmente avviato e il team si mobilita.

Cosa succede:

• Setup della governance del progetto (comitato direttivo, percorsi di escalation, diritti decisionali)
• Piano di progetto dettagliato con milestone e dipendenze
• Provisioning degli ambienti (tenant V2, subaccount BTP, middleware di integrazione)
• Onboarding del team: i responsabili business lato cliente seguono la formazione sui fondamentali di V2
• Definizione della strategia di migrazione dati
• Documenti di design dell’integrazione per ogni punto di contatto

Deliverable chiave:

• Project charter firmato dall’executive sponsor
• Piano di progetto dettagliato (MS Project, Jira o qualunque strumento usi il vostro PMO)
• Diagramma del landscape di sistema con tutti gli ambienti (sviluppo, test, produzione)
• Piano di migrazione dati con mappatura campo-per-campo sorgente-destinazione
• Specifiche di design dell’integrazione

Insidie comuni:

• Il provisioning degli ambienti richiede più tempo del previsto. Il provisioning del tenant SAP non è istantaneo: avviate la richiesta nella fase Discover se possibile.
• Sottovalutare la complessità della migrazione dati. «Esportiamo dal vecchio CRM e importiamo» non è mai così semplice. Iniziate la mappatura dei campi ora.
• Saltare i documenti di design dell’integrazione. Gli accordi verbali su «cosa si sincronizza» non hanno alcun valore. Documentate ogni campo, ogni direzione, ogni trigger.

Explore (2–4 settimane)

Qui il team configura V2 per abbinare i vostri processi di business e valida la corrispondenza attraverso prototipazione iterativa. Che cosa significhino in concreto «i vostri processi» cambia da un settore all’altro: le nostre guide per il commercio all’ingrosso e la distribuzione e per i servizi professionali illustrano le scelte di configurazione tipiche.

Cosa succede:

• Configurazione baseline di V2 secondo la definizione dell’ambito
• Workshop di walkthrough dei processi con gli utenti business (mostrate loro V2 configurato per il loro processo, non demo generiche)
• Risoluzione dei gap: per ogni gap identificato nella fase Discover, definire se viene affrontato tramite configurazione, estensione, integrazione o cambio di processo
• Sviluppo delle estensioni per requisiti personalizzati (estensioni side-by-side basate su BTP)
• Avvio dello sviluppo dell’integrazione (stream parallelo)
• Setup degli strumenti di migrazione dati e primi caricamenti di test

Deliverable chiave:

• Sistema V2 configurato che copre l’80%+ dei requisiti definiti
• Registro di risoluzione dei gap (ogni gap tracciato con approccio di risoluzione e sforzo)
• Specifiche delle estensioni e sviluppo iniziale
• Middleware di integrazione configurato con connettività iniziale
• Dati di test caricati dai sistemi sorgente

Insidie comuni:

• Morte per workshop. Servono sessioni focalizzate, delimitate nel tempo e con demo preparate, non discussioni aperte su cosa il sistema potrebbe fare.
• Scope creep tramite «piccole» modifiche di configurazione. Ognuna aggiunge sforzo di testing. Tracciatele rigorosamente.
• Costruire estensioni prima di esaurire le opzioni di configurazione. Le capacità di configurazione di V2 sono estese. Un’estensione che avrebbe potuto essere una configurazione è debito tecnico dal primo giorno.

Realize (3–6 settimane)

La fase più lunga. Qui tutto viene costruito, integrato, testato e irrobustito.

Cosa succede:

• Configurazione completa del sistema e fine-tuning basato sul feedback di Explore
• Completamento dello sviluppo delle estensioni e unit testing
• Sviluppo dell’integrazione, testing e gestione degli errori
• Migrazione dati: ciclo completo di migrazione di test dai sistemi sorgente
• System Integration Testing (SIT): test end-to-end dei processi attraverso V2 e sistemi collegati
• User Acceptance Testing (UAT) con i rappresentanti del business
• Performance testing (specialmente per grandi volumi di dati e utenti concorrenti)
• Security review e configurazione ruoli/autorizzazioni
• Sviluppo dei materiali formativi

Deliverable chiave:

• Sistema V2 completamente configurato con tutte le estensioni deploiate
• Integrazioni testate con gestione degli errori e monitoraggio
• Migrazione di test a volume completo riuscita con report di riconciliazione
• Sign-off UAT dagli stakeholder business
• Materiali formativi (specifici per ruolo, non generici)
• Piano di cutover con timeline ora per ora

Insidie comuni:

• I test di integrazione evidenziano problemi che avrebbero dovuto essere intercettati nel design. Se la specifica di integrazione era vaga, nella fase Realize ne pagate il prezzo.
• Partecipanti UAT che non hanno mai visto il sistema. Avrebbero dovuto partecipare ai workshop di Explore. Portarli a freddo allo UAT garantisce change request che fanno saltare la timeline.
• Saltare il performance testing. V2 gestisce bene la scalabilità, ma estensioni personalizzate e integrazioni possono introdurre colli di bottiglia. Testate con volumi di dati realistici.
• Testare solo il percorso felice. Il vostro SIT deve coprire gli scenari di errore: cosa succede quando l’ERP è fuori servizio, quando manca un campo obbligatorio, quando arriva un duplicato.

Deploy (1–2 settimane)

Preparazione ed esecuzione del go-live.

Cosa succede:

• Setup dell’ambiente di produzione e trasporto delle configurazioni
• Migrazione dati finale (cutover di produzione)
• Attivazione delle integrazioni in produzione
• Preparazione del team di hypercare
• Riunione di decisione go/no-go
• Esecuzione del go-live
• Monitoraggio immediato post-go-live

Deliverable chiave:

• Sistema di produzione live e accessibile
• Tutte le integrazioni attive e monitorate
• Dati di produzione caricati e validati
• Modello di supporto hypercare attivo
• Lista dei problemi noti con workaround

Insidie comuni:

• Errori di trasporto della configurazione tra test e produzione. Fate sempre una prova a vuoto.
• Delta della migrazione dati: il divario tra l’ultima migrazione di test e il cutover di produzione. Pianificate un processo di caricamento delta.
• Andare live di lunedì. Andate live di mercoledì o giovedì: avete due giorni di lavoro normale prima del weekend, e evitate il backlog del lunedì che colpisce un sistema che non ha mai visto carico reale.

Run (In corso)

Stabilizzazione post-go-live e miglioramento continuo.

Cosa succede:

• Supporto hypercare (prime 2–4 settimane): team dedicato in standby per i problemi
• Triage e risoluzione dei problemi
• Raccolta e prioritizzazione del feedback utenti
• Grooming del backlog della Fase 2
• Monitoraggio dell’adozione (tassi di login, qualità dei dati, conformità dei processi)
• Business review trimestrali per misurare il ROI rispetto al business case

Deliverable chiave:

• Sistema di produzione stabilizzato con backlog dei problemi prioritizzato
• Dashboard di adozione che traccia le metriche chiave
• Roadmap della Fase 2 basata sul feedback reale degli utenti
• Handover al team di supporto interno o al partner di servizi gestiti

Insidie comuni:

• Terminare l’hypercare troppo presto. Due settimane sono il minimo. Quattro settimane sono più sicure con integrazioni complesse.
• Non misurare l’adozione. Se il 40% del vostro team vendite torna ai fogli di calcolo entro 3 mesi, non avete implementato un CRM: avete comprato una licenza.
• Trattare la Fase 2 come una lista dei desideri. Prioritizzate in base all’impatto sul business, non in base a chi urla più forte.

Struttura del team

Un’implementazione di SAP Sales Cloud V2 richiede ruoli specifici sia lato partner che lato cliente. Sottodimensionare uno dei due lati rallenta il progetto.

Ruoli lato partner

Ruolo	Responsabilità	Allocazione tipica
Project Manager	Timeline, budget, rischio, comunicazione stakeholder	50–100% durante tutto il progetto
Solution Architect	Design del sistema, architettura di integrazione, decisioni tecniche	50–75% Discover–Explore, 25% Realize–Deploy
Functional Consultant	Configurazione V2, design dei processi, workshop, supporto UAT	100% Explore–Realize
Integration Developer	Configurazione middleware, integrazione API, gestione errori	50–100% Explore–Realize
Extension Developer	Estensioni personalizzate basate su BTP, adattamenti UI	Secondo necessità durante Realize
Data Migration Specialist	Analisi delle sorgenti, mappatura, trasformazione, caricamento, validazione	25–50% Prepare–Deploy
Change Management Lead	Formazione, comunicazione, strategia di adozione	25% durante tutto il progetto, 50% Deploy–Run

Ruoli lato cliente

Ruolo	Responsabilità	Allocazione tipica
Executive Sponsor	Approvazione budget, risoluzione escalation, autorità organizzativa	5–10% durante tutto il progetto
Project Lead (Business)	Decisioni quotidiane, validazione requisiti business, coordinamento UAT	50–75% durante tutto il progetto
Sales Process Owner	Definire «come vendiamo», validare la configurazione rispetto ai flussi di lavoro reali	25–50% Explore–Realize
IT Lead	Connettività di integrazione, security review, infrastruttura	25–50% Prepare–Deploy
Super User / Champion	Early adopter che testano, danno feedback e formano i colleghi	25% Explore–Run
Data Owner	Qualità dei dati sorgente, regole di business per la migrazione, sign-off di validazione	25% Prepare–Deploy

Matrice RACI (semplificata)

Attività	Partner PM	Solution Architect	Sponsor Cliente	Project Lead Cliente
Piano di progetto	R/A	C	I	C
Design della soluzione	C	R/A	I	C
Configurazione	C	A	I	R (valida)
Build integrazione	A	R	I	C
Migrazione dati	A	C	I	R (valida)
UAT	C	C	A	R
Decisione go/no-go	C	C	R/A	C
Formazione	R	C	I	A
Misurazione adozione	C	I	A	R

R = Responsabile, A = Accountable, C = Consultato, I = Informato

L’errore di staffing più comune, e lo diciamo per esperienza diretta: il cliente assegna un project lead che porta anche una quota commerciale piena. Un’implementazione V2 richiede il 50–75% del tempo di una persona durante le fasi Explore e Realize. Se il vostro miglior responsabile vendite divide la propria attenzione tra una pipeline da 2 milioni e i test UAT, entrambi ne soffriranno.

Tempistiche realistiche

Questa è l’unica tabella dei tempi a cui fa riferimento tutta la guida. Il fattore principale è il numero e la profondità delle integrazioni, non il numero di utenti.

Scenario	Utenti	Integrazioni	Tempistica	Cosa ottenete
Pacchetto PMI a prezzo fisso	Piccoli team	Nessuna	10 giorni	Il nostro pacchetto CRM in 10 giorni: perimetro di base predefinito (account, contatti, opportunità, pipeline, dashboard) a prezzo fisso.
PMI standard	10–25	0–1 (ERP base)	4–8 settimane	CRM di base adattato al vostro processo. Personalizzazione minima.
PMI con integrazione	10–25	2–3	6–12 settimane	CRM core + integrazione ERP (preventivi, ordini) + un sistema aggiuntivo (marketing, servizio)
Mid-market	25–100	3–5	8–16 settimane	Processo commerciale completo: territori, forecasting, workflow di approvazione. Molteplici integrazioni. Estensioni personalizzate.
Enterprise, singola regione	100–300	5–10	3–5 mesi	Processi complessi, molteplici canali di vendita, analytics avanzati, integrazione pesante.
Enterprise, più regioni	300+	10+	4–6 mesi	Rollout multi-paese, localizzazione, autorizzazioni complesse, deployment a fasi.

Due referenze pubblicate si collocano nelle righe superiori: intelligentfood è andata in produzione con Sales e Service Cloud V2 in tre mesi, collegata al suo ERP, e Nussbaum Matzingen è passata in cinque mesi da fogli Excel e cartelle Outlook a una piattaforma Sales Cloud V2 centrale.

Cosa determina la tempistica

Numero e complessità delle integrazioni è il singolo fattore più importante. Ogni integrazione aggiunge 2–4 settimane di sviluppo, test e gestione degli errori. Un’integrazione ERP da sola (account, contatti, prodotti, preventivi, ordini) può richiedere 4–6 settimane se volete sincronizzazione bidirezionale con risoluzione dei conflitti.

Volume e qualità dei dati. Migrare 5.000 account puliti è un compito da weekend. Migrare 500.000 account con duplicati, campi mancanti e formattazione incoerente è un progetto dentro il progetto. Pianificate di conseguenza.

Complessità delle personalizzazioni. La configurazione standard di V2 copre l’80–90% dei processi di vendita tipici. Il restante 10–20% (campi personalizzati, logica di business personalizzata, estensioni UI) aggiunge tempo in modo sproporzionato perché ogni personalizzazione richiede configurazione, test, documentazione e manutenzione continua.

Numero di utenti influenza le tempistiche di formazione e change management più di quelle tecniche. Configurare V2 per 25 utenti versus 250 non è drammaticamente diverso. Formare 250 persone lo è.

Velocità decisionale dell’organizzazione. Questo è il fattore che nessuno mette in un piano di progetto ma tutti sentono. Se il vostro comitato direttivo si riunisce mensilmente e impiega due settimane per approvare i cambiamenti di scope, ogni punto decisionale aggiunge un mese alla timeline. I progetti più veloci hanno project lead con potere decisionale in tempo reale.

Ripartizione dei costi

Abbiamo trattato i prezzi in dettaglio nella nostra guida ai prezzi e costi di SAP Sales Cloud V2. Ecco la ripartizione specifica per l’implementazione.

Costi di licenza

SAP non pubblica un listino fisso per Sales Cloud V2. Nelle trattative che vediamo, la licenza si colloca tipicamente intorno a 60–80 USD/utente/mese (valore indicativo, negoziato su volume e durata). Per 50 utenti sono circa 36.000–48.000 USD/anno. Cosa fa variare questo numero lo spiega la guida ai prezzi.

Costi di implementazione per scenario

Valori indicativi, USD, IVA esclusa, aggiornati a settembre 2026; non un’offerta. Le durate sono quelle della tabella dei tempi.

Scenario	Costo implementazione	Durata	Note
Pacchetto PMI a prezzo fisso	Prezzo fisso	10 giorni	CRM in 10 giorni, perimetro predefinito
PMI standard	25.000–50.000 USD	4–8 settimane	Accelerator preconfigurato, personalizzazione minima
PMI con integrazione	40.000–80.000 USD	6–12 settimane	CRM core + 2–3 integrazioni
Mid-market	80.000–200.000 USD	8–16 settimane	Configurazione completa + integrazioni + estensioni
Enterprise, singola regione	150.000–350.000 USD	3–5 mesi	Processi complessi, integrazione pesante
Enterprise, più regioni	250.000–500.000+ USD	4–6 mesi	Multi-paese, rollout a fasi, localizzazione

Costi nascosti che nessuno menziona

Migrazione dati. Prevedete 10.000–50.000 USD separatamente. Estrazione dai sistemi sorgente, data cleansing, logica di trasformazione, molteplici caricamenti di test, validazione e l’inevitabile momento «ci siamo dimenticati degli allegati». Il costo scala con il volume dei dati e il numero di sistemi sorgente.

Formazione. Prevedete 5.000–20.000 USD. Formazione specifica per ruolo (non sessioni generiche «ecco il sistema»), setup dell’ambiente di formazione, sviluppo dei materiali formativi e almeno due cicli di sessioni (iniziale + rinfresco dopo 4 settimane). Lo sviluppo dell’e-learning aggiunge ulteriori costi.

Change management. Prevedete 10.000–30.000 USD per il mid-market e oltre. Piani di comunicazione, messaggistica executive, setup della rete di champion, gestione della resistenza. Questa è la voce di budget più spesso tagliata e più spesso la ragione per cui l’adozione fallisce.

Supporto post-go-live. Prevedete 5.000–15.000 USD/mese per 3–6 mesi. Supporto hypercare, risoluzione problemi, miglioramenti minori, coaching sull’adozione. Questo si riduce nel tempo man mano che il team interno acquisisce competenze.

Costi SAP BTP continuativi. Se costruite estensioni personalizzate su BTP, ci sono costi di runtime: Cloud Foundry compute, HANA Cloud storage, licenze Integration Suite. Tipicamente 500–2.000 USD/mese per il mid-market, di più per l’enterprise.

Costo totale di proprietà nel primo anno

Componente	PMI (25 utenti)	Mid-market (75 utenti)	Enterprise (200 utenti)
Licenze (annuali, a 60–80 USD/utente/mese)	18.000–24.000 USD	54.000–72.000 USD	144.000–192.000 USD
Implementazione	25.000–50.000 USD	80.000–200.000 USD	150.000–350.000 USD
Migrazione dati	5.000–15.000 USD	15.000–30.000 USD	30.000–50.000 USD
Formazione	5.000–10.000 USD	10.000–15.000 USD	15.000–25.000 USD
Change management	0–5.000 USD	10.000–20.000 USD	20.000–30.000 USD
Post-go-live (6 mesi)	10.000–20.000 USD	30.000–60.000 USD	60.000–90.000 USD
Primo anno totale	63.000–124.000 USD	199.000–397.000 USD	419.000–737.000 USD

La tabella mostra lo schema: nel primo anno i servizi (implementazione, migrazione, formazione, hypercare) costano da due a quattro volte la licenza. I progetti PMI restano nella fascia bassa perché il perimetro è predefinito; i progetti enterprise dipendono dal numero di integrazioni. Usate la tabella come ordine di grandezza, poi fate stimare il vostro panorama applicativo.

Integrazione S/4HANA ed ERP

Per i clienti SAP ERP, l’integrazione tra Sales Cloud V2 e S/4HANA è la ragione principale per scegliere il CRM di SAP. È anche il punto in cui i progetti CRM si bloccano più spesso: l’offerta che non si riesce a prezzare, l’ordine che non viene registrato. Per questo copriamo entrambi i lati con un solo team, e per questo abbiamo scritto una guida sulla scelta di un partner per Cloud ERP e CRM insieme. Per un approfondimento su come S/4HANA Public Cloud e Sales Cloud V2 funzionano come stack integrato (master data condivisi, flusso quote-to-cash e il business case per l’adozione congiunta) consultate la nostra guida dedicata. E se state ancora valutando il lato ERP, partite dalla nostra panoramica di SAP S/4HANA Public Cloud.

Approcci nativi vs middleware

Opzione 1: SAP Integration Suite (consigliata). SAP pubblica contenuti di integrazione standard per Sales Cloud V2 e S/4HANA sul SAP Business Accelerator Hub, ad esempio il pacchetto SAP Sales Cloud Version 2 Integration for Sales Processes with SAP S/4HANA Cloud Public Edition (vedi anche la documentazione di configurazione SAP). I contenuti coprono scenari comuni come la replica dei business partner, l’anagrafica prodotti, la simulazione e il trasferimento degli ordini di vendita. Li configurate ed estendete invece di partire da zero, ma il perimetro degli oggetti dipende dall’edizione di S/4HANA: verificatelo sul pacchetto attuale prima di stimare. Un perimetro standard richiede tipicamente da tre a quattro settimane.

Opzione 2: Integrazione API diretta. V2 espone API REST; S/4HANA espone API OData e SOAP. Potete costruire integrazioni punto-a-punto senza middleware. Funziona per scenari semplici (sync unidirezionale, basso volume) ma diventa ingestibile man mano che la complessità cresce. Non lo raccomandiamo per più di 2–3 punti di integrazione.

Opzione 3: Middleware di terze parti (MuleSoft, Boomi, ecc.). Se usate già MuleSoft o Boomi per altre integrazioni, ha senso usare la stessa piattaforma. Ma perdete i contenuti SAP e dovete costruire i mapping da zero. Costo di licenza aggiuntivo: indicativamente 30.000–80.000 USD/anno, a seconda del volume e del contratto esistente.

Cosa coprono tipicamente i contenuti standard

Con i contenuti standard della SAP Integration Suite (il perimetro dipende da edizione e release; verificate il pacchetto attuale):

Oggetto	Direzione	Contenuto standard?	Note
Account / Clienti	Bidirezionale	Disponibile (verificare)	Account V2 ↔ Business partner S/4
Contatti	Bidirezionale	Disponibile (verificare)	Contatto V2 ↔ Persona di contatto S/4
Prodotti	S/4 → V2	Disponibile (verificare)	Replica anagrafica prodotti
Prezzi	S/4 → V2	Disponibile (verificare)	Determinazione prezzi via simulazione o replica delle condizioni, a seconda dello scenario
Preventivi → Ordini	V2 → S/4	Disponibile (verificare)	Simulazione e trasferimento dell’ordine di vendita in S/4
Attività	Bidirezionale	Parziale	Report visita, telefonate, task
Oggetti personalizzati	No	No	Mapping personalizzati richiesti

Scenari di integrazione personalizzati

Oltre al sync standard, costruiamo frequentemente:

• Verifica credito in tempo reale: quando un venditore crea un preventivo in V2, il sistema chiama S/4HANA per verificare il limite di credito del cliente e le partite aperte prima di permettere l’invio.
• Sync base installata / equipment: per le aziende che vendono a clienti esistenti (manifattura, field service), la replica della base installata da S/4 in V2 dà ai venditori il contesto su ciò che il cliente possiede già.
• Calcolo provvigioni: V2 cattura i dati dell’opportunità e della chiusura, che alimentano il motore provvigioni di S/4.
• Flusso documenti: allegare note di consegna e fatture S/4 all’opportunità V2 così il venditore può vedere l’intero ciclo di vita dell’ordine senza lasciare il CRM.

Ogni integrazione personalizzata aggiunge 2–4 settimane e 10.000–30.000 USD a seconda della complessità.

Pattern architetturale

L’architettura raccomandata per l’integrazione SAP-a-SAP:

SAP Sales Cloud V2
    ↕ (Events / API REST)
SAP Integration Suite (su BTP)
    ↕ (IDoc / BAPI / OData)
SAP S/4HANA (Cloud o On-Premise)

L’Integration Suite agisce da broker. Gestisce mapping, trasformazione, gestione degli errori, logica di retry e monitoraggio. Gli eventi V2 attivano sync in tempo reale. Job pianificati gestiscono la replica massiva. I record in errore finiscono in una dead-letter queue per la risoluzione manuale.

Per sistemi ERP non-SAP (Oracle, Microsoft Dynamics, legacy AS/400), si applica lo stesso pattern: l’Integration Suite o il vostro middleware preferito sostituisce i pacchetti di contenuto SAP-a-SAP con mapping personalizzati.

Strategia di migrazione dati

La migrazione dati è il filone di lavoro più sottovalutato in ogni implementazione CRM. Non è un esercizio tecnico. È un esercizio di processo aziendale avvolto in complessità tecnica.

Valutazione dei sistemi sorgente

Prima di migrare un singolo record, rispondete a queste domande:

1. Quali sistemi contengono oggi i dati di vendita? CRM (V1, Salesforce, fogli di calcolo), ERP, marketing automation, email, drive condivisi. La maggior parte delle aziende ha dati di vendita in 3–5 sistemi.
2. Qual è la qualità dei dati? Account duplicati, contatti mancanti, opportunità obsolete, convenzioni di denominazione incoerenti. Eseguite un report sulla qualità dei dati prima di dimensionare la migrazione.
3. Quali dati devono effettivamente essere migrati? Non tutti. Le opportunità perse nel 2018 non devono essere in V2. Definite regole di conservazione e archiviate il resto.
4. Chi possiede i dati? Non l’IT. I data owner aziendali (sales operations, CRM admin) devono validare i risultati della migrazione. Devono avere tempo allocato per questo.

Data cleansing prima della migrazione

Migrare dati sporchi in un sistema pulito crea un sistema sporco. Imponiamo una fase di pulizia prima di ogni migrazione:

• Deduplicazione: unire account e contatti duplicati. Usate il fuzzy matching (somiglianza dei nomi, matching degli indirizzi, dominio email) perché la deduplicazione per match esatto manca i duplicati ovvi.
• Standardizzazione: normalizzare codici paese, formati telefonici (E.164), formattazione indirizzi, classificazioni settoriali.
• Arricchimento: compilare i campi mancanti dove possibile. I fornitori di dati terzi (Dun & Bradstreet, ZoomInfo) possono colmare le lacune nei dati account.
• Archiviazione: rimuovere o archiviare i record che non appartengono al nuovo sistema. Opportunità perse più vecchie di 2 anni. Contatti senza attività da 3+ anni. Account che sono stati inattivi.

Prevedete 2–4 settimane per la pulizia. È un lavoro noioso. È anche l’attività con il ROI più alto dell’intero progetto.

Strumenti di migrazione

Migrazione V1 → V2: SAP Data Transfer Tool (DTT). SAP fornisce il DTT specificamente per le migrazioni V1-a-V2. Gestisce la mappatura del modello dati tra le entità V1 e V2. Non è una migrazione con un clic (dovete comunque configurare i mapping e gestire i campi personalizzati), ma per gli oggetti standard non serve costruire un ETL personalizzato. Descriviamo il procedimento nella nostra guida passo per passo alla migrazione con DTT.

Altre sorgenti → V2: ETL personalizzato. Per Salesforce, Dynamics, fogli di calcolo o altri CRM, serve una pipeline di migrazione. Opzioni:

• SAP Integration Suite con elaborazione batch (consigliata per i clienti SAP)
• Script personalizzati usando l’API OData di V2 (funziona per volumi ridotti)
• Strumenti ETL di terze parti (Informatica, Talend)

Indipendentemente dallo strumento, il processo è lo stesso: estrarre dalla sorgente, trasformare nel formato V2, caricare in V2, validare.

Validazione e riconciliazione

Dopo ogni caricamento di migrazione (test o produzione), eseguite la riconciliazione:

• Conteggio record: conteggio sorgente vs conteggio destinazione per ogni tipo di oggetto
• Completezza dei campi: controllo a campione di 50+ record per oggetto per la precisione a livello di campo
• Integrità delle relazioni: gli account sono ancora collegati ai loro contatti? Le opportunità sono ancora collegate all’account corretto?
• Validazione della logica di business: i territori di vendita si calcolano ancora correttamente? Le fasi della pipeline sono mappate correttamente?
• Validazione utente: i data owner aziendali hanno fisicamente esaminato record campione e confermato l’accuratezza?

Pianificate almeno tre cicli completi di migrazione di test prima del cutover di produzione. Il primo evidenzierà errori di mapping. Il secondo evidenzierà casi limite. Il terzo dovrebbe essere pulito. Se non lo è, non siete pronti per la produzione.

Adozione utente e change management

Le implementazioni CRM raramente falliscono perché la tecnologia non funziona. Falliscono perché le persone non usano il sistema.

Approcci alla formazione

Formazione specifica per ruolo, non tour delle funzionalità. Un venditore deve sapere come registrare una visita, aggiornare un’opportunità e consultare il report della propria pipeline. Non ha bisogno di un tour di 2 ore del pannello di amministrazione. Costruite percorsi formativi per ruolo: venditore, responsabile vendite, sales operations, dirigenza.

Pratica, non slide. Ogni sessione formativa dovrebbe essere almeno al 60% pratica in un ambiente di formazione configurato con dati realistici. Forniamo a ogni partecipante account, contatti e opportunità di esempio che rispecchiano il loro lavoro reale.

Just-in-time, non just-in-case. Formate le persone 1–2 settimane prima che inizino a usare il sistema, non 6 settimane prima del go-live. La ritenzione della conoscenza cala drasticamente dopo 2 settimane senza pratica. Organizzate una sessione di rinfresco 4 settimane dopo il go-live.

Microlearning per l’adozione continua. Video tutorial brevi (2–5 minuti) per attività specifiche. «Come creare un’opportunità.» «Come aggiornare il vostro forecast.» «Come trovare lo storico ordini di un cliente.» Questi diventano la libreria di riferimento che il vostro team usa davvero.

Strategia della rete di champion

Identificate 1 champion ogni 10–15 utenti. I champion sono:

• Early adopter genuinamente entusiasti (non semplicemente assegnati)
• Rispettati dai colleghi (se il top performer usa il CRM, gli altri seguono)
• Hanno accesso anticipato durante la fase Explore
• Formati a un livello più approfondito rispetto agli utenti standard
• Ci si aspetta che siano il primo punto di riferimento per il loro team (non un sostituto dell’helpdesk, ma una risorsa «come faccio X?»)
• Riconosciuti e premiati per il loro ruolo (riconoscimento pubblico, non solo lavoro aggiuntivo)

Nei nostri progetti i champion sono lo strumento di adozione più efficace: i team con un champion attivo adottano il sistema sensibilmente più in fretta di quelli senza.

Misurare l’adozione

Non si può migliorare ciò che non si misura. Tracciate queste metriche settimanalmente per i primi 3 mesi dopo il go-live:

Metrica	Obiettivo	Segnale d’allarme
Utenti attivi giornalieri	80%+ degli utenti con licenza	Sotto il 50% dopo la settimana 2
Aggiornamenti pipeline per settimana	Come minimo, i venditori aggiornano le opportunità settimanalmente	Opportunità stagnanti (nessun aggiornamento da 2+ settimane)
Tasso invio forecast	100% dei manager inviano i forecast in tempo	Sotto l’80% entro la settimana 4
Registrazione attività	I venditori registrano visite, chiamate ed email	Meno di 3 attività per venditore a settimana
Punteggio qualità dati	Duplicati in calo, completezza dei campi in aumento	Tasso di duplicazione in crescita, campi obbligatori vuoti

Quando una metrica diventa rossa, non inviate un’email minacciosa. Investigate. Il processo è troppo macchinoso? Un workflow è rotto? L’esperienza mobile è scadente? Correggete il sistema, non la persona.

La checklist di go-live

Usiamo questa checklist in ogni progetto. Stampatela. Esaminate ogni punto. Non andate live finché ogni casella non è spuntata.

Prontezza tecnica (1–7)

1. Ambiente di produzione provisionato e configurato: tutte le configurazioni trasportate dal test, verificate dal functional consultant.
2. Tutte le integrazioni attive in produzione: testate end-to-end con credenziali di produzione, gestione errori verificata.
3. Monitoraggio integrazioni configurato: alerting sugli errori, elaborazione dead-letter queue documentata.
4. Single sign-on (SSO) configurato e testato: ogni utente può accedere tramite l’identity provider aziendale.
5. Accesso mobile verificato: app mobile SAP Sales Cloud testata su iOS e Android con dati di produzione.
6. Integrazione email testata: se si usa la sync email lato server, verificata con il sistema di posta di produzione.
7. Performance validata: tempi di caricamento pagina sotto i 3 secondi, generazione report sotto i 10 secondi, nessun errore di timeout sotto il carico concorrente previsto.

Prontezza dei dati (8–12)

8. Migrazione dati di produzione completata: tutti i record nell’ambito caricati e riconciliati.
9. Conteggio record riconciliato: sorgente vs destinazione per ogni tipo di oggetto, documentato e firmato.
10. Integrità delle relazioni verificata: account collegati ai contatti, opportunità collegate agli account, nessun record orfano.
11. Sign-off del data owner: il data owner aziendale ha fisicamente controllato a campione i record e confermato l’accuratezza.
12. Piano migrazione delta pronto: processo per migrare i record creati nel sistema sorgente tra l’ultima migrazione e il go-live.

Prontezza dell’integrazione (13–16)

13. Integrazione ERP validata end-to-end: preventivo di test creato in V2, verificato che crea un ordine di vendita in S/4, verificato che lo stato dell’ordine si sincronizza con V2.
14. Scenari di errore testati: cosa succede quando l’ERP è fuori servizio? Quando manca un campo obbligatorio? Quando arriva un duplicato?
15. Logica di retry verificata: i messaggi di integrazione falliti vengono ritentati automaticamente e compaiono nel monitoraggio.
16. Processi di fallback documentati: se l’integrazione fallisce durante il go-live, quale processo manuale seguono gli utenti?

Prontezza utente (17–19)

17. Tutti gli utenti formati: formazione specifica per ruolo completata, presenze registrate, materiali formativi accessibili.
18. Rete di champion attiva: i champion usano il sistema da 2+ settimane, sanno dove escalare i problemi.
19. Comunicazione inviata: annuncio go-live, istruzioni di login, contatti supporto, documentazione «dove ottenere aiuto» distribuita.

Prontezza operativa (20)

20. Piano hypercare attivo: team di supporto identificato, matrice di escalation pubblicata, dashboard di monitoraggio configurati, standup giornaliero pianificato per le prime 2 settimane.

Piano di rollback

Ogni go-live ha bisogno di un piano di rollback. Cosa succede se un difetto critico emerge nelle prime 48 ore?

• Rollback dati: potete ripristinare il sistema precedente e riprendere le operazioni lì?
• Rollback integrazioni: potete reindirizzare le integrazioni al sistema precedente?
• Comunicazione utenti: chi comunica il rollback e le istruzioni?
• Soglia: quale livello di gravità attiva una decisione di rollback? Chi prende la decisione?

Un piano di rollback che non si usa mai è un’assicurazione economica. Scrivetelo comunque.

Cosa può andare storto (e come prevenirlo)

Dalla nostra esperienza di progetto, questi sono i cinque errori più comuni.

1. Sottovalutazione dell’integrazione

Cosa succede: Il piano di progetto prevede 3 settimane per «l’integrazione ERP». Il lavoro effettivo richiede 10 settimane. L’ambito dell’integrazione era descritto come «sincronizzare account e ordini» ma la realtà include sync bidirezionale, risoluzione conflitti, gestione errori, mappatura campi personalizzati, elaborazione delta e logica di retry.

Come prevenirlo: Scrivete documenti di design dell’integrazione dettagliati durante la fase Prepare. Ogni campo. Ogni direzione. Ogni trigger. Ogni scenario di errore. Poi aggiungete un margine generoso alla stima dei tempi: l’integrazione è il filone di lavoro che sfora più spesso.

2. Migrazione dati trattata come un ripensamento

Cosa succede: La migrazione dati è l’ultimo filone a partire e il primo a essere compresso quando la timeline scivola. Il team scopre durante il primo caricamento di test che la qualità dei dati sorgente è terribile. La pulizia richiede 4 settimane invece della settimana prevista.

Come prevenirlo: Iniziate la valutazione dei dati nella fase Discover. Iniziate la pulizia nella fase Prepare. Eseguite la prima migrazione di test nella fase Explore, non Realize. Trattate la migrazione dati come un filone di primo livello con un proprio piano, risorse e timeline.

3. Change management tagliato dal budget

Cosa succede: L’executive sponsor approva il budget tecnologico ma taglia le cose «soft»: formazione, comunicazione, programma champion. Il sistema va live tecnicamente perfetto. Nessuno lo usa. Dopo 6 mesi, il VP Sales chiede perché l’investimento CRM da 200.000 USD non ha migliorato la visibilità della pipeline.

Come prevenirlo: Includete il change management nel budget non negoziabile. Presentate le metriche di adozione accanto ai milestone tecnici. Rendete l’executive sponsor responsabile dell’adozione, non solo del go-live.

4. Scope creep tramite «configurazione»

Cosa succede: Durante Explore, gli utenti business vedono V2 per la prima volta e hanno idee. Buone idee, ma ognuna aggiunge scope. «Possiamo aggiungere un campo personalizzato qui?» «Possiamo cambiare questo workflow?» Ogni modifica è piccola. Collettivamente, aggiungono 4 settimane a Realize e 2 settimane al testing.

Come prevenirlo: Mantenete un backlog con stime di sforzo. Ogni richiesta passa dal project lead. La Fase 1 ha una data di scope freeze. Tutto ciò che viene dopo quella data va alla Fase 2. Siate disciplinati su questo o il vostro progetto non finirà mai.

5. Disallineamento partner-cliente

Cosa succede: Il partner di implementazione presume che il team del cliente sarà disponibile al 50% per workshop e test. Il team del cliente lavora al 100% sulle attività quotidiane. I workshop vengono riprogrammati. I ritardi nei test si accumulano. Il partner fattura il tempo di attesa. Nessuno è contento.

Come prevenirlo: Concordate l’allocazione delle risorse lato cliente per iscritto durante la fase Prepare. Includetela nella project charter. Se il cliente non può dedicare il tempo, adattate la timeline in anticipo, non a metà della fase Realize.

Per chi sta ancora scegliendo chi realizzerà l’implementazione, il nostro confronto delle migliori società di consulenza SAP CX in Svizzera indica i criteri, e la nostra pagina sulla consulenza SAP CX in Svizzera spiega come realizziamo i progetti Sales Cloud V2.

Domande frequenti

Quanto tempo richiede l’implementazione di SAP Sales Cloud V2?

Dipende dal perimetro, e i numeri vengono dalla tabella dei tempi: 10 giorni per il pacchetto a prezzo fisso CRM in 10 giorni, 4–8 settimane per un perimetro PMI su misura (6–12 settimane con due o tre integrazioni), 8–16 settimane per il mid-market e 3–6 mesi per l’enterprise. La variabile principale è la complessità dell’integrazione, non il numero di utenti.

Quanto costa l’implementazione di SAP Sales Cloud V2?

Valori indicativi per l’implementazione (USD, IVA esclusa, aggiornati a settembre 2026, non un’offerta): 25.000–50.000 USD per un perimetro PMI standard, 80.000–200.000 USD per il mid-market e 150.000–500.000+ USD per l’enterprise. Le licenze sono a parte. Nella nostra tabella del costo totale del primo anno, 25 utenti si collocano a 63.000–124.000 USD e 75 utenti a 199.000–397.000 USD. Il lato licenze è spiegato nella guida ai prezzi.

Ho bisogno di un partner per l’implementazione di SAP Sales Cloud V2?

Tecnicamente no: SAP fornisce documentazione e risorse di apprendimento. In pratica la maggior parte delle aziende ne usa uno, perché configurazione, integrazione e migrazione dati di V2 richiedono competenze raramente disponibili internamente. La vera domanda è quale partner. Cercate esperienza specifica su V2 (non solo V1/C4C), esperienza di integrazione con il vostro ERP e progetti V2 completati con referenze contattabili. Il nostro articolo su cosa significa essere SAP Gold Partner aiuta a leggere le dichiarazioni dei partner, e come lavoriamo descrive il nostro metodo.

Posso implementare SAP Sales Cloud V2 senza S/4HANA?

Sì. V2 funziona come CRM autonomo e si collega ad altri ERP (Oracle, Microsoft Dynamics, SAP ECC) tramite API e middleware, oppure lavora senza ERP. S/4HANA porta i contenuti di integrazione standard di SAP e dati anagrafici condivisi, un vantaggio concreto per i clienti SAP; mapping, licenze e monitoraggio vanno comunque pianificati. Se S/4HANA è nella vostra roadmap, il nostro assessment di readiness S/4HANA mostra a che punto è il vostro lato ERP.

Qual è la differenza tra implementazione V1 e V2?

Tutto il lato tecnico è diverso: modello dati, superficie API, framework di estensione, framework UI, piattaforma di hosting. La metodologia di implementazione (SAP Activate) è la stessa, ma ogni deliverable tecnico cambia. Le estensioni V1 non funzionano in V2. Le integrazioni V1 devono essere ricostruite. La migrazione dati da V1 a V2 richiede il Data Transfer Tool di SAP. Leggete il nostro confronto completo V1 vs V2.

Cos’è SAP Activate e perché è importante?

SAP Activate è la metodologia di implementazione di SAP: Discover, Prepare, Explore, Realize, Deploy, Run. Fornisce un framework strutturato con deliverable definiti, quality gate e best practice. È importante perché previene la modalità di fallimento implementativo più comune: iniziare a costruire prima di capire cosa si sta costruendo. Ogni partner SAP serio segue SAP Activate o un suo derivato.

Come gestisco la migrazione dati da Salesforce a V2?

Non esiste uno strumento di migrazione automatico da Salesforce a V2. Serve una pipeline ETL personalizzata: estrarre da Salesforce tramite le sue API, trasformare nel modello dati di V2 (mappatura campi, mappatura valori, mappatura relazioni) e caricare tramite le API OData di V2 o import batch. Prevedete 3–6 settimane a seconda del volume e della complessità dei dati. La logica di trasformazione è la parte difficile: Salesforce e V2 modellano opportunità, contatti e attività in modo diverso.

Cosa succede dopo il go-live?

Le prime 4 settimane dopo il go-live sono hypercare: un team di supporto dedicato monitora il sistema, risolve i problemi e affianca gli utenti. Dopo l’hypercare, si passa a un modello di supporto a regime (team interno o partner di servizi gestiti). La maggior parte delle organizzazioni avvia un progetto di Fase 2 a 2–3 mesi dal go-live per affrontare gli elementi del backlog e i nuovi requisiti emersi durante le prime settimane di utilizzo reale. Il monitoraggio dell’adozione continua per almeno 6 mesi.

Posso implementare V2 a fasi?

Sì, e lo raccomandiamo. La Fase 1 copre il CRM core (account, contatti, opportunità, gestione pipeline) più le integrazioni critiche. La Fase 2 aggiunge funzionalità avanzate: gestione territori, forecasting, integrazione CPQ, connettività con il marketing automation. L’implementazione a fasi riduce il rischio, consegna valore più velocemente e dà agli utenti tempo per assorbire il cambiamento. La maggior parte dei nostri progetti si articola in 2–3 fasi distribuite su 6–12 mesi.

E SAP Sales Cloud V2 per i team di vendita sul campo?

V2 include un’app mobile (iOS e Android) e funzionalità offline per le vendite sul campo. Le considerazioni di implementazione per i team sul campo includono: configurazione del sottoinsieme dati offline (quali dati sono disponibili senza connettività), workflow di pianificazione visite, ottimizzazione percorsi e registrazione attività. Il testing specifico per il mobile è essenziale: non date per scontato che l’esperienza desktop si traduca perfettamente sul mobile. Abbiamo scritto specificamente di V2 per manifattura e vendita sul campo.

---

Implementare SAP Sales Cloud V2 non è banale, ma metodo, strumenti ed esperienza esistono. Ciò che distingue un’implementazione riuscita da una difficile sono la pianificazione, la disciplina e la disponibilità a investire nel lavoro meno appariscente: qualità dei dati, progettazione dell’integrazione, change management.

Se state valutando V2 o pianificando un’implementazione, parliamone. Vi diremo onestamente quanto costerà il vostro progetto, quanto tempo ci vorrà e dove sono i rischi. Quella conversazione è gratuita e di solito fa risparmiare più di quanto costa in errori evitati.

Sulla nostra pagina dedicata a SAP Sales Cloud V2 trovate cosa realizziamo dall’inizio alla fine. Oppure leggete il caso di studio Nussbaum Matzingen: un produttore svizzero di imballaggi passato in cinque mesi a una piattaforma Sales Cloud V2 centrale.