La separazione dell'ERP definisce la tempistica di tutte le altre attività

In breve

La tempistica della separazione ERP è ciò che di fatto determina il ritmo di una scissione aziendale. La funzione finanziaria non può chiudere un libro contabile autonomo. La funzione acquisti non può emettere i propri ordini di acquisto. La logistica non può effettuare spedizioni ai clienti finché la tempistica della separazione ERP non è stata completata. I team incaricati dell’operazione spesso definiscono i termini del contratto di servizi di transizione sulla base di ipotesi relative alla funzione finanziaria e alle risorse umane. Successivamente, considerano la tempistica di separazione dell’ERP come un dettaglio tecnico che un integratore può portare a termine su richiesta. Se la scelta dell’architettura dei sistemi avviene in ritardo, è solitamente la tempistica di separazione dell’ERP a determinare la data effettiva di uscita, non il contratto.

Perché la tempistica della scissione dell’ERP è in contrasto con gli accordi sui servizi di transizione (TSA)

L'acquisizione è stata completata. L'azienda ha firmato l'accordo sui servizi di transizione, che prevede un obiettivo di dodici mesi per l'uscita dai servizi condivisi. Sulla carta, il programma di separazione appare ben strutturato. I flussi di lavoro relativi alle risorse umane, all'area commerciale, alle entità giuridiche e alla catena di approvvigionamento prevedono ciascuno le proprie tappe fondamentali.

Nel giro dei primi sessanta giorni, il quadro cambia. Il reparto Finanza non riesce a finalizzare il piano dei conti autonomo. Nessuno ha configurato il libro mastro. Il reparto Operazioni non può emettere ordini di acquisto autonomi finché il database della gestione dei materiali non sarà separato da quello della società madre. Il reparto Logistica non può spedire i componenti finiti. Il team non ha ancora ripristinato il collegamento per lo scambio elettronico di dati con lo stabilimento del cliente.

Il calendario relativo alla scissione dell’ERP non è un semplice flusso di lavoro tra tanti. Esso determina il ritmo di tutti gli altri flussi di lavoro della scissione. Pochi team incaricati dell’operazione ne tengono conto al momento della firma.

Sfide transfrontaliere nell'attuazione di una separazione (carve-out) di SAP

Il calendario per la separazione (carve-out) dell’ERP diventa davvero complesso quando gli stabilimenti produttivi si trovano in un Paese diverso da quello della casa madre. Uno scenario comune: il venditore gestisce un’unica istanza SAP o Oracle dalla sede centrale in Germania, Francia o Svizzera. Gli stabilimenti che svolgono l’attività produttiva si trovano invece in Polonia, Repubblica Ceca, Ungheria o Romania.

Gestione dei dati anagrafici condivisi e rischi legati alla separazione delle attività SAP (carve-out)

In un sistema integrato, i dati relativi a materiali, fornitori e clienti risiedono in tabelle condivise tra diverse divisioni. Estrapolare i dati di una singola unità aziendale non è una semplice operazione di esportazione. Spesso un venditore e un’unità ceduta condividono codici di pezzi fusi, specifiche delle leghe o conti clienti. Qualcuno deve separare i dati commerciali riservati senza compromettere le distinte base storiche. Ciò richiede persone che comprendano l’impianto fisico, non solo il database. Questo è esattamente il motivo per cui la tempistica di separazione ERP subisce un rallentamento proprio in questa fase, prima che qualsiasi altro flusso di lavoro ne risenta.

Rispetto delle norme locali in materia di conformità normativa e fiscale sin dal primo giorno della separazione

Un’entità autonoma nell’Europa centrale non può limitarsi ad adottare un unico modello globale e dare per scontato che la conformità ne derivi automaticamente. Le attività in Polonia necessitano di un modulo di rendicontazione SAF-T conforme. Le entità ceche sono soggette a norme di ammortamento e dichiarazioni di controllo IVA proprie. Le filiali rumene necessitano di fatturazione elettronica certificata. Se il nuovo sistema ERP non è in grado di fornire questi elementi il giorno del passaggio al nuovo sistema, la filiale non potrà legalmente emettere fatture né spedire merci.

Prevenzione dei malfunzionamenti nell'interscambio elettronico di dati (EDI) e nell'interfaccia con i clienti

