Personalizzare un ERP: la domanda non è quanto, è dove

In un progetto che ho seguito, il modello commerciale dell’azienda funzionava così. Un cliente poteva essere servito da più reti di vendita, ognuna col proprio listino, e alcuni prodotti comparivano su più listini; su ogni prodotto si applicava una cascata di sconti legata alla tipologia di cliente; lo stesso cliente poteva comprare da più venditori, anche della stessa rete, e ogni tipologia di venditore portava con sé listini e sconti propri. Le promozioni, molto articolate e diverse per rete, restarono fuori dall’ERP: gli ordini arrivavano già prezzati dal sistema con cui i venditori li raccoglievano.

Le conseguenze maturarono negli anni, una alla volta. Per far entrare listini e sconti nel sistema si personalizzò il core, e da lì in avanti ogni evoluzione dello standard richiese manutenzione dedicata alle modifiche. Le promozioni rimaste fuori si gestirono a mano, sia alla raccolta degli ordini sia al controllo sull’ERP; dopo anni si automatizzò la sola raccolta, con un beneficio modesto. E poiché il prezzo finale nasceva fuori dal sistema che custodiva costi e margini, misurare l’effetto delle promozioni sui costi complessivi e sulle marginalità rimase un lavoro di riconciliazione fra due sistemi, che si faceva di rado e a fatica.

Questo è il secondo approfondimento della serie sugli errori nei progetti ERP (Enterprise Resource Planning, il gestionale che tiene insieme conti, magazzino, produzione e vendite). Il pezzo sul costo totale ha contato quanto costa personalizzare; questo parte dalla domanda che in quel progetto non venne posta: dove conviene mettere la complessità.

Che cos’è il core, e perché modificarlo esce dal patto

Il core è il codice che il produttore riverifica per tutti; ogni modifica lì dentro esce dal patto.

Il core di un ERP - la parola inglese per «nucleo», il nome che il mestiere usa - è il codice che il produttore scrive, aggiorna e riverifica per tutti i suoi clienti insieme. Finché il sistema resta com’è, ogni aggiornamento arriva già collaudato: il costo di tenere il software vivo lo sostiene il produttore, ed è ripartito su migliaia di aziende. Ogni modifica al core - il pezzo sul costo totale la chiama personalizzazione del software di base - esce da quel patto: da lì in avanti, ciò che il produttore riverifica per tutti va riverificato un’altra volta contro le tue modifiche, a ogni aggiornamento, per sempre. E gli aggiornamenti non aspettano: nel cloud arrivano a calendario del produttore, come la serie ha già visto con One Version.

Per questo la domanda «quanto personalizzare» misura la cosa sbagliata. Due aziende possono personalizzare nella stessa quantità e pagare costi lontanissimi: quella che ha modificato il core paga la riverifica a vita, quella che ha costruito accanto non la paga. La domanda che decide il costo è dove.

La scala delle risposte

Standard, configurazione, estensione, modifica del core: l’ordine con cui si risponde a un bisogno, con l’onere della prova che sale a ogni gradino.

Quando il sistema non copre un bisogno così com’è, le risposte possibili sono quattro, e formano una scala da percorrere in ordine - la scala delle risposte. Si sale di gradino solo con una prova in mano: che il gradino sotto non basta. La regola si gioca in un momento preciso e affollato: l’analisi fit-gap - il confronto, voce per voce, fra quello che il sistema fa e quello che l’azienda chiede - dove in poche settimane si classificano centinaia di requisiti, e la penna in mano ce l’ha il partner, che sui divari trovati guadagna. La scala serve lì, come griglia per classificare i requisiti, non solo come regola da ricordare a decisioni già prese.

