SAP Business Technology Platform

Che cos’è SAP BTP?

SAP Business Technology Platform (SAP BTP) è la piattaforma cloud di SAP per integrazione, estensioni, automazione dei processi, dati e IA: lo strato che collega sistemi SAP e non SAP e che porta la logica che non appartiene a un’applicazione standard. Spadoom è un SAP Gold Partner svizzero che implementa SAP BTP per collegare SAP S/4HANA Public Cloud con Sales Cloud V2, Service Cloud V2 e il resto dello stack CX, e che gestisce le interfacce e le estensioni che costruisce. Da settembre 2026 Spadoom è anche partner SAP PartnerEdge Build: le nostre soluzioni BTP passano la verifica di SAP e saranno offerte nello SAP Store.

In pratica BTP porta tre tipi di lavoro: l’interfaccia tra ERP e applicazioni CX, il passaggio di approvazione che il vostro processo richiede e che lo standard non prevede, e l’evento che deve raggiungere tre sistemi nell’ordine corretto. La documentazione della piattaforma SAP è il riferimento tecnico ufficiale, la pagina prodotto di SAP BTP presenta le famiglie di servizi, SAP Integration Suite è il servizio da cui parte la maggior parte dei nostri progetti e lo SAP Discovery Center è il catalogo SAP di servizi, piani e missioni di riferimento, con lo strumento di stima dei costi che usiamo nella definizione dell’ambito.

La regola che seguiamo: BTP non è la prima risposta. Verifichiamo le funzionalità standard, poi le estensioni in-app supportate e solo dopo un’estensione side-by-side su BTP. Un’estensione di cui non avevate bisogno è un sistema che ora dovete gestire, aggiornare e trasferire. Se preferite partire dall’introduzione generale, il nostro blog spiega che cos’è SAP BTP e quando serve. Questa pagina parla di implementazione: che cosa costruiamo su BTP, come viene concesso in licenza e chi lo gestisce dopo.

Spadoom lavora su BTP come parte della delivery Cloud ERP e Customer Experience in Svizzera, Germania, Austria e Italia, con un unico team per il lato ERP e il lato CX di ogni interfaccia.

Caso cliente: oltre un milione di messaggi al mese in Meier Tobler

Meier Tobler fornisce tecnica per riscaldamento, ventilazione e sanitari in tutta la Svizzera. La vecchia piattaforma SAP PI/PO non garantiva dati affidabili in tempo reale tra lo shop online e SAP S/4HANA, perciò prezzi e giacenze nello shop erano spesso non aggiornati. Abbiamo prima offerto consulenza sull’acquisto e sul dimensionamento delle licenze SAP Integration Suite per il loro volume di messaggi, poi abbiamo implementato SAP Integration Suite come piattaforma di integrazione centrale e costruito le interfacce tra shop ed ERP.

Oggi più di un milione di messaggi al mese passa da un’unica piattaforma monitorata, prezzi e giacenze nello shop sono sincronizzati in tempo reale e gli ordini rientrano nell’ERP senza interventi manuali. La nuova architettura prepara inoltre la dismissione graduale dei vecchi sistemi PI/PO. Leggete la storia completa di Meier Tobler.

In intelligentfood il lavoro su BTP è stato di natura diversa: applicazioni mobili per un team di vendita che lavora in viaggio, insieme a Sales Cloud V2 e all’integrazione con Cloud ERP.

Integration Suite, Build o IA: quale servizio BTP fa che cosa

«Ci serve BTP» non è ancora un ambito. BTP è un catalogo di servizi, ciascuno con licenza e gestione proprie, e la maggior parte dei progetti ne usa due o tre, non tutti. Ecco come spieghiamo i principali prima di ordinare qualsiasi cosa.

