Gobernanza del catálogo de servicios: Cómo hacer vinculantes los SLAs, OLAs y KPIs

Una gobernanza del catálogo de servicios que funcione determina en la práctica si las promesas de servicio son gestionables y verificables, o si en la operativa cotidiana desembocan en discusiones, escalaciones y hallazgos de auditoría. Muchas organizaciones tienen un catálogo de servicios en la herramienta o en el wiki, pero sin obligatoriedad: los SLA no están definidos de forma medible, los OLA son solo «acuerdos de equipo» sin capacidad de ejecución, los KPI se informan por intuición o no pueden acreditarse en una auditoría.

En este artículo no se trata de términos ITIL por sí mismos, sino de una mecánica de gobernanza implementable: qué contenidos necesita obligatoriamente un catálogo de servicios, cómo encajan los SLA (Service Level Agreements, es decir, compromisos de servicio hacia el cliente) y los OLA (Operational Level Agreements, es decir, acuerdos internos de entrega entre equipos), cómo definir los KPI (Key Performance Indicators, indicadores medibles de control) de modo que la monitorización, el ticketing y el reporting hablen el mismo idioma —y cómo hacer todo esto apto para auditoría.

El estado objetivo está claro: la dirección de TI puede priorizar y presupuestar los servicios, las operaciones pueden escalar de forma ordenada, Security y Compliance pueden aportar evidencias, y la dirección ejecutiva recibe informes verificables en lugar de semáforos interpretados.

Por qué «definido» no es lo mismo que «vinculante»

La vinculidad surge solo cuando una promesa de servicio es apta para la toma de decisiones: debe ser inequívoca, medible, asignada a un propietario, documentada con dependencias realistas e integrada en un régimen de cambios y reporting. De lo contrario, en la práctica suele ocurrir lo siguiente:

• Inflación de SLA: Las áreas de negocio reclaman «99,9% de disponibilidad» o «soporte 24/7» como estándar. Sin un modelo de costes y riesgos se promete lo que luego no se puede cumplir.
• Lagunas de OLA: El propietario del servicio «vende» un SLA, pero los equipos internos no tienen tiempos de reacción y entrega vinculantes, no existe una regla de guardias, ni compromiso de capacidad.
• Teatro de KPI: Existen KPI, pero la fuente, la lógica de cálculo y el alcance son ambiguos. En auditorías o en escalaciones no es posible rastrear cómo se obtienen las cifras.
• Contradicciones entre herramientas: La monitorización mide algo distinto al sistema de tickets, y el reporting mide otra cosa. Las discusiones giran entonces en torno a los datos en lugar de las acciones.

La gobernanza del catálogo de servicios es por tanto menos «documentación» y más un marco de control y evidencia: quién decide qué, en base a qué datos, y con qué consecuencias ante desviaciones.

Separar claramente los términos: SLA, OLA y KPI en el contexto operativo

La causa más frecuente de imprecisión es una lógica de niveles incorrecta. Una separación práctica se ve así:

• SLA (Service Level Agreement): Acuerdo entre TI (o proveedor de servicios TI) y el «cliente» (área de negocio, filial, clientes externos). Contenido: horarios de servicio, disponibilidad, canales de soporte, objetivos de reacción y resolución, ventanas de mantenimiento, obligaciones de comunicación, responsabilidades, excepciones.
• OLA (Operational Level Agreement): Acuerdo interno entre equipos/unidades que posibilitan el SLA (p. ej., equipo de plataforma, red, base de datos, operaciones de seguridad). Contenido: tiempos de reacción internos, traspasos, tareas operativas, condiciones de aceptación, guardias, dependencias, estándares técnicos mínimos.

Importante: un SLA es una promesa. Un OLA es una capacidad de entrega. Los KPIs son la medición. La gobernanza conecta los tres mediante roles, fuentes de datos, control de versiones, escalado y medidas correctoras.

Gobernanza del catálogo de servicios como sistema de decisión y control

Si configura el catálogo de servicios como instrumento de gobernanza, no debe tratarlo como una lista de „cosas que hace TI“, sino como un inventario controlado de servicios con un ciclo de vida definido. Las preguntas clave son:

• ¿Qué servicios son oficiales? („aptos para catálogo“ con propietario, ciclo de vida, modelo de costes, riesgos)
• ¿Qué niveles de servicio existen realmente? (estándar, ampliado, crítico – con condiciones y asignación de precios/CapEx/OpEx)
• ¿Cómo se mide? (fuente de monitorización, lógica de cálculo, alcance, calidad de datos)
• ¿Cómo se decide? (aprobación de excepciones de SLA, priorización de mejoras, decisiones de inversión)
• ¿Cómo se evidencia? (registro de auditoría, versiones, evidencias, informes, seguimiento de acciones)

Esta lógica reduce la carga operativa: las escalaciones son menos „personales“ porque se basan en criterios definidos. Al mismo tiempo, el cumplimiento se vuelve manejable porque las evidencias provienen de un sistema controlado en lugar de capturas de pantalla reunidas ad hoc.

Los contenidos mínimos de una entrada de catálogo de servicios auditable

Una entrada del catálogo de servicios debe ser lo suficientemente completa para que un nuevo responsable (o auditor) pueda situar el servicio sin conocimiento implícito. En la práctica han demostrado su eficacia campos obligatorios que pueden reflejarse en herramientas (ITSM, CMDB) o en una estructura centralizada de documentación.

Campos obligatorios (compactos, pero completos)

• Nombre y propósito del servicio: ¿Qué soporta el servicio en la empresa, para quién, con qué delimitación?
• Propietario del servicio: responsable funcional de los niveles de servicio, priorización, decisiones de presupuesto/riesgo (no solo „jefe de equipo de operaciones“).
• Propietario técnico / responsabilidad operativa: quién opera, quién realiza cambios, quién autoriza medidas de emergencia.
• Criticidad del servicio: clase de impacto empresarial (p. ej. financiera, regulatoria, crítica para la seguridad) con criterios claros.
• Horarios de servicio y canales de soporte: p. ej. 8×5/12×5/24×7, canal de incidentes, ruta para incidentes mayores.
• Componentes del SLA: disponibilidad (¡definición!), objetivos de respuesta/solución, ventanas de mantenimiento, obligaciones de comunicación.
• Dependencias: plataformas internas, identidad, red, proveedores externos; cada una con referencia OLA.
• Concepto de medición: fuentes de datos, cálculo, puntos de medición, exclusiones, retención de datos (para auditoría).
• Requisitos de seguridad y cumplimiento: p. ej. registro (logging), retención, controles de acceso, cifrado, ciclos de parcheo, gestión de vulnerabilidades.
• Reglas de cambio/lanzamiento: cambios estándar vs. cambios de riesgo, CAB/Change Advisory Board (comité para autorizaciones de cambio) u otra lógica de aprobación.
• Ciclo de vida: introducción, operación, deprecación/retirada, ruta de migración.

Quien aquí considere conscientemente «demasiado»: precisamente esta información se solicita de todas formas en las escalaciones. Gobernanza significa mantenerla estructurada de antemano.

Formular los SLAs de modo que sean medibles y negociables

Muchos textos de SLA están formulados jurídicamente u organizativamente, pero no son medibles técnicamente. Eso genera conflictos en dos situaciones: en caso de incumplimiento y en la auditoría. Un SLA fiable requiere por tanto ventanas de medición definidas, límites claros del sistema y un cálculo transparente.

Componentes típicos de un SLA y sus riesgos

• Disponibilidad: Defina «Service up» como un estado medible (p. ej., transacción sintética exitosa, comprobación de salud de la API, inicio de sesión posible) y aclare si las ventanas de mantenimiento están excluidas. Evite métricas puramente de infraestructura (p. ej., «Servidor accesible») como disponibilidad del servicio.
• Rendimiento: Si el rendimiento es relevante para el SLA, debe quedar claro: punto de medición (cliente, Edge, Backend), percentil (p. ej., p95), periodo, exclusiones (p. ej., picos de carga por ejecuciones masivas autorizadas).
• Reacción y resolución de incidentes: El tiempo de reacción no es igual al tiempo de resolución. Defina los puntos de inicio (¿entrada del ticket? ¿alarma?), cambios de estado en el ITSM y reglas para el caso de información faltante.
• Ventanas de mantenimiento y cambios: La gobernanza requiere una política clara: quién aprueba, cómo se anuncia, cómo se revierte, qué evidencias se generan.
• Comunicación: Especialmente en servicios críticos, un SLA de comunicación suele ser tan importante como los valores técnicos: quién informa a quién, por qué canal, con qué cadencia en incidentes graves.