Il primo gradino è adottare lo standard: cambiare il processo, non il sistema. È il gradino più frainteso, perché somiglia a una resa e invece è una domanda - quella complessità merita di essere difesa? Il modo in cui il sistema fa una cosa è il distillato di migliaia di aziende che la fanno; il modo in cui la fate voi, a volte, è solo il sedimento di com’è andata finora. Questo gradino, poi, si salta per una ragione che di economico ha poco: cambiare un processo interno non si decide al tavolo del progetto. Si decide ai tavoli dei reparti e della direzione, dove quel processo si è stratificato negli anni fino a diventare parte della cultura aziendale - e quei tavoli, messi davanti alla scelta, preferiscono quasi sempre scaricare sul progetto l’onere dell’adattamento piuttosto che toccare il modo in cui si è sempre lavorato. Così la personalizzazione diventa la via facile due volte: il suo costo sta nel budget del progetto, visibile e negoziabile; il costo di cambiare il processo sta fuori, su tavoli che il progetto non governa. L’asimmetria spinge a percorrere la scala al contrario. Nel racconto d’apertura il modello commerciale era il dato di partenza, mai messo in discussione; le conseguenze arrivarono sia dentro sia fuori dal sistema.

Il secondo gradino è la configurazione: i parametri che il produttore ha previsto perché ogni azienda regoli il sistema sulle proprie misure. Il suo perimetro è molto più largo di quanto ai tavoli di progetto si creda - flussi di approvazione, regole di prezzo e di sconto, campi, stampe, profili e permessi - e nei sistemi moderni copre la maggior parte dei bisogni reali, a costo di aggiornamento quasi nullo, perché i parametri sopravvivono per costruzione. Qui si nasconde la causa di personalizzazione più banale che esista: nessuno al tavolo conosce abbastanza lo standard. Nell’analisi fit-gap si classifica come mancanza ciò che in verità è una funzione che nessuno dei presenti sa configurare, e il partner - in buona fede - sviluppa quello che dello standard non conosce. Prima di salire oltre, quindi, la domanda da fare al tavolo è una: qualcuno ha verificato davvero che la configurazione non copra già il bisogno? Su questo gradino si vincono i progetti.

Il terzo gradino è l’estensione, in due forme che non toccano il codice standard. La prima vive dentro l’ambiente: il produttore dichiara dei punti di aggancio - campi, eventi, classi pensate per essere estese - che gli aggiornamenti rispettano per contratto; per l’utente è una funzione in più al posto solito, nell’interfaccia che già conosce. La seconda vive accanto: moduli e applicazioni costruiti fuori, che parlano col sistema via interfacce documentate; questa via apre agli strumenti e ai componenti più comuni, che gli ambienti di sviluppo degli ERP spesso non hanno, ma consegna all’utente una seconda interfaccia su cui lavorare. In entrambe il core resta intatto, e in entrambe il codice è vostro, con la manutenzione e la sicurezza che ogni software chiede: a ogni aggiornamento le estensioni vanno riprovate - il perimetro però resta limitato agli agganci e alle interfacce - e con gli aggiornamenti a calendario quella riprova o si automatizza o alla terza volta non si fa più. Il pezzo sui test della serie descrive il piano e la catena di prove con cui si organizza.

L’ultimo gradino, la personalizzazione del core, è ormai più un’eredità del passato che una scelta possibile: nei grandi ERP in cloud, modificare il codice standard è vietato o non è proprio previsto, come documenta la sezione seguente. Nei sistemi in cui è ancora possibile, la modifica va trattata come una decisione formale: si scrive il motivo, si mette a bilancio il costo della riverifica, e qualcuno la firma - non può essere un’abitudine di cantiere. Dove invece non è possibile, rimane una sola strada: chiedere al produttore che il bisogno entri nello standard. Sono richieste che il produttore non sempre accoglie, e mai in tempi certi, perché devono trovare posto in piani di sviluppo decisi con largo anticipo.

Il core pulito lo predicano gli stessi produttori

I tre produttori dicono la stessa cosa: Microsoft vieta la modifica del codice standard, SAP la scoraggia con la strategia del core pulito, Oracle non l’ha mai permessa.

