← Hub
Anti-complessità · SuperOps · Unified Secure IT

Aggiungi solo
ciò che cambia un'azione.

Quali campi attivano catene che valgono davvero, e quali sotto-livelli sono solo precisione-vanità da non costruire. Un documento volutamente corto — perché predica la sottrazione: la precisione che non cambia un'azione non è qualità, è zavorra.

Una sola regola di filtro
9 catene che si meritano l'esistenza
3 sole sotto-cause
Massima automazione, minimo attrito
01 · La regola

Un solo filtro per ogni campo

Il fallimento da "troppa precisione" nasce sempre dallo stesso errore: aggiungere distinzioni che sembrano utili ma non cambiano nulla di concreto. L'antidoto è una domanda da farsi prima di creare qualsiasi campo, valore o sotto-livello.

"Questa distinzione cambia un'azione, un'assegnazione, un SLA o una riga fatturabile?"
Se no → è precisione-vanità → non si costruisce
Il ribaltamento mentale. In passato il principio era "tracciamo tutto, un giorno servirà". Il nuovo principio è l'opposto: si parte minimi e si aggiunge solo quando la realtà lo chiede — non prima, per paura. Aggiungere un valore dopo costa un minuto. Smontare una tassonomia che tutti già odiano costa mesi e fiducia. Nel dubbio: non aggiungere.
02 · Le catene

Cosa attiva cosa — e perché vale

Sì, alcuni campi attivano altri in catena. Ma ognuna di queste nove catene supera il test: ognuna cambia un'azione reale, e quasi tutte a costo umano zero perché le esegue il sistema.

impatto×urgenzaprioritàSLA

La catena d'oro. Due tendine all'apertura, il resto è automatico. Zero attrito, massima resa.

Cambia: priorità · SLA · escalation
tipo = SR/Changemostra imac_code

Progressive disclosure. Il campo IMAC appare solo quando ha senso. Su un Incident non esiste nemmeno: niente da scegliere, niente da sbagliare.

Cambia: quale campo è visibile
categoriateam di dispatch

Assegnazione automatica. Rete/Postazione/Stampa → L1; Server/Cloud/Sicurezza → L2-3; Gestionale → coda Dylog. Nessun dispatch manuale sui casi standard.

Cambia: assegnazione
categoria = Sicurezzaclock NIS2 + CISO + runbook

Un campo, una catena. La sicurezza fa scattare la risposta, il cronometro di notifica e l'allerta — non un semplice dispatch.

Cambia: azione · obbligo di legge · SLA
causa = Competenzasuggerisce segnale MANA

Il radar che si auto-innesca. Quando la causa ricorrente è "competenza", il sistema propone il segnale verso MANAzone. Demand-sensing dai dati.

Cambia: opportunità commerciale
segnale ≠ Nessunolead collegato al commerciale

Cross-sell senza attrito. Il segnale genera un lead linkato (non muta il ticket) e lo gira a chi vende. Il tecnico segnala, non vende.

Cambia: pipeline · riga fatturabile futura
stato = pausaferma orologio SLA

La protezione dai tempi non tuoi. Attesa fornitore/cliente/LAB ferma il clock. Non vieni penalizzato per ciò che non controlli.

Cambia: SLA
brandtemplate TOV + firma

Voce coerente, gestione unica. Il brand (ereditato dalla mailbox) sceglie il tono di risposta. Zero scelta manuale.

Cambia: comunicazione
contrattocopertura(se Extra) notifica SPOC

Margine protetto. Il sistema sa cosa è incluso. Se è extra, avvisa prima che parta lavoro non coperto.

Cambia: riga fatturabile
03 · Si merita / si taglia

Le sotto-distinzioni: 3 sì, il resto no

Qui rispondo diretto alla tua domanda sulle sotto-cause e sotto-categorie. La maggior parte è zavorra. Solo poche cambiano un'azione — e sono le uniche che costruiamo.

✓ Si merita l'esistenza
  • Sotto-causa di Competenza
    → quale ambito (M365 / Sicurezza / Gestionale / AI). Determina il tipo di offerta MANA.
  • Sotto-causa di Fornitore
    → quale fornitore + peso sul nostro sistema. Determina l'esclusione SLA, l'affidabilità vendor e quanto ci sovraccarica.
  • Sotto-causa di Bene a fine-vita
    → hardware, software, accessori o forniture: guasto vs fine-vita/fine-supporto. Il fine-vita attiva il radar OMEGAtech.
  • Sotto-categoria di Gestionale
    → quale gestionale. Cambia il partner/referente (Dylog vs altro).
✕ Si taglia (precisione-vanità)
  • Sotto-cause delle altre 5 cause
    Errore utente, Config, Software, Rete, Sicurezza: la causa basta, il dettaglio non cambia azione.
  • Alberi di rete profondi
    Rete > Switch > VLAN > Trunk: bellissimi, inutili. Nessuna azione cambia.
  • Sotto-categorie "per completezza"
    Postazione > Desktop > marca > modello: ce l'ha già l'inventario asset.
  • Resolution code troppo fini
    Bastano 7 codici netti. Venti codoni sfumati = nessuno sceglie giusto.
