Chiedete a chiunque abbia provato ad acquistare una casa con un fratello o una sorella, a dividere il conto con un gruppo di amici o a capire chi sia effettivamente al comando in un’azienda di famiglia, e vi dirà la stessa cosa: i rapporti interpersonali sono complicati. La stessa persona può essere sia il vostro socio in affari che vostro cognato. Il tuo padrone di casa potrebbe anche essere un tuo cliente. Il tuo principale concorrente in un determinato mercato potrebbe essere il tuo distributore più importante in un altro.
Le aziende hanno esattamente lo stesso problema, ma su scala molto più ampia. Nel settore del software aziendale, abbiamo un nome per definirlo: relazioni con partner commerciali che ricoprono più ruoli. Ed è uno dei problemi più difficili e più costantemente sottovalutati nella gestione dei dati di riferimento.
La stessa azienda che ricopre ruoli diversi
Ecco uno scenario che si ripete ogni giorno all’interno delle grandi imprese: un distributore acquista prodotti finiti da voi e vi fornisce anche materie prime. Un singolo ordine potrebbe essere effettuato dalla sede centrale, spedito a un magazzino regionale, fatturato a un centro servizi condiviso e pagato da un’entità completamente diversa all’interno del gruppo. Tutte e quattro queste parti sono legittime, corrette e potrebbero dover essere gestite in modo diverso: condizioni di credito per una, finestre di consegna per un’altra, termini di pagamento per una terza.
La maggior parte dei sistemi non è stata progettata per questo. Uno strumento di gestione delle relazioni con i clienti (CRM) parte dal presupposto che un’azienda sia un cliente. L’anagrafica fornitori di un sistema di pianificazione delle risorse aziendali (ERP) presuppone che un’azienda sia un fornitore. Quando la stessa entità giuridica deve ricoprire entrambi i ruoli, la maggior parte delle piattaforme reagisce creando due record scollegati — uno per ciascun ruolo — sperando che nessuno debba mai riconciliarli.
Ma alla fine qualcuno dovrà farlo, perché nessuna, per quanto accurata, immissione di dati può risolvere un problema di architettura.
Perché le organizzazioni sono molto più complesse degli individui
Una persona di solito può ricoprire solo un numero limitato di ruoli contemporaneamente. Un’organizzazione non ha questo limite, ed è proprio qui che il problema smette di essere un caso eccezionale e diventa la norma.
Una singola entità giuridica potrebbe vendere attraverso cinque aree di vendita, ciascuna con prezzi e condizioni propri. Potrebbe essere tassata in modo diverso in ogni giurisdizione in cui opera ed essere soggetta a un regime normativo diverso in ciascuna di esse. Potrebbe apparire nei vostri sistemi come destinatario della vendita in una transazione, come destinatario della spedizione in un’altra, come destinatario della fattura in una terza e come pagatore in una quarta: a volte tutti e quattro nello stesso ordine, a volte suddivisi tra quattro entità diverse appartenenti allo stesso gruppo aziendale. Aggiungete diversi marchi, alcune acquisizioni e un paio di sistemi ERP regionali, e ciò che era iniziato come «un unico cliente» diventa ora una rete di ruoli e relazioni che nessuno all’interno dell’azienda è in grado di comprendere appieno, figuriamoci di gestire manualmente.
È proprio qui che la situazione diventa rapidamente ingestibile — non perché qualcuno abbia sbagliato qualcosa, ma perché la complessità è reale e la maggior parte delle piattaforme non è mai stata progettata per rappresentarla come tale. Sono state progettate per considerarla come “rumore”, da ripulire in un secondo momento. Ma in realtà non viene mai ripulita del tutto.
Due diversi tipi di “ruolo” — e perché la differenza è importante
Per districarsi in questa situazione, occorre innanzitutto riconoscere che il termine «ruolo» in realtà indica due cose diverse, e che è proprio la loro confusione a causare il silenzioso collasso della maggior parte dei modelli di dati.
Il ruolo di partner commerciale risponde a questa domanda: che cos’è questa entità? Un’azienda può ricoprire più di uno di questi ruoli contemporaneamente: può essere un cliente e un fornitore allo stesso tempo, nello stesso record, nello stesso sistema. Questo è il classico problema del partner commerciale con ruoli multipli, ed è una questione di classificazione: a quali funzioni aziendali e transazioni è autorizzata a partecipare questa entità?
Il ruolo di interazione risponde a una domanda completamente diversa: in quale veste agisce questa entità nei confronti di un’altra entità specifica, per questa transazione? È qui che rientrano i ruoli “destinatario della spedizione”, “destinatario della fattura”, “acquirente” e “pagatore”. Una singola azienda può ricoprire diversi ruoli di interazione nell’ambito di un unico ordine, e l’entità che ricopre un ruolo spesso non è la stessa che ne ricopre un altro. È fondamentale che queste relazioni vengano convalidate, non solo registrate. Se un ruolo di «destinatario della spedizione» richiede un ruolo di «pagatore» dall’altra parte della relazione, ciò deve essere garantito nel momento stesso in cui la relazione viene creata, non scoperto durante un rapporto di riconciliazione tre settimane dopo.
La maggior parte dei fornitori confonde questi due concetti in un'unica visione appiattita del “ruolo” e spera che la differenza non abbia importanza. Invece è sempre importante. Uno riguarda ciò che un soggetto è; l’altro riguarda ciò che sta facendo, per chi, in questo preciso momento.
Chi può vedere cosa
La complessità non si limita alla conoscenza dei ruoli ricoperti da una parte. Quando un'azienda opera tramite rivenditori, franchising o una rete di affiliati regionali, una seconda domanda emerge subito dopo la prima: chi è autorizzato a visualizzare queste informazioni e chi è autorizzato a modificarle?
Una grande rete di distribuzione potrebbe contare decine di affiliate, ciascuna delle quali gestisce la propria serie di partner commerciali, alcuni dei quali sono condivisi tra due o più affiliate che gestiscono lo stesso cliente in paesi diversi. Ciò solleva due requisiti distinti.
In primo luogo, la sicurezza. Un’affiliata dovrebbe generalmente visualizzare solo i partner commerciali che è autorizzata a vedere, e utenti diversi potrebbero necessitare di livelli di accesso diversi a diversi ambiti dello stesso record. Chi gestisce i dati di vendita relativi a un cliente potrebbe non avere alcuna ragione per modificare i relativi dati finanziari, e alcuni utenti dovrebbero poter solo esaminare e approvare, senza poter creare o modificare alcunché.
In secondo luogo, l’ambito di applicazione. Un’affiliata deve poter visualizzare sia i dati anagrafici effettivamente condivisi a livello aziendale – dove la ragione sociale e la partita IVA di un’azienda non variano a seconda di chi li consulta – sia i dati specificamente locali, in cui un campo condiviso può legittimamente contenere valori diversi da un’affiliata all’altra.
Nessuno di questi aspetti è un semplice “extra” per un’azienda di questo tipo. Se si commette un errore in uno dei due, si finisce per esporre dati che una filiale non dovrebbe vedere oppure si costringe ogni filiale a utilizzare un campo “universale” che non si adatta bene a nessuno.
La risposta sincera è che STEP, la nostra piattaforma di intelligence di fiducia, possiede la flessibilità e i meccanismi di governance necessari per risolvere adeguatamente la questione: sicurezza a livello di nodo, ruoli definiti a livello di dominio, accesso solo previa approvazione e gestione contestuale degli attributi sono tutte funzionalità native, non soluzioni di ripiego. Come configurarle esattamente – quale struttura di affiliazione, quali domini di dati, quali catene di approvazione – è un argomento che vale la pena discutere direttamente, perché tale configurazione dovrebbe rispecchiare il modo in cui la vostra azienda opera realmente, piuttosto che basarsi su un modello generico.
Se state effettuando la migrazione a SAP S/4HANA, non potete eludere questo aspetto
Per qualsiasi organizzazione che passi a SAP S/4HANA, questa non è più una questione teorica di modellazione dei dati, ma diventa una decisione progettuale obbligatoria. S/4HANA unifica la gestione dei clienti e dei fornitori in un unico concetto di partner commerciale (BP): un’entità, uno o più ruoli di partner commerciale, gestiti a livello centrale. Se i vostri dati anagrafici esistenti erano strutturati attorno a record separati e scollegati tra clienti e fornitori, tale riconciliazione deve avvenire prima o durante la migrazione. Non è un aspetto che si può semplicemente ignorare.
Questo è esattamente il terreno su cui STEP è stato progettato per operare. STEP supporta nativamente il modello di dati del partner commerciale SAP, inclusi i ruoli BP, le funzioni dei partner e le categorie di relazione BP, in modo che le organizzazioni che migrano verso S/4HANA non siano costrette a scegliere tra l’adeguamento al modello SAP e il mantenimento della governance dei dati anagrafici su cui già fanno affidamento. Se l’approccio giusto per la vostra organizzazione sia un unico oggetto partner commerciale unificato oppure tipi di oggetti separati per clienti, fornitori e referenti è di per sé una decisione di governance, non una limitazione, ed è un aspetto che STEP è progettato per supportare in entrambi i casi. Se desiderate i dettagli tecnici su come ciò si traduca in pratica, la nostra documentazione ne parla in modo esaustivo.
Perché questo aspetto è più importante ora rispetto al passato
Per anni si è trattato di un problema di qualità dei dati: fastidioso, ma gestibile con un adeguato intervento di pulizia manuale. La situazione sta cambiando rapidamente.
Gli agenti di IA non effettuano pulizie manuali. Un agente a cui viene chiesto di ottimizzare una catena di approvvigionamento, risolvere una controversia di fatturazione o segnalare un rischio di conformità deve analizzare le relazioni per ragionarvi sopra, il che rappresenta un’evoluzione significativa rispetto alla semplice pulizia dei record. Deve sapere quale entità sia realmente responsabile di questa fattura, quale magazzino sia effettivamente il destinatario di questo ordine e quale filiale sia realmente la controparte in questo contratto. Se tali relazioni non sono modellate in modo significativo, un agente di IA si trova a lavorare con una mappa in cui sono segnate tutte le città ma non è tracciata nessuna strada.
Questo è il ragionamento alla base del grafico di dati semantico di STEP e del nostro MCP Server: dati master che memorizzano le relazioni regolate e tipizzate tra ciò che esiste, a disposizione degli agenti di IA come substrato di ragionamento — non solo come tabella di riferimento.
Il punto chiave
Le relazioni sono sempre state complesse. Ciò che è cambiato è quanto ora dipenda dalla loro corretta interpretazione e quanto rapidamente si manifestino le conseguenze di un errore, che si tratti di una spedizione inviata all’entità sbagliata o di un agente di IA che agisce con sicurezza sulla base di una relazione che in realtà non è mai stata valida.
I dati di riferimento che descrivono solo ciò che un’azienda è erano destinati a rimanere incompleti. Le aziende che stanno risolvendo questo problema oggi sono quelle che investono in dati di riferimento in grado di descrivere anche ciò che un’azienda fa: in ogni ruolo di partner commerciale che ricopre, in ogni ruolo di interazione che svolge e in ogni relazione che li collega.
