Una migrazione a S/4HANA pone i dati anagrafici al centro dell'attenzione in un modo che raramente si verifica al di fuori di un programma di trasformazione.
Di solito, però, l’ambito dei dati anagrafici viene definito innanzitutto in base a ciò che il programma S/4HANA deve migrare e gestire. I dati relativi a materiali/prodotti, partner commerciali e finanza possono essere gestiti in modo sufficientemente adeguato per il passaggio all’ERP, mentre i contenuti correlati, le relazioni e le classificazioni presenti nella gestione delle informazioni di prodotto (PIM), nella gestione del ciclo di vita del prodotto (PLM), nella gestione delle relazioni con i clienti (CRM), nei sistemi dei fornitori e nelle applicazioni regionali rimangono al di fuori dell’ambito immediato del programma.
I problemi emergono in seguito, quando un’iniziativa di IA necessita che i dati relativi a fornitori, prodotti e finanza siano coerenti tra loro e non dispone di quella base su cui fare affidamento.
A quel punto, potreste non disporre più del budget del programma e dell’attenzione da parte dei dirigenti che hanno reso possibile il lavoro.
La gestione dei dati di riferimento (MDM) è il lavoro che sta alla base di tale fondamento.
È ciò che definisce chi è il proprietario di un record, quali regole segue e a quali sistemi è collegato. La maggior parte dei programmi S/4HANA ne sviluppa una quantità sufficiente a supportare l’ERP. Ma per l’IA, occorre qualcosa di molto più ampio.
Qual è la differenza tra l’MDM per l’ERP e l’MDM per l’IA?
L’MDM incentrato sull’ERP ottimizza i dati master gestiti per i modelli operativi e i processi richiesti dall’ERP.
L’MDM pronto per l’IA estende tale base a diversi ambiti, sistemi e relazioni, in modo che l’IA possa ragionare su un contesto aziendale coerente anziché su record isolati.
Ad alcuni questa differenza può sembrare minima, ma cambia ciò che i dati sono in grado di supportare.
Un agente di IA che opera sui dati relativi a fornitori, prodotti e finanze non legge un record alla volta. Ragiona sulle relazioni. Quale fornitore è collegato a quale materiale, e quale materiale entra nella configurazione di quale prodotto, che a sua volta ha un prezzo diverso a seconda del mercato.
Questo contesto più ampio non emerge automaticamente da un programma S/4HANA. SAP Master Data Governance (MDG) è in grado di governare e consolidare i dati SAP e di terze parti, ma molte aziende gestiscono ancora i dati correlati in applicazioni separate. A meno che tali domini non vengano deliberatamente armonizzati, la stessa entità può comunque assumere definizioni e relazioni diverse all’interno dell’intero panorama aziendale.
Tra gli esempi figurano:
- Dati PIM
- Portali fornitori
- Banche dati regionali
- Piattaforme di e-commerce
- Dati anagrafici dei clienti
Senza un modello di governance a livello aziendale, gli identificatori, le definizioni e le relazioni possono comunque variare da un sistema all’altro.
Perché la migrazione a S/4HANA rappresenta il momento migliore per correggere i dati anagrafici in vista dell’IA?
I programmi di trasformazione aziendale rappresentano uno dei pochi momenti in cui le organizzazioni dispongono sia del mandato esecutivo che dello slancio operativo necessari per affrontare la questione dei dati anagrafici su larga scala.
Al di fuori di questi programmi, la necessità viene riconosciuta, ma spesso non riceve i finanziamenti necessari. Priorità concorrenti la rimandano ogni volta.
Un programma S/4HANA costringe ad affrontare le domande che di solito rimangono senza risposta:
- Chi è il proprietario di questi dati?
- Chi fa rispettare le regole?
- Come si conciliano le varianti regionali?
Con un budget dedicato alla migrazione e alla trasformazione e un team di progetto dedicato, avete un'opportunità rara per risolverli. Dopo la messa in produzione, quel sostegno e quei finanziamenti mirati spesso diminuiscono.
Ciò non significa che una piattaforma MDM sostituisca gli strumenti di migrazione di SAP. SAP esegue e convalida la transizione; il ruolo di STEP, la piattaforma di intelligence affidabile di Stibo Systems, è quello di preparare, armonizzare e governare i dati master da cui dipendono tali processi, per poi mantenere tale governance nell’intero ambiente aziendale dopo la messa in produzione.
Lo stesso problema riemerge in seguito, spesso quando un’iniziativa di IA necessita di dati coerenti e non trova alcuna base su cui attingere, né alcun programma rimasto per finanziare la correzione.
Cosa rende una base di dati pronta per l’IA e non solo per S/4HANA?
1. Allinea i dati tra i diversi ambiti
Un prodotto ha lo stesso significato indipendentemente dal fatto che venga esaminato dai team di approvvigionamento, commerciali o finanziari. Le classificazioni dei fornitori sono allineate alle specifiche dei materiali. Le gerarchie di mercato rimangono coerenti da una regione all’altra.
2. Integra la governance anziché documentarla
Le regole risiedono nell’infrastruttura stessa e vengono applicate automaticamente a ogni record, anziché essere contenute in un documento normativo che nessuno consulta durante un trimestre particolarmente intenso.
3. Rende tracciabili gli input dell’IA
Quando i dati governati riportano la genealogia, la provenienza, le relazioni e il contesto delle regole, le informazioni fornite a un sistema di IA possono essere ricondotte alle loro fonti. Ciò non rende ogni decisione del modello intrinsecamente spiegabile, ma rende il contesto dei dati verificabile e più facile da analizzare.
4. Fornisce dati con il livello di attualità richiesto dal caso d’uso
Molti casi d’uso operativi e autonomi dell’IA – quali la determinazione dei prezzi, il ribilanciamento delle scorte o il monitoraggio del rischio fornitori – necessitano di dati aggiornati o quasi in tempo reale. Una struttura progettata esclusivamente per la riconciliazione periodica potrebbe non supportarli.
La differenza fondamentale non sta quindi semplicemente nella contrapposizione tra SAP e non-SAP, o tra elaborazione batch e tempo reale. Riguarda piuttosto il fatto che la governance, la semantica e la distribuzione siano progettate in modo coerente tra i sistemi e i requisiti di attualità da cui il caso d’uso dell’IA dipende effettivamente.
Un MDM nell’ambito SAP può garantire i primi due aspetti all’interno dell’ERP. Gli ultimi due, in particolare l’operatività in tempo reale su sistemi non di proprietà di SAP, richiedono una piattaforma progettata fin dall’inizio tenendo conto dell’IA.
Quali sono i quattro risultati derivanti dalla correzione dei dati master durante una migrazione a S/4HANA?
Se questo aspetto viene gestito correttamente durante il programma, ne derivano quattro vantaggi.
1. Le fasi di test e di passaggio al nuovo sistema non vengono più ostacolate da incongruenze nei dati che avrebbero dovuto essere individuate in precedenza.
Quando materiali, prodotti, fornitori e gerarchie chiave hanno definizioni chiare e responsabili ben identificati, il team che gestisce il programma non si trova a dover risolvere problemi relativi ai dati nel bel mezzo di un ciclo di test.
2. L’armonizzazione dei dati tra i vari paesi e le unità aziendali diventa più rapida. Le varianti locali relative ad attributi, classificazioni e unità di misura vengono allineate a un modello condiviso, mentre le differenze di mercato significative rimangono intatte. Ciò si traduce in una riduzione delle rielaborazioni durante il programma e in un minor lavoro di pulizia una volta che questo è attivo.
3. Un modello canonico governato per materiali/prodotti, fornitori e altre entità master riduce le mappature personalizzate dei dati master e fornisce alle integrazioni a valle una fonte semantica coerente.
4. Le basi sono pronte per ciò che seguirà la messa in produzione:
- S/4HANA standardizza il modo in cui i processi vengono eseguiti
- I dati anagrafici standardizzano il significato dei dati
Un caso di studio pubblicato da Stibo Systems relativo a un cliente del settore manifatturiero mostra come ciò possa concretizzarsi su scala aziendale. Nell’ambito del proprio percorso di migrazione a S/4HANA, l’organizzazione ha ridotto oltre 200 modelli di dati legacy a cinque modelli semantici distribuiti su oltre 500 applicazioni e oltre 1.000 interfacce, a supporto di oltre 600 progetti globali.
Qual è il ruolo dell’MDM aziendale rispetto a SAP MDG e SAP Business Data Cloud?
SAP MDG è un'opzione valida per la governance centralizzata, il consolidamento e l’elaborazione di massa nei domini dei dati anagrafici SAP ed è in grado di integrarsi con fonti di dati SAP e di terze parti. L’acquisizione di Reltio da parte di SAP amplia inoltre la posizione di SAP nell’MDM multidominio all’interno di Business Data Cloud.
Ciò cambia la prospettiva architettonica. La questione non è più se SAP sia in grado di governare i dati al di fuori di S/4HANA, bensì dove l’organizzazione desideri che la proprietà, la semantica e la governance dei dati anagrafici aziendali siano collocate all’interno degli ambienti applicativi SAP, non SAP e futuri.
STEP fornisce un livello di governance multidominio indipendente in grado di integrare SAP MDG, coesistere con SAP Business Data Cloud o fungere da piano di controllo dei dati anagrafici aziendali nell’intero panorama. Con STEP, le aziende possono:
- Gestire i dati relativi a prodotti, fornitori, clienti e sedi all’interno di un modello multidominio condiviso, con relazioni e gerarchie rese esplicite
- Collegarsi a SAP R/3, ECC e S/4HANA e a una libreria di oltre 100 connettori e integrazioni predefiniti
- Applicare regole di governance, flussi di lavoro, validazioni e autorizzazioni, indipendentemente dal fatto che le modifiche siano avviate da persone o dall’automazione
- Conservare la cronologia verificabile e la provenienza delle modifiche gestite per supportare la tracciabilità
- Fornire agli agenti di intelligenza artificiale un accesso basato su standard ai dati anagrafici gestiti e al contesto semantico tramite «Data as a Service» e il server MCP di Stibo Systems, riducendo la necessità di integrazioni personalizzate degli agenti
In sintesi
Una migrazione a S/4HANA offre un’opportunità unica per creare dati anagrafici che vadano oltre l’ambito dell’ERP.
Se si definisce correttamente l’ambito durante il programma, i benefici si manifestano su entrambi i fronti. I test procedono in modo più agevole, l’armonizzazione richiede meno ritocchi e l’integrazione diventa più semplice.
Gli agenti di intelligenza artificiale che elaborano dati relativi a fornitori, prodotti e finanze dipendono dal fatto che tale base sia già presente. Se si perde questa occasione, ci si ritroverà a dover svolgere lo stesso lavoro in un secondo momento, senza il budget del programma né l’attenzione dei dirigenti che lo hanno reso possibile la prima volta.
Per approfondire i motivi per cui questa finestra si apre proprio in quel momento e quali sono i requisiti di una base di dati pronta per l’IA, scarica il nostro white paper“AI at Scale”, redatto in collaborazione con Accenture.
FAQ
Come standardizzi i dati sui materiali e sui fornitori prima di una migrazione a SAP S/4HANA?
Inizia assegnando la responsabilità per ciascun dominio a un team specifico, poi codifica le regole che decidono cosa conta come dati validi, completi o duplicati invece di lasciarle in un documento.
Da lì, riconciliare le diverse versioni presenti in ERP, PIM e portali dei fornitori in un'unica registrazione governata per entità, e collegare quella registrazione a ogni sistema che la utilizza.
Fare questo prima del passaggio significa che il team di migrazione testa su dati puliti invece di trovare le incoerenze durante il go-live.
Quale piattaforma MDM funziona meglio con SAP S/4HANA?
Non c'è una risposta universale. La scelta dipende dall'architettura target, dal modello operativo di governance, dai domini, dai requisiti di coesistenza e da quanto lontano devono estendersi i dati master affidabili oltre SAP.
SAP MDG è una scelta forte quando le organizzazioni desiderano una governance centrale e una consolidazione incentrate su SAP. STEP è una scelta ideale quando la governance multidominio deve rimanere indipendente dall'ERP e servire SAP insieme a un patrimonio eterogeneo più ampio. In alcune architetture, i due coesistono.
SAP MDG o MDM multidominio dedicato, quale è la scelta migliore a lungo termine?
Si tratta di responsabilità architettonica piuttosto che di una scelta generale di uno strumento come "migliore". SAP MDG e Reltio all'interno di SAP Business Data Cloud offrono ai clienti SAP opzioni di master data più ampie.
Una piattaforma multidominio indipendente e dedicata come STEP è maggiormente differenziata quando l'organizzazione desidera un unico strato di governance e un modello semantico che abbracci più ERP, PLM/PIM, CRM, sistemi dei fornitori, canali e futuri consumatori di IA senza rendere la proprietà dei dati master aziendali dipendente da un'unica suite di applicazioni.
Questo lavoro deve essere completato prima del go-live, o può essere fatto dopo?
Può succedere dopo, ma il costo cambia. Durante il programma, il lavoro sui dati master dipende dal budget e dall'attenzione esecutiva già previsti per la migrazione.
Dopo il go-live, quel budget e quell'attenzione si spostano su altre priorità, quindi lo stesso lavoro di solito necessita di un proprio business case, sponsor e ciclo di finanziamento per essere approvato.
I tipi di oggetti SAP coprono gli stessi ambiti dei domini aziendali come prodotto o fornitore?
Non necessariamente. Gli oggetti di dati master ERP sono progettati principalmente attorno ai requisiti transazionali e di processo dell'ERP. Un dominio aziendale può includere relazioni, classificazioni, contenuti e contesti di governance più ricchi, mantenuti attraverso sistemi adiacenti.
Un prodotto, ad esempio, può combinare gli attributi di materiale/prodotto di SAP con i contenuti PIM, le specifiche PLM, le classificazioni regionali e le relazioni con i fornitori. L'architettura deve governare il significato completo del business, senza assumere che ogni attributo rilevante appartenga a un'unica applicazione.
La correzione dei dati master durante la migrazione rallenterà il programma S/4HANA?
Aggiunge lavoro, ma non necessariamente tempo. La razionalizzazione dei dati può procedere in parallelo con la progettazione e il collaudo dei processi, piuttosto che come una fase separata aggiunta al programma.
Saltare il lavoro può spingere i problemi di qualità dei dati nei test o dopo il go-live, dove sono generalmente più difficili e più dirompenti da risolvere.
