Hace unos meses un director financiero me pidió una segunda opinión sobre un informe de auditoría de ciberseguridad que había recibido de una de las Big Four. 120 páginas, 47 hallazgos, matriz de riesgo, plan de remediación de 450.000 €. Todo muy profesional, muy visualmente cuidado. Lo leí tres veces buscando lo que me faltaba. Luego abrí una terminal, hice un nmap contra los rangos de IPs de la empresa, y en seis minutos encontré el problema crítico que el informe de 120 páginas ni siquiera mencionaba. Esa tarde te voy a contar por qué eso ocurre una y otra vez.
En este artículo te explico, con tres casos reales, la diferencia entre la consultoría que te entrega un PowerPoint y la consultoría que entra con un laptop en la sala de servidores y sale seis horas después con el problema resuelto. Los tres son casos de clientes españoles que antes habían pagado a grandes consultoras internacionales y que al final me llamaron a mí. Los nombres están anonimizados pero los detalles técnicos son exactos.
El mito de la gran consultora
Durante años existió una creencia en las empresas medianas y grandes: para los proyectos importantes, siempre contratas a una Big Four o a una multinacional del sector. El razonamiento era sencillo: nadie te puede acusar de haber elegido mal al proveedor si ese proveedor aparece en el Dow Jones. Si algo sale bien, es porque contrataste a los mejores. Si algo sale mal, es por culpa del cliente o del contexto.
La realidad que he visto de cerca durante veinte años es otra. Las grandes consultoras son máquinas de facturación con estructura piramidal. En lo más alto hay uno o dos partners que firman el contrato y conocen bien el negocio. Debajo hay managers que organizan proyectos. Y en la base — donde se hace el trabajo real — hay consultores junior con uno o dos años de experiencia, recién salidos de la universidad, a los que la consultora cobra al cliente entre 800 y 1.500 € al día y a los que paga entre 100 y 200 €. El margen es brutal y el incentivo estructural es claro: maximizar las horas facturables, no minimizar los problemas del cliente.
Eso no significa que las grandes consultoras no sepan trabajar. Significa que su modelo no está alineado con tu interés. Cuando contratas una Big Four para una migración de SAP, la consultora tiene un incentivo económico en que la migración dure el máximo tiempo posible. Cuando contratas una Big Four para una auditoría de seguridad, la consultora tiene un incentivo económico en que el informe sea lo más largo y complejo posible, porque eso justifica las horas. Y cuando contratas una Big Four para "implementar la transformación digital" de tu empresa, lo que contratas realmente es un ejército de gente que va a documentar lo que ya haces, va a presentarte treinta PowerPoints en tres meses, y va a dejarte exactamente donde estabas pero con una factura de seis cifras.
En los próximos minutos voy a contarte tres casos concretos donde una gran consultora falló estrepitosamente y donde la solución real costó una fracción del tiempo y el dinero. No porque yo sea más listo, sino porque el modelo de trabajo que aplico es radicalmente distinto.
Caso 1: la migración SAP que olvidó el backup
Empresa de logística en Valencia, aproximadamente 200 empleados, facturación de 45 millones al año. Llevaban quince años trabajando con SAP Business One — suficientemente bien para mantener las operaciones, pero con limitaciones importantes en reporting y analítica. El consejo decidió migrar a SAP S/4HANA y contrató a una consultora multinacional con oficinas en Madrid.
Presupuesto inicial: 380.000 €. Plazo: 18 meses. Equipo asignado: un project manager senior, dos consultores funcionales, un consultor técnico y un arquitecto de datos. Sobre el papel, un equipo sólido. La realidad del día a día era que el project manager estaba dividido entre cuatro proyectos a la vez, los consultores funcionales eran junior y los que realmente entendían SAP en profundidad solo aparecían en reuniones de fase cada tres meses.
En el mes 14 del proyecto, durante una fase de "pruebas de migración final", uno de los consultores junior ejecutó un script de limpieza sobre el entorno de QA creyendo que estaba apuntando a un entorno de sandbox. El script borró parte de los datos maestros de clientes y proveedores — aproximadamente 11.000 registros activos. El error se descubrió al día siguiente, cuando los test de integración empezaron a fallar en cascada.
La respuesta inmediata de la consultora fue la esperada: "necesitamos restaurar desde backup, pero el backup de esa tabla específica requiere una restauración completa de la base de datos, que llevará entre 48 y 72 horas". Durante esas horas, la empresa tenía que operar con procesos manuales, algo impensable en logística donde cada hora de retraso significa penalizaciones contractuales con clientes.
Me llamó el director de IT el mismo día. Llegué a la oficina dos horas después. Tres cosas que la consultora había ignorado:
- Snapshots de HANA: SAP HANA permite configurar snapshots automáticos a nivel de schema con frecuencia de 15 minutos. Nadie los había habilitado porque "no estaba en el alcance del proyecto". Tardé treinta minutos en revisar la configuración.
- Logs de transacciones persistentes: aunque los snapshots no estaban activados, HANA mantiene por defecto los redo logs durante varios días. Con acceso SSH al servidor y unas queries sobre la vista
M_UNDO_CLEANUP_FILES, identifiqué el rango de operaciones del script problemático. - Auditoría a nivel de fila: la consultora había instalado S/4HANA sin activar el audit trail a nivel de tabla, pero el histórico de cambios de datos maestros se mantiene por defecto durante 30 días en tablas específicas de tipo
*_HIST.
En cuatro horas reconstruí los 11.000 registros borrados combinando los tres mecanismos anteriores. Identifiqué al usuario que había ejecutado el script, documenté la operación paso a paso, y antes de las ocho de la tarde la empresa estaba operativa de nuevo sin necesidad de restore completo.
Coste de mi intervención: 2.800 €. Coste estimado de restaurar backup completo según el plan de contingencia de la consultora: entre 40.000 y 80.000 € solo en pérdidas operativas de esas 72 horas, más el coste de las horas extras del equipo.
Lo más interesante del caso no es el rescate técnico. Es que cuando le pregunté a los consultores de la Big Four por qué no habían activado los snapshots de HANA, la respuesta fue: "en las formaciones internas que damos, no se menciona esa funcionalidad". Es decir: el personal junior de una consultora multinacional no sabía lo que yo había aprendido leyendo la documentación oficial de SAP en un fin de semana cualquiera. Y esa gente cobraba 1.200 € al día al cliente.
Cuando contratas a una gran consultora para un proyecto crítico, no estás contratando al experto que sale en las fotos del partner. Estás contratando al junior que acaba de salir del máster, supervisado por un manager que lleva siete proyectos simultáneos.
Caso 2: la auditoría de seguridad que ignoró lo obvio
Empresa farmacéutica española con presencia en tres países europeos. Por requisitos regulatorios del sector sanitario, tenían que realizar una auditoría de ciberseguridad anual. En 2023 el consejo decidió "subir el nivel" y contrataron una de las Big Four por 85.000 € para un assessment completo.
El informe final fue un documento de 120 páginas elegantemente maquetado. Incluía 47 hallazgos clasificados entre crítico, alto, medio y bajo; una matriz de riesgo con ejes de probabilidad e impacto; referencias cruzadas al framework NIST Cybersecurity Framework; un plan de remediación con fases a 6, 12 y 24 meses; y un presupuesto estimado de 450.000 € para implementar las recomendaciones.
El director financiero llamó a consejo pidiendo una segunda opinión antes de aprobar ese presupuesto. Por recomendación de un director de IT de otra empresa que había trabajado conmigo, me encargaron revisar el informe en 48 horas.
Lo leí con cuidado. Los 47 hallazgos eran todos razonables — políticas de contraseñas, ciclos de parcheo, segmentación de red, gestión de identidades privilegiadas, plan de respuesta ante incidentes. Cosas que toda empresa debería tener. Pero algo no me cuadraba. Los hallazgos de "crítico" eran demasiado genéricos — del tipo "implementar SIEM para monitorización continua" — y ninguno mencionaba problemas específicos de la infraestructura real de la empresa.
Cerré el informe y abrí una terminal. Hice un reconocimiento básico desde Internet: un nmap al rango de IPs públicas de la empresa, revisión de los certificados SSL de cada endpoint expuesto, búsqueda en Shodan del dominio y de las IPs asociadas, y pruebas manuales de los portales web de administración encontrados.
En seis minutos encontré lo siguiente: el panel de administración de su ERP principal estaba expuesto a Internet en un puerto no estándar (8443), con certificado autofirmado, accesible desde cualquier IP del mundo, y — lo peor — con dos usuarios de prueba creados durante la instalación inicial en 2019 con contraseñas por defecto del proveedor que nunca habían sido cambiadas. Uno de esos usuarios tenía permisos de administración completos sobre la base de datos del ERP, que contenía información de pacientes, recetas, consumos hospitalarios y datos de facturación — todo sujeto a la LOPD-GDD y al RGPD.
La empresa había estado técnicamente un clic de distancia de un incidente de seguridad catastrófico durante cuatro años. Y el informe de 120 páginas de la Big Four no mencionaba este problema en ningún sitio.
¿Por qué? Cuando el director financiero les preguntó, la respuesta de la consultora fue: "el scope del assessment contratado cubría la auditoría documental de políticas y procedimientos, no incluía penetration testing externo". Es decir: pagaron 85.000 € por un informe que analizaba las políticas escritas, no por una revisión de si esas políticas estaban siendo aplicadas en la realidad.
Lo arreglé en una tarde. Dos horas para cerrar el endpoint expuesto, cambiar todas las contraseñas por defecto, configurar el firewall perimetral y activar el MFA. Dos horas más para documentar el proceso y entregar un informe de cuatro páginas que el director financiero entendió en diez minutos. Coste total: 1.400 €.
Sobre el presupuesto de 450.000 € propuesto por la Big Four: les recomendé posponerlo indefinidamente, identificar los hallazgos genuinamente relevantes (había unos 12 de los 47) y abordarlos con presupuesto interno. Ahorraron aproximadamente 400.000 € siguiendo esa recomendación.
Caso 3: la integración con maquinaria industrial "imposible"
Cadena española de lavanderías industriales. Una docena de centros, cada uno con entre ocho y quince máquinas de lavado industrial de la marca Miele Professional. El gerente de operaciones quería algo sencillo: automatizar la programación de ciclos de lavado desde su software de gestión de pedidos, para que cuando un hospital enviara una orden de sábanas con un código específico, el sistema programara automáticamente las máquinas disponibles con los parámetros adecuados.
Habían pedido presupuestos a tres consultoras especializadas en integración industrial. Las tres dieron la misma respuesta: no se puede directamente. Las máquinas Miele Professional son propietarias, no exponen APIs públicas para control externo, y el único camino oficial es contratar la plataforma Miele@home Professional a 80-120 € al año por máquina, con un contrato mínimo de tres años y costes de implementación adicionales. Para la flota completa de 150 máquinas, hablamos de un mínimo de 60.000 € solo en licencias, más la integración, más la obligación de rehacerlo todo si algún día cambiaban de marca.
Me contactaron por recomendación de otro cliente industrial. La pregunta era: ¿hay alguna forma de hacerlo sin pasar por Miele Cloud?
Lo primero que hice fue ir a un centro y abrir físicamente una máquina. Dentro del panel eléctrico encontré lo que esperaba: un conector RS-485 etiquetado como "Service Port" — el que usan los técnicos de Miele cuando hacen mantenimiento. Ese puerto habla un protocolo industrial documentado (una variante de Modbus sobre RS-485 con algunas extensiones específicas de Miele) y permite tanto leer estados como enviar comandos de programación.
Miele no ofrece esa documentación públicamente. Pero la documentación existe: la usan los propios técnicos de servicio y circula en foros técnicos industriales. En dos días de ingeniería inversa con un conversor RS-485 a Ethernet de 15 € y un analizador de protocolo, mapeé los comandos principales: inicio de ciclo, selección de programa, parada de emergencia, lectura de estado, lectura de errores, contadores de servicio.
La solución final fue un gateway en Python que exponía las máquinas como una API REST privada dentro de la red interna del cliente. Cada centro recibió un pequeño servidor embebido — una Raspberry Pi 4 con un conversor USB-RS485 — que se conectaba a las máquinas locales y exponía una API uniforme hacia el software de gestión central. El sistema completo costó:
- 4.200 € en hardware (conversores, cableado, Raspberry Pi, cajas DIN)
- 18.000 € en desarrollo del gateway y la integración con el ERP
- 6.400 € en instalación y puesta en marcha de los 12 centros
Total: 28.600 €. Frente a los 60.000 € mínimos de la plataforma Miele Cloud solo el primer año, más los costes de integración que las consultoras habían estimado entre 40.000 y 60.000 € adicionales. Ahorro aproximado: 70.000 € el primer año, y sin contratos recurrentes.
Cuatro años después, el sistema sigue funcionando sin problemas. El cliente ha cambiado de software de ERP una vez, y la única modificación que necesité hacer fue actualizar el API del gateway — dos días de trabajo. El cliente ha mantenido además la capacidad de cambiar de marca de lavadora en el futuro, porque el gateway es agnóstico al fabricante: cualquier máquina con un puerto RS-485 y protocolo conocido se puede integrar con el mismo patrón.
Por qué las grandes consultoras no pudieron hacer esto
Los tres casos anteriores tienen un patrón común, y entenderlo es clave para saber cuándo contratar a una gran consultora y cuándo no.
Las grandes consultoras operan con equipos piramidales donde el trabajo técnico real lo hacen perfiles junior. Esos perfiles están entrenados en procedimientos documentados: checklists oficiales, frameworks certificados, metodologías estandarizadas. Son buenos haciendo exactamente lo que está en el playbook. Cuando el problema es un problema estándar — implementar una herramienta de mercado, auditar contra un framework conocido, migrar un sistema a otro — funcionan razonablemente bien.
El problema aparece cuando el cliente tiene un problema no-estándar. Un incidente técnico específico que requiere leer la documentación profunda de un producto. Una auditoría de seguridad real, no documental. Una integración con un protocolo industrial no documentado oficialmente. Ninguna de esas cosas está en el playbook de una gran consultora. Y los consultores junior no tienen la experiencia — ni el incentivo — para salirse del playbook.
Mi trabajo consiste precisamente en los casos donde el playbook no sirve. No porque sea más inteligente que los consultores de una Big Four, sino porque llevo veinte años trabajando en el campo, he leído la documentación que los junior no tienen tiempo de leer, he abierto físicamente máquinas industriales, he escrito código a bajo nivel, y he visto lo suficiente como para identificar rápidamente qué importa y qué no.
Qué es consultoría IT senior de verdad
Después de veinte años haciéndolo, mi definición de consultoría IT senior se reduce a cuatro puntos:
- Haber hecho el trabajo manual. Un consultor senior debe haber pasado años escribiendo código, configurando routers, depurando bases de datos, abriendo paneles eléctricos o lidiando con clientes furiosos a las tres de la mañana. Esa experiencia no se puede sustituir por una certificación ni por un máster.
- Poder trabajar solo. Un consultor senior no necesita un equipo de junior por detrás para entregar resultados. Si no puede sentarse con un laptop, acceder al problema y resolverlo en persona, no es senior.
- Tener incentivos alineados. Un consultor senior cobra por resolver problemas, no por horas. Si tu modelo de negocio está en maximizar las horas facturables, estás estructuralmente incentivado a dejar los problemas abiertos.
- Saber decir "no lo sé". Un consultor senior sabe cuándo un problema está fuera de su área y lo dice en la primera conversación. No te vende humo para entrar y luego subcontratar lo importante.
Conclusión
Las grandes consultoras tienen su lugar. Son útiles cuando necesitas un proveedor con brazos largos para ejecutar proyectos muy grandes en plazos largos, con miles de usuarios afectados y un riesgo reputacional alto. Si estás migrando toda tu infraestructura a Azure y necesitas gente trabajando durante dos años a tiempo completo, una Big Four puede ser una opción razonable — con la reserva de que vas a pagar mucho y de que los resultados dependerán en gran medida de los partners y managers concretos que te asignen.
Pero para los problemas específicos, los incidentes críticos, las auditorías reales, las integraciones industriales no-estándar, los rescates técnicos urgentes — todo ese espacio donde un PowerPoint no resuelve nada — lo que necesitas es un consultor senior independiente con experiencia de campo real, que pueda sentarse con tu director de IT una mañana y tener el problema diagnosticado al mediodía.
No hay misterio. El trabajo que hago yo no es magia. Es leer la documentación que los consultores junior no han tenido tiempo de leer, abrir las máquinas que ellos no se atreven a abrir, y escribir código cuando el código es la respuesta correcta. Todo lo que hago lo podría hacer cualquiera — con veinte años de experiencia encima y una filosofía de trabajo distinta.
Si estás a punto de aprobar un presupuesto de seis cifras con una gran consultora para resolver un problema técnico concreto, párate a pedir una segunda opinión. No digo que me llames necesariamente a mí — digo que busques a alguien que pueda explicarte el problema en un folio y la solución en dos. Si no puede hacerlo, no te está diciendo la verdad. Y si la auditoría que te proponen cuesta 85.000 € pero un nmap en seis minutos encuentra el problema crítico que el informe ignoró — hablemos antes de firmar.