Come gestire ciò che esce dal ticket ordinario — attacchi, disaster recovery, renew infrastrutturali, ammodernamenti, nuovi strumenti. Due nature opposte sotto un'apparenza sola: contenere ORA un'emergenza, o consegnare NEL TEMPO un cambiamento pianificato. La risposta sbagliata fa danni.
"Eventi e progetti straordinari" sono due nature opposte travestite da una sola. Confonderle è l'errore più costoso: gestire un'emergenza con la calma di un progetto è troppo lento; gestire un progetto con l'ansia di un ticket SLA è il caos. Una sola domanda smista tutto.
Ticket, ma con processo elevato. Velocità, comando unico, comunicazione serrata. Misurato in ore.
Modulo progetti. Fasi, milestone, preventivo, risorse. Misurato in settimane/mesi.
Gli stessi casi che hai citato, ciascuno al posto giusto. Nota come lo stesso tema (DR, cyber) cambia natura a seconda che sia in corso o da costruire.
| Caso straordinario | Natura | Dove vive |
|---|---|---|
| Attacco informatico in corso | Emergenza da contenere ora | Major Incident + catena cyber (NIS2, CISO) |
| Attivazione DR reale (disastro) | Emergenza da contenere ora | Major Incident + runbook DR |
| Hardening post-attacco | Cambiamento pianificato | Progetto (generato dall'incident) |
| Setup / piano DR | Cambiamento pianificato | Progetto + documentazione |
| Renew infrastruttura | Cambiamento pianificato | Progetto |
| Ammodernamento / config innovate | Cambiamento pianificato | Progetto |
| Inserimento nuovo strumento | Cambiamento pianificato | Progetto (spesso cross-brand) |
| Sostituzione/aggiunta postazione | Richiesta discreta | Ticket (IMAC) — non è straordinario |
Un Major Incident resta un ticket — ma con un processo che la normale gestione non ha. Si dichiara, ha un comandante unico, una comunicazione serrata, e si chiude con una revisione che spesso genera un progetto.
Renew, ammodernamenti, nuovi strumenti, setup DR: vivono nel modulo progetti di SuperOps, non come ticket giganti. Hanno fasi, milestone, risorse, un preventivo e un proprio orologio — fatto di traguardi, non di SLA.
Ticket, incident e progetti non sono compartimenti stagni: si generano a vicenda. Riconoscere questi passaggi è ciò che tiene lo storico intatto e trasforma un problema in crescita.
Dall'emergenza al rafforzamento. L'attacco si contiene come incident; a freddo, l'hardening per non rivederlo mai più diventa un progetto. La revisione post-incidente è l'innesco.
Dal piano all'esecuzione. Il progetto genera i ticket di lavoro: ciascuno eseguibile e tracciato, ma sotto il cappello del progetto. La cartella e i suoi file.
Dalla domanda al cross-sell. Un segnale ecosistema che cresce (parco da rinnovare, nuovo strumento, lacuna di processo) diventa un progetto — e fa salire il cliente nella scala di maturità. Il radar realizzato.
Il progetto è dove l'ecosistema si materializza. Un "nuovo strumento" tira dentro PRAGMA (soluzione gestita), MANA (adozione e formazione delle persone), OMEGAtech (hardware). Un progetto, più brand, più valore.
L'errore che rovina i margini: mettere un progetto sotto l'SLA del contratto ricorrente. Significherebbe doverlo consegnare in 4 ore. Ognuno dei tre ha il suo orologio e il suo modo di fatturare.
| Tipo | Orologio | Contratto / fatturazione |
|---|---|---|
| Ticket ordinario Ticket | SLA standard (P1-P4) | Ricorrente · già incluso |
| Major Incident Incident | Risposta emergenza elevata | Relazione · P1 emergenza o monte ore. Se fuori contratto → extra |
| Progetto Progetto | Milestone, non SLA | One-time o T&M dedicato · fattura a tappe |
copertura del ticketing qui dice "Fuori contratto → Progetto". OMEGAtech in Art.57: non usare come entità di fatturazione per strumenti condivisi.Emergenza e progetto chiedono leadership diverse: una di comando rapido, una di coordinamento nel tempo. Entrambe poggiano sul team che già hai.
Sette modi di sbagliare emergenze e progetti, e il guardrail. Sezione interna.
Un renew di 3 mesi aperto come ticket → panico SLA, nessuna milestone, nessuna fatturazione a tappe, caos.
Un attacco gestito come P1 qualsiasi → nessun commander, nessuna war room, cliente nel panico senza aggiornamenti.
Obbligo impossibile di consegnare un progetto "entro l'SLA", e lavoro extra fatturato come incluso. Margine bruciato.
Tutti decidono, quindi nessuno decide. Si discute mentre il sistema brucia.
Scope creep infinito: si aggiunge "solo un'altra cosa" finché il progetto non finisce e non si fattura.
Nel momento peggiore si improvvisa perché il runbook non c'è o non è stato provato.
Contenuta l'emergenza, si torna alla normalità senza l'hardening → l'attacco ritorna.