La decisione di Lidl di fermare l’implementazione di SAP Hana a causa dell’aumento dei costi potrebbe essere un primo segno dei problemi che l’aggiornamento a S/4 Hana comporta.

Mentre poco è stato rivelato sul motivo per cui Lidl ha deciso di eliminare SAP, quello che è diventato evidente dai rapporti sul progetto del rivenditore è che ha staccato la spina a causa dell’aumento dei costi.

Quando Computer Weekly ha iniziato a vedere i fallimenti dei progetti SAP alla fine degli anni ’90, i costi di implementazione erano uno dei fattori che contribuivano. Il problema era che SAP veniva venduto come una serie di processi di business preconfezionati, che incapsulavano i processi di business di alcune delle più grandi aziende del mondo, ma spesso questi non corrispondevano a come le aziende che cercavano di implementare SAP vedevano i loro processi di business. Questo significava che spesso era necessario personalizzarli.

Due decenni dopo, gli esperti sono d’accordo sul fatto che la personalizzazione di SAP dovrebbe essere evitata perché i costi e la complessità aumentano rapidamente. Questo è vero oggi per le aziende che si imbarcano in un’implementazione di SAP S/4 Hana come lo era quando hanno implementato SAP R/3 negli anni ’90.

Nel 2025, SAP terminerà ufficialmente il supporto per ECC6, il componente centrale delle risorse aziendali (ERP) del suo prodotto. Dal punto di vista di SAP, questo dà alle aziende meno di sei anni per implementare S/4 Hana.

Le aziende che eseguono sistemi SAP implementati negli ultimi due decenni devono prendere una decisione difficile su come il loro codice personalizzato SAP esistente dovrebbe essere sviluppato nuovamente per S/4 Hana.

C’è un dibattito in corso su come i sistemi esistenti possano essere rielaborati per S/4 Hana, ma il consenso generale è che S/4 Hana significa implementare un sistema interamente ERP.

Identificare i processi di business esistenti

Come tale, le aziende devono capire quali sono i loro processi di business esistenti, quanto è codificato in SAP, quanta della personalizzazione nell’implementazione originale è ora parte di S/4 Hana standard, e se è davvero un imperativo di business implementare il vecchio codice personalizzato nella piattaforma. Questo è particolarmente vero se un processo di business che è stato codificato due decenni fa non viene più utilizzato, o è stato adattato ma il codice personalizzato non è stato aggiornato.

Secondo il whitepaper Optimising business processes for success dell’analista IDC: “I processi mal coordinati che non si adattano alle esigenze di business e che minano i sistemi di produzione quando vengono implementati non sono semplicemente costosi – possono ostacolare un efficace posizionamento aziendale e la reattività alle pressioni competitive in rapido cambiamento e alle richieste globali.”

Nel whitepaper, IDC raccomanda di stabilire strategie che comprendano un cambiamento culturale, strutture organizzative (sfruttando centri di eccellenza esistenti, uffici di gestione di progetti o programmi, o DevOps – o formandoli), processi per la qualità dei processi aziendali, e valutazione e adozione di soluzioni di automazione appropriate per aiutare a creare applicazioni rilevanti, adattive e centrate sul business.

Consegnare le richieste del business

Secondo il consulente SAP Panaya, per ottenere il massimo valore da un investimento in SAP S/4 Hana, il dipartimento IT dovrà consegnare le richieste del business il più rapidamente possibile senza interrompere il business. Con diversi percorsi di progetto da intraprendere – migrazione, implementazione, greenfield, ecc – i team IT si stanno imbarcando in progetti da 12 a 18 mesi, ha scritto la società in un recente whitepaper.

L’aggiornamento tecnico per SAP S/4 Hana può essere veloce come tre mesi. Tuttavia, per soddisfare i nuovi standard di SAP S/4 Hana, Panaya ha detto che i restanti nove – 15 mesi dovrebbero essere concentrati sui cambiamenti dei processi di business, sulla personalizzazione e sulla garanzia di qualità.

In effetti, SAP S/4 Hana introduce molti cambiamenti in aree come la tecnologia, i processi di business e le interfacce utente. Secondo Panaya, questi cambiamenti influenzeranno sia il modo in cui i team IT lavorano sia il modo in cui personalizzano il sistema SAP.

