ERP a due livelli: S/4HANA Public Cloud nella filiale mentre la casa madre mantiene il suo ERP

In sintesi: una filiale non deve aspettare l’ERP del gruppo. Con un ERP a due livelli usa S/4HANA Public Cloud come ERP locale completo, mentre la casa madre resta su ECC o S/4HANA Private Edition. Funziona se si chiariscono prima quattro questioni: dove passa il confine tra i livelli, a chi appartiene ciascun oggetto anagrafico, come registra realmente l’intercompany e chi risponde delle interfacce alle due di notte.

Una conversazione che affrontiamo più o meno una volta al mese. La filiale svizzera è cresciuta oltre quello che ha in casa: forse un vecchio ECC su cui il gruppo non investe più, forse un ERP locale che la capogruppo tollera, a volte un insieme di fogli di calcolo che spaventerebbe qualsiasi revisore. Vogliono andare avanti. E poi qualcuno a Stoccarda o a Milano dice che il gruppo non toccherà il proprio ERP prima del 2030.

A prima vista sembra una situazione di stallo. Non lo è. È il caso da manuale dell’ERP a due livelli, e il manuale funziona in silenzio da anni.

Che cosa significa davvero ERP a due livelli

Il primo livello è la casa madre. ECC, S/4HANA private edition, qualunque cosa il gruppo abbia costruito in un decennio. Lì risiedono la contabilità di gruppo, il consolidamento, di solito l’anagrafica fornitori e l’anagrafica materiali globale.

Il secondo livello è la filiale, che gestisce S/4HANA Public Cloud. Conduce il business locale dall’inizio alla fine: vendite locali, acquisti locali, scorte locali, chiusura di legge propria.

I due sono collegati attraverso un elenco di processi deliberatamente corto. Acquisto e vendita intercompany. Reporting di gruppo. Gli oggetti anagrafici che appartengono realmente al gruppo. E questo è quasi tutto. SAP descrive i modelli di impiego (casa madre e filiale, servizi centrali, ecosistema della supply chain) e i contenuti di integrazione preconfigurati nella sua pagina tematica sull’ERP a due livelli con S/4HANA Public Cloud.

Ciò che sfugge di solito è che cosa l’ERP a due livelli non è. Non è un sistema satellite che alimenta una nave madre. La filiale ha un ERP proprio, completo, in grado di chiudere e di essere verificato. Semplicemente non si porta dietro vent’anni di modifiche di gruppo.

Perché si adatta in particolare al caso svizzero

La Svizzera produce questa costellazione più di altri mercati, per ragioni strutturali prosaiche. Molte entità svizzere sono la filiale redditizia, scomoda e non in euro di un gruppo DACH o italiano più grande. Abbastanza grandi da avere esigenze ERP reali e abbastanza piccole perché la roadmap di gruppo non le metta in cima alle priorità.

Si aggiungono i requisiti locali che il sistema di gruppo di solito gestisce male comunque: la QR-fattura, i file di pagamento ISO 20022 verso una banca svizzera, l’IVA alle aliquote svizzere, un perimetro salariale che con quello tedesco non ha nulla in comune. Un’entità svizzera su un ECC tedesco porta tipicamente un piccolo cumulo di soluzioni tampone locali proprio su questi punti, mantenute da una persona vicina alla pensione.

L’approccio a due livelli trasforma quelle soluzioni tampone in scope standard di un sistema che include una versione nazionale svizzera, con la gestione della QR-fattura. Spesso è questa la motivazione vera, ed è una buona motivazione.

Le quattro decisioni da cui dipende l’esito

Tutto il resto è dettaglio realizzativo. Su questi quattro punti i progetti si vincono o si perdono, e tutti e quattro sono decisioni di business travestite da questioni tecniche.

1. Dove passa il confine tra i livelli

Non “quali moduli”, ma quali processi terminano al confine. Da scrivere per processo, con un nome accanto.

