AMS SAP: perché “gestire i ticket” non basta
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:
- Governance IT frammentata: decisioni prese per urgenza, con ownership poco chiara.
- Costi in crescita: più interventi spot, più rework, più attività non pianificate.
- Affidabilità che si erode: le eccezioni diventano normalità e il sistema perde prevedibilità.
Questa non è una “questione organizzativa generica”: è un tema di metodo e di controllo.
Come SAP inquadra il tema: operations & support come parte della metodologia
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.
Strumenti SAP coerenti con un AMS strutturato: visibilità, monitoraggio, service management
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.
Impatto per il Business: perché è una decisione di modello (non di staffing)
Per un CIO (e per chi decide il fornitore), la domanda reale non è “quante risorse servono in AMS”. È:
- chi decide le priorità (IT vs business, e con quali criteri)
- cosa rientra nel perimetro AMS e cosa è progetto/evolutiva
- come si governa il cambiamento senza trasformare ogni ticket in una micro‑eccezione
- come si misura la qualità del servizio (non solo tempi di risposta)
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.)
Chiusura: da back‑office a governance del sistema
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?