La mayoría de los diagnósticos de infraestructura terminan igual: un documento de 40 páginas con capturas de pantalla, una lista de "hallazgos" ordenados por color y ninguna decisión tomada tres meses después. El problema no es la falta de información — es que el diagnóstico se hizo para documentar, no para decidir.
Un diagnóstico útil responde preguntas de negocio: ¿qué se cae primero si falla X?, ¿dónde estamos pagando por capacidad que no usamos?, ¿qué inversión es urgente y cuál puede esperar 18 meses? Si el entregable no permite responder eso, es un inventario caro.
Empezar por las dependencias, no por el inventario
El inventario de activos es necesario, pero es el punto de partida, no el resultado. Lo que cambia decisiones es el mapa de dependencias: qué aplicaciones dependen de qué servidores, qué servidores dependen de qué switches, qué procesos de negocio se detienen si un enlace se cae. Un servidor de 8 años no es automáticamente crítico; uno de 2 años que sostiene la facturación sin redundancia, sí.
En la práctica, esto significa entrevistar a quienes operan los procesos, no solo escanear la red. Los escáneres encuentran equipos; no encuentran el hecho de que la báscula de embarques depende de un servidor que nadie ha respaldado.
Medir comportamiento real, no solo configuración
Un checklist genérico revisa si existe firewall, si hay antivirus, si hay respaldos configurados. Un diagnóstico serio verifica si funcionan: ¿cuándo fue la última restauración de prueba exitosa?, ¿qué porcentaje del ancho de banda se consume en horario pico y en qué?, ¿cuántos días de logs conserva el firewall y alguien los revisa?
- Respaldos: no "¿Hay respaldos?", sino "¿He ha restaurado algo en los últimos seis meses y cuánto tardó?"
- Red: no "¿Hay switches administrables?", sino "¿Hay visibilidad de qué tráfico circula y hay cuellos de botella medidos?"
- Servidores: no "¿Qué edad tienen?", sino "¿Qué carga real soportan y qué margen queda? ¿Cuentan aún con soporte?"
Priorizar por riesgo y costo de inacción
El entregable clave no es la lista de hallazgos: es la priorización. Cada hallazgo debe traer tres cosas: qué pasa si no se atiende, un rango de esfuerzo o inversión para atenderlo, y un plazo recomendado. Sin eso, la dirección recibe una lista de pendientes técnicos que no puede jerarquizar, y la respuesta natural es posponerlo todo.
Suele ocurrir que los hallazgos más baratos de corregir son los de mayor riesgo — credenciales compartidas, respaldos sin verificar, equipos de red sin firmware actualizado. Un diagnóstico que empieza pidiendo presupuesto grande antes de corregir lo barato debería levantar sospechas.
El entregable: decisiones, no páginas
Un formato que funciona: un resumen ejecutivo de una página con las 5 decisiones que hay que tomar, un anexo técnico con la evidencia, y un roadmap tentativo de 12 meses. Si quien lee solo la primera página puede decidir, el diagnóstico cumplió. Si necesita leer las 40 páginas para entender qué hacer, no.
También importa la independencia del criterio: si quien diagnostica solo recomienda comprar lo que él mismo vende, el documento es una cotización disfrazada. Las recomendaciones deben incluir opciones — incluida la de no hacer nada todavía, cuando aplica.
Un diagnóstico bien hecho se paga solo la primera vez que evita una compra innecesaria o anticipa una falla que hubiera detenido la operación. El criterio para evaluarlo es simple: ¿Tres meses después, se tomaron decisiones basadas en él?
Si hoy te pidieran justificar tu próxima inversión de TI ante dirección general, ¿Tendrías evidencia de tu propio entorno para hacerlo, o solo la recomendación de un proveedor?