CausaSotto-causa?Perché
CompetenzaDetermina il tipo di offerta MANA (radar)
FornitoreEsclusione SLA + affidabilità vendor + peso/sovraccarico sul nostro sistema (posizionamento)
Bene a fine-vitaHardware/software/accessori/forniture: fine-vita → radar OMEGAtech
Errore utenteNoLa causa basta · nessuna azione diversa
ConfigNoSta nella soluzione, non serve sotto-livello
SoftwareNoIl resolution code dice già abbastanza
ReteNoIl dettaglio è nella nota, non in un campo
SicurezzaNoAttiva già la catena cyber, non serve altro
Tre sotto-cause, una sotto-categoria. Tutto qui. E nota: tutte e tre le sotto-cause "che si meritano" esistono perché alimentano il radar o l'SLA — cioè cambiano denaro o impegno. Non per descrivere meglio: per decidere meglio.
Il 4° livello fornitore: non solo esclusione SLA, ma posizionamento. Tracciare il peso del fornitore fa tre cose insieme: (1) misura quanto il loro lavoro ci sovraccarica — un costo nascosto che oggi non vedi; (2) rende visibile la nostra centralità — siamo noi a dare voce tecnica al cliente che col fornitore non saprebbe parlare, a fare escalation e solleciti; (3) separa nettamente la nostra responsabilità da quella del fornitore, così un ritardo del vendor non viene percepito come nostro. È "IT senza IT" con un confine: traduciamo tutto, ma tracciamo cosa è nostro e cosa no. Il dato diventa anche argomento di valore in QBR e in fase di rinnovo.
04 · Massima automazione

Sette leve per ridurre l'impatto di gestione

Automatizzare al massimo non significa più regole: significa che l'umano tocca il sistema il meno possibile, e quando lo tocca sceglie da liste corte. Sette leve, in ordine di resa.

1

Deriva, non chiedere

Brand, canale, priorità, copertura: il sistema li sa già. Mai chiedere ciò che si può dedurre.

2

Mostra solo nel contesto

IMAC, sotto-causa, segnale appaiono solo quando servono. Progressive disclosure: niente campi inutili davanti agli occhi.

3

RMM pre-compila

L'alert genera il ticket già categorizzato e prioritizzato. Il problema è in coda prima della chiamata.

4

Liste corte, mai scroll

Max 7-9 valori per tendina. Se devi scorrere, hai troppe opzioni e sceglierai male.

5

Obbligatorio solo dove conta

Causa e resolution obbligatori sui P1-P2 e ricorrenti, non su ogni P4. Il dato dove serve, non ovunque.

6

Default intelligenti

Categoria probabile da parole chiave, priorità media di default. Il tecnico conferma o corregge, non compila da zero.

7

Una schermata d'apertura

Quattro campi, una vista. Tutto il resto arriva dopo, nel flusso. Aprire un ticket è questione di secondi.

Il principio sotto le leve. L'impatto di gestione si riduce spostando il lavoro dall'umano al sistema e dall'apertura al contesto giusto. Ogni leva fa una delle due cose. Insieme, rendono la macchina potente e leggera — mai ingessata.
05 · Pre-mortem · la trappola della precisione

I sette modi in cui la precisione uccide

Questo pre-mortem è il tuo, Simo — sui fallimenti che hai già vissuto. Riconoscerli è metà della cura. Ognuno ha lo stesso antidoto: la regola del §01.

1

La tassonomia infinita

Categorie su categorie finché nessuno le rispetta → i dati diventano peggiori di quando non c'erano, perché ora sono anche falsi.

2

Obbligatorio ovunque

Campi obbligatori dappertutto → i tecnici scelgono a caso pur di chiudere. Hai precisione apparente e dati spazzatura.

3

Sotto-livelli che non decidono nulla

Distinzioni elegantissime che non cambiano un'azione → tempo speso a categorizzare, zero valore estratto.

4

"Un giorno servirà"

Si costruisce per un futuro che non arriva → complessità oggi, certa, per un beneficio domani, ipotetico.

5

La precisione rallenta l'ingresso

Aprire un ticket diventa un modulo → si smette di aprirli, o si aprono male. La precisione uccide il dato che voleva catturare.

6

Automazioni intrecciate

Regole su regole che si attivano a vicenda → nessuno le capisce più → si disattiva tutto per paura. Fine dell'automazione.

7

Si misura tutto, non si decide niente

Cento metriche → paralisi da dati. Pochi numeri che cambiano decisioni valgono più di mille che decorano un cruscotto.

L'antidoto unico. Tutti e sette nascono dallo stesso istinto — "di più è meglio" — e si curano con la stessa regola: aggiungi solo ciò che cambia un'azione, e nel dubbio non aggiungere. La complessità si toglie prima di metterla, perché dopo non la toglie più nessuno. Forte non è chi prevede tutto: è chi tiene il sistema così snello da poterlo cambiare domani.
06 · Il verdetto

Cosa costruiamo, cosa no

La sintesi che porti nell'istanza. Numeri piccoli, di proposito.

Il sistema, in cifre
4

campi manuali all'apertura

9

catene automatiche che si meritano l'esistenza

3+1

sole sotto-cause + 1 sotto-categoria

Cosa NON costruiamo (e va benissimo così). Niente alberi di rete profondi. Niente sotto-cause sulle 5 cause che non cambiano azione. Niente sotto-categorie già coperte dall'inventario. Niente campi obbligatori sui P4. Niente metriche che non guidano una decisione. Tutto questo resta fuori, per scelta — e si aggiunge solo il giorno in cui la realtà, non la paura, lo chiederà.
Prossimo passo. Questa è la specifica anti-complessità. Da qui, nell'istanza: configurare le 4 tendine d'apertura con liste corte, le 9 catene come Event/Time Trigger, le 3 sotto-cause condizionali. Poi si misura un trimestre e — solo se i dati lo chiedono — si aggiunge. Mai prima. Quando vuoi, pratichiamo con la prima catena: impatto × urgenza → priorità.