SAP S/4HANA vs SAP ECC: differenze reali per chi deve migrare

Chi lavora con SAP in Italia nel 2025 si trova in mezzo al guado. Da una parte SAP ECC, l’ERP storico che gira da vent’anni nelle aziende, stabile e conosciuto. Dall’altra SAP S/4HANA, la nuova suite che dovrebbe sostituirlo entro fine 2027. La scelta su come e quando migrare non e’ solo una decisione IT: tocca processi, custom code, interfacce, budget pluriennali. Vale la pena capire cosa cambia davvero sotto il cofano, non solo a livello di marketing.

Cos’e’ SAP ECC

ECC sta per ERP Central Component, il cuore di SAP Business Suite rilasciato nel 2004. Gira su database tradizionali (Oracle, DB2, SQL Server o lo stesso MaxDB di SAP) e usa un’architettura che separa i dati transazionali dai dati aggregati: quando registri una fattura, il sistema scrive in diverse tabelle, poi costruisce totali e indici per le query successive. L’interfaccia standard e’ SAP GUI, quella che molti utenti ancora oggi chiamano “SAPpino”: veloce per chi la conosce, ostica per chi arriva da applicazioni web moderne.

ECC funziona bene. Il problema e’ che non evolve piu’. SAP ha annunciato fine mainstream maintenance a dicembre 2027, estendibile a pagamento fino al 2030 con extended maintenance. Dopo, chi resta su ECC paghera’ supporto custom senza nuove feature e senza patch di compliance.

Cos’e’ SAP S/4HANA

S/4HANA e’ la riscrittura della suite ERP su database in-memory HANA, rilasciata nel 2015. In-memory significa che i dati stanno in RAM invece che su disco: le query che su ECC richiedevano minuti qui tornano in secondi. Ma il cambio di database e’ solo la punta dell’iceberg. Sotto ci sono modifiche al modello dati che rompono la compatibilita’ con il codice ABAP scritto negli anni su ECC.

Il punto e’ questo: S/4HANA non e’ ECC piu’ veloce. E’ un sistema diverso che condivide solo una parte della logica funzionale. Chi lo capisce subito si risparmia mesi di fraintendimenti con consulenti e project manager.

Universal Journal: ACDOCA al posto di FI/CO separate

Il cambio piu’ profondo e’ il modello dati finanziario. Su ECC, contabilita’ generale (FI) e controllo di gestione (CO) vivevano in tabelle separate: BKPF/BSEG per i documenti FI, COEP per i movimenti CO, piu’ aggregati come GLT0, KNC1, LFC1. Le riconciliazioni tra FI e CO erano un classico grattacapo, con job notturni e quadrature da sistemare a mano.

Su S/4HANA esiste una sola tabella: ACDOCA, chiamata Universal Journal. Ogni scrittura contabile finisce li’, con tutte le dimensioni (conto, centro di costo, ordine interno, WBS, profit center, segmento) in riga. Gli aggregati non servono piu’: il database in-memory calcola i totali al volo. Risultato: niente riconciliazioni FI/CO, reportistica real-time, meno tabelle da imparare. Per chi gestisce chiusure mensili il cambio e’ tangibile.

Fiori: l’interfaccia che abbandona SAPGUI

SAP Fiori e’ la UX moderna di S/4HANA: app web basate su SAPUI5, pensate per un utente, un task, un device. Al posto delle transazioni a codice (ME21N, FB60, VA01) ci sono tile, dashboard, card. Alcune app replicano transazioni classiche, altre introducono analisi che prima richiedevano report custom o export su Excel.

SAP GUI resta disponibile per le transazioni legacy, ma SAP spinge Fiori come standard. Nelle aziende dove gli utenti sono abituati a MIRO o VF01 la transizione non e’ indolore: servono training, redesign dei ruoli, spesso un lavoro di change management piu’ pesante dell’installazione tecnica.

Tre scenari di migrazione

SAP offre tre strade per passare da ECC a S/4HANA, ognuna con trade-off diversi:

• Greenfield: si parte da un sistema S/4HANA vuoto, si ridisegnano i processi su standard, si migrano solo anagrafiche e saldi di apertura. Adatto ad aziende che vogliono ripulire anni di custom code e tornare vicino allo standard. Costoso e lungo, ma rigenera l’ERP.
• Brownfield: upgrade tecnico del sistema ECC esistente verso S/4HANA. Si conservano storico, custom, configurazioni. Piu’ rapido e meno invasivo, ma porta con se’ anche il debito tecnico accumulato.
• Selective Data Transition: via di mezzo. Si costruisce un nuovo S/4HANA e si migrano selettivamente dati, aziende o moduli. Utile per gruppi multi-societa’ o per chi vuole fare pulizia parziale.

Non esiste la scelta giusta in assoluto. Dipende da quanto custom c’e’ nel sistema, quanta storia serve davvero, quanto budget e tempo ci sono. Le aziende italiane con ECC vecchi di 15 anni spesso scoprono che greenfield costa meno di brownfield, una volta contato il lavoro di pulizia post-upgrade.

Le sfide che emergono sempre

Tre aree tendono a far saltare i piani di progetto:

• Custom code ABAP: anni di Z-programmi, user exit, enhancement. Su S/4HANA alcune API cambiano (MATNR passa da 18 a 40 caratteri, tabelle MKPF/MSEG diventano MATDOC), il codice va analizzato con tool SAP come Custom Code Migration Worklist.
• Output gestionali: form SmartForms, SAPscript, Adobe Interactive. Funzionano ancora ma vanno testati; molte aziende approfittano per passare a Adobe Forms o template moderni.
• Interfacce con sistemi terzi: EDI, middleware, integrazioni con MES/WMS/CRM. Gli IDoc restano, ma endpoint e struttura dati possono cambiare. Va rifatta la mappatura e testata in integrazione, non solo in unit.

Perche’ vale la pena sapere su cosa si sta lavorando

Chi scrive software gestionale, integrazioni o reportistica in aziende italiane prima o poi incontra SAP. Capire se il cliente e’ su ECC o su S/4HANA cambia tutto: le tabelle da interrogare, le BAPI da chiamare, il modo in cui arrivano i dati contabili. Una query che su ECC richiede join tra BKPF, BSEG e COEP, su S/4HANA si fa con una SELECT su ACDOCA e basta.

Chi vuole approfondire l’ecosistema SAP moderno puo’ guardare anche la guida ai moduli SuccessFactors, la suite HR cloud di SAP, e Joule, il copilota AI che SAP sta integrando dentro Fiori e S/4HANA.

La vera domanda

La deadline 2027 sembra lontana, ma un progetto di migrazione SAP serio richiede 18-36 mesi tra assessment, design, realizzazione, test e go-live. Chi parte nel 2025 arriva in tempo, chi parte nel 2026 comincia a stringere. La domanda onesta non e’ “quando migrare”, e’ “cosa vogliamo che faccia il nostro ERP tra cinque anni”. Perche’ S/4HANA e’ un’occasione, ma se si porta dietro tutto il debito di ECC senza ripensarlo, resta solo un upgrade tecnico costoso.