Madurez de TI: De la evaluación a un plan de acción
July 30, 2026
La mayoría de los directores de TI han pasado por evaluaciones de madurez que solo han dado como resultado una diapositiva con gráficas de colores. El ejercicio mide la posición de un centro de servicios frente a un ideal teórico, entrega una puntuación y pasa al siguiente punto de la agenda. Seis meses después, las mismas escalaciones se acumulan, las mismas transferencias manuales ralentizan las solicitudes y nadie puede señalar qué cambió realmente como resultado de un diagnóstico que supuestamente era tan revelador.
El problema no es el concepto de madurez en sí. Una evaluación solo justifica su lugar en la hoja de ruta cuando el resultado se traduce en algo concreto: un flujo de trabajo que configurar, un informe que activar, una política que aplicar de manera consistente en cada equipo que interactúa con un ticket. Planteado así, una puntuación de madurez deja de ser una etiqueta académica y se convierte en el punto de partida para una secuencia de decisiones sobre las que un equipo de TI puede actuar este trimestre, no eventualmente, ni después de otra ronda de revisión por parte de un comité.
Este artículo se centra en qué hacer una vez que tiene un resultado en mano, en lugar de catalogar cada etapa del modelo con un detalle exhaustivo, ya que ese nivel de matiz está mejor cubierto por la evaluación misma. En cambio, mapea las capacidades de Freshservice que normalmente hacen avanzar a un equipo, independientemente de dónde empiece.
La mayoría de los marcos de trabajo fracasan por la misma razón: describen un estado final sin describir el camino para llegar a él. Un informe que dice que "las organizaciones optimizadas utilizan análisis predictivos" es cierto y, a la vez, inútil, porque no le da a un director de TI nada que configurar un lunes por la mañana. Los equipos leen la descripción, reconocen que no están ni cerca y cierran el documento discretamente.
La solución es anclar el diagnóstico a elementos directamente observables en las operaciones diarias: cómo llegan los tickets, con qué frecuencia se repite el mismo incidente, si alguien puede decir con confianza qué activos existen y quién es su propietario. Cuando los indicadores son observables, la evaluación deja de ser subjetiva y se convierte en algo que un director puede revisar con su propio equipo en una tarde, convirtiendo una puntuación en una lista corta de brechas que vale la pena cerrar primero.
Los modelos de madurez suelen describir un puñado de etapas, pasando de prácticas caóticas y reactivas hacia otras definidas, gestionadas y, finalmente, optimizadas. En lugar de analizar cada etiqueta en detalle, la forma más rápida de saber exactamente dónde se encuentra tu equipo es realizar una revisión de cómo opera hoy: en GB Advisors creamos un test de madurez de TI gratuito que toma menos de cinco minutos y entrega un resultado personalizado (no una recomendación genérica) con el paso siguiente más relevante para tu situación actual. Es una forma concreta de convertir la sensación de "podríamos estar mejor organizados" en un diagnóstico que puedas llevar directo a tu próxima conversación de planificación o presupuesto.
Una vez que conozcas tu punto de partida, la guía práctica a continuación se aplica independientemente de la etapa en la que te encuentres, ya que las brechas subyacentes tienden a repetirse en todas las organizaciones, incluso cuando la puntuación inicial difiere bastante de un equipo a otro. Lo que cambia es qué sección priorizar primero, no qué prácticas son importantes a largo plazo.
Si las solicitudes llegan por teléfono, correo electrónico, conversaciones de pasillo y chat sin un sistema de registro único, nada de lo que ocurra después (informes, priorización, SLA) puede funcionar de manera fiable. El primer paso concreto para casi cualquier equipo, independientemente de su punto de partida, es consolidar cada canal en una cola única para que el volumen, las categorías y los tiempos de respuesta sean visibles por primera vez.
La bandeja de entrada unificada de tickets de Freshservice y su conversión de correo electrónico a ticket ofrecen ese punto de partida sin un proceso de configuración prolongado. Una vez que cada solicitud llega a un solo lugar, incluso el filtrado y etiquetado básico exponen patrones que antes eran invisibles: qué categoría domina la cola, qué grupo de solicitantes genera el mayor volumen y dónde reside realmente el trabajo pendiente. Esa visibilidad por sí sola suele ser suficiente para justificar la siguiente inversión en procesos.
Estandarizar un proceso significa lograr un acuerdo entre personas que han estado resolviendo problemas a su manera durante años, y la gestión del cambio es el ejemplo más claro de dónde se estanca este proceso. Sin un flujo de trabajo documentado, los cambios se realizan de forma improvisada, los conflictos pasan desapercibidos hasta que algo se rompe y nadie puede decir después qué se modificó realmente ni quién lo hizo.
Crear un calendario de cambios, definir etapas de aprobación y exigir un plan de reversión antes de la implementación son los pasos específicos que llevan a un equipo de las soluciones improvisadas a un proceso repetible. La misma disciplina se aplica a la categorización de incidentes y a las aprobaciones de solicitudes de servicio: documenta el proceso, automatiza el enrutamiento y exige al equipo que lo cumpla durante al menos un trimestre completo antes de realizar ajustes.
Toda mejora posterior depende de datos fiables, y la brecha más común es la visibilidad de los activos. Muchos equipos tienen una hoja de cálculo que era precisa hace seis meses, lo que significa que cada decisión sobre capacidad, licencias o exposición a riesgos de seguridad comienza con una suposición en lugar de un hecho, sin importar cuán bien definidos estén los procesos circundantes.
Una base de datos de gestión de configuración que se actualiza a través de herramientas de descubrimiento elimina esas conjeturas. Una vez que los inventarios de hardware y software se reconcilian automáticamente, el cumplimiento de licencias, los tiempos de renovación y la aplicación de parches de seguridad se convierten en actividades planificadas en lugar de sorpresas. Junto con los paneles de SLA y el seguimiento de incidentes recurrentes, este es el punto en el que un equipo deja de reaccionar ante el último incendio y comienza a gestionar una cartera.
Una vez que la gestión de solicitudes, las aprobaciones y un catálogo de autoservicio funcionan sin problemas para TI, la misma infraestructura puede absorber solicitudes de RR. HH., legal y finanzas con solo cambios de configuración modestos. Esto no se trata tanto de nuevas herramientas sino de ampliar el alcance de lo que ya funciona, razón por la cual suele ocurrir más tarde que al principio.
Esta es la etapa en la que TI deja de ser un centro de costos que solo recibe quejas y comienza a ser la columna vertebral operativa que otros departamentos utilizan. El análisis predictivo también comienza a dar sus frutos en este punto, señalando posibles incidentes importantes antes de que escalen, en lugar de hacerlo solo después de que los tickets comiencen a acumularse.
Nada de esto es útil como una evaluación única. El valor de cualquier diagnóstico proviene de utilizarlo como un punto de control recurrente: identifica la mayor brecha entre tu estructura actual y el siguiente paso razonable, enfócate en cerrarla dentro de un plazo definido y solo entonces vuelve a evaluar. Intentar arreglar todo a la vez suele significar procesos a medio terminar en todos los ámbitos en lugar de una sola cosa bien hecha.
Un conjunto pequeño y recurrente de indicadores vinculados a una revisión mensual protege ese progreso mucho mejor que cualquier auditoría anual, principalmente porque los problemas salen a la luz mientras aún son lo suficientemente pequeños como para solucionarlos en una tarde, en lugar de convertirse en un proyecto de optimización de un trimestre. Cuatro métricas suelen ser suficientes para mantener la honestidad del equipo sin convertir la revisión en un ejercicio de investigación:
Los paneles que se actualizan automáticamente hacen que esto sea sostenible. Cuando el cumplimiento de los SLA, las tendencias en el volumen de tickets y la precisión de los activos son visibles sin que nadie tenga que compilar un informe manualmente, la revisión se convierte en una conversación de quince minutos en lugar de un proyecto de medio día, y esa diferencia es a menudo lo que separa a las organizaciones que siguen mejorando de aquellas que, en menos de un año, vuelven silenciosamente a apagar fuegos.
Si tu equipo nunca ha comparado sus prácticas actuales con un modelo como este, el ejercicio bien vale la tarde que requiere. Comienza con un análisis honesto de dónde provienen realmente las solicitudes y con qué consistencia se aprueban los cambios, y deja que eso determine qué sección de este plan deben abordar primero.
