L'integrazione è il punto in cui i progetti SAP smettono di essere tecnici e diventano un fatto di business. Ogni ordine che arriva da un marketplace, ogni movimento di magazzino registrato da un WMS, ogni anagrafica sincronizzata con il CRM è un flusso che — se progettato male — diventa il principale collo di bottiglia operativo dell'azienda.
Il modello che adottiamo in Ocra parte da un principio non negoziabile: l'integrazione non è una scatola di middleware da montare a fine progetto, è un'architettura da disegnare insieme al disegno dei processi. Solo così si evita il pattern tipico in cui SAP viene riempito di customizzazioni per "tenere insieme" sistemi che non si parlano in modo strutturato.
Le tre regole d'oro
- Niente integrazioni punto-punto sul core SAP: tutto passa da un layer di mediazione (SAP Integration Suite, MuleSoft o equivalente)
- Contratti di interfaccia versionati, documentati e testati come codice
- Monitoring end-to-end: se un flusso si rompe alle 03:00, qualcuno se ne accorge prima del customer service
Cosa colleghiamo, ogni giorno
SAP S/4HANA con piattaforme e-commerce (Shopify, Magento, Salesforce Commerce), PIM e DAM, WMS di magazzino, sistemi di trasporto, marketplace (Amazon, Zalando), POS retail, CRM, sistemi di pagamento, portali B2B, EDI con fornitori e clienti. Per ognuno di questi mondi esiste un pattern di integrazione consolidato che riutilizziamo invece di reinventare ogni volta.
Un'integrazione ben fatta è invisibile: i dati arrivano nel posto giusto, alla velocità giusta, con la qualità giusta. Quando si vede l'integrazione, vuol dire che sta fallendo.
Il pattern Ocra
Partiamo sempre da un integration assessment che mappa flussi, volumi e SLA reali. Solo dopo proponiamo l'architettura. Quasi sempre emergono integrazioni "fantasma" — file Excel scambiati via mail, script in VBA, copia-incolla notturni — che pesano sui processi senza essere mai stati censiti. Bonificare questo strato è il primo guadagno.
Per il livello tecnologico il default è SAP Integration Suite su BTP, perché garantisce certificazione SAP e pattern pre-costruiti per gli scenari S/4HANA più comuni. Quando il cliente ha già investito in MuleSoft, Boomi o iPaaS proprietario ci innestiamo lì, preservando lo standard SAP via API pubbliche.
L'errore da non fare
Il rischio più grande non è tecnico ma di governance: senza un owner unico delle interfacce, ogni team aggiunge il proprio flusso e il middleware torna a essere un caos. Per questo nei progetti enterprise istituiamo un piccolo team di Integration Governance — anche solo due persone — che approva ogni nuovo flusso, assegna un contratto di interfaccia e ne presidia il ciclo di vita.