I clienti dei settori automobilistico e aerospaziale applicano rigidi protocolli di consegna, come gli standard tedeschi VDA ed europei Odette. Il nuovo sistema potrebbe non inviare correttamente l’avviso di spedizione anticipato. Potrebbe generare un’etichetta di imballaggio con un numero di serie errato. Entrambi questi errori consentono a un cliente di primo livello di rifiutare la consegna all’ingresso. Il cliente può quindi addebitare al fornitore i costi derivanti dal fermo della linea di produzione.

Individuazione dei segnali di allarme precoci relativi a scostamenti rispetto alla tempistica prevista per lo scorporo delle attività ERP

I consigli di amministrazione raramente si accorgono dei problemi relativi alla tempistica di scorporo dell'ERP quando viene mancato un traguardo. La deriva si manifesta già prima, attraverso sintomi specifici nei primi quattro mesi.

Ritardi da parte dei partner di implementazione del sistema e slittamento della data di messa in funzione

Il partner esterno incaricato dell'implementazione chiede ripetute proroghe della tempistica prevista per il distacco del sistema ERP. La data di entrata in funzione slitta da nove mesi a quindici o diciotto.

Restrizioni informatiche della società madre e ritardi nell’accesso al database

La ex società madre ritarda l'accesso diretto al database. Adduce come motivazione la tutela dei dati e la riservatezza degli account dei clienti condivisi che intende preservare.

Test EDI non superati ed escalation nella catena di approvvigionamento del cliente

I test di scambio elettronico di dati (EDI) effettuati prima del lancio generano etichette danneggiate o trasmissioni respinte. Il team logistico del cliente segnala il problema ai livelli superiori.

Soluzioni alternative manuali e aumento dei sovrapprezzi previsti dall'accordo sui servizi di transizione (TSA)

I responsabili di stabilimento e i responsabili delle spedizioni creano fogli di calcolo manuali. Nessuno li ha formati sul nuovo sistema e nessuno si fida dei dati. Nel frattempo, il tempo previsto dal contratto di servizi di transizione continua a scorrere. I costi di proroga aumentano secondo un calendario prestabilito, indipendentemente dall’effettivo andamento della tempistica prevista per il distacco dal sistema ERP.

Quando diversi di questi sintomi si manifestano contemporaneamente, il quadro è inequivocabile. Un ritardo tecnico nella migrazione di un database si trasforma, nel giro di poche settimane, in un problema concreto alla banchina di carico.

Quadro strategico per accelerare la separazione dei sistemi IT e il passaggio al nuovo sistema

Per recuperare il ritardo nella tabella di marcia relativa allo scorporo dell'ERP è necessario un dirigente designato che abbia il controllo operativo. Un comitato direttivo che si riunisce mensilmente non è sufficiente.

Scegliere la giusta strategia di separazione ERP: migrazione o realizzazione ex novo

Nel valutare come inserire il processo di scorporo in un calendario molto serrato, la dirigenza prende solitamente in considerazione tre diversi approcci strutturali:

• Clona e dividi
• Migrazione selettiva dei dati
• Costruzione ex novo

In un arco di tempo compreso tra nove e dodici mesi, la realizzazione ex novo di un impianto raramente rientra nei tempi previsti. Una migrazione mirata e selettiva o un modello cloud preconfigurato riducono al minimo la necessità di personalizzazione e rispecchiano i processi esistenti dello stabilimento, salvaguardando le routine già note al personale di produzione.

Distinguere l'esecuzione degli impianti dalla governance del passaggio informatico

Un direttore di stabilimento non può gestire tre turni di lavoro e allo stesso tempo testare migliaia di transazioni ERP. Chiedergli di fare entrambe le cose significa condannarlo al fallimento in entrambi i casi. Dovrebbe invece esserci un responsabile di programma indipendente che gestisca la fase di transizione, coordinando direttamente l’IT aziendale, l’integratore e le operazioni dello stabilimento.

Definizione delle riserve di sicurezza operative prima del passaggio al nuovo sistema

Per proteggersi da eventuali interruzioni della catena di approvvigionamento, il consiglio di amministrazione dovrebbe approvare in anticipo misure di emergenza specifiche. Tre sono gli aspetti fondamentali per il calendario di separazione del sistema ERP:

• Scorta di prodotti finiti: costituire scorte presso i magazzini dei clienti principali.
• Procedura cartacea: mantenere una procedura di spedizione manuale sottoposta a revisione contabile come piano di riserva.
• Blocco delle modifiche: applicare un blocco alle modifiche non essenziali al sistema prima dell’inizio della finestra di transizione.

I dati di rendicontazione possono rimanere imperfetti per qualche giorno. Una consegna non effettuata a un cliente, invece, no.

