Qualche mese fa un direttore finanziario mi ha chiesto una seconda opinione su un report di audit di cybersecurity ricevuto da una delle Big Four. 120 pagine, 47 findings, matrice di rischio, piano di remediation da 450.000 €. Tutto molto professionale, molto curato graficamente. L'ho letto tre volte cercando quello che mi mancava. Poi ho aperto un terminale, ho fatto un nmap contro i range di IP pubblici dell'azienda, e in sei minuti ho trovato il problema critico che il report di 120 pagine nemmeno citava. In questo pomeriggio ti racconto perché questo succede in continuazione.
In questo articolo ti spiego, con tre casi reali, la differenza tra la consulenza che ti consegna un PowerPoint e la consulenza che entra nella sala server con un laptop e ne esce sei ore dopo con il problema risolto. Tutti e tre sono clienti spagnoli che avevano già pagato grandi società di consulenza internazionali e alla fine hanno chiamato me. Nomi anonimizzati, dettagli tecnici esatti.
Il mito della grande società di consulenza
Per anni c'è stata una convinzione nelle aziende medio-grandi: per i progetti importanti, si chiamano sempre le Big Four o una multinazionale del settore. Il ragionamento era semplice: nessuno può incolparti di aver scelto male il fornitore se quel fornitore è quotato al Dow Jones. Se le cose vanno bene, è perché hai scelto i migliori. Se vanno male, è colpa del cliente o del contesto.
La realtà che ho visto da vicino in vent'anni è un'altra. Le grandi società di consulenza sono macchine di fatturazione con struttura piramidale. In cima ci sono uno o due partner che firmano il contratto e conoscono davvero il business. Sotto ci sono manager che organizzano i progetti. E alla base — dove si fa il lavoro vero — ci sono consulenti junior con uno o due anni di esperienza, appena usciti dall'università, che la società fattura al cliente tra gli 800 e i 1.500 € al giorno e paga tra i 100 e i 200 €. Il margine è brutale e l'incentivo strutturale è chiaro: massimizzare le ore fatturabili, non minimizzare i problemi del cliente.
Questo non significa che le grandi società non sappiano lavorare. Significa che il loro modello non è allineato con il tuo interesse. Quando assumi una Big Four per una migrazione SAP, la società ha un incentivo economico a che la migrazione duri il più possibile. Quando assumi una Big Four per un audit di sicurezza, ha un incentivo economico a che il report sia più lungo e complesso possibile, perché giustifica le ore. E quando assumi una Big Four per "implementare la trasformazione digitale", quello che assumi davvero è un esercito di persone che documenterà quello che già fai, ti presenterà trenta PowerPoint in tre mesi, e ti lascerà esattamente dov'eri ma con una fattura a sei cifre.
Nei prossimi minuti ti racconto tre casi concreti in cui una grande società di consulenza ha fallito clamorosamente e in cui la soluzione reale è costata una frazione del tempo e dei soldi. Non perché io sia più intelligente, ma perché il modello di lavoro che applico è radicalmente diverso.
Caso 1: la migrazione SAP che aveva dimenticato il backup
Azienda di logistica a Valencia, circa 200 dipendenti, 45 milioni di fatturato annuo. Lavoravano con SAP Business One da quindici anni — abbastanza bene per tenere in piedi le operazioni, ma con grandi limiti in reportistica e analytics. Il consiglio ha deciso di migrare a SAP S/4HANA e ha assunto una società di consulenza multinazionale con uffici a Madrid.
Budget iniziale: 380.000 €. Durata: 18 mesi. Team: un project manager senior, due consulenti funzionali, un consulente tecnico, un architetto dati. Sulla carta, un team solido. La realtà di ogni giorno era che il project manager era diviso su quattro progetti in contemporanea, i consulenti funzionali erano junior, e le persone che davvero capivano SAP in profondità comparivano solo nelle review di fase ogni tre mesi.
Al mese 14 del progetto, durante una fase di "test finali di migrazione", uno dei consulenti junior ha eseguito uno script di cleanup sull'ambiente di QA pensando che puntasse a un sandbox. Lo script ha cancellato parte dei dati anagrafici di clienti e fornitori — circa 11.000 record attivi. L'errore è stato scoperto il giorno dopo, quando i test di integrazione hanno iniziato a fallire a cascata.
La risposta immediata della società di consulenza è stata prevedibile: "bisogna ripristinare dal backup, ma il backup di quella tabella specifica richiede un restore completo del database, che durerà tra le 48 e le 72 ore". Durante quelle ore l'azienda avrebbe dovuto operare con processi manuali — impensabile nella logistica, dove ogni ora di ritardo significa penali contrattuali con i clienti.
Il direttore IT mi ha chiamato lo stesso giorno. Due ore dopo ero in ufficio. Tre cose che la società di consulenza aveva ignorato:
- Snapshot di HANA: SAP HANA permette di configurare snapshot automatici a livello di schema ogni 15 minuti. Nessuno li aveva attivati perché "non era nel perimetro del progetto". Ci ho messo trenta minuti a controllare la configurazione.
- Log di transazioni persistenti: anche senza snapshot, HANA mantiene per default i redo log per diversi giorni. Con accesso SSH al server e qualche query sulla vista
M_UNDO_CLEANUP_FILES, ho identificato il range di operazioni dello script problematico. - Audit a livello di riga: la società aveva installato S/4HANA senza attivare l'audit trail a livello di tabella, ma lo storico delle modifiche dei dati anagrafici viene conservato per default per 30 giorni in tabelle specifiche di tipo
*_HIST.
In quattro ore ho ricostruito gli 11.000 record cancellati combinando i tre meccanismi precedenti. Ho identificato l'utente che aveva eseguito lo script, ho documentato l'operazione passo passo, e prima delle otto di sera l'azienda era di nuovo operativa senza aver fatto un restore completo.
Costo del mio intervento: 2.800 €. Costo stimato del restore completo secondo il piano di contingenza della società: tra i 40.000 e gli 80.000 € solo in perdite operative di quelle 72 ore, più il costo degli straordinari del team.
La parte più interessante del caso non è il salvataggio tecnico. È che quando ho chiesto ai consulenti della Big Four perché non avessero attivato gli snapshot di HANA, la risposta è stata: "quella funzionalità non è menzionata nei nostri corsi interni". Vale a dire: il personale junior di una società di consulenza multinazionale non sapeva quello che io avevo imparato leggendo la documentazione ufficiale SAP in un weekend qualunque. E quella gente fatturava al cliente 1.200 € al giorno.
Quando assumi una grande società di consulenza per un progetto critico, non stai assumendo l'esperto nelle foto del partner. Stai assumendo il junior appena uscito dal master, supervisionato da un manager che sta seguendo sette progetti in contemporanea.
Caso 2: l'audit di sicurezza che ha ignorato l'ovvio
Azienda farmaceutica spagnola con presenza in tre paesi europei. Per requisiti regolatori del settore sanitario, dovevano fare un audit di cybersecurity annuale. Nel 2023 il consiglio ha deciso di "alzare il livello" e ha assunto una delle Big Four per 85.000 € per un assessment completo.
Il report finale era un documento di 120 pagine impaginato con cura. Comprendeva 47 findings classificati tra critico, alto, medio e basso; una matrice di rischio con assi di probabilità e impatto; riferimenti incrociati al framework NIST Cybersecurity Framework; un piano di remediation con fasi a 6, 12 e 24 mesi; e un budget stimato di 450.000 € per implementare le raccomandazioni.
Il direttore finanziario ha chiesto una seconda opinione prima di approvare quel budget. Su segnalazione di un direttore IT di un'altra azienda che aveva lavorato con me, mi hanno chiesto di rivedere il report in 48 ore.
L'ho letto con cura. I 47 findings erano tutti ragionevoli — politiche di password, cicli di patching, segmentazione di rete, gestione delle identità privilegiate, piano di risposta agli incidenti. Cose che ogni azienda dovrebbe avere. Ma qualcosa non tornava. I findings "critici" erano troppo generici — del tipo "implementare un SIEM per il monitoraggio continuo" — e nessuno menzionava problemi specifici dell'infrastruttura reale dell'azienda.
Ho chiuso il report e aperto un terminale. Ricognizione base da Internet: un nmap ai range di IP pubblici dell'azienda, revisione dei certificati SSL di ogni endpoint esposto, ricerche su Shodan del dominio e degli IP associati, e test manuali dei portali web di amministrazione trovati.
In sei minuti ho trovato questo: il pannello di amministrazione del loro ERP principale era esposto a Internet su una porta non standard (8443), con certificato autofirmato, accessibile da qualsiasi IP del mondo, e — peggio — con due utenti di test creati durante l'installazione iniziale nel 2019 con le password di default del fornitore che non erano mai state cambiate. Uno di quegli utenti aveva permessi di amministrazione completi sul database dell'ERP, che conteneva informazioni sui pazienti, ricette, consumi ospedalieri e dati di fatturazione — tutto soggetto a LOPD-GDD e GDPR.
L'azienda era stata tecnicamente a un clic di distanza da un incidente di sicurezza catastrofico per quattro anni. E il report da 120 pagine della Big Four non menzionava questo problema in nessun punto.
Perché? Quando il direttore finanziario ha chiesto spiegazioni, la risposta della società di consulenza è stata: "il perimetro dell'assessment contratto copriva l'audit documentale di politiche e procedure, non includeva penetration testing esterno". Vale a dire: avevano pagato 85.000 € per un report che analizzava le politiche scritte, non per verificare se quelle politiche venissero davvero applicate nella realtà.
L'ho sistemato in un pomeriggio. Due ore per chiudere l'endpoint esposto, cambiare tutte le password di default, configurare il firewall perimetrale e attivare l'MFA. Altre due ore per documentare il processo e consegnare un report di quattro pagine che il direttore finanziario ha capito in dieci minuti. Costo totale: 1.400 €.
Sul budget da 450.000 € proposto dalla Big Four: ho raccomandato di rinviarlo a tempo indeterminato, identificare i findings genuinamente rilevanti (circa 12 dei 47) e affrontarli con budget interno. Hanno risparmiato circa 400.000 € seguendo quel consiglio.
Caso 3: l'integrazione con macchinari industriali "impossibile"
Catena spagnola di lavanderie industriali. Una dozzina di centri, ognuno con otto-quindici lavatrici industriali del marchio Miele Professional. Il responsabile operativo voleva qualcosa di semplice: automatizzare la programmazione dei cicli di lavaggio dal loro software di gestione ordini, in modo che quando un ospedale mandasse un ordine di lenzuola con un codice specifico, il sistema programmasse automaticamente le macchine disponibili con i parametri corretti.
Avevano chiesto preventivi a tre società specializzate in integrazione industriale. Tutte e tre avevano dato la stessa risposta: non si può fare direttamente. Le macchine Miele Professional sono proprietarie, non espongono API pubbliche per il controllo esterno, e l'unico percorso ufficiale è assumere la piattaforma Miele@home Professional a 80-120 € all'anno per macchina, con un contratto minimo di tre anni e costi di implementazione aggiuntivi. Per la flotta completa di 150 macchine, parliamo di un minimo di 60.000 € solo in licenze, più l'integrazione, più l'obbligo di rifare tutto se un giorno avessero cambiato marca.
Mi hanno contattato su segnalazione di un altro cliente industriale. La domanda era: c'è un modo di farlo senza passare da Miele Cloud?
La prima cosa che ho fatto è stato andare a un centro e aprire fisicamente una macchina. Dentro il pannello elettrico ho trovato quello che mi aspettavo: un connettore RS-485 etichettato come "Service Port" — quello che usano i tecnici Miele durante la manutenzione. Quella porta parla un protocollo industriale documentato (una variante di Modbus su RS-485 con alcune estensioni specifiche Miele) e permette sia di leggere gli stati sia di inviare comandi di programmazione.
Miele non offre quella documentazione pubblicamente. Ma la documentazione esiste: la usano i loro stessi tecnici di servizio e circola nei forum tecnici industriali. In due giorni di reverse engineering con un convertitore RS-485 a Ethernet da 15 € e un analizzatore di protocollo, ho mappato i comandi principali: avvio ciclo, selezione programma, arresto di emergenza, lettura stato, lettura errori, contatori di servizio.
La soluzione finale è stata un gateway in Python che esponeva le macchine come un'API REST privata dentro la rete interna del cliente. Ogni centro ha ricevuto un piccolo server embedded — una Raspberry Pi 4 con un convertitore USB-RS485 — che si collegava alle macchine locali ed esponeva un'API uniforme verso il software di gestione centrale. Il sistema completo è costato:
- 4.200 € di hardware (convertitori, cablaggio, Raspberry Pi, scatole DIN)
- 18.000 € di sviluppo del gateway e integrazione con l'ERP
- 6.400 € di installazione e messa in opera dei 12 centri
Totale: 28.600 €. Contro i 60.000 € minimi della piattaforma Miele Cloud solo il primo anno, più i costi di integrazione che le società avevano stimato tra i 40.000 e i 60.000 € aggiuntivi. Risparmio approssimativo: 70.000 € il primo anno, e senza contratti ricorrenti.
Quattro anni dopo, il sistema funziona ancora senza problemi. Il cliente ha cambiato software ERP una volta, e l'unica modifica che ho dovuto fare è stata aggiornare l'API del gateway — due giorni di lavoro. Il cliente ha inoltre mantenuto la capacità di cambiare marca di lavatrice in futuro, perché il gateway è agnostico al produttore: qualsiasi macchina con una porta RS-485 e un protocollo noto si può integrare con lo stesso schema.
Perché le grandi società di consulenza non sono riuscite a farlo
I tre casi precedenti hanno un pattern comune, e capirlo è la chiave per sapere quando assumere una grande società di consulenza e quando no.
Le grandi società di consulenza operano con team piramidali dove il lavoro tecnico vero lo fanno profili junior. Quei profili sono addestrati in procedure documentate: checklist ufficiali, framework certificati, metodologie standardizzate. Sono bravi a fare esattamente quello che c'è nel playbook. Quando il problema è un problema standard — implementare uno strumento di mercato, fare audit rispetto a un framework noto, migrare da un sistema a un altro — funzionano ragionevolmente bene.
Il problema appare quando il cliente ha un problema non-standard. Un incidente tecnico specifico che richiede di leggere la documentazione profonda di un prodotto. Un audit di sicurezza reale, non documentale. Un'integrazione con un protocollo industriale non documentato ufficialmente. Nessuna di queste cose è nel playbook di una grande società di consulenza. E i consulenti junior non hanno l'esperienza — né l'incentivo — per uscire dal playbook.
Il mio lavoro è proprio nei casi in cui il playbook non basta. Non perché io sia più intelligente dei consulenti di una Big Four, ma perché lavoro sul campo da vent'anni, ho letto la documentazione che i junior non hanno tempo di leggere, ho aperto fisicamente macchinari industriali, ho scritto codice a basso livello, e ho visto abbastanza da identificare in fretta cosa conta e cosa no.
Cos'è la vera consulenza IT senior
Dopo vent'anni di questo lavoro, la mia definizione di consulenza IT senior si riduce a quattro punti:
- Aver fatto il lavoro manuale. Un consulente senior deve aver passato anni a scrivere codice, configurare router, debuggare database, aprire quadri elettrici o gestire clienti furiosi alle tre di notte. Quell'esperienza non si può sostituire con una certificazione o con un master.
- Saper lavorare da solo. Un consulente senior non ha bisogno di un team di junior dietro per consegnare risultati. Se non può sedersi con un laptop, accedere al problema e risolverlo in prima persona, non è senior.
- Avere incentivi allineati. Un consulente senior viene pagato per risolvere problemi, non a ore. Se il tuo modello di business è massimizzare le ore fatturabili, sei strutturalmente incentivato a lasciare i problemi aperti.
- Saper dire "non lo so". Un consulente senior sa quando un problema è fuori dal suo campo e lo dice alla prima conversazione. Non ti vende fumo per entrare e poi subappaltare la parte importante.
Conclusione
Le grandi società di consulenza hanno il loro posto. Sono utili quando ti serve un fornitore con braccia lunghe per eseguire progetti molto grandi su tempi lunghi, con migliaia di utenti coinvolti e rischio reputazionale alto. Se stai migrando tutta la tua infrastruttura ad Azure e ti servono persone a tempo pieno per due anni, una Big Four può essere un'opzione ragionevole — con la riserva che pagherai molto e i risultati dipenderanno in gran parte dai partner e dai manager specifici che ti assegneranno.
Ma per i problemi specifici, gli incidenti critici, gli audit veri, le integrazioni industriali non-standard, i salvataggi tecnici urgenti — tutto quello spazio in cui un PowerPoint non risolve nulla — quello di cui hai bisogno è un consulente senior indipendente con esperienza di campo reale, uno che possa sedersi con il tuo direttore IT una mattina e avere il problema diagnosticato all'ora di pranzo.
Non c'è mistero. Quello che faccio io non è magia. È leggere la documentazione che i consulenti junior non hanno avuto tempo di leggere, aprire le macchine che non osano aprire, e scrivere codice quando il codice è la risposta giusta. Tutto quello che faccio potrebbe farlo chiunque — con vent'anni di esperienza alle spalle e una filosofia di lavoro diversa.
Se stai per approvare un budget a sei cifre con una grande società di consulenza per risolvere un problema tecnico specifico, fermati a chiedere una seconda opinione. Non dico necessariamente di chiamare me — dico di cercare qualcuno che sappia spiegarti il problema in un foglio e la soluzione in due. Se non è in grado di farlo, non ti sta dicendo la verità. E se l'audit che ti propongono costa 85.000 € ma un nmap in sei minuti trova il problema critico che il report ha ignorato — parliamone prima che tu firmi.