Hay temas que en la práctica sostienen media organización. La planificación y el control de las TIC es uno de ellos. Porque una infraestructura puede ser técnicamente brillante y, aun así, fracasar si no está alineada con el negocio, si nadie mide bien su rendimiento o si una incidencia tarda horas en escalarse.

La tecnología empieza a ser útil de verdad cuando deja de ser un conjunto de equipos, aplicaciones y tickets, y se convierte en un servicio fiable, medible y gobernable. Ahí entran conceptos como la gestión de servicios e infraestructuras TIC, los acuerdos de nivel de servicio, la gestión de incidencias y marcos como ITIL o COBIT.

Planificación y control de las TIC: cómo convertir la tecnología en servicio, valor y confianza

La planificación y control de las TIC, no solo es comprar servidores, desplegar redes o contratar nube. Es algo bastante más importante: decidir qué necesita realmente la organización, cómo se presta ese servicio, qué riesgos asumimos, cómo medimos si funciona y qué hacemos cuando deja de funcionar.

Ese es el salto de madurez. Pasar de “tener tecnología” a “gobernar servicios”. Un CPD, una red corporativa, una plataforma de tramitación o un servicio SaaS no aportan valor por existir, sino por mantener niveles aceptables de disponibilidad, capacidad, seguridad, continuidad y soporte al usuario. ITIL sitúa precisamente ahí el foco: en crear, entregar y gestionar servicios, con una visión orientada al valor, apoyada en principios guía, cadena de valor del servicio y cuatro dimensiones de la gestión del servicio.

La gestión de servicios e infraestructuras TIC, por tanto, no va solo de operación técnica. Va de diseñar una prestación estable y repetible. Eso incluye catálogo de servicios, monitorización, gestión de capacidad, continuidad, seguridad, cambios, configuración y soporte. Y también incluye algo que muchas veces se subestima: traducir lo técnico a compromisos comprensibles para el negocio.

Ahí aparecen los acuerdos de nivel de servicio o SLA. Un SLA define qué servicio se presta, qué nivel de rendimiento se espera, cómo se mide y qué pasa si no se cumple. Puede existir entre proveedor y cliente externo, pero también dentro de la propia organización, entre áreas internas. Además, suele apoyarse en objetivos concretos de nivel de servicio, los conocidos SLO, y en métricas que permitan verificar si el servicio está respondiendo como debe. Un SLA no solo fija expectativas, también establece responsabilidades, mecanismos de medición y consecuencias ante incumplimientos.

Un SLA serio no debería quedarse en una frase tipo “soporte rápido y alta disponibilidad”. Debería concretar, por ejemplo, disponibilidad mensual, tiempos de respuesta, tiempos de resolución por severidad, ventana de mantenimiento, latencia, tasa de error, escalado y reporting. Y, sobre todo, debería evitar dos trampas muy habituales: medir cosas irrelevantes y prometer más de lo que la arquitectura puede sostener.

La pregunta buena no es “¿qué SLA queda bonito en un pliego o en un contrato?”, sino “¿qué nivel de servicio necesita realmente el proceso de negocio y qué coste tiene garantizarlo?”. Porque subir del 99,5 % al 99,95 % puede parecer un pequeño ajuste en una tabla, pero técnicamente suele exigir redundancia, automatización, operación más madura y, en muchos casos, bastante más presupuesto.

Todo esto conecta de forma directa con la gestión del valor de las TIC. Si la organización invierte en tecnología, tiene que poder explicar qué obtiene a cambio: menos caídas, mejor experiencia de usuario, más productividad, más trazabilidad, menor riesgo, mayor resiliencia o mejor cumplimiento. COBIT insiste justamente en esa idea de gobierno y gestión de la información y la tecnología orientados a las necesidades de las partes interesadas, con objetivos claros y métricas asociadas. Su modelo nuclear define 40 objetivos de gobierno y gestión, y su lógica de cascada traduce necesidades del negocio en objetivos, procesos y medición.