Gestione della governance e delle operazioni nel contesto del disaccoppiamento IT in contesti multigiurisdizionali

L’ufficio di implementazione dell’acquirente ha solitamente sede in un paese, mentre l’ufficio di separazione del venditore si trova in un altro. Spesso i due fanno capo a figure diverse con incentivi diversi. Stabilire una base informativa condivisa tra loro garantisce che la tempistica della separazione dell’ERP rimanga realistica. Due piani di progetto in competizione tra loro, invece, non lo fanno. Alcuni stabilimenti ceduti si trovano in luoghi in cui né il team tecnologico dell’acquirente né la funzione IT del venditore operano quotidianamente. In tale contesto, un unico dirigente responsabile è spesso l’unica persona che tiene effettivamente insieme la tempistica di separazione dell’ERP.

Dati di settore sui rischi legati alla separazione dei sistemi ERP e agli accordi sui servizi di transizione

Secondo Gartner ricerca dimostra che dal 55 al 75 per cento dei progetti ERP non riesce a raggiungere gli obiettivi operativi previsti. Nel settore della produzione discreta e nelle catene di approvvigionamento multisito, i malfunzionamenti post-avvio relativi alla gestione delle spedizioni dal magazzino e alla pianificazione della produzione sono le cause principali delle difficoltà. Si tratta proprio dei malfunzionamenti che una tempistica di separazione e scorporo dell’ERP mette a rischio.

L'operazione transfrontaliera di Roland Berger studi giungono a una conclusione analoga. Indicano la separazione tra IT e risorse umane come le due principali insidie che causano il mancato raggiungimento dei parametri di riferimento relativi a costi, tempistiche o qualità in oltre un terzo dei casi di scorporo. Un’altra indagine condotta da Roland Berger su quasi quattrocento esperti individua le stesse due aree. È proprio nella separazione tra IT e risorse umane che si concentrano maggiormente i superamenti dei costi e i ritardi. Le due cause principali ricorrenti sono: la mancanza di esperienza pregressa in materia di separazione all’interno del team di progetto e una pianificazione irrealistica al momento della firma.

BCG's ricerca indica che la separazione tra l’ERP e l’architettura IT rappresenta il singolo processo più lungo nelle operazioni di cessione aziendale. Gli acquirenti di private equity e le società venditrici talvolta non riescono a predisporre in anticipo e isolare le dipendenze IT prima della chiusura dell’operazione. Quando ciò accade, le proroghe degli accordi sui servizi di transizione e le dis-sinergie operative erodono rapidamente il valore dell’operazione.

Di McKinsey analisi sottolinea che la separazione dei sistemi IT è spesso più complessa dell’integrazione da parte dell’acquirente. L’interfaccia tecnica tra l’ufficio di implementazione dell’acquirente e l’ufficio di separazione del venditore richiede una rigorosa governance operativa, la stessa governance che un accordo sui servizi di transizione per la separazione dei sistemi IT è destinato a garantire. In assenza di tale governance, i passaggi da un sistema all’altro iniziano a causare controversie commerciali e mancati adempimenti nei confronti dei clienti.

Le linee guida di EY relative ai programmi di separazione collocano la tempistica di separazione dei sistemi ERP nella stessa posizione. La regola è la seguente: dedicare l’80% dello sforzo di separazione all’ERP, alla gestione delle retribuzioni e alla gestione delle prestazioni aziendali. Questi sistemi sono in genere tra gli ultimi servizi a essere disattivati nell’ambito di un accordo di transizione.

Nel loro insieme, queste cinque fonti indicano tutte la stessa direzione. Il calendario relativo alla separazione dell’ERP merita l’attenzione da parte dei dirigenti che un team incaricato della transazione riserva solitamente alla due diligence finanziaria. Raramente riceve più attenzione di quella riservata a una dipendenza tecnica.

Caso di studio: Gestione di un processo di scorporo SAP della durata di 10 mesi nel settore della produzione automobilistica

Il seguente mandato illustra come un intervento esecutivo rigoroso abbia consentito di portare a termine la separazione (carve-out) di SAP entro i tempi previsti dall’accordo di transizione.

Il mandato: strategia di scorporo della produzione automobilistica transfrontaliera

Questo mandato da 85 milioni di euro rappresenta l'attuazione concreta del piano di scorporo nell'ambito dell'ERP. Un investitore europeo di private equity ha acquisito una divisione specializzata in componenti di precisione per motopropulsori automobilistici da un conglomerato industriale tedesco di primo livello. L’entità scorporata gestiva due stabilimenti: un sito di lavorazione di precisione in Sassonia, Germania, che impiegava 320 dipendenti, e uno stabilimento di assemblaggio a Plzeň, nella Repubblica Ceca, che impiegava 200 operatori tecnici.

