Per un’azienda manifatturiera che opera in più Paesi, la scelta dell’architettura ERP parte dalle attività che gli stabilimenti devono svolgere insieme. Il reporting finanziario di gruppo, gli acquisti e i trasferimenti tra stabilimenti richiedono forme diverse di coordinamento. Non richiedono necessariamente flussi di lavoro locali identici.
Il confronto utile, quindi, non è semplicemente tra ERP globale ed ERP locali. Occorre capire quanta responsabilità operativa affidare a un sistema comune, quanta lasciarne agli stabilimenti e dove applicare regole condivise.
In un webinar di SoftEngine sulla strategia ERP, i relatori sostengono che la coerenza con la strategia aziendale conti più del Paese d’origine del fornitore. Discutono delle capacità di rollout internazionale, della conoscenza dei mercati regionali e di soluzioni che collegano ERP operativi locali a un sistema internazionale. È un punto di partenza utile: scegliere la ripartizione delle responsabilità prima di considerare la nazionalità del fornitore un indicatore della sua adeguatezza.
Distinguere prodotto, istanza e processo
La scelta di un’architettura ERP multinazionale deve rispondere a domande distinte:
- Scelta del prodotto: gli stabilimenti devono usare lo stesso software ERP o prodotti diversi?
- Disegno delle istanze: devono condividere un ambiente applicativo oppure operare su ambienti separati?
- Standardizzazione dei processi: quali regole aziendali, definizioni e flussi di lavoro devono essere comuni, indipendentemente dal sistema in cui vengono eseguiti?
È importante mantenere separate queste domande quando si discute dell’architettura. «Lo stesso ERP» non dovrebbe sostituire una risposta a tutte. Un prodotto condiviso con configurazioni locali gestite in modo indipendente è cosa diversa da un prodotto condiviso governato attraverso un modello comune. Una ricerca pubblicata in Communications of the ACM distingue esplicitamente una configurazione standardizzata tra unità aziendali da più configurazioni diverse, con impatti organizzativi potenzialmente differenti.
Un template ERP globale dovrebbe esprimere le regole che l’organizzazione intende riutilizzare: definizioni condivise dei dati, strutture contabili, responsabilità sulle transazioni e processi che collegano gli stabilimenti. Va deciso separatamente se distribuire quel template in un ambiente condiviso o replicarlo in ambienti distinti. Altrimenti, una decisione di distribuzione può trasformarsi silenziosamente in una politica organizzativa che nessuno ha approvato esplicitamente.
Occorre anche separare l’architettura dalla decisione d’investimento. Mantenere un ERP locale non dimostra che sia adeguato allo scopo, così come scegliere processi comuni non dimostra che tutti i sistemi debbano essere sostituiti. Questo punto va risolto attraverso una valutazione sull’opportunità di migliorare o sostituire l’ERP, anziché usare l’etichetta dell’architettura come business case.
Cosa richiede all’azienda un approccio ERP globale comune
Un approccio comune è più coerente quando gli stabilimenti devono coordinarsi strettamente e possono accettare definizioni e responsabilità decisionali condivise. La sua attrattiva è la possibilità di definire una regola centralmente e riutilizzarla, invece di tradurre ripetutamente interpretazioni locali. L’obbligo corrispondente è rendere quella regola adatta agli stabilimenti che dovranno seguirla.
Si parte dai dati anagrafici. Occorre decidere quali identificativi di prodotto, unità di misura, identità di clienti e fornitori e classificazioni finanziarie appartengano al gruppo. Poi vanno distinti dagli attributi locali. Un’identità comune del materiale non deve necessariamente comportare parametri di pianificazione identici in ogni stabilimento. Allo stesso modo, consentire parametri di pianificazione locali non dovrebbe diventare un’autorizzazione a creare identità incompatibili per lo stesso materiale.
Le transazioni intercompany richiedono una precisione analoga. Per i trasferimenti tra entità giuridiche, bisogna concordare la relazione tra le registrazioni del mittente e del destinatario, gli eventi che attestano spedizione e ricevimento e chi risolve le divergenze. Un ambiente applicativo comune non dovrebbe essere accettato come sostituto di queste decisioni. Occorre chiedere in che modo il disegno scelto renda visibile e controllabile la transazione concordata.
L’impegno organizzativo emerge con maggiore chiarezza quando vengono richieste modifiche. Chi può cambiare un campo condiviso? Quali stabilimenti devono approvare la modifica di un processo? Chi decide se un requisito locale debba entrare nel template? Il controllo centrale è utile solo se prevede un percorso praticabile per risolvere differenze reali.
La stessa logica va applicata agli aggiornamenti. Per un ambiente condiviso, bisogna stabilire come gli stabilimenti partecipano all’approvazione dei rilasci e come i loro calendari operativi incidono sulla programmazione. Per ambienti separati che usano un template comune, occorre decidere quali modifiche debbano procedere insieme e come monitorare gli scostamenti. La scelta dell’architettura dovrebbe includere questo coordinamento continuativo, non soltanto il rollout iniziale.
Un nucleo centrale con ERP locali sposta il confine della condivisione
In un’architettura ERP a due livelli per la produzione, i sistemi centrali e quelli degli stabilimenti hanno responsabilità diverse. Infor descrive questa ripartizione assegnando agli stabilimenti i sistemi operativi necessari alla loro attività e alla sede centrale la gestione finanziaria e gli altri sistemi trasversali all’organizzazione. Questa divisione è un punto di partenza per definire il perimetro, non un disegno d’integrazione completo.
Il perimetro condiviso può essere relativamente ristretto. La ricerca ACM descrive un’autonomia operativa locale combinata con un consolidamento finanziario comune, includendo un esempio di prodotti ERP operativi diversi collegati a un sistema finanziario comune. Descrive anche un modello più ampio, in cui la sede centrale coordina la supply chain attraverso l’accesso ai fabbisogni d’acquisto, alle scorte e ai programmi di produzione locali. Sono architetture sostanzialmente diverse: il solo reporting finanziario non risponde alle esigenze informative del coordinamento produttivo tra stabilimenti.
Il nucleo centrale va definito di conseguenza. Se il suo scopo è il consolidamento, occorre specificare come i conti locali vengono ricondotti al reporting di gruppo, come vengono riconciliati i dati trasmessi e come vengono approvate le rettifiche. Se coordina anche gli approvvigionamenti, bisogna specificare di quali informazioni su scorte e pianificazione abbia bisogno, quale sia il loro significato e in quale momento diventino utilizzabili per le decisioni.
L’integrazione non elimina la necessità di standardizzare. Cambia il punto in cui deve essere fatto rispettare l’accordo. Per i dati anagrafici, occorre individuare chi ha autorità su ciascun campo condiviso e definire come vi si collegano le estensioni locali. Per le transazioni intercompany, bisogna concordare gli identificativi che collegano le registrazioni tra sistemi e la responsabilità di risolvere le discrepanze. Per il consolidamento, va mantenuta una relazione tracciabile tra i valori trasmessi al gruppo e le registrazioni locali.
Queste attività richiedono responsabili continuativi:
- I responsabili dei dati approvano le definizioni e le mappature condivise.
- I responsabili dei processi risolvono le divergenze tra le regole transazionali centrali e locali.
- I responsabili delle applicazioni e delle integrazioni gestiscono le modifiche alle interfacce, gli scambi rifiutati e le responsabilità di ripristino.
- I responsabili finanziari approvano le riconciliazioni e le rettifiche di reporting.
Anche l’autonomia locale sui rilasci dovrebbe avere un confine chiaro. Quando una modifica interessa un campo, una transazione o un output di reporting condiviso, va richiesta una valutazione d’impatto. Si può consentire una programmazione locale dove le dipendenze lo permettono, ma le verifiche di compatibilità devono rientrare nell’approvazione dei rilasci sia centrali sia locali. Altrimenti, «autonomia locale» lascia indefinita la responsabilità di proteggere i processi condivisi.
Distinguere le differenze reali dalle preferenze ereditate
Una differenza locale merita di essere esaminata nel merito, senza accettarla o respingerla automaticamente. Nel confronto di SoftEngine, i relatori distinguono la conoscenza dei mercati regionali e le particolarità normative dalle considerazioni sul rollout globale, riportando però la decisione alle priorità strategiche dell’azienda. Questa impostazione va tradotta in riscontri concreti sul requisito stesso.
Per una differenza normativa, occorre identificare l’obbligo applicabile, le registrazioni o gli output che modifica e il responsabile finanziario o legale locale. Poi va valutato se la soluzione comune possa soddisfarlo attraverso una localizzazione supportata o la configurazione. Un requisito legale stabilisce cosa deve essere ottenuto; da solo non dimostra la necessità di un ERP separato.
Esempio illustrativo: uno stabilimento che realizza macchinari progettati su commessa e uno che produce ripetutamente componenti standard possono aver bisogno di flussi di pianificazione diversi. Prima di prescrivere un processo comune, occorre esaminare le differenze effettive nella definizione dell’ordine, nella programmazione e nel calcolo dei costi. Potrebbero comunque condividere le identità dei materiali, le definizioni dei clienti e le regole di reporting di gruppo. La decisione riguarda dove la condivisione resti utile, non se gli stabilimenti siano identici.
Al contrario, «abbiamo sempre usato questa sequenza di approvazione» non basta a giustificare un’eccezione permanente. Bisogna chiedere quale obbligo aziendale o vincolo operativo soddisfi quella sequenza. Se il processo comune risponde a tale esigenza, mantenere la vecchia sequenza aggiunge una differenza senza uno scopo chiaro. Una volta compreso il requisito, un processo di approvazione delle configurazioni e delle personalizzazioni aiuta a decidere come implementarlo.
L’autonomia dello stabilimento va inoltre distinta dal confine con i sistemi di fabbrica. Stabilire se un’attività produttiva appartenga all’ERP o a un software di esecuzione della produzione è una questione diversa dal decidere se lo stabilimento abbia bisogno di un proprio ERP. La ripartizione delle responsabilità tra ERP e MES dovrebbe sostenere l’architettura scelta, senza diventare un modo implicito per indicare l’indipendenza locale.
Scegliere le responsabilità condivise prima del panorama applicativo
È preferibile un approccio globale comune quando regole operative condivise e uno stretto coordinamento tra stabilimenti giustificano un controllo collettivo sulle modifiche. È preferibile un nucleo centrale con ERP locali quando differenze operative significative giustificano responsabilità locali e l’organizzazione è pronta a farsi carico delle mappature, delle interfacce e delle riconciliazioni che li collegano.
Nessuna delle due scelte elimina la governance. L’approccio comune concentra le decisioni su processi e rilasci condivisi. Quello ibrido colloca più responsabilità nei punti di collegamento tra sistemi. Il disegno migliore è quello di cui l’azienda sa spiegare, assegnare e sostenere le responsabilità continuative.
Se state definendo questa ripartizione tra Paesi e stabilimenti, i servizi ERP di Digiventi sono un passo successivo pertinente per discutere insieme configurazione dei processi e integrazione dei sistemi.