Che il core vada lasciato intatto non è una prudenza da consulenti: è la posizione dichiarata dei produttori, che l’hanno scritta nella documentazione e in un caso nel prodotto stesso. Microsoft, nella pagina sull’estensibilità di Dynamics 365 F&O, è categorica: l’estensione «è l’unico quadro di personalizzazione» disponibile, e la vecchia pratica di sovrascrivere il codice dell’applicazione «non è supportata». La motivazione è la stessa di questo pezzo: il cloud, con aggiornamenti frequenti, «richiede un modello di personalizzazione meno intrusivo, così che gli aggiornamenti abbiano meno probabilità di toccare le soluzioni su misura».

SAP arriva allo stesso punto per via di strategia. Il core pulito - clean core - è il suo quadro dichiarato per i sistemi S/4HANA, e la diagnosi di partenza suona familiare a chi ha letto il pezzo sul costo totale: paesaggi ERP «appesantiti da codice su misura, modifiche non documentate e integrazioni difficili da mantenere», che limitano la flessibilità, rallentano gli aggiornamenti e alzano il costo totale di possesso - il TCO, nominato dal produttore stesso. Fra i cinque princìpi del quadro, due sono i gradini di questa scala: disaccoppiare le estensioni dal core standard, e tenere le integrazioni su interfacce moderne. Le estensioni complesse, dice SAP, si costruiscono e si ospitano su una piattaforma separata che ha un nome preciso - la Business Technology Platform, BTP: è la parola da cercare quando si valuta come un sistema SAP si lascia estendere - per tenere il core «pulito e sicuro da aggiornare».

Oracle è andata più in là di tutti: per Fusion la domanda non si pone proprio. La guida ufficiale alla configurazione e all’estensione contempla tre sole vie - le configurazioni degli amministratori, le estensioni costruite a tempo d’esecuzione con Visual Builder Studio, le personalizzazioni dei singoli utenti - e le accompagna con la garanzia scritta: configurazioni, estensioni e personalizzazioni «si conservano quando si passa a un aggiornamento di rilascio». La modifica del codice del core non è contemplata, per il cliente come per i partner: l’ultimo gradino della scala, in quel mondo, non esiste.

Quando i maggiori produttori mondiali di ERP scrivono la stessa regola, conviene leggerla per quello che è: il core pulito non è una rinuncia che il cliente fa per prudenza, è il patto di funzionamento dei sistemi in cloud.

Il criterio prima della scelta: come si lascia estendere

L’architettura di estensione si verifica prima di scegliere un sistema o un modulo: quali porte ha, da quale versione, a che prezzo.

Se la strada giusta per quasi tutto è il terzo gradino, allora la qualità delle porte diventa un criterio di scelta del sistema, da controllare prima di firmare come si controllano i costi e le referenze. E oggi vale più di ieri, per una ragione precisa: l’AI generativa scrive codice e applicazioni a costi che due anni fa non esistevano, ma lo fa bene solo dove le interfacce sono documentate e stabili nel tempo. Un ERP con le porte descritte per bene permette di costruire estensioni in tempi che prima chiedevano un progetto; uno con le porte opache lascia solo la scelta fra rinunciare o modificare il core.

Le porte hanno due nomi. Le API - le interfacce con cui un programma espone i propri servizi a un altro - sono la porta classica. I server MCP sono la porta nuova: il Model Context Protocol è il protocollo aperto con cui gli assistenti AI scoprono e usano gli strumenti di un sistema, e i produttori di ERP hanno cominciato a offrire server ufficiali di casa propria. Molte di queste porte parlano lo stesso dialetto, OData - Open Data Protocol, uno standard aperto per leggere e scrivere dati via web - che Microsoft usa per le entità di Dynamics e SAP ha adottato per le API applicative di S/4HANA: due concorrenti sulla stessa porta standard, un buon segno per chi ci deve costruire sopra.

