Vai al contenuto

Implementazione SAP nel settore pubblico: compliance e rischi

Nel settore pubblico, in SAP la compliance va configurata nel sistema fin dal primo giorno. Rimediarvi dopo il go-live è il modo in cui nascono audit, sforamenti dei costi e titoli di giornale.

Noel D'Costa entra nell'atrio di un edificio governativo
Indice
  1. Perché SAP nel settore pubblico è diverso
  2. I fallimenti di compliance che accadono davvero
  3. Compliance finanziaria
  4. Compliance negli acquisti
  5. Residenza e protezione dei dati
  6. Le sfide di implementazione da pianificare
  7. Rollout a fasi o go-live completo
  8. Le scelte di deployment nel 2026
  9. La residenza dei dati decide il modello di deployment
  10. La Public Edition ha ora un perimetro per il settore pubblico
  11. Che cosa RISE copre e che cosa no
  12. Governo federale USA: SAP NS2
  13. AI e sovranità dei dati
  14. Checklist pre-contrattuale per il cloud nel settore pubblico
  15. Il team di cui ha bisogno
  16. Domande frequenti

Nel settore pubblico, in SAP la compliance va configurata nel sistema fin dal primo workshop di progettazione. Contabilità per fondi e controlli di budget appartengono a Public Sector Management (PSM). La segregazione dei compiti appartiene al disegno dei ruoli. Soglie di acquisto e registri delle gare appartengono al workflow. La residenza dei dati va definita nel contratto prima che qualcuno firmi. Questa guida è per CFO, CIO e direttori di programma di enti governativi e di entità collegate al governo. Tratta i controlli che evitano i rilievi di audit, le scelte di deployment per il 2026 e il team necessario. Usi la tabella dei controlli e la checklist pre-contrattuale qui sotto.

I governi non hanno margine per fallimenti di compliance che emergono in sede di audit. Lavoro su progetti SAP nel settore pubblico da oltre 10 anni e il divario tra «compliance documentata» e «compliance imposta dal sistema» è il più costoso da colmare dopo il go-live.

Ho visto che cosa succede quando la compliance è integrata fin dall'inizio: fa risparmiare tempo agli enti, evita bocciature in audit e rende chiare le responsabilità. Ho lavorato anche a progetti in cui i team hanno saltato i controlli di compliance, pensando di poterli gestire dopo. Mesi più tardi, lacune di sicurezza e violazioni di legge li hanno costretti a tornare indietro, a un costo di milioni.

L'esempio recente meglio documentato non riguarda affatto SAP. Nel 2018 il Birmingham City Council aveva stanziato poco meno di 20 milioni di sterline per sostituire il proprio sistema con Oracle Fusion. Il rapporto di interesse pubblico del 2025 del revisore esterno ha rilevato che il sistema, più il lavoro per correggerlo, sarebbe costato almeno 90 milioni di sterline in più rispetto al budget originale. Il recupero doveva protrarsi fino al 2026. Le cause erano prevedibili. Lo sono quasi sempre, nei fallimenti ERP del settore pubblico.

I consulenti che portano con sé le ipotesi del settore privato creano problemi che emergono tardi, quando sono costosi da risolvere.

Gli acquisti richiedono più tempo. L'approvazione dei fornitori comporta controlli normativi che negli acquisti commerciali non ci sono. Un fornitore approvato in fretta può non superare più tardi una verifica di sicurezza, e questo diventa un problema di progetto. Si pianifichino gli acquisti sul ciclo normativo, non su quello commerciale.

Le strutture di budget sono più complesse. Contabilità per fondi, sovvenzioni e impegni pluriennali richiedono una configurazione di PSM che un'implementazione standard non include. Le agenzie fiscali e delle entrate hanno bisogno anche di Public Sector Collection and Disbursement (PSCD) per le entrate rivolte ai cittadini. Se sbaglia l'una o l'altra, i report finanziari non riflettono la realtà fino all'audit.

I cicli di approvazione sono fissati per legge. Le approvazioni governative non si possono snellire come i workflow commerciali. Li si progetti fin dall'inizio. I workflow che ignorano quei requisiti di legge vengono aggirati e le scappatoie distruggono l'audit trail.

I dati sono più sensibili. I dati dei cittadini, le registrazioni fiscali e le informazioni sui dipendenti comportano obblighi di sovranità. Dove risiedono i dati è un requisito di legge nella maggior parte delle giurisdizioni, non una preferenza tecnica.