La versione che funziona: la filiale è responsabile di order-to-cash, procure-to-pay, scorte e della propria chiusura di legge. Il gruppo è responsabile di consolidamento, tesoreria di gruppo e degli oggetti anagrafici che governa realmente.

La versione che fallisce: il gruppo tiene per sé “solo la determinazione prezzi” o “solo l’anagrafica clienti” perché qualcuno ci è affezionato, e allora ogni ordine di vendita locale richiede un viaggio di andata e ritorno verso un sistema in un altro Paese con una finestra di manutenzione diversa. Abbiamo visto configurazioni simili: l’inserimento ordini della filiale dipendeva da un job notturno nel centro dati della casa madre, quindi un cliente creato il martedì pomeriggio non poteva essere fatturato fino al giovedì. Nessuno lo aveva progettato così. Si era accumulato.

2. A chi appartiene ciascun oggetto anagrafico

Un proprietario per oggetto, replicato in sola lettura nell’altra direzione. Scrivete la tabella, concordate la tabella, e poi non rinegoziatela ogni trimestre.

Una ripartizione che regge nella maggior parte dei gruppi:

Oggetto	Proprietario	Direzione
Anagrafica fornitori (fornitori di gruppo)	Livello 1	Verso il basso, sola lettura nel livello 2
Anagrafica materiali prodotti finiti	Livello 1	Verso il basso, campi locali aggiuntivi nel livello 2
Clienti locali	Livello 2	Solo locale
Prezzi e condizioni locali	Livello 2	Solo locale
Piano dei conti	Livello 1	Verso il basso, mappato
Centri di costo, locali	Livello 2	Verso l’alto per il reporting

La regola sotto la tabella: nulla è bidirezionale. Nel momento in cui un oggetto viene mantenuto in entrambi i livelli, avete costruito una race condition dentro la vostra chiusura mensile, e riemergerà tre trimestri dopo come una differenza di arrotondamento che nessuno sa spiegare.

3. Come registra realmente l’intercompany

Il punto che nei workshop passa senza discussione e poi divora otto settimane di test.

Il gruppo vende alla filiale, oppure la filiale rivende ai clienti del gruppo, ed entrambe le parti hanno bisogno di documenti coerenti, prezzi di trasferimento coerenti, trattamento fiscale coerente e tempistiche coerenti. Public Cloud porta con sé buoni contenuti standard per l’intercompany. Li porta con opinioni precise su come il processo debba svolgersi, e quelle opinioni non coincideranno con il processo su misura che il gruppo usa da vent’anni.

Da chiarire in fase di progettazione, non in fase di test: chi emette la fattura, a quale prezzo di trasferimento e chi lo mantiene, quale valuta e quale cambio, come avviene l’elisione a livello di gruppo e che cosa fa un reso intercompany. Scrivete il report di riconciliazione prima di scrivere l’interfaccia. Se non sapete descrivere come dimostrereste che le due parti coincidono a fine mese, non siete pronti a costruire.

4. Chi risponde delle interfacce alle due di notte

Il punto organizzativo, quello che si salta perché non è divertente.

Il confine tra i livelli corre esattamente lungo una linea dell’organigramma. L’IT di gruppo risponde del primo livello. L’IT locale o un partner risponde del secondo. Le interfacce stanno esattamente sulla cucitura, il che significa che alle due di notte dell’ultimo giorno lavorativo del mese, quando il lotto di fatture intercompany non è arrivato, non è un incidente di nessuno.

Nominate un unico responsabile per il livello di integrazione, con monitoraggio, allarmi e un percorso di escalation che raggiunga una persona da entrambe le parti. SAP Integration Suite vi dà gli strumenti e i contenuti a due livelli. Non vi dà un turno di reperibilità. Quello dovete scriverlo voi.

Quanto costa

Non vi darò una cifra, perché qualsiasi cifra senza il vostro scope è teatro. La forma però è costante nei progetti che abbiamo condotto.

