IT Governance Operating Model — Gonzato Group / Ind.i.a SpA
Pacchetto onboarding IT Gonzato · Fase P3 · Head of IT · v1 03/07/2026 · bozza da compilare in azienda
Scopo del documento
Descrive come funziona la governance IT nel quotidiano: i comitati, le cadenze decisionali e il flusso di richieste e change a livello di board IT. Traduce il mandato del charter e le responsabilità della RACI in un meccanismo operativo ripetibile.
Serve a sostituire le decisioni informali e ad-hoc con un ritmo strutturato, condiviso e trasferibile — abilitando coordinamento cross-società e crescita, senza appesantire l'operatività.
Comitati e forum
| Forum | Missione | Partecipanti | Cadenza | Output |
|---|---|---|---|---|
| IT Steering (board IT) | Indirizzo strategico, priorità, budget | Direzione, Resp. IT Gruppo, [da compilare] | Trimestrale | Decisioni strategiche, roadmap |
| IT Operations Review | Stato operativo, incidenti, change, rischio | Resp. IT Gruppo, team IT, referenti sede | Mensile | Azioni, escalation |
| Change Advisory (CAB light) | Approvazione change rilevanti | Resp. IT Gruppo, referenti tecnici | Su richiesta / bisettimanale | Change approvati/respinti |
| Security & Risk review | Rischio cyber, incidenti, NIS 2 | Resp. IT Gruppo, referente sicurezza, DPO | Trimestrale | Registro rischi aggiornato |
[da compilare: adattare cadenze e partecipanti alla realtà Gonzato dopo i primi mesi]
Cadenze decisionali
- Operative (quotidiane): gestite dal team IT entro le deleghe RACI, senza forum.
- Tattiche (settimanali/mensili): portate all'IT Operations Review.
- Change rilevanti: passano dal Change Advisory prima dell'implementazione.
- Strategiche / budget: portate all'IT Steering trimestrale; oltre soglia di spesa vanno al CdA (rif. charter).
Flusso richieste e change
Richiesta (utente / società / fornitore)
│
Intake registrato (canale unico)
│
Triage (Resp. IT Gruppo / referente)
│
┌──────┴───────┐
Operativa Rilevante / rischiosa
│ │
Team IT Change Advisory → approvazione
│ │
Esecuzione Esecuzione pianificata
│ │
Chiusura + registrazione + comunicazione- Canale di intake unico: [da compilare: strumento/ticketing o casella dedicata] per evitare richieste "a voce" non tracciate.
- Criteri di rilevanza change (esempio da tarare): impatto su più società · sistemi critici · dati clienti · spesa oltre soglia · rischio sicurezza.
- Registrazione: ogni decisione e change registrato per audit e trasferibilità del know-how.
Escalation
| Livello | Trigger | A chi |
|---|---|---|
| L1 | Richiesta operativa standard | Team IT |
| L2 | Change rilevante / rischio medio | Resp. IT Gruppo (via Change Advisory) |
| L3 | Incidente maggiore / spesa oltre soglia / impatto strategico | Direzione / CdA |
KPI di governance (starter)
| KPI | Descrizione | Target |
|---|---|---|
| % change tracciati | Change passati dal flusso formale | [da compilare] |
| Tempo medio triage richieste | Dalla ricezione all'assegnazione | [da compilare] |
| Incidenti con root cause documentata | Copertura post-incident | [da compilare] |
| Policy approvate vs pianificate | Avanzamento corpus (rif. index) | [da compilare] |
Principio di adozione
Il modello parte leggero e cresce con la maturità del Gruppo: meglio poche cadenze rispettate che molti forum ignorati. Il team IT è coinvolto come co-progettista del flusso, così che il modello rifletta l'operatività reale e non un ideale astratto.
Approvazione e revisione
| Ruolo | Nome | Firma | Data |
|---|---|---|---|
| Direzione | Dario Gonzato | ||
| Responsabile IT di Gruppo | [da compilare] | ||
| Referente team IT | [da compilare] |
Revisione dopo i primi 3-6 mesi di adozione, poi annuale. Owner: Responsabile IT di Gruppo.