Come i modelli operativi e i processi IT cambiano, Panaya ha avvertito che le richieste di cambiamento, i requisiti e i processi di gestione dei test e del rilascio potrebbero essere una transizione difficile per l’IT aziendale.

“Per molte organizzazioni, l’implementazione di questi cambiamenti in una modalità di consegna a cascata richiederà troppo tempo, influenzando il ROI della soluzione. Questi cambiamenti avranno bisogno di essere implementati in modo incrementale, fornendo diverse richieste di cambiamento in ogni ciclo utilizzando DevOps e la consegna continua”, dice il whitepaper di Panaya.

Assumersi la responsabilità

Stuart Browne, amministratore delegato della società di consulenza indipendente SAP Resulting, ha detto che un problema comune che incontra è che le aziende spesso presumono erroneamente che sia l’integratore di sistemi ad avere la responsabilità di ottenere la giusta implementazione ERP, quando in definitiva è responsabilità del cliente.

Browne ha detto che una delle sfide tecniche per le aziende è che S/4Hana non è ancora completo. “È un prodotto incompiuto e non semplifica la suite di prodotti SAP. L’adozione di S/4 Hana ora semplifica alcune funzionalità, ma non tutte.”

Siccome è ancora un lavoro in corso, Browne ha detto che c’è una mancanza di strumenti e di persone con le giuste competenze per implementare S/4 Hana. Questo è aggravato dal fatto che le persone che capiscono l’implementazione ECC6 SAP ERP esistente e che hanno circa 20 anni di esperienza con essa si stanno dirigendo verso il pensionamento.

“C’è una forza lavoro che invecchia e si avvicina al pensionamento. Tutti tendono ad avere tra i 40 e i 50 anni”. Ha detto che i giovani stanno generalmente facendo “cose più fresche” piuttosto che implementare SAP, e c’è un’inflazione salariale dell’8% in India, il che significa che esternalizzare le competenze SAP è costoso.

Deferendo l’aggiornamento

Rimini è una delle aziende che ha costruito un business intorno al supporto dei vecchi sistemi SAP. L’idea dietro l’assunzione di un contratto di manutenzione da parte di terzi è che permette all’azienda di abbassare il suo canone di manutenzione in corso mentre ritarda la migrazione al prodotto più recente, in questo caso SAP S/4 Hana.

Hari Candadai, vicepresidente del gruppo per il marketing di prodotto e la strategia di Rimini Street, ha detto che è stato “molto significativo” che Lidl abbia dovuto rivalutare e personalizzare così tanti processi per far funzionare il nuovo sistema SAP per il suo business.

“Il risultato chiave è che ogni cliente aziendale che sta considerando un importante spostamento della piattaforma SAP, compresa una potenziale reimplementazione di S/4 Hana dal suo sistema SAP esistente, deve capire che è tutt’altro che semplice”, ha detto Candadai. “Sbagliate e questo avrà un forte impatto sulla vostra linea di fondo. La vera domanda è: ‘Qual è stato il ROI preteso sul posto per considerare anche solo di strappare e sostituire i vostri sistemi di back office di record?’.”

Siccome il supporto per ECC6 continuerà fino al 2025, le aziende non devono necessariamente comprare in S/4 Hana proprio ora, soprattutto se sentono che non è ancora un prodotto completo.

Sei anni sono tanti, e dato che SAP S/4 Hana è considerato un’implementazione importante, Browne ha detto che c’è un’opportunità per le aziende di rivalutare come il core ERP dovrebbe funzionare all’interno dell’azienda e di guardare alla fattibilità di implementare alternative come NetSuite o Microsoft Dynamics.

C’è anche la questione di quale architettura IT sarà necessaria nel 2025 per supportare ciò che il business spera di fare in quel momento. Per esempio, mentre S/4 Hana fornisce interfacce di programmazione delle applicazioni (API), Browne ha affermato che queste sono troppo restrittive, specialmente se l’azienda vuole aprire le sue interfacce di programmazione delle applicazioni e partecipare a un’economia API, dove le aziende transano usando un approccio cloud-native basato su microservizi leggeri.

E mentre SAP può essere stata venduta in passato come un modo per incapsulare processi di business di livello mondiale, le aziende tradizionali rischiano di essere sconvolte perché un ERP inventato negli anni ’90 non è all’altezza delle innovative supply chain del 21° secolo.