Por eso COBIT me parece especialmente útil cuando una organización ya no se conforma con “que TI funcione”, sino que quiere saber si TI está aportando valor real. El marco ayuda a conectar estrategia, procesos, controles, responsabilidades y métricas. Y eso importa mucho, porque el valor TIC no se demuestra con intuiciones. Se demuestra con evidencias.

En ese punto entran las métricas. COBIT trabaja con objetivos y métricas en distintos niveles, y la propia literatura de ISACA insiste en que deben adaptarse a cada organización, no copiarse sin pensar. Entre las métricas más razonables para este ámbito están el número de interrupciones que afectan al servicio, el porcentaje de cumplimiento de niveles acordados, la satisfacción de usuarios y áreas de negocio, el volumen de incidencias con impacto real y la tendencia de reclamaciones o degradaciones del servicio. ISACA también subraya que las métricas deben enlazar objetivos empresariales, objetivos TIC y objetivos de proceso.

Y llegamos a una de las piezas más visibles del día a día: la gestión de incidencias. Aquí el objetivo no es buscar la causa raíz perfecta en caliente, sino restaurar el servicio normal cuanto antes y reducir el impacto en el negocio. La práctica de Incident Management en ITIL se define precisamente por esa misión de recuperar rápidamente la operación normal del servicio tras una interrupción. PeopleCert, custodio actual de ITIL, insiste además en medir la eficacia de la práctica mediante factores de éxito y métricas clave.

Me gusta insistir en algo que a veces se confunde: una incidencia no es lo mismo que un problema. La incidencia exige respuesta operativa rápida; el problema busca causa raíz y prevención. Mezclar ambos planos ralentiza la respuesta. En operación real, primero se contiene, se comunica, se escala y se restaura. Después se analiza con calma.

En la práctica, un flujo sano de gestión de incidencias suele incluir detección, registro, categorización, priorización, diagnóstico inicial, escalado funcional o jerárquico, resolución, recuperación y cierre con documentación mínima útil. Si el incidente es grave, además, hace falta una disciplina específica de “major incident”: mando claro, comunicación frecuente, decisiones rápidas y trazabilidad.

Aquí es donde ITIL y COBIT no compiten, sino que se complementan. ITIL baja al terreno de la gestión del servicio, las prácticas operativas y la entrega de valor de forma continua. COBIT aporta una capa más ejecutiva y de gobierno: objetivos, control, alineamiento, rendición de cuentas y medición. Dicho de forma sencilla: ITIL me ayuda a gestionar mejor; COBIT me ayuda a gobernar mejor.

Y ambos cobran mucho más sentido cuando se aterrizan a infraestructuras reales. De hecho, si te interesa ver esta lógica aplicada al sector público y a servicios troncales de altísima criticidad, puedes visitar mi artículo sobre Redes públicas: El latido digital del Estado (SARA, sTESTA), donde explico precisamente la operación de redes e infraestructuras críticas y su necesidad de fiabilidad, seguridad y gestión continua.

Conclusión

Si tuviera que condensar todo este tema en una sola idea, sería esta: planificar y controlar las TIC no consiste en vigilar tecnología, sino en garantizar servicios que sostienen procesos de negocio. Y eso obliga a pensar en valor, no solo en componentes; en niveles de servicio, no solo en buena voluntad; en métricas, no solo en impresiones; y en gobierno, no solo en operación.

ITIL aporta una base sólida para organizar la gestión de servicios, especialmente en ámbitos como incidencias, niveles de servicio o mejora continua. COBIT, por su parte, da el marco para conectar esa gestión con objetivos de negocio, control, medición y rendición de cuentas. Juntos forman una combinación muy potente para cualquier organización que quiera pasar de la improvisación a una gestión TIC seria.

Y aquí está, para mí, la clave de fondo: cuando las TIC se gobiernan bien, dejan de ser “el departamento que arregla cosas” y pasan a ser una capacidad estratégica de la organización.

Si te interesa este enfoque, déjame tu visión en comentarios. Me interesa especialmente saber una cosa: ¿en tu experiencia el mayor problema suele estar en la tecnología, en la definición del servicio o en cómo se mide lo que TI realmente aporta?