I quattro ambienti della tabella non sono scelti a caso. Oracle e SAP sono il primo e il secondo produttore mondiale per ricavi ERP nella classifica di Apps Run The World, e nei due quadranti Gartner del cloud ERP per le imprese - quello per le aziende di prodotto e quello per le aziende di servizi - Oracle, SAP e Microsoft compaiono tutti e tre fra i Leader: è il terreno su cui si giocano le scelte delle aziende medie e grandi. Odoo è il contrappunto, scelto apposta: un ERP open source diventato un caso internazionale, coi numeri in coda fra le fonti. Quattro modi di attrezzare la stessa strada:

Una nota su Odoo, che nella tabella fa storia a sé: la via maestra dichiarata è l’estensione per moduli, e nella sua documentazione non c’è il divieto che i tre grandi hanno scritto - un modulo, volendo, arriva fino al comportamento del core. La scala vale anche lì, ma a impedire l’ultimo gradino non è il produttore: deve bastare la disciplina di chi sceglie.

La terza colonna merita una riflessione, perché è il riscontro più concreto del criterio: le interfacce con l’ERP cambiano nel tempo con la sua versione, e hanno date di scadenza. Il server MCP di Microsoft chiede una versione minima del sistema, e quello della generazione precedente si ritira a una data scritta; Odoo ha già fissato l’anno in cui le sue API storiche spariranno; Oracle documenta le interfacce rilascio per rilascio, ogni trimestre. Chi valuta un sistema, o un modulo da integrare, deve chiedere non solo «che porte ha?» ma «da quale versione, e fino a quando?» - e chi resta su una versione vecchia per non riverificare le proprie personalizzazioni scopre che le porte nuove non lo aspettano.

Anche l’ultima colonna è un criterio, perché la porta ha sempre un prezzo e ogni produttore lo fa pagare a modo suo: crediti contati fino al decimo per chiamata, una metrica pubblica col prezzo che si tratta, un «incluso» che non pubblica i limiti, un salto di piano coi prezzi in chiaro - per l’API esterna di Odoo serve il piano Custom, circa 22 euro per utente al mese. Quattro filosofie di prezzo per la stessa porta, e tutte finiscono nel costo totale di possesso, nella riga che i preventivi di solito non hanno.

Un’avvertenza, infine, su quanto è nuova questa strada: il server MCP che Microsoft ritira aveva tredici strumenti fissi; quello che lo sostituisce copre dati, pagine e codice dell’applicazione. Questo salto è avvenuto in un anno. La direzione è chiara e i produttori ci stanno investendo - le stesse porte le usano anche i loro assistenti AI - ma chi ci costruisce sopra deve trattare le interfacce come cosa versionata, da tenere d’occhio come si tiene d’occhio il calendario degli aggiornamenti, non come fondamenta eterne. E il costo basso ha un rovescio: le estensioni si moltiplicano. Dieci estensioni piccole sono una comodità; cento senza un censimento sono un ERP ombra. Il registro che serve è l’inventario delle interfacce descritto nell’approfondimento sulla direzione IT, esteso a tutto ciò che si aggancia al core.

Il conto degli aggiornamenti, e chi lo deve pagare

Tre voci che i preventivi non mostrano: la riverifica perpetua, moltiplicata dagli aggiornamenti obbligatori; la dipendenza da chi conosce le modifiche; i dati che smettono di rispondere. E la via d’uscita: le modifiche pesanti a chi le mantiene per molti clienti, le leggere in casa.

Il racconto d’apertura permette di guardare da vicino le tre voci di questo conto, che nel preventivo della personalizzazione non compaiono mai.