Compliance finanziaria

Ogni fallimento comune ha un controllo SAP specifico:

RischioCome si presentaControllo SAP
Spesa dei dipartimenti non tracciataBudget sforati senza visibilità fino alla chiusura mensileGestione dei fondi e controllo di disponibilità del budget in PSM
Audit trail mancantiTransazioni senza uno storico completo delle approvazioniConfigurazione del flusso documenti e passaggi di approvazione obbligatori
Override manuali dei controlliUtenti che aggirano l'approvazione per velocizzare l'elaborazioneProgettazione delle autorizzazioni e applicazione della segregazione dei compiti
Pagamento senza verificaFatture pagate prima dell'entrata merci o dell'approvazioneThree-way match imposto tra MM e FI
Impostazione fiscale errataRegole fiscali degli enti pubblici assenti dal sistemaImpostazione delle giurisdizioni fiscali e configurazione delle aliquote
Lacune nella segregazione dei compitiUna stessa persona crea e approva un pagamentoRevisione del disegno dei ruoli e matrice di segregazione dei compiti

La segregazione dei compiti viene sistematicamente sottovalutata. Se una sola persona può creare un fornitore, emettere un ordine d'acquisto, ricevere le merci e approvare il pagamento, il sistema non ha alcun controllo efficace, per quante regole esistano sulla carta.

Dove stanno i controlli in un pagamento del settore pubblicoLa segregazione dei compiti in un'immagine. Se una sola persona può eseguire ogni passaggio, le regole esistono solo sulla carta.
  1. Creare il fornitorePrima la verifica rispetto ai controlli normativi
  2. Emettere l'ordine d'acquistoIl controllo di disponibilità del budget in PSM blocca gli sforamenti
  3. Ricevere le merciRegistrato in MM rispetto all'ordine
  4. Abbinare la fatturaThree-way match imposto tra MM e FI
  5. Approvare il pagamentoApprovazione obbligatoria da parte di un'altra persona

Pagato, con lo storico completo delle approvazioni nel flusso documenti

Compliance negli acquisti

Gli acquisti pubblici hanno più modi di fallire di quanto la maggior parte dei team si aspetti. Questi cinque ricorrono di continuo.

  1. Approvazione dei fornitori affrettata. Il calendario sembrava stretto, così un fornitore è stato approvato in un giorno. Più tardi lo stesso fornitore non ha rispettato un requisito di sicurezza che era nel contratto fin dall'inizio. La lacuna era nella progettazione del processo, non nel sistema.
  2. Modifiche contrattuali non tracciate. Qualcuno aggiunge una riga di servizio e i responsabili di budget la approvano in fretta. Sei mesi dopo nessuno sa dire quando è cambiato il perimetro né chi l'ha autorizzato. Il rilievo di audit arriva di conseguenza.
  3. Spesa anticipata rispetto all'autorizzazione del budget. I team impegnano la spesa aspettandosi che i fondi arrivino. La finanza respinge la fattura, il fornitore sospende il lavoro e iniziano le spiegazioni.
  4. Registri di gara incompleti. I revisori vogliono la traccia completa delle valutazioni delle offerte e delle decisioni di aggiudicazione. Se sta nelle e-mail e non in SAP, chiederanno perché. Una volta ho passato una settimana a ricostruire le evidenze di gara mancanti, e non è lì che dovrebbe andare il tempo a metà implementazione.
  5. Soglie aggirate. Gli utenti trovano modi per eludere i limiti di approvazione pensati per far scattare una revisione. Ogni scorciatoia fa risparmiare un giorno e crea un vero rischio di compliance.

Per vedere come questo si traduce in un sistema di acquisti governativo, consulti le mie note su SAP Ariba nel settore pubblico degli EAU.

Residenza e protezione dei dati

I fornitori cloud ospitano i dati in più regioni. Se l'hosting non viene verificato sia a livello contrattuale sia tecnico, i dati governativi possono finire fuori dal paese senza che nessuno se ne accorga, e l'ufficio legale lo scopre nel momento peggiore. Le lacune ricorrenti sono sedi di hosting poco chiare, crittografia parziale o configurata male, accessi amministrativi concessi in modo ampio per comodità, regole di conservazione che si discostano e backup governati meno rigorosamente dei sistemi in produzione. Dare per scontato che se ne occupi qualcun altro è il modo in cui nascono i problemi di sovranità. Si nomini un responsabile, lo si mappi in fase di progettazione e lo si testi prima del go-live.

