In molte organizzazioni l’AMS viene ancora trattato come un “servizio di supporto”: arriva una richiesta, si apre un ticket, si risolve, si chiude. È un’impostazione comprensibile, soprattutto quando la priorità è garantire continuità operativa.
Il punto è che, in un landscape SAP moderno (ECC, S/4HANA, integrazioni, Fiori, cloud), questo approccio non regge a lungo. Non perché l’AMS “non funzioni”, ma perché il sistema evolve continuamente: release, cambiamenti di processo, nuove integrazioni, nuove esigenze del business. Se l’AMS resta solo un meccanismo di risposta, diventa inevitabilmente reattivo, costoso e difficile da governare.
un AMS SAP efficace è un modello operativo che governa il ciclo di vita del sistema in esercizio, non solo la gestione dei ticket.
Il problema strutturale: quando il post go‑live diventa un “progetto infinito”
La dinamica tipica è nota: dopo il go‑live il sistema “sta in piedi”, ma iniziano a comparire anomalie, richieste di evoluzione, eccezioni operative. Se non esiste una distinzione netta tra incidente, change e miglioramento, e se non ci sono regole di priorità condivise, l’AMS assorbe tutto.
Nel tempo questo porta a tre effetti concreti:
Questa non è una “questione organizzativa generica”: è un tema di metodo e di controllo.
SAP non tratta l’operatività come un “dopo” informale. Nella metodologia SAP Activate, la gestione del ciclo di vita è esplicitata attraverso workstream dedicati: tra questi ci sono Operations and Support (IT operations e processi di end‑user support) e, nel project management, la definizione di governance, standard e processi di incident e change.
In altre parole: SAP formalizza che, per rendere sostenibile il valore di S/4HANA (e dell’ecosistema), non basta “implementare bene”. Serve che la fase di esercizio sia governata con processi chiari, ruoli e standard.
Questo si collega anche ai modelli di governance consigliati da SAP Activate: strutture multilivello (decisioni, escalation, responsabilità) e organismi che evitano derive fuori standard durante e dopo il progetto.
Quando si passa da AMS reattivo a AMS strutturato, il primo requisito è la visibilità: cosa sta succedendo nei processi, nelle integrazioni, nell’esperienza utente, nei job, nei servizi.
SAP inquadra questo bisogno in modo diretto con SAP Cloud ALM for Operations, descrivendolo come piattaforma per garantire continuità operativa tramite full‑stack monitoring e alerting, root‑cause analysis (tecnica e di processo) e automazione di task operativi, con attenzione alla collaborazione tra Line of Business e IT.
Il messaggio, qui, è molto pratico: l’AMS non è solo “persone che risolvono”, ma un insieme di processi + strumenti che rendono misurabile e governabile l’esercizio.
Per un CIO (e per chi decide il fornitore), la domanda reale non è “quante risorse servono in AMS”. È:
A livello operativo, anche nelle offerte AMS ben strutturate si vede che i pilastri ricorrenti sono: service management, incident e change management, monitoraggio e gestione reattiva, modelli di escalation e strumenti di supporto.
(Non è “marketing”: è il riflesso di come un AMS deve funzionare se vuole essere sostenibile.)
Se c’è un punto che vale la pena portarsi a casa è questo: nei contesti SAP complessi, l’AMS è parte della governance. Non un’attività di back‑office.
Un AMS reattivo può tenere in piedi l’operatività nel breve.
Un AMS strutturato, invece, protegge nel tempo tre asset che interessano direttamente CIO e business: affidabilità, costi e capacità di evoluzione.
La domanda utile, quindi, non è “abbiamo un AMS?”.
È: abbiamo un modello di AMS che governa davvero il sistema in esercizio?