Il custom code è allo stesso tempo il punto di forza e il tallone d'Achille delle implementazioni SAP. Da un lato abilita processi specifici del business, dall'altro è l'ostacolo numero uno alla migrazione a S/4HANA. Questa guida ti propone un approccio sistematico per individuare il custom code, stabilire le priorità e portare a termine la remediation, così da affrontare con successo la trasformazione verso S/4HANA.

I numeri reali:

• Un'azienda media ha tra 50.000 e 200.000 righe di codice ABAP custom
• Il 30-40% va modificato per essere compatibile con S/4HANA
• Remediation manuale: 6-12 mesi di lavoro
• Gli strumenti automatici riducono i tempi a 2-4 mesi

Perché il custom code smette di funzionare in S/4HANA

Il modello dati semplificato di S/4HANA elimina migliaia di tabelle del database, cambia la lunghezza di molti campi e depreca diversi function module. Con ogni probabilità il tuo custom code si appoggia proprio su queste strutture.

Pattern di codice incompatibili

• Accesso diretto a tabelle obsolete (BSEG, KONV)
• Uso di function module deprecati
• Lunghezze dei campi hard-coded (ora cambiate)
• Letture da tabelle pool/cluster (ora diventate tabelle standard)
• Enhancement custom dentro codice SAP modificato

Le alternative in S/4HANA

• CDS view per l'accesso ai dati
• BAPI e API rilasciate
• Dimensionamento dinamico dei campi
• Accesso alle tabelle standard
• Implementazioni di BAdI (non modifiche)

Fase 1: discovery e assessment

Passo 1: esegui SAP Readiness Check

SAP mette a disposizione lo strumento Readiness Check (transazione SYCM oppure tramite SAP Support Portal).

// Transazioni per l'analisi:

ATC

// ABAP Test Cockpit - Analisi statica del codice

SYCM / SAT / SE80

// Punti di partenza per la scansione del custom code

/SDF/CD_CDS

// Verifica di compatibilità delle CDS

Passo 2: classifica il custom code

Matrice di classificazione:

DA CORREGGERE

Processo di business critico + errore di sintassi/dump
Esempio: programma Z di gestione ordini che accede direttamente a BSEG

PRIORITÀ ALTA

Processo core + warning di performance
Esempio: report che usa un FM deprecato: funziona, ma è lento

MEDIA

Processo non critico + problema di compatibilità
Esempio: programma di utility usato di rado, con lunghezze dei campi non allineate

BASSA / DA DISMETTERE

Codice inutilizzato o processo obsoleto
Esempio: programmi che non vengono eseguiti da più di 2 anni: meglio cancellarli che correggerli

Fase 2: strategie di remediation

Strategia 1: sostituisci con funzionalità SAP standard

Lo scenario migliore: S/4HANA offre ora una funzionalità standard che sostituisce il tuo custom code.

Esempio:

Programma custom per la gestione del credito → S/4HANA Advanced Credit Management (app Fiori)

Azione: dismetti il custom code e forma gli utenti sulla nuova app Fiori. Nessuno sforzo di remediation.

Strategia 2: refactoring verso le CDS view

Sostituisci l'accesso diretto alle tabelle con le CDS consumption view.

Prima (ECC):

SELECT * FROM bseg INTO TABLE lt_bseg

WHERE bukrs = p_bukrs

AND gjahr = p_gjahr.

Dopo (S/4HANA):

SELECT * FROM i_journalentryitem INTO TABLE lt_items

WHERE companycode = p_bukrs

AND fiscalyear = p_gjahr.

Strategia 3: aggiorna la lunghezza dei campi

S/4HANA ha esteso i campi chiave da 10 a 40 caratteri. Le lunghezze hard-coded provocano dump.

❌ Codice problematico:

DATA: lv_vbeln TYPE c LENGTH 10. " Lunghezza fissa!

✅ Codice corretto:

DATA: lv_vbeln TYPE vbeln_va. " Usa il data element!

Strategia 4: sostituisci i function module deprecati

SAP mette a disposizione il Simplification Database, che elenca gli oggetti deprecati e i relativi sostituti.

Sostituzioni più comuni:

Deprecato: BAPI_CUSTOMER_GETLIST

Usa: API_BUSINESS_PARTNER

Deprecato: SD_VBAP_READ_WITH_VBELN

Usa: CDS View I_SALESORDERITEM

Deprecato: FI_DOCUMENT_READ

Usa: I_JOURNALENTRY CDS

Fase 3: strategia di test

Un approccio di test su più livelli

1. Unit test (ABAP Unit)

Testa ogni programma sottoposto a remediation in isolamento, con dati di esempio

2. Test di integrazione

Esegui i processi di business end-to-end nel sistema di QA

3. Test di performance

Confronta i tempi di esecuzione con la baseline ECC (le CDS dovrebbero essere più veloci!)

4. User Acceptance Test (UAT)

Gli utenti di business verificano che gli output corrispondano alle attese

Strumenti automatici per la remediation

Strumenti nativi SAP

ATC: code inspector integrato
Readiness Check 2.0: analisi completa
Custom Code Migration App: workbench basato su Fiori

Soluzioni di terze parti

Strumenti di refactoring automatico (assistiti dall'AI)
Piattaforme di impact analysis
Analisi dell'utilizzo del codice (per individuare il codice morto)

Best practice e consigli

1
Parti presto
Avvia la remediation 12-18 mesi prima del go-live previsto. Il collo di bottiglia è sempre il custom code.
2
Stabilisci priorità rigorose
Correggi solo ciò che è critico per il business. Dismetti il 30-40% di codice inutilizzato.
3
Documenta tutto
Tieni un tracker della remediation: nome del programma, problema, correzione applicata, tester, stato.
4
Coinvolgi subito il business
Alcune "correzioni" cambiano il comportamento dei programmi. Ottieni il via libera degli utenti prima della remediation.
5
Monitora dopo la migrazione
Anche il codice "corretto" può comportarsi diversamente in S/4HANA. SUPtime ne mostra gli effetti a runtime: dump ST22, errori di update SM13 e durata dei job SM37.

Conclusione

La remediation del custom code è la parte più impegnativa, in termini di effort, di una migrazione a S/4HANA, ma è anche un'occasione per modernizzare e semplificare il tuo landscape SAP. Con un'analisi sistematica, priorità ben definite e gli strumenti giusti, puoi trasformare questa sfida in un vantaggio competitivo.

Ti serve aiuto con la migrazione a S/4HANA?

SUPtime non analizza il custom code, ma mostra dove il codice non adeguato fallisce a runtime: dump ST22 con programma e utente, errori di update SM13 e job SM37 più lunghi della loro media.

Parla con i nostri esperti

Remediation del custom code per S/4HANA