Queste sono le aree in cui il perimetro del settore pubblico si discosta da un programma commerciale:

Area di sfidaChe cosa richiede
Strutture di budget complessePSM per la contabilità per fondi, le sovvenzioni e il controllo di budget pluriennale
Riscossione di imposte ed entratePSCD per crediti verso i cittadini, rimborsi e riscossioni
Normativa sugli acquistiWorkflow per catene di approvazione fisse e registri degli acquisti tracciabili
Integrazione con i sistemi legacyMigrazione da piattaforme sviluppate su misura e interfacce affidabili
Regole sindacali e di payrollPayroll che rifletta i contratti collettivi e le retribuzioni specifiche dei sindacati
Servizi rivolti ai cittadiniIntegrazione con la gestione delle pratiche e controlli sulla privacy dei dati dei cittadini
Processi multi-enteSAP Central Finance per strutture finanziarie condivise tra i dipartimenti
Documentazione di auditArchiviazione, storico delle approvazioni e registri di gara che i revisori possano recuperare

I progetti governativi raramente falliscono per colpa del software. Falliscono quando il perimetro supera la capacità dell'organizzazione di assorbire il cambiamento, o quando i requisiti di compliance vengono scoperti dopo il go-live.

Procedere a fasi riduce il rischio di ogni singolo go-live. Prima finanza e acquisti, perché hanno il maggior peso in termini di compliance. Payroll e HR quando la contabilità di base è stabile. Poi i servizi rivolti ai cittadini. Il go-live completo funziona solo quando la pianificazione è completa, i requisiti di compliance sono stati documentati prima della configurazione, il team interno ha capacità e i dati sono puliti. Questa combinazione nella pubblica amministrazione è rara. Quando manca, la strada a fasi è più sicura. La mia guida alle strategie di implementazione confronta i modelli più nel dettaglio.

La compliance non è una fase. È il fondamento. Ho visto progetti trattare la compliance come una voce di checklist vicino al go-live. Ognuno di loro ha poi avuto una conversazione costosa con i revisori.

La residenza dei dati decide il modello di deployment

Per gli acquirenti del settore pubblico, la strategia di rollout e di migrazione viene dopo la scelta di deployment, e questa scelta è guidata dalla residenza dei dati.

Se i dati dei cittadini devono restare nel paese e SAP può dimostrare un hosting verificato nel paese con le autorizzazioni giuste, RISE with SAP su S/4HANA Cloud Private Edition è l'opzione più solida. Sposta l'infrastruttura su SAP, il che aiuta gli enti con team Basis interni ridotti. Se non si può dimostrare l'hosting nel paese, l'on-premise o un partner di sovereign cloud restano la risposta più sicura, nonostante il carico operativo.

La Public Edition ha ora un perimetro per il settore pubblico

SAP ora rilascia funzioni per il settore pubblico in S/4HANA Cloud Public Edition. Il suo scope bundle per PSM copre gestione del budget, sovvenzioni, fondi vincolati e controllo di disponibilità, e SAP lo sta rilasciando paese per paese nel corso del 2025 e del 2026. Per un ente che parte in greenfield con processi standard, elimina molto lavoro di base. Non elimina la progettazione specifica della giurisdizione: piano dei conti, strutture fiscali e regole di budget. L'indicazione della stessa SAP è che fornisce i principi contabili locali (local GAAP) di ciascun paese e non include un principio contabile IPSAS dedicato, quindi si pianifichi la mappatura IPSAS come parte della progettazione.

Che cosa RISE copre e che cosa no

L'errore più comune con RISE nel settore pubblico è presumere che SAP intercetti tutti i problemi di compliance perché gestisce l'infrastruttura. SAP copre la compliance dell'infrastruttura: hosting, crittografia, disponibilità della piattaforma. Non copre la segregazione dei compiti, le interfacce progettate male né le lacune nella documentazione di gara. Di queste restano responsabili l'ente e il suo partner.