Ai sensi del contratto di acquisto, l’ex società madre gestiva l’infrastruttura IT, la posta elettronica e il sistema centrale SAP ECC 6.0. Lo faceva nell’ambito di un rigoroso accordo di servizi di transizione della durata di dodici mesi. Il contratto prevedeva ingenti premi di proroga: il 25% per i mesi dal tredicesimo al quindicesimo e il 50% oltre tale periodo. Il mancato rispetto di una scadenza esponeva l’acquirente a costi aggiuntivi pari a ben 600.000 euro.

Dove è fallito il piano temporale per la scissione dell'ERP

Al quarto mese, il programma era in notevole ritardo. L’integratore scelto dallo sponsor propose di passare direttamente a una versione personalizzata di SAP S/4HANA nel cloud. Si trattava di quel tipo di separazione ambiziosa dei sistemi SAP che su una diapositiva sembra perfetta. La tempistica prevista di diciotto mesi avrebbe comportato un ritardo di sei mesi rispetto a quanto stabilito nell’accordo di transizione.

Contemporaneamente, l'estrazione dei dati anagrafici si è bloccata. Il team IT della casa madre tedesca ha negato l'accesso agli estratti completi del database. Le tabelle anagrafiche storiche dei clienti contenevano dati riservati sui prezzi relativi alle linee di prodotti che la casa madre aveva mantenuto.

A Plzeň, il team ha riscontrato che il sistema di destinazione proposto non era conforme alle normative fiscali e doganali ceche in materia di rendicontazione. Il progetto ha quindi effettuato i primi test di scambio elettronico di dati con gli stabilimenti di assemblaggio di Wolfsburg e Lipsia. I messaggi di spedizione non sono andati a buon fine a causa di una serializzazione dei codici a barre non corrispondente. I clienti principali hanno emesso avvisi formali in merito al rischio per i loro programmi di consegna.

Direzione ad interim del programma ERP e intervento di risanamento rapido

Il partner operativo ha incaricato CE Interim di coordinare il calendario relativo alla separazione del sistema ERP. Entro 72 ore dal completamento del brief relativo all’incarico, un direttore di programma ERP ad interim di comprovata esperienza e in linea con i requisiti dell’incarico ha assunto l’incarico. Il dirigente vantava oltre vent’anni di esperienza nel settore della produzione industriale e nel risanamento aziendale.

Per recuperare il ritardo accumulato, il dirigente ha adottato quattro decisioni in rapida successione:

• Abbiamo interrotto il progetto di sviluppo personalizzato della durata di diciotto mesi e abbiamo riorientato il programma verso un'estrazione selettiva dei dati su un modello cloud standardizzato, rispecchiando i flussi di lavoro esistenti e riducendo di cinque mesi i tempi previsti.
• Abbiamo inserito un team dedicato e bilingue (ceco-tedesco) per la correzione dei dati direttamente in officina, con il compito di verificare e ripulire 1.800 distinte base, cicli di lavorazione e profili di imballaggio dei clienti attivi, risolvendo le questioni relative alla privacy dei dati in collaborazione con l'ufficio legale della società madre.
• Ho collaborato con i direttori della logistica dei clienti per riconfigurare le transazioni di scambio elettronico di dati in uscita secondo gli standard VDA 4905 e 4913, ottenendo l'approvazione formale entro 30 giorni.
• Abbiamo progettato una transizione strutturata della durata di 72 ore da effettuare durante un weekend festivo prolungato, avvalendoci di una scorta di prodotti finiti sufficiente per cinque giorni e di una procedura di ripiego cartacea.

Il risultato: uscita anticipata dalla TSA e zero tempi di inattività operativa

Durante il weekend festivo, lo stabilimento ha completato il passaggio completo al nuovo database. Non si è verificata nemmeno un'ora di fermo macchina non programmato. Martedì mattina, il sistema autonomo era già operativo. Le liste di prelievo automatizzate, i programmi di smistamento delle macchine e i manifesti doganali venivano elaborati senza intoppi.