Le licenze Public Cloud per una filiale sono contenute rispetto all’impronta di un ERP di gruppo, e l’implementazione è davvero più breve di un progetto di primo livello, perché lo scope standard è esattamente il punto. Dove l’approccio a due livelli costa più di una stima ingenua è il livello di integrazione e la progettazione del processo intercompany. Metteteli a budget come un vero flusso di lavoro con un vero responsabile, non come una voce in fondo all’elenco.

L’altro costo onesto: ora gestite due ERP. Due cicli di rilascio, due cicli di test, due regimi di governance dei dati anagrafici. Public Cloud riceve due release principali all’anno, che il gruppo sia pronto o no. È un vantaggio ed è anche un impegno. Se nessuno in azienda vuole farsi carico di quel ritmo, l’approccio a due livelli sarà infelice comunque sia costruito bene.

Quando l’approccio a due livelli è la risposta sbagliata

Tre casi in cui lo diciamo apertamente.

Il gruppo è già impegnato su S/4HANA entro circa diciotto mesi, con la filiale nello scope. Allora i due livelli sono una deviazione: costruite un confine, lo usate poco e lo smontate.

La filiale non è davvero un business separato. Se condivide clienti, prezzi, scorte e persone con la capogruppo al punto che il “confine” taglierebbe le operazioni quotidiane, non state progettando due livelli, state progettando una faglia.

Nessuno se ne occupa localmente. I due livelli richiedono una filiale capace di portare il proprio ERP, aggiornamento semestrale incluso. Se il team locale è composto da due persone che hanno già un lavoro a tempo pieno, questo va detto onestamente nel business case, non scoperto al nono mese.

Dove entra la CX, perché di solito è la stessa conversazione

La maggior parte delle filiali che si rivolgono a noi per questo non chiede solo di ERP. Chiede perché il team vendite non vede le scorte, o il team assistenza non vede l’ordine. I due livelli sono un buon momento per sistemare la questione, dato che il confine lo state definendo comunque.

Sales Cloud V2 si collega al secondo livello, non al sistema di gruppo. I venditori della filiale guardano scorte, prezzi e ordini della filiale, cioè ciò contro cui vendono davvero. L’alternativa, puntare il CRM sull’ERP di gruppo attraverso il confine, reintroduce esattamente la latenza per cui avete costruito il secondo livello.

Su questa cucitura passiamo la maggior parte del nostro tempo, ed è anche il punto in cui i progetti a due livelli riescono o deludono in silenzio. Il confine ERP e il confine CX devono essere lo stesso confine. Quando non lo sono, il team vendite lavora su una versione della verità e l’amministrazione chiude su un’altra. Spieghiamo a parte perché lo stack SAP integrato di S/4HANA Public Cloud e Sales Cloud V2 conviene e perché conta che un solo partner realizzi sia il lato ERP sia quello CRM.

Da dove partire

Non partite da una selezione di sistema. Partite dall’elenco dei processi e dalla tabella anagrafica qui sopra, in una stanza con la parte di gruppo e quella locale presenti insieme. Due giorni, fatti onestamente, vi dicono se i due livelli sono la vostra risposta e all’incirca quanto costeranno. Per inciso, fanno emergere presto le domande politiche, ed è proprio questo il punto.

Se lo volete strutturato, il nostro assessment di readiness S/4HANA dura cinque giorni a prezzo fisso e viene scomputato dalla trasformazione in caso di incarico. E se la questione di gruppo è ancora aperta, la panoramica sulla trasformazione illustra l’architettura di destinazione verso cui lavoriamo.

Una cosa che vale la pena dire chiaramente: aspettare il gruppo è anch’essa una decisione, e raramente è quella economica. Ogni anno che la filiale passa su un sistema in cui nessuno investe è un anno di soluzioni tampone che qualcuno prima o poi dovrà smontare.