Servizio BTP	Che cosa fa	Uso tipico in un progetto ERP e CX	Quando non serve
SAP Integration Suite	Gestisce le interfacce tra sistemi: mappature, instradamento, ripetizioni, gestione delle API, eventi e monitoraggio	Ordini, prezzi, giacenze e anagrafiche clienti tra S/4HANA, Sales o Service Cloud V2, Commerce e sistemi terzi	Quando un’integrazione standard fornita da SAP copre il flusso così com’è, senza requisiti aggiuntivi di mappatura o monitoraggio
SAP Build (Build Apps, Build Process Automation, Build Code)	App low-code, workflow di approvazione e automazione dei processi, più un ambiente di sviluppo per codice professionale	Un passaggio di approvazione che manca nello standard, un’app mobile per la forza vendita, un’applicazione side-by-side su API rilasciate	Quando le estensioni key-user in S/4HANA o nell’applicazione CX risolvono il requisito
SAP AI Core, Generative AI Hub e Joule	Accesso a modelli linguistici di grandi dimensioni, scenari di IA propri sull’infrastruttura SAP e l’assistente IA di SAP	Un caso d’uso che richiede dati aziendali autorizzati e un controllo umano, per esempio lo smistamento dei casi di servizio	Quando una funzione di IA già presente nell’applicazione SAP fa il lavoro (vedere Business AI)
SAP Datasphere e SAP Business Data Cloud	Modelli di dati armonizzati e prodotti di dati su fonti SAP e non SAP	Analisi che uniscono dati ERP e CX, come il margine di servizio per cliente	Quando le analisi integrate di un’applicazione coprono il suo fabbisogno di reporting (vedere Business Data Cloud)
SAP Cloud Identity Services	Autenticazione e provisioning centralizzati degli utenti nelle applicazioni cloud SAP	Single sign-on e provisioning utenti per S/4HANA, applicazioni CX e app BTP	Raramente: la maggior parte dei paesaggi cloud SAP lo usa già, quindi si tratta di configurazione e non di un nuovo acquisto

L’ordine conta. Integration Suite arriva di solito per prima, perché ERP e applicazioni CX devono concordare sui dati prima che sopra di essi si automatizzi qualcosa. Build segue quando manca un passaggio di processo. L’IA arriva per ultima, quando i dati su cui si basa sono corretti e qualcuno è responsabile del controllo.

Clean core: quando un’estensione va su BTP

Clean core significa mantenere l’ERP vicino allo standard, così che le release SAP si installino senza rilavorazioni. In SAP S/4HANA Cloud un requisito può essere risolto in tre punti, e li verifichiamo in questo ordine.

1. Estensioni key-user nel sistema. Campi propri, logica propria in punti di estensione rilasciati, moduli e schermate adattati. Nessuna piattaforma separata, nessuna gestione aggiuntiva.
2. Estensioni per sviluppatori nel sistema. Sviluppo ABAP Cloud su API rilasciate, vicino ai dati, per la logica che deve girare all’interno della transazione ERP.
3. Side-by-side su SAP BTP. Un’applicazione o un workflow separati che comunicano con l’ERP solo tramite API ed eventi rilasciati. È il posto giusto quando la logica serve più sistemi (ERP e CX insieme), ha utenti propri fuori dall’ERP o deve scalare o cambiare con un ritmo diverso dal core.

Un’estensione side-by-side costa di più da gestire rispetto a una in-app: deployment proprio, ruoli di accesso propri, monitoraggio proprio. La raccomandiamo quando vale uno dei motivi sopra, e scriviamo quel motivo nella decisione di architettura, così che il team successivo possa seguirlo.

Connettere. Estendere. Automatizzare.

SAP BTP è la base delle nostre estensioni. Colleghiamo SAP S/4HANA Public Cloud con Sales Cloud, Service Cloud, Commerce, CPQ e FSM. Partiamo dal processo aziendale, concordiamo quale sistema è il riferimento per ogni dato e costruiamo attorno interfacce, applicazioni e monitoraggio.

Tre domande decidono la maggior parte dei progetti di interfaccia prima che venga scritta una riga di codice:

• A chi appartiene il dato? Un prezzo vive nell’ERP, un’opportunità in Sales Cloud, un ordine di servizio in FSM. Ogni interfaccia copia dal sistema di riferimento, mai in entrambe le direzioni senza una regola per i conflitti.
• Sincrono o evento? Un controllo del prezzo durante l’offerta richiede una risposta immediata. Uno stato di consegna può arrivare come evento qualche secondo dopo. La scelta cambia gestione degli errori, volumi e costi.
• Che cosa succede se il sistema di destinazione non risponde? Ripetizioni, una dead-letter queue e un avviso a una persona designata, concordati prima del go-live.

Su SAP BTP sviluppiamo anche prodotti nostri, tra cui le estensioni Engage per Sales e Service Cloud V2: vedere Built by Spadoom.

Dal preventivo all’intervento sul campo

Il commerciale prepara un’offerta in Sales Cloud e CPQ. L’ordine accettato arriva a Cloud ERP, che verifica affidabilità creditizia, prezzi e disponibilità. Una richiesta di servizio genera un intervento per il team sul campo in FSM, e le ore e il materiale confermati tornano all’ERP per la fatturazione. BTP collega i passaggi e porta le estensioni necessarie al processo, per esempio un’approvazione per uno sconto oltre una soglia. È un’architettura di esempio: interfacce, ambito dei prodotti e licenze vengono verificati durante l’assessment. La nostra panoramica sulla trasformazione mostra come i tasselli ERP e CX si incastrano dall’inizio alla fine.