La prima è la riverifica perpetua, e non riguarda solo il core: tutto ciò che si è costruito intorno al sistema - estensioni, integrazioni - va riprovato al cambio di rilascio, ognuno col suo costo. La differenza la fa il perimetro: chi ha estensioni riprova agganci e interfacce, chi ha modificato il core riprova il core. E la frequenza non la decide più il cliente: le soluzioni in cloud hanno sempre più spesso politiche di aggiornamento obbligatorie, a calendario del produttore, e ogni obbligo in calendario moltiplica il conto, perché la domanda non è più «quando aggiorniamo?» ma «quanto ci costa ogni rilascio?».

Il pezzo sui test ha già dato un nome a questo conto - il debito di collaudo - e la personalizzazione del core è il modo più sicuro di portarlo al massimo grado. E non pesa solo sul bilancio IT: i collaudi li fanno anche i key user, e il loro tempo si sottrae ai compiti per cui i reparti li impiegano. Ogni rilascio obbligatorio è un prelievo di tempo su tutta l’azienda, in proporzione a quanto c’è da riprovare: non servono percentuali da studio di settore, basta il meccanismo - ciò che si è costruito si riprova a ogni aggiornamento, per tutta la vita del sistema, e quanto costa dipende da dove lo si è costruito.

La seconda è la dipendenza: le modifiche al core le conosce chi le ha scritte, e chi le ha scritte diventa difficile da sostituire. È il vincolo al fornitore di cui parla il pezzo sul costo totale, nella sua forma più concreta: non un contratto che lega, ma un sapere che non si trasferisce.

La terza è la più sottile, e il racconto d’apertura la mostra meglio di qualunque teoria: quando la complessità si sparge dove capita - un po’ nel core, un po’ fuori, un po’ nelle mani di chi controlla a mano - i dati smettono di rispondere. La domanda «questa promozione ha reso?» non era difficile per mancanza di strumenti: era difficile perché la risposta viveva in due sistemi che non si parlavano sul punto decisivo. Un’estensione ben fatta parla col core per interfacce dichiarate e gli riconsegna i dati; una complessità sparsa non li riconsegna a nessuno.

Tre costi diversi, un tratto comune: nessuno compare nel preventivo, e tutti compaiono negli anni.

Un rimedio pratico esiste, e costa una riga di preventivo: per ogni personalizzazione proposta, chiedere al partner due numeri invece di uno - il costo di farla, e il costo di riprovarla a ogni rilascio moltiplicato per i rilasci di un anno. Con quei due numeri il preventivo dice finalmente la verità, e molte modifiche si fermano da sole.

Se ne esce assegnando ogni personalizzazione al proprietario giusto per il suo peso. Le personalizzazioni importanti - quelle dal perimetro di riprova largo - devono passare a chi le mantiene per molti clienti: al produttore, quando la funzione esiste nei suoi piani o nelle sue versioni di settore, o a un partner che si impegna per contratto a mantenerle a ogni rilascio. Le personalizzazioni leggere possono restare in carico all’azienda, a patto di costruirle su interfacce garantite e stabili nel tempo, dove la riprova resta piccola e si automatizza. È la stessa scala, riletta chiedendosi chi possiede ogni modifica: più il perimetro della riprova è largo, meno la modifica può restare in casa.

Quando toccare il core è giusto e quando non lo è

Il processo distintivo merita l’ultimo gradino; i suoi due travestimenti no.

La scala non vieta l’ultimo gradino: lo riserva, dove il sistema lo consente ancora. Il caso che lo merita è uno: il processo davvero distintivo, quello con cui l’azienda vince sul mercato e che nessuno standard può contenere. Se il vostro modo di prezzare, produrre o consegnare è la ragione per cui i clienti vi scelgono, piegarlo allo standard sarebbe rinunciare al vantaggio; lì la riverifica perpetua è un costo che compra qualcosa. Ma dev’essere una decisione presa alla luce del sole: scritta, motivata, col costo a bilancio e una data per riguardarla.

