Il passaggio a SAP S/4HANA non è soltanto una scelta software ma anche una decisione infrastrutturale essendo basato su database in-memory HANA, l’ERP richiede grandi quantità di memoria ram su server certificati e risorse hardware proporzionate al numero di utenti e al volume dei dati che l’azienda deve gestire: il dimensionamento iniziale è più difficile da capire rispetto alle vecchie soluzioni con db classico. Non esiste un modello valido per tutti, ma sfruttando le linee guida di Sap per il dimensionamento – per prima la guida quick sizing sviluppata sulle esperienze di volumi di calcolo SD – e usando le altre linee guida sull’hardware dei partner, si riesce ad orientarsi in modo più consapevole.
Come dicevamo il primo elemento di cui tenere conto è che S/4HANA sfrutta intensivamente la memoria ram, i dati principali vengono caricati in memoria per garantire tempi di risposta molto rapidi. Per questo motivo il dimensionamento ruota principalmente intorno alla quantità di ram disponibile, alla quale devono essere bilanciati cpu e storage ad alte prestazioni: che si tratti di i infrastrutture virtuali o fisiche non si deve risparmiare sulla quantità di ram iniziale e sulla sua possibilità di espansione, non rientrare più nella memoria disponibile o upgradabile vi costringerà a cambiare i nodi di elaborazione e quindi a costi aggiuntivi.
Aziende intorno ai 100 utenti
In una realtà di piccole dimensioni, con un centinaio di utenti concorrenti e un utilizzo concentrato sui moduli finanziari e logistici di base, non servono infrastrutture mastodontiche. Oggi è possibile operare tranquillamente con un server certificato da 512 GB a 1 TB di RAM, corredato da una trentina di core e uno storage SSD da una decina di tera-byte. Con questa configurazione si garantiscono tempi di risposta nell’ordine del secondo anche durante i picchi operativi, con costi contenuti e la possibilità di implementare l’intera piattaforma in un singolo nodo che comprende sia application server che database. Ci sono aziende che scelgono anche il cloud pubblico (AWS, Azure, GCP) ma sono ancora rare per i costi sotenuti dello stesso, qui le stesse risorse sono disponibili in modalità flessibile cosi da scalare rapidamente in caso di necessità.
Aziende intorno ai 500 utenti
Il discorso cambia sensibilmente quando parliamo di organizzazioni più strutturate, con alcune centinaia di utenti contemporanei e un utilizzo esteso dei moduli di produzione, logistica e pianificazione avanzata. In questo caso la memoria necessaria sale a 2–4 terabyte, distribuita su server con 48/64 o più core CPU. Lo storage deve essere dimensionato di conseguenza, con sistemi da piu di 10 terabyte su SSD/NVMe e log collocati su dischi ad alte prestazioni.
Per aziende di questa fascia è fondamentale pensare non solo alle risorse di produzione, ma a un landscape completo che includa oltre ai sistemi di sviluppo e test anche un ambiente di disaster recovery. In questa scala i tempi di risposta rimangono molto rapidi anche con elaborazioni più pesanti, come l’ATP o le analisi finanziarie consolidate, purché il server sia correttamente dimensionato.
Aziende oltre i 1000 utenti
Arriviamo infine al mondo delle grandi imprese e dei gruppi internazionali, dove il numero di utenti simultanei supera abbondantemente il migliaio e i volumi dati crescono in modo esponenziale. Qui parliamo di server con 6, 8 o anche più di 12 terabyte di RAM, spesso organizzati in architetture scale-up di fascia alta o in cluster scale-out. Il numero di core può arrivare superare facilmente 128, mentre lo storage deve raggiungere diverse decine di terabyte, con sistemi enterprise dedicati e ridondanza garantita.
In contesti così complessi, l’alta disponibilità e la replica verso un sito secondario non sono un’opzione, ma un requisito imprescindibile per assicurare la continuità del business. Le prestazioni devono restare stabili anche durante elaborazioni massive, consolidamenti internazionali e analisi in tempo reale, che costituiscono uno dei punti di forza di HANA.
Considerazioni finali
Il messaggio principale è che non esiste un “taglia unica” per SAP S/4HANA. Una piccola impresa può gestire la propria operatività quotidiana con un nodo compatto da 1 TB di RAM, mentre una multinazionale può aver bisogno di un cluster da piu di 12 TB. Tra questi due estremi si colloca una vasta gamma di scenari intermedi, che vanno valutati attentamente caso per caso, si va da hardware consumer ad hardware quasi dedicato per tipo di business.
La scelta finale passerà sicuramente tramite gli strumenti ufficiali come SAP Quick Sizer per stimare CPU, RAM e storage sulla base dei processi effettivamente utilizzati e la compatibilità dei server consultando la SAP HANA Hardware Directory ma poi le scelte finali avverranno man mano che si inizieranno a dimensionare le sandbox e si faranno test massivi simili a produzione per capire la capacità del sistema.
Si tratta di una scienza complessa influenzata da migliaia di fattori, solo con la conoscenza esatta dei processi aziendali, dei loro volumi e tanta esperienza si può avere una buona idea delle capacità di calcolo, memoria e storage di cui si può aver bisogno, impossibile averne un’idea precisa ma l’importante è aver garantito che l’investimento hardware sia allineato alla scalabilità necessaria all’azienda.