La pressione verso la personalizzazione è spesso alta nella pubblica amministrazione. Si inserisca nella struttura di governance un forum di revisione delle estensioni, in modo che ogni lacuna riceva una decisione registrata: configurare, estendere tramite API rilasciate o respingere.

Governo federale USA: SAP NS2

Non ho guidato programmi del governo federale USA, quindi questo è solo un commento basato su fonti pubbliche. I carichi di lavoro cloud federali e della difesa degli Stati Uniti passano per SAP National Security Services (SAP NS2), la controllata statunitense separata di SAP, che eroga S/4HANA Cloud Private Edition con operazioni e personale esclusivamente statunitensi. Nel 2025 la DISA le ha concesso un'autorizzazione provvisoria per S/4HANA Cloud Private Edition e SAP BTP al FedRAMP+ Impact Level 5. A ottobre 2025 SAP è entrata nel marketplace FM QSMO del Tesoro statunitense per la gestione finanziaria federale. I partner di questi programmi devono avere autorizzazioni corrispondenti e personale con nulla osta di sicurezza, il che restringe drasticamente la rosa dei candidati.

AI e sovranità dei dati

Le funzioni di AI che si basano su modelli ospitati nel cloud o su infrastrutture condivise possono entrare in conflitto con le regole che impediscono ai dati dei cittadini di lasciare il paese o di essere elaborati su piattaforme condivise.

La linea pratica: l'AI usata dal team di implementazione sul materiale di progetto (bozze di requisiti in SAP Cloud ALM, riepiloghi di riunioni in Copilot, registri delle decisioni in Confluence) di solito va bene, purché non vi passino dati dei cittadini. L'AI che elabora in tempo reale dati sovrani dei cittadini, come l'instradamento automatico delle pratiche o l'analisi predittiva sulle registrazioni fiscali, richiede una verifica esplicita della residenza dei dati prima del rilascio. Alcune funzioni non sono affatto disponibili nelle configurazioni sovrane. La demo del fornitore non segnalerà il conflitto. La revisione legale, mesi dopo, lo farà.

Checklist pre-contrattuale per il cloud nel settore pubblico

Si confermi ciascuno di questi punti per iscritto prima della firma:

  1. La regione di hosting per produzione, ambienti non produttivi e disaster recovery
  2. Le restrizioni sull'instradamento transfrontaliero dei dati, anche per gli accessi di supporto
  3. La crittografia dei dati a riposo e in transito, e chi detiene le chiavi
  4. Dove sono conservati i backup e come sono governati
  5. Quale personale del fornitore può accedere al sistema, da quali paesi e come vengono registrati gli accessi
  6. Quali funzioni di AI sono incluse, dove elaborano i dati e se possono essere disattivate
  7. Le condizioni di restituzione e cancellazione dei dati a fine contratto

Consulenti con esperienza nel settore pubblico. Contabilità per fondi, sovvenzioni, acquisti governativi e riscossione delle entrate sono ambiti specifici. I consulenti con sola esperienza SAP commerciale applicano modelli di progettazione sbagliati.

Responsabili finanziari che conoscono la contabilità pubblica. IPSAS, contabilità per fondi e budget pluriennali non sono la contabilità finanziaria (FI) commerciale standard. I Suoi rappresentanti del business devono conoscere la differenza. La mia guida a SAP FICO tratta la base commerciale che dovranno adattare.

Compliance e ufficio legale al tavolo fin dal primo giorno. Nei workshop di progettazione, non consultati alla fine. Le decisioni di compliance prese nel blueprint costano meno di quelle prese dopo il go-live.

Data owner nominati. Una persona ciascuno per i dati dei cittadini, dei fornitori, finanziari e dei dipendenti, con l'autorità di decidere e la responsabilità della qualità.

La compliance imposta dal sistema supera l'audit. La compliance scritta nelle policy e aggirata nella pratica no.

Che cosa distingue l'implementazione SAP nel settore pubblico da quella commerciale?

Tre cose: struttura contabile, regole sugli acquisti e governance dei dati.

La contabilità pubblica traccia entrate e spese rispetto a fondi, sovvenzioni ed esercizi di bilancio, il che richiede PSM, più PSCD per le agenzie delle entrate. Gli acquisti pubblici seguono quadri normativi che impongono trasparenza, gare competitive e catene di approvazione fisse. I dati dei cittadini, le registrazioni fiscali e le informazioni sui dipendenti comportano requisiti di sovranità che stabiliscono dove e come il sistema può essere ospitato.