Ayuda para la toma de decisiones: niveles de SLA como producto, no como lista de deseos

En lugar de renegociar cada servicio cada vez, resulta eficaz un conjunto modular de 2–4 niveles de SLA (p. ej., Estándar, Ampliado, Crítico). La regla de gobernanza es: las desviaciones son posibles, pero sujetas a aprobación y deben transparentar costes/riesgos. Eso evita los «SLA en la sombra» por correo electrónico.

OLAs como cadena de suministro: compromisos internos a lo largo de las dependencias

Los OLAs suelen subestimarse, pero son la palanca real para la responsabilidad. Porque un responsable del servicio sólo puede responsabilizarse de un SLA si los equipos internos han prometido sus contribuciones. En la práctica eso significa: cada servicio necesita un mapa de dependencias con compromisos internos de entrega claros.

Qué debe incluir un OLA (y qué no)

• Objetivos de reacción y de gestión: p. ej., «DBA reacciona en 30 minutos ante P1» (con criterio P1 definido).
• Reglas de guardia: On-Call, niveles de escalación, suplencia.
• Puntos de transferencia: cuándo se considera que un ticket/incidente está «transferido», qué información es obligatoria (enlace al runbook, logs, métricas).

No deben incluirse en un OLA: objetivos imprecisos («en breve»), listas de deseos técnicas sin ruta de operación o dependencias sin responsable. Los textos OLA son contratos de trabajo entre equipos – deben funcionar en operación.

KPIs: De la métrica al control (y a la evidencia de auditoría)

Los KPIs solo tienen sentido si influyen en decisiones. En el contexto de la gobernanza del catálogo de servicios se distinguen tres clases:

• SLA-KPIs (contractuales): p. ej. disponibilidad en la ventana de medición, cumplimiento de objetivos de respuesta/solución por prioridad.
• KPIs operativos (de control): p. ej. volumen de incidentes por servicio, incidentes repetidos, tasa de fallos en cambios (Change-Failure-Rate), Mean Time to RESTore (MTTR).
• KPIs de cumplimiento/seguridad (de control): p. ej. cumplimiento de parches, cobertura de logging, revisiones de permisos en plazo, plazos de corrección de vulnerabilidades según criticidad.

Una regla importante de gobernanza: Cada KPI necesita una ficha técnica. Sin ficha técnica del KPI, el reporting se convierte en una cuestión de interpretación. Una ficha técnica de KPI incluye como mínimo definición, cálculo, fuente de datos, frecuencia de medición, responsables, valor objetivo/umbrales y tratamiento de lagunas de datos.

Concepto de medición: fuentes de datos, cálculo y capacidad probatoria

La obligatoriedad a menudo no fracasa por falta de voluntad, sino por datos inconsistentes. Por ello, un concepto de medición es obligatorio — especialmente si los SLAs deben ser válidos en caso de disputa o ante una auditoría.

Directrices prácticas para un concepto de medición robusto

• Fuente única de la verdad por KPI: Defina qué sistema es la fuente (Monitoring, ITSM, Log-Analytics). Valores mezclados sin regla clara son susceptibles de impugnación.
• Sincronización temporal: base de tiempo uniforme (NTP), zonas horarias definidas, asignación clara de eventos (inicio/fin de incidente).
• Disciplina de puntos de medición: la disponibilidad del servicio mediante chequeos de servicio (transacciones sintéticas) es más representativa que los pings del host.
• Conservación de datos: para auditoría y análisis de tendencias los datos en bruto deben estar disponibles durante el tiempo suficiente (retención de logs, métricas, tickets).
• Documentar excepciones: ventanas de mantenimiento, fuerza mayor, tiempos de inactividad aprobados por el negocio: todo debe versionarse y ser demostrable.