Entro il decimo mese, l’azienda si era completamente disconnessa dall’infrastruttura IT della precedente società madre. Il completamento è avvenuto con due mesi di anticipo, evitando così interamente il pagamento dei 600.000 euro previsti per i premi di proroga. Entro trenta giorni dal lancio, l’accuratezza dell’inventario ha raggiunto il 99,2%. La percentuale di consegne puntuali e complete ha raggiunto il 98,7%. Il team ha eliminato ogni soluzione alternativa manuale. Il dirigente ha quindi completato un passaggio di consegne strutturato della piattaforma operativa, sottoposta a revisione contabile e indipendente, alla dirigenza IT permanente. Questo è l’esempio di una tempistica disciplinata per lo scorporo ERP: gestita dall’inizio alla fine da un unico dirigente responsabile.

Domande frequenti: tempistiche per il distacco delle attività ERP aziendali e strategie di uscita dalla TSA

Perché la tempistica della scissione dell’ERP determina l’andamento del resto del processo di scissione?

Il sistema ERP è alla base della contabilità generale, della fatturazione, della gestione delle scorte, degli approvvigionamenti e delle spedizioni ai clienti. Tutte le altre funzioni dipendono da esso. Nessun altro flusso di lavoro può essere portato a termine in modo autonomo finché la tempistica prevista per la scissione dell’ERP non avrà separato il database dalla ex società madre.

Qual è il percorso di migrazione ERP più veloce in caso di scorporo aziendale?

Una migrazione selettiva dei dati, oppure un modello cloud standardizzato e preconfigurato, rappresenta solitamente la soluzione più rapida. Consente infatti di mantenere inalterati i percorsi di produzione collaudati. Una realizzazione ex novo, ovvero una separazione completa di SAP partendo da zero, richiede mesi in più di configurazione e riqualificazione del personale.

Cosa succede se il passaggio all'ERP non rispetta la scadenza prevista dall'accordo di transizione?

Il mancato rispetto delle tempistiche previste per la separazione e lo scorporo del sistema ERP comporta l’applicazione dei premi di proroga previsti dal contratto. Ciò mette a dura prova il rapporto commerciale con il venditore. Inoltre, si corre il rischio di interruzioni del servizio qualora il venditore aggiorni o dismetta l’infrastruttura da cui l’acquirente dipende ancora.

In che modo un impianto evita le interruzioni delle linee di produzione durante il passaggio al nuovo sistema?

Gli stabilimenti che evitano i fermi di linea creano una scorta temporanea di prodotti finiti nei magazzini regionali. Sospendono le modifiche non essenziali al sistema prima della finestra di transizione. Preparano una procedura di spedizione manuale, cartacea e verificata, da utilizzare in caso di necessità.

Quando il consiglio di amministrazione dovrebbe nominare un direttore ad interim del programma ERP?

La nomina si rende necessaria in tre situazioni. L’attività ceduta fa parte di un’unica entità capogruppo con una struttura profondamente interconnessa. I team interni non hanno esperienza in materia di separazione transfrontaliera. Oppure la tempistica proposta dall’integratore è già in conflitto con l’accordo di transizione.

È possibile che il calendario per il distacco dell'ERP abbia inizio dopo il completamento anziché prima?

È possibile, e spesso accade. È più conveniente correggere la scelta del percorso e la mappa delle dipendenze prima del completamento. Un intreccio di istanze condivise scoperto dopo la firma tende ad allungare di mesi un piano il cui costo è già stato calcolato nell’accordo di transizione.

Conoscenze correlate e passo successivo

Alcune unità scorporate operano già su un'istanza isolata con licenze proprie. In questi casi, un team IT interno è solitamente in grado di gestire autonomamente il calendario di separazione del sistema ERP. La situazione cambia quando l’azienda condivide tabelle di database, distinte base e licenze con la società madre in diversi paesi. Cambia anche quando la roadmap dell’integratore supera già i tempi previsti dall’accordo di transizione.

Un CIO ad interim o un direttore responsabile della separazione dei sistemi IT è una figura davvero rara. I casi in cui è opportuno ricorrervi sono limitati. Ciò vale per un processo di separazione di un sistema ERP a istanza singola, profondamente intricato, che il team interno non ha mai gestito prima. In questi casi, la soluzione offerta da CE Interim è un dirigente di comprovata esperienza, in linea con il mandato e pronto a entrare in carica entro 72 ore dal completamento del brief del mandato.

Letture correlate

• Crisi e ristrutturazione
• Turnaround Operativo
• Integrazione post-fusione

È necessario chiarire la questione del perimetro prima che qualcuno possa definire la tempistica del processo di separazione dell'ERP. Per discutere in via riservata della tempistica attuale del processo di separazione dell'ERP, rivolgersi a un Partner ad interim di CE.