Quali sono i fallimenti di compliance più comuni in SAP nel settore pubblico?

Quattro causano la maggior parte dei rilievi di audit: lacune nella segregazione dei compiti, audit trail mancanti, violazioni della residenza dei dati e documentazione degli acquisti conservata nelle e-mail invece che nel sistema. Ognuno è un problema di progettazione che configurazione e processo possono prevenire, e ognuno costa molto di più da correggere dopo il go-live.

Che cos'è SAP PSM e quando serve?

SAP Public Sector Management (PSM) copre la contabilità pubblica che la contabilità finanziaria standard (FI) non copre: contabilità per fondi, gestione delle sovvenzioni, controllo di disponibilità del budget che blocca la spesa oltre il budget autorizzato e impegni pluriennali con regole di riporto.

Serve a ogni ente con budget per fondi, finanziamenti tramite sovvenzioni o programmi di investimento pluriennali. Le agenzie delle entrate e fiscali hanno bisogno anche di PSCD per crediti verso i cittadini, rimborsi e riscossioni. Si progettino il piano dei conti, la struttura dei fondi e le regole di budget in base ai principi contabili che si applicano alla Sua organizzazione.

Come si dovrebbe gestire la residenza dei dati in un'implementazione SAP cloud nel settore pubblico?

La si verifichi e la si documenti prima della firma del contratto. Il contratto dovrebbe indicare le regioni dei data center, limitare l'instradamento transfrontaliero, coprire i backup e definire quale personale del fornitore può accedere al sistema e da dove.

Poi la si testi tecnicamente: si confermi la regione di hosting, si convalidi la crittografia dei dati a riposo e in transito e si limitino gli accessi amministrativi a persone nominate nella giurisdizione corretta. Scoprire un problema di residenza dopo il go-live è costoso e pubblico.

Che cos'è RISE with SAP per il settore pubblico?

RISE with SAP è l'offerta in sottoscrizione di SAP, di solito su S/4HANA Cloud Private Edition, con SAP che gestisce infrastruttura e operazioni tecniche. È adatta agli enti in cui SAP può dimostrare un hosting verificato nel paese con le autorizzazioni giuste, e aiuta quelli con team Basis interni ridotti.

Non rende SAP responsabile della compliance applicativa o di processo. Segregazione dei compiti, workflow e registri di gara restano all'ente e al suo partner. Negli Stati Uniti, i carichi di lavoro cloud federali e della difesa passano invece per SAP NS2.

Un'implementazione SAP nel settore pubblico dovrebbe essere a fasi o tutta insieme?

A fasi, per la maggior parte delle organizzazioni del settore pubblico. La capacità di gestire il cambiamento è limitata, i requisiti di compliance spesso emergono progressivamente e un fallimento di compliance dopo il go-live completo costa più di uno scoperto in una prima fase limitata.

Di solito vanno per prime finanza e acquisti, poi payroll e HR, poi i servizi rivolti ai cittadini. Il go-live completo può funzionare quando pianificazione, dati, capacità del team e documentazione di compliance sono tutti pronti prima della configurazione. È raro.

Come si presenta la preparazione all'audit dopo il go-live in SAP nel settore pubblico?

In un sistema ben implementato, la preparazione all'audit diventa generazione di report. Gli storici delle approvazioni stanno nel flusso documenti, i registri di gara nei documenti d'acquisto e il consumo di budget in PSM.

Questo vale solo se i dati sono stati mantenuti correttamente. I workflow aggirati lasciano buchi nella traccia e i registri di gara tenuti fuori dal sistema non possono essere prodotti da esso. La prontezza all'audit è tanto disciplina di processo quanto configurazione.

Noel D'Costa

Scritto da

Noel D'Costa

25 anni di programmi ERP SAP e Oracle nei settori aviazione, pubblica amministrazione, finanza, retail e manifatturiero. Formazione in finanza. Aiuto i team di leadership a definire con onestà il perimetro delle trasformazioni, a recuperare i programmi in difficoltà e a costruire sistemi che superano il primo anno in produzione.

Il prossimo passo

Sta gestendo un programma ERP in questo momento?

Se questo articolo tocca un programma che sta seguendo in questo momento, una conversazione di 30 minuti di solito porta più lontano di un'altra settimana di analisi interna.