Come viene concesso in licenza SAP BTP

SAP vende BTP con due modelli commerciali, a consumo e in abbonamento, e molti clienti li usano entrambi. È un orientamento, non un’offerta: i vostri diritti effettivi dipendono dal vostro contratto. Il materiale formativo SAP sui modelli commerciali di SAP BTP li descrive in dettaglio.

• A consumo con cloud credit prepagati. Con lo SAP BTP Enterprise Agreement (BTPEA) vi impegnate per la durata del contratto su un volume prepagato di cloud credit, e l’uso effettivo dei servizi idonei viene addebitato ogni mese su quei credit. BTPEA è il modello per i nuovi contratti; il precedente Cloud Platform Enterprise Agreement (CPEA) funziona allo stesso modo e prosegue per gli account CPEA esistenti. I due elenchi di servizi non sono identici.
• Pay-As-You-Go. Nessun impegno anticipato; ricevete ogni mese una fattura a posteriori per ciò che usate. SAP lo posiziona per piccole applicazioni, proof of concept e progetti pilota.
• Abbonamento. Un prezzo fisso per un servizio e un piano specifici su una durata fissa, indipendentemente dal consumo. Adatto a servizi con un utilizzo prevedibile.
• Free tier. Molti servizi offrono piani gratuiti con limiti di utilizzo, sufficienti per prototipare un flusso prima di ordinare qualsiasi cosa.

Anche RISE with SAP e GROW with SAP contengono BTP: SAP indica i cloud credit BTP come componente di RISE, ed entrambe le edizioni di GROW includono credit del BTP Enterprise Agreement e diritti sulle funzionalità SAP Build. Se quei credit coprono le integrazioni previste dipende dal volume e dai servizi utilizzati.

Che cosa verifichiamo prima di definire l’ambito, perché la licenza non vi sorprenda dopo il go-live:

• Diritti esistenti. Quali servizi, piani e credit BTP contiene già il vostro contratto attuale (anche RISE o GROW).
• Servizi e piani necessari al flusso. Integration Suite, un servizio Build, un servizio di IA o nessuno di questi, e con quale piano.
• Una stima dei consumi. Volume di messaggi e connessioni previsti, calcolati con lo strumento di stima dello SAP Discovery Center e documentati con le relative ipotesi. In Meier Tobler questo dimensionamento è stato il primo risultato, prima di costruire una sola interfaccia.
• Chi controlla i consumi. I credit si consumano ogni mese; qualcuno dalla vostra parte o dalla nostra verifica l’utilizzo nel BTP cockpit e riceve un avviso prima che il budget si esaurisca.

Quanto costa gestirlo, oltre a costruirlo

Un business case BTP raramente si decide sulla costruzione. Si decide su chi controlla le interfacce a fine mese, su che cosa coprono davvero i diritti di servizio previsti dal vostro contratto e su cosa accade quando un sistema di destinazione non risponde alle due di notte. Ruoli di accesso, registri, deployment e avvisi rientrano nell’ambito dall’inizio, e i test di accettazione li concordiamo prima dello sviluppo, non dopo.

Dopo il go-live ci sono due opzioni, e concordiamo quale vale prima di iniziare a costruire. O il vostro team IT subentra con documentazione, runbook e il passaggio di ogni avviso, oppure Spadoom gestisce interfacce ed estensioni con un contratto di supporto: monitoriamo l’elaborazione dei messaggi, analizziamo i messaggi in errore, testiamo le release trimestrali SAP sulle interfacce e riferiamo sui consumi. In entrambi i casi ogni interfaccia ha un responsabile designato e un percorso di ripristino documentato.

Iniziare con un flusso. Costruirlo bene.

Portate un processo che oggi dipende ancora dalla copia dei dati o dai solleciti via email. In un assessment a prezzo fisso mappiamo sistemi, responsabili dei dati ed eccezioni, verifichiamo i vostri diritti BTP esistenti e stimiamo i consumi. Ricevete una proposta di architettura, l’ambito di consegna e una base di costo. Monitoraggio e passaggio di consegne fanno parte dell’ambito, non di una richiesta di modifica successiva.

Se usate ancora SAP PI/PO, lo stesso assessment può partire dal vostro inventario delle interfacce: quali flussi passano a Integration Suite così come sono, quali vengono riprogettati e quali possono essere eliminati.

Parliamo della vostra integrazione oppure scoprite come ERP e CX si incastrano.