Si desea estandarizar políticas o pasos de verificación, ayuda una plantilla breve y copiable. Ejemplo de una estructura de política interna (sin contenido específico de herramientas, pero utilizable como lista de control):

POLICY: Medibilidad de KPI y SLA (estándar breve)

1) Cada valor de SLA tiene:
   - Ventana de medición (horas, días)
   - Punto de medición (chequeo sintético / API / endpoint)
   - Definición "cumplido/no cumplido"
   - Regla para ventanas de mantenimiento y tiempo de inactividad autorizado

2) Cada KPI tiene una ficha técnica:
   - Nombre del KPI, propósito, responsable
   - Fórmula de cálculo
   - Fuente de datos primaria (sistema + conjunto de datos)
   - Frecuencia de medición y frecuencia de reporte
   - Valor objetivo/umbrales + regla de escalado
   - Verificación de calidad de datos (valores faltantes, duplicados)

3) Comprobabilidad:
   - Retención de datos brutos (al menos X meses según directiva interna)
   - Versionado de informes (no sobrescribir un informe mensual posteriormente)
   - Registro de auditoría para excepciones (autorizaciones de cambio/mantenimiento)

Roles, responsabilidades y escalamiento: sin RACI no hay gobernanza

En la práctica la gobernanza se vuelve tangible cuando las responsabilidades no solo se nombran, sino que son efectivas en la toma de decisiones. Para ello es útil una lógica RACI: Responsible (ejecutante), Accountable (con responsabilidad última), Consulted (a consultar), Informed (a informar).

Conjunto mínimo de roles para la gobernanza del catálogo de servicios

• Service-Owner (Accountable): responde por los compromisos SLA, priorización, asuntos de presupuesto/riesgo y autorizaciones de excepción.
• Operations Owner / Betriebsverantwortlicher (Responsible): garantiza runbooks, monitorización, procesos on-call y la respuesta a incidentes.
• Resolver Groups (Responsible): equipos especializados (red, DB, plataforma) que entregan OLAs.
• Security/Compliance (Consulted/Control): define requisitos de evidencia y control, revisa la calidad de KPI y logging, y acompaña las auditorías.
• Service Management / ITSM-Funktion (Responsible): opera el proceso del catálogo, el versionado, los ciclos de revisión y los estándares de reporting.

Sin estos roles cada escalamiento se convierte en un problema organizativo. Con roles claros, se convierte en un problema de proceso —y por tanto solucionable.

Mecanismos de gobernanza: versionado, ciclos de revisión y procesos de excepción

Para que los SLA/OLA/KPI sigan siendo vinculantes se necesitan mecanismos que controlen los cambios y eviten compromisos obsoletos. Tres elementos son especialmente eficaces:

1) Versionado con fecha de vigencia

Cada versión de SLA/OLA debe incluir una fecha de vigencia y una razón del cambio. Lo importante no es el „papel“, sino la trazabilidad: ¿qué reglas estaban vigentes cuando ocurrió un incidente?

2) Revisiones periódicas (no solo tras problemas)

La cadencia adecuada depende de la criticidad del servicio: servicios críticos con más frecuencia, servicios estándar con menos. Una revisión debe cubrir al menos: tendencias de KPI, incidentes mayores, fallos recurrentes, calidad de cambios, capacidad/cola de trabajo, hallazgos de seguridad. El resultado debe incluir siempre decisiones (corregir, aceptar, invertir, reducir alcance).

3) Proceso de excepción con lógica de riesgo y coste

Las excepciones son normales: un departamento solicita un nivel de servicio mayor, un sistema legacy no alcanza ciertos valores, un proveedor impone límites. Se vuelve vinculante cuando las excepciones se registran formalmente: temporales, justificadas, aprobadas, con un plan de medidas o con aceptación consciente del riesgo.

Una plantilla práctica de excepción como bloque copiable:

PLANTILLA: Excepción SLA/OLA (Formulario breve)

- Servicio afectado:
- Valor afectado (SLA/OLA/KPI):
- Desviación (real vs. objetivo):
- Justificación (técnica/organizativa):
- Impacto en el negocio si se mantiene:
- Evaluación de riesgo (p. ej. disponibilidad, seguridad, cumplimiento):
- Medidas compensatorias (monitorización, fallback, comunicación):
- Limitación temporal (hasta fecha) y fecha de revisión:
- Aprobador (Service-Owner + en su caso cumplimiento/seguridad):

Perspectiva de auditoría: Qué evidencias suelen faltar

Las auditorías (internas o externas) rara vez verifican solo si existe un documento. Valoran si la organización gobierna y puede aportar evidencias. Las lagunas típicas en la gobernanza de SLA/OLA/KPI son:

• Falta de un registro de auditoría consistente: los informes se modifican a posteriori, las excepciones no se versionan, las ventanas de mantenimiento no son trazables.
• Origen de datos poco claro: los valores KPI son «del dashboard», pero faltan los datos crudos, las consultas o las reglas de cálculo.
• Falta de responsabilidad definida: no se ha designado un Service-Owner o no tiene derechos de decisión (presupuesto, priorización, aprobación de excepciones).
• Controles sin seguimiento: los hallazgos se documentan, pero las medidas no se persiguen (sin responsable, sin plazos, sin evidencia de eficacia).
• Confusión de alcance: componentes de infraestructura se presentan como servicio sin una visión end-to-end (identidad, rutas de red, dependencias externas).

Si desea alcanzar la auditabilidad, piense en artefactos: documentos SLA/OLA versionados, hojas de datos KPI, vinculaciones de tickets, aprobaciones de cambios, informes de incidentes mayores, evidencias de revisiones y listas de medidas.

Costes y capacidad: Por qué los niveles de servicio siempre requieren un modelo operativo

Los niveles de servicio no son solo «objetivos», sino que consumen capacidad: turnos de guardia, redundancia, monitorización, esfuerzo de pruebas, costes de repuestos y licencias, contratos con proveedores, controles de seguridad. La gobernanza debe hacer visible esta conexión; de lo contrario las SLAs se convierten en un compromiso presupuestario implícito.

Factores de coste concretos que deben considerarse en decisiones de SLA

• On-call y capacidad 24/7: cobertura de personal, cadenas de escalamiento, runbooks, formación.
• Redundancia y failover: infraestructura adicional, complejidad operativa, pruebas periódicas (pruebas de failover).
• Monitorización y observabilidad: checks sintéticos, retención de logs, alertas, reporting SLO/SLA.
• Seguridad en cambios: entornos de staging, mecanismos de rollback, procesos de aprobación, automatización.
• Seguridad/Cumplimiento: controles más estrictos (p. ej. obligaciones de logging y revisión más rigurosas) aumentan el esfuerzo pero reducen el riesgo.

La dirección de TI necesita claridad decisoria: ¿Qué servicios son tan críticos que justifican un nivel de servicio superior? ¿Qué riesgos se aceptan? ¿Qué deudas técnicas (Technical Debt) impiden alcanzar un objetivo y cuánto cuesta eliminarlas?

Lógica de implementación: en 6 pasos hacia SLAs, OLAs y KPIs vinculantes

Un error típico es el «Big Bang»: definirlo todo primero y desplegar después. En la práctica, un enfoque iterativo es más estable cuando aporta gobernanza desde el inicio.

1. Delimitar el portafolio de servicios: Empiece con 10–20 servicios que sean realmente relevantes (procesos de negocio críticos, incidentes frecuentes, relevancia regulatoria).
2. Establecer ownership: Asigne por servicio un Service-Owner con mandato de decisión, además de responsables de operación y grupos de resolución (Resolver Groups).
3. Establecer medición: Definir 3–5 KPIs por servicio, determinar las fuentes de datos, crear fichas de KPI y aclarar la retención de datos.
4. Definir un kit de SLAs: 2–4 niveles de servicio con ventanas de medición claras, horarios de servicio, objetivos de respuesta/solución y obligaciones de comunicación.
5. Formalizar OLAs según las dependencias: Para cada valor relevante del SLA debe existir un compromiso interno correspondiente (incl. On-Call y traspasos).
6. Establecer un ritmo de gobernanza: Ciclos de revisión, proceso de excepciones, reporting, seguimiento de medidas. Solo entonces escale a más servicios.

Importante: cada etapa aporta un beneficio operativo. Ya después del paso 3 puede tomar mejores decisiones, porque existe medición y responsabilidad.

Lista de comprobación: preguntas de gobernanza que debe responder por servicio

Esta lista de comprobación está intencionadamente formulada con enfoque en auditoría y operación. Si puede responder „sí“ aquí, estará mucho más cerca de la obligatoriedad que muchas organizaciones con documentos extensos pero ineficaces.

• ¿Existe un Service-Owner nombrado con mandato de decisión (presupuesto, prioridades, excepciones)?
• ¿Están los valores de SLA definidos de forma que sean medibles técnicamente (punto de medición, ventana de medición, exclusiones)?
• ¿Existe para cada valor de SLA una fuente de datos y un cálculo documentado?
• ¿Existen OLAs para todas las dependencias esenciales (incl. disponibilidad on-call, traspasos, cambios estándar)?
• ¿Está la priorización de incidentes clara y aplicada de forma consistente en ITSM/monitoring?
• ¿Hay ventanas de mantenimiento definidas y un proceso de cambios trazable?
• ¿Se almacenan los informes KPI versionados y los datos en bruto están disponibles durante el tiempo suficiente?
• ¿Existe un proceso de excepciones con plazo, aceptación de riesgos y plan de acciones?
• ¿Existe un ritmo de revisión fijo con decisiones y tareas documentadas?
• ¿Están los requisitos de seguridad y cumplimiento anclados en el catálogo de servicios (logging, acceso, parches, evidencias)?

Conflictos típicos y cómo los resuelve la gobernanza

La gobernanza del catálogo de servicios es también gestión de conflictos con reglas claras. Tres conflictos recurrentes pueden mitigarse con una mecánica bien definida:

Conflicto 1: «Necesitamos 24/7» vs. capacidad de entrega real

Solución: un kit de SLAs con lógica de costos/capacidad y una excepción formalizada. Si se exige 24/7, debe quedar claro qué cadena de on-call, qué redundancia y qué pruebas se financian. Sin esa cadena, 24/7 es solo una etiqueta.

Conflicto 2: «El KPI parece bueno» vs. los usuarios se quejan

Solución: comprobar el punto de medición (End-to-End en lugar de infraestructura), percentiles en vez de medias, transacciones sintéticas. La gobernanza obliga a definir qué significa «el servicio funciona».

Conflicto 3: «Esto es un problema de plataforma» vs. «esto es un problema de servicio»

Solución: cadena OLA y Resolver Groups con entregas claras. Las escalaciones no se gestionan por personas, sino por límites de responsabilidad y plazos definidos.

Conclusión: La obligatoriedad surge de la medibilidad, la responsabilidad y la evidencia

Los SLAs, OLAs y KPIs no se vuelven vinculantes por el hecho de figurar en un documento. Se vuelven vinculantes cuando su gobernanza del catálogo de servicios conecta de forma coherente tres elementos: definiciones medibles (incluidas fuentes de datos y cálculo), responsabilidad con capacidad de decisión (propietario del servicio con mandato y cadena OLA) y control demostrable (versionado, revisiones, proceso de excepciones, pista de auditoría).

Si empieza de manera pragmática, con un portafolio de servicios acotado y un claro modelo de medición y roles, surge rápidamente un efecto: menos discusiones sobre cifras, más enfoque en las medidas. Y eso es precisamente la diferencia entre un «catálogo de servicios» y un catálogo de servicios que realmente soporta la operación, el cumplimiento y la gestión.

Para este tema también son importantes la gestión de servicios TI y las vías de escalación. El artículo sitúa estos aspectos de forma comprensible y muestra qué resulta importante en la práctica diaria.