Por qué los errores de criterio son más costosos que los errores técnicos
Un error técnico en infraestructura TI —una configuración incorrecta, un driver incompatible, un backup que no se verificó— tiene un costo acotado y un diagnóstico posible. Se identifica, se corrige, y el sistema vuelve a operar. El tiempo de recuperación puede ser horas o días, pero el problema tiene solución técnica.
Un error de criterio tiene un costo diferente. Una herramienta sobredimensionada que el equipo no puede operar genera dependencia externa indefinida. Un proceso sin documentar que depende de una persona clave es un riesgo latente que se materializa el día que esa persona no está disponible. Una decisión de arquitectura tomada sin el análisis correcto puede bloquear opciones durante años.
Los tres errores que describimos a continuación son de criterio. No aparecen en los logs del servidor. Aparecen en las conversaciones cuando algo falla y nadie sabe exactamente qué hacer.
Error 1: implementar la herramienta más potente, no la más adecuada
El patrón se repite con una consistencia que no sorprende: se identifica una necesidad, se investiga qué usan las empresas grandes, se elige la solución enterprise-grade, se implementa, y seis meses después el equipo no puede mantenerla de forma autónoma. La plataforma opera, pero cualquier cambio o incidente requiere llamar al proveedor que la instaló.
El problema no es la herramienta. Es que la herramienta es un activo solo cuando el equipo puede operarla. Cuando no puede, es un pasivo con costo de mantenimiento externo indefinido y un riesgo operacional que crece cada vez que el proveedor cambia sus condiciones o disponibilidad.
La causa de fondo es que la evaluación se hace comparando capacidades técnicas, no comparando capacidades técnicas con capacidad operacional del equipo. Una herramienta con el 70% de las capacidades de la alternativa más potente, pero que el equipo puede operar de forma autónoma, entrega más valor real que la herramienta más potente que nadie sabe gestionar cuando falla.
La pregunta que falta en la mayoría de las evaluaciones no es qué puede hacer la herramienta. Es qué puede hacer el equipo con esa herramienta en doce meses.
Error 2: no documentar lo que quedó implementado
La documentación técnica es probablemente el entregable más subestimado en proyectos TI de empresas medianas. No el plan previo al proyecto, que suele estar bien desarrollado. Lo que se subestima es la documentación de lo que realmente quedó implementado: la arquitectura resultante, las decisiones que se tomaron en el camino y por qué, y los procedimientos que el equipo necesita para operar el sistema de forma autónoma.
La razón por la que no se documenta es siempre la misma: al final del proyecto hay presión para cerrar, el equipo técnico quiere pasar al siguiente trabajo, y documentar lo que ya funciona parece menos urgente que cualquier otra cosa. El costo aparece después, cuando alguien necesita entender cómo está configurado algo que implementó otra persona hace dieciocho meses.
El costo concreto es la dependencia del proveedor que implementó. Cada ajuste menor, cada cambio de configuración, cada diagnóstico de incidente requiere involucrar a alguien externo porque el conocimiento de lo que se implementó no quedó en la organización. Eso tiene un costo económico directo y un costo operacional en tiempo de respuesta.
La solución no es documentar todo: es documentar lo que el equipo necesita para operar de forma autónoma. Procedimientos de recuperación ante fallas comunes, arquitectura de red y almacenamiento con los valores reales de la implementación, y registro de las decisiones de diseño que no son evidentes para alguien que llega al sistema por primera vez.
Error 3: normalizar la dependencia crítica en personas de TI
Este es el riesgo más frecuente y menos gestionado en empresas medianas. No porque no se identifique —en la mayoría de los casos el equipo directivo sabe que hay una o dos personas de las que depende todo el funcionamiento de TI— sino porque resolverlo requiere tiempo e inversión que siempre compite con la urgencia del día a día.
La dependencia crítica tiene varias formas. La más obvia es que solo una persona sabe cómo opera un sistema crítico. Las menos obvias son que solo una persona tiene las credenciales de acceso a ciertos sistemas, que los procedimientos de recuperación existen solo en la memoria de esa persona, o que el monitoreo de la infraestructura depende de que esa persona esté presente para detectar problemas.
El costo se materializa de forma predecible: vacaciones, enfermedad, renuncia, o simplemente no estar disponible en el momento en que ocurre un incidente. En ese momento, lo que era un riesgo conocido y gestionable se convierte en una crisis con costo operacional real.
La solución no es contratar más personas. Es sistematizar el conocimiento que hoy existe solo en cabezas: documentación técnica actualizada, procedimientos de recuperación escritos y probados, gestión centralizada de accesos y credenciales, y monitoreo activo que detecte problemas antes de que los reporte un usuario. Esas cuatro medidas reducen la dependencia crítica sin cambiar la estructura del equipo.
Por qué los tres errores se repiten
Los tres errores comparten una causa común: son consecuencias de decisiones tomadas bajo presión operacional, donde la urgencia del día a día desplaza el análisis de mediano plazo. Implementar la herramienta más potente parece más seguro cuando hay presión por tomar una decisión rápida. No documentar es la consecuencia natural de cerrar un proyecto con prisa. Normalizar la dependencia crítica es lo que ocurre cuando resolver el problema compite con todo lo demás que hay que hacer.
Reconocer el patrón no lo resuelve, pero es el punto de partida. El segundo paso es tratar estas tres dimensiones —elección de herramientas, documentación, y dependencia de personas— como parte del diseño de cualquier proyecto TI, no como tareas pendientes para después.