I travestimenti da riconoscere sono due. Il primo è la procedura ombra travestita da vantaggio competitivo: «noi facciamo così» non è un processo distintivo, è un’abitudine che nessuno ha più discusso - e il pezzo sulla pianificazione ha mostrato quanto costa scoprirlo tardi. Il secondo è la ricostruzione dell’esistente: rifare nel sistema nuovo il sistema vecchio, funzione per funzione, finché il nuovo non somiglia al vecchio - pagando il prezzo di entrambi. Il pezzo sulla migrazione l’ha raccontata dal lato dei dati, coi listini che tre sistemi scrivevano in tre lingue diverse: quello era il sintomo; qui c’è la malattia.

La soluzione verticale, mantenuta dal partner

La versione di settore costruita e mantenuta da chi la vende: la riverifica passa a lui, il vincolo si somma a quello verso il produttore, e la solidità del partner decide il rischio.

Quando il core va davvero toccato in profondità, la regola di proprietà appena vista ha già un nome di mercato: la soluzione verticale, la versione di settore costruita da un partner - o dal produttore stesso, come avviene spesso nel mondo SAP - con personalizzazioni del core mantenute da chi la vende. Il senso economico è quello del patto descritto in apertura, applicato un livello più in alto: la riverifica a ogni rilascio non sparisce, cambia proprietario - la fa il partner, una volta per tutti i suoi clienti, invece che ognuno per sé. Ma il conto va letto intero: a vincolo si somma vincolo, perché non si sceglie più solo il produttore dell’ERP, si sceglie anche il partner, e il costo di uscita da quel momento porta due nomi. Quando le personalizzazioni pesanti servono davvero, però, a questo vincolo non si sfugge nemmeno facendole in casa: difficilmente l’IT interno di un’azienda può mantenere in autonomia una personalizzazione importante del core di un ERP, rilascio dopo rilascio. Chi vende la verticale diventa allora il garante di quelle modifiche: è lui che risponde della loro coerenza a ogni aggiornamento del produttore, ed è a lui che si chiede conto quando qualcosa si rompe. Fra un vincolo di fatto senza nessuno che ne risponda e un vincolo dichiarato con un garante, il secondo almeno si negozia.

E poiché chi garantisce vale quanto gli anni che resterà in piedi, la scelta del partner merita la stessa istruttoria della scelta del produttore: è solido? Ha le spalle per restare a lungo sul mercato? Che garanzie dà di mantenere la personalizzazione nel tempo e a regola d’arte? E con quanto ritardo segue i rilasci del produttore? - perché la verticale che si certifica mesi dopo ogni rilascio consegna al partner anche il calendario degli aggiornamenti. Le risposte cambiano il rischio più del contenuto della soluzione. La forma più protetta è quella in cui la verticalizzazione appartiene al produttore stesso dell’ERP, entrata nel suo catalogo e nel suo ciclo di rilasci: nel mondo SAP è una storia frequente, con soluzioni di settore nate presso i partner e diventate col tempo versioni della casa. Nel mondo Oracle Fusion, dove la modifica del core non è contemplata per nessuno, le soluzioni dei partner vivono per costruzione come estensioni: il vincolo verso il partner resta, ma il core non c’entra. L’uscita migliore di tutte resta quella già accennata al quarto gradino, e chi scrive l’ha vista funzionare nel mondo Dynamics: i partner possono chiedere al produttore un’estensione dello standard - Microsoft ha un canale dichiarato per queste richieste - e con tempi non brevi, anche un anno, la risposta arriva. È la fine più pulita che una personalizzazione possa fare: smettere di esserlo, perché il bisogno che la giustificava è entrato nello standard.

Chi decide, e dove la decisione si scrive

Decide la direzione IT, e scrive la decisione nel registro delle deroghe: motivo, costo, data di revisione. E il no scritto è un atto di governo.

Resta la domanda di governo: chi decide? La scala delle risposte è un’ottima regola e, come tutte le regole, non si applica da sola. Ogni gradino è una delle decisioni informatiche che l’approfondimento sulla direzione IT ha messo sul tavolo del governo della tecnologia: decidere dove si risponde a un bisogno è esattamente il mestiere di chi guarda l’interesse dell’azienda e non le giornate che una personalizzazione genera. Lo strumento è poco più di un quaderno: un registro delle deroghe, dove ogni personalizzazione del core entra con il motivo, la firma, il costo di riverifica stimato e una data per chiedersi se serve ancora. Nello stesso registro entra la soluzione verticale, con le stesse voci più il nome di chi la mantiene: due vincoli si governano solo se sono scritti. Il rito che tiene vivo il registro esiste già: ogni aggiornamento del produttore è la data in cui si riapre, voce per voce. E il registro lavora ben oltre il cantiere: in esercizio diventa la spina dorsale della guida di collaudo - da ogni voce nasce un passo del percorso che i key user seguono a ogni rilascio, così ogni personalizzazione registrata è anche una prova prevista, e nessuna prova si inventa al momento. E il no scritto - «questo bisogno si risolve al secondo gradino» - è l’atto di governo più economico che esista: costa un’ora quando si firma e ne risparmia mille negli anni.

Un’ultima parola per chi legge tutto questo da un sistema già personalizzato in profondità, come sono molte imprese con sistemi installati anni fa: la scala vale anche lì, ma si percorre al contrario. Si parte da un censimento delle modifiche esistenti, e per ognuna si fa la stessa domanda della scala: cade, torna standard, diventa estensione, o merita la firma nel registro? È un lavoro da fare prima della prossima migrazione, non durante - chi lo rimanda consegna al cantiere la ricostruzione dell’esistente.

Il core pulito, alla fine, è un patrimonio con un valore misurabile: un sistema che si aggiorna senza paura, estensioni che si spostano o si rifanno senza toccare il centro, e un core standard che il giorno della sostituzione - perché quel giorno arriva, e il pezzo sul costo totale lo chiama costo di uscita - si lascia molto più facilmente di uno scavato. La personalizzazione resta una spesa pregiata, da fare dove rende. La scala serve a questo - non a personalizzare di meno, ma a personalizzare nel posto giusto. Se davanti al modello dei prezzi dell’apertura qualcuno avesse fatto quella domanda - dove mettiamo questa complessità? - il conto non sarebbe arrivato da tre direzioni.

I concetti che questo articolo introduce

Nove voci nuove sull’ambito ERP: dal core pulito alla scala delle risposte, dall’analisi fit-gap al registro delle deroghe.

---

Fonti

• Microsoft, Extensibility home page (Dynamics 365 F&O), documentazione ufficiale, aperta e consultata - l’estensione come unico quadro di personalizzazione, la sovrascrittura del codice standard non supportata, e la motivazione: un modello meno intrusivo perché gli aggiornamenti frequenti non tocchino le soluzioni su misura. La stessa pagina documenta il canale delle richieste di estensibilità (extensibility requests) verso Microsoft; i tempi di risposta citati nel pezzo vengono dall’esperienza di chi scrive.
• SAP, Clean Core Extensibility for SAP Cloud ERP, documentazione ufficiale, aperta e consultata - il core pulito come quadro strategico; la diagnosi che lega codice su misura, modifiche non documentate e integrazioni fragili all’aumento del costo totale di possesso; le estensioni complesse costruite accanto, sulla Business Technology Platform (BTP), per tenere il core sicuro da aggiornare.
• Microsoft, Use Model Context Protocol for finance and operations apps, documentazione ufficiale, aperta e consultata - i tre gruppi di strumenti del server MCP (dati, pagine, azioni), la versione minima 10.0.47, il ritiro del server statico a tredici strumenti il 1° ottobre 2026, e i costi in crediti (un decimo di credito per chiamata fuori da Copilot Studio).
• SAP, How Model Context Protocol (MCP) Server Enables AI Integration e Creating an MCP Server, documentazione ufficiale della Integration Suite, aperta e consultata - il server MCP come artefatto di prima classe, costruito esponendo come strumenti le proprie API (da artefatto rilasciato, da specifica OpenAPI, da operazioni RFC), con disponibilità legata al piano di servizio.
• Oracle, Configuring and Extending Applications, guida 26C in PDF (G56221-01), documentazione ufficiale, aperta e consultata (capitolo 1) - i tre tipi di modifica di Fusion (configurazioni, estensioni in Visual Builder Studio, personalizzazioni), tutti con strumenti a tempo d’esecuzione, e la garanzia testuale: «Configurations, extensions, and personalizations are preserved when you move on to a newer release update». La modifica del codice standard non compare fra le vie possibili.
• Oracle, annuncio ufficiale sull’espansione di AI Agent Studio per Fusion Applications, marzo 2026 e How do I use AI Agent Studio?, guida 26C in PDF - lo studio incluso senza costi aggiuntivi, gli strumenti sui business object con la sicurezza nativa, e il client MCP verso server esterni; i limiti d’uso delle REST API non risultano pubblicati.
• Odoo, External JSON-2 API, External RPC API e pagina dei prezzi, documentazione ufficiale, aperta e consultata - l’API esterna disponibile solo dai piani Custom, il ritiro delle API XML-RPC e JSON-RPC programmato per Odoo 22 (autunno 2028), i prezzi pubblici per utente.
• Microsoft, One Version service updates overview, documentazione ufficiale, aperta e consultata, già fonte della serie - gli aggiornamenti di servizio a calendario del produttore, con rinvio possibile per al massimo un aggiornamento consecutivo.
• Apps Run The World, Top 10 ERP Software Vendors, Market Size and Forecast, agosto 2026, società di ricerca specializzata, consultata dal browser - il mercato ERP 2025 a 151 miliardi di dollari; Oracle e SAP primo e secondo per ricavi (6,5% e 6,4%), Microsoft quinto; i primi dieci produttori insieme coprono meno di un terzo del mercato totale.
• Gli annunci ufficiali dei tre produttori sul riconoscimento di Leader nei quadranti Gartner del cloud ERP per le imprese, aperti e consultati: Oracle (novembre 2025, «posizioni tenute dalla nascita di ciascun rapporto»), SAP (novembre 2024, terzo anno consecutivo) e Microsoft (dicembre 2024). Sono pagine dei produttori su un rapporto Gartner ad accesso chiuso, e vanno lette per quello che sono: la conferma incrociata che tutti e tre siedono fra i Leader di entrambi i quadranti.
• SAP Learning, Identifying OData APIs for Billing Documents, lezione ufficiale aperta, consultata - la definizione di OData (Open Data Protocol, protocollo web per interrogare e aggiornare dati via HTTP) e la sua adozione: «OData rende più facile, per SAP, per i partner e per i clienti, costruire applicazioni basate su standard». Il catalogo completo delle API sul Business Accelerator Hub richiede l’accesso, e la proporzione esatta di servizi OData non è stata verificata qui.
• Odoo, annuncio della transazione da 500 milioni di euro, novembre 2024, pagina ufficiale, aperta e consultata - la valutazione a 5 miliardi di euro con CapitalG e Sequoia alla guida; gli oltre 13 milioni di utenti e i settemila nuovi clienti al mese sono numeri dichiarati dall’azienda. La licenza open source (LGPLv3) è nel repository pubblico, verificato sui file di licenza.
• L’aneddoto del modello dei prezzi - le reti di vendita, la cascata di sconti, le promozioni tenute fuori e gestite a mano per anni - viene dall’esperienza diretta di progetto di chi scrive, coi dettagli volutamente sfumati, e come tale va letto. Dalla stessa esperienza vengono le osservazioni sulle soluzioni verticali: le verticalizzazioni di settore assorbite nel catalogo del produttore nel mondo SAP, e i tempi delle richieste di estensione dello standard nel mondo Dynamics.