El problema: TI habla un idioma que gerencia no entiende

El gerente de TI entra a la reunión ejecutiva y dice:

• "Implementamos CI/CD en 4 ambientes, reducimos el MTTR de 2 horas a 30 minutos."
• "Tenemos 99.5% de uptime, con RTO de 4 horas y RPO de 1 hora."
• "Procesamos 50 millones de transacciones diarias con latencia promedio de 120ms."

El CEO mira confundido. ¿Eso está bien? ¿Está mal? ¿Cuánto vale? ¿Qué decisión tomo con esa información?

El problema es este: los KPIs técnicos tradicionales no están conectados con lo que a la gerencia le importa:

• ¿Cuánto dinero cuesta mantener esa infraestructura?
• ¿Si baja la disponibilidad, cuánto dinero pierdo por caída?
• ¿Mis clientes están satisfechos con la velocidad, o debería invertir más?
• ¿Hay riesgos de seguridad que deba conocer ahora?
• ¿La velocidad de desarrollo de nuevas funciones es competitiva?

Un buen conjunto de KPIs de TI responde preguntas de negocio, no preguntas técnicas.

Los 5 pilares de KPIs de TI que importan a la gerencia

1. Disponibilidad: ¿Cuándo el negocio se detiene?

KPI Clave: Uptime de sistemas críticos (por sistema)

• Qué medir: Disponibilidad del ERP, plataforma de ventas, portal del cliente, etc.
• Fórmula: (Tiempo total - Tiempo de caída) / Tiempo total × 100
• Unidad: Porcentaje (%). Meta típica: 99.5% o superior.
• Frecuencia: Mensual (pero monitoreo 24/7).

¿Por qué importa a la gerencia?

Si tu e-commerce cae 2 horas un sábado por la tarde (cuando hay más tráfico), perdiste ventas. ¿Cuántas? Si tu promedio es 50 órdenes/hora × S/ 500/orden = S/ 25,000/hora. Una caída de 2 horas = S/ 50,000 perdidos (sin contar reputación dañada).

Métricas complementarias:

• MTTR (Mean Time To Recover): Tiempo promedio para recuperarse de un incidente. Si un gerente espera que cuando se caiga el ERP se recupere en 30 minutos, MTTR es crítico.
• RTO (Recovery Time Objective): Máximo tiempo que el negocio puede tolerar sin el sistema. ¿El ERP se puede caer por 4 horas? Probablemente no. RTO = 1 hora es más realista.
• RPO (Recovery Point Objective): Cuántos datos puedes perder. Si RPO = 1 hora, es aceptable perder transacciones de última hora.

Meta recomendada para PYMES:

• Sistemas críticos: 99.5% uptime (máx 3.6 horas/mes de caída).
• Sistemas secundarios: 99% uptime (máx 7.2 horas/mes).
• MTTR: menos de 30 minutos para críticos.

2. Velocidad: ¿Los clientes esperan mucho?

KPI Clave: Tiempo de respuesta (latencia) y throughput

• Latencia p95: El 95% de las transacciones se completa en X milisegundos. Meta: menos de 500ms para interfaces de usuario, menos de 100ms para APIs.
• Throughput: Transacciones por segundo que tu sistema puede procesar. Si tu plataforma maneja 100 transacciones/seg pero tienes 150 en pico, hay problema.
• Tiempo de carga de página: El 95% de las páginas carga en menos de 2 segundos. Cada segundo extra = 7% menos conversión (empíricamente probado).

¿Por qué importa a la gerencia?

Un sitio lento = clientes que se van. Un portal que tarda 10 segundos en cargar = tus operarios desperdician 5 minutos/día (10 seg × 30 operaciones/día). Con 30 operarios × 5 min × S/ 20/hora ÷ 60 = S/ 50 al día. S/ 50 × 250 días/año = S/ 12,500/año en productividad perdida.

Meta recomendada para PYMES:

• Latencia p95: menos de 300ms.
• Throughput: 20-30% superior a pico histórico.
• Tiempo de carga: menos de 2 segundos (web), menos de 1 segundo (mobile).

3. Calidad y confiabilidad: ¿Los sistemas fallan siempre en lo mismo?

KPI Clave: Tasa de errores y fallos recurrentes

• Error rate: Porcentaje de transacciones que fallan (p.e., "500 Server Error"). Meta: menor a 0.1%.
• Fallos recurrentes: ¿Hay un bug que hemos "arreglado" 5 veces? Eso es calidad mala, no un arreglo de verdad.
• Regresiones: Errores que reaparecen en versiones nuevas. Si pasada al 10% de errores en regresión, el proceso QA está quebrado.
• Defectos encontrados en producción vs en testing: Idealmente 90% de bugs se encuentran antes de ir a producción. Si 30% escapa a producción, hay problema.

¿Por qué importa a la gerencia?

Un cliente llama diciendo "No puedo facturar, el sistema me da error". Si esto sucede 5 veces al mes con errores diferentes, es un problema de calidad. Si sucede por el mismo error 5 veces, es un problema de proceso (no aprendes de tus errores). Ambos son costosos.

Meta recomendada para PYMES:

• Error rate: menor a 0.1%.
• Cero fallos recurrentes (mismo bug no aparece 2 veces en el mismo año).
• Máximo 10% de defectos escapen a producción.

4. Costo: ¿Cuánto nos cuesta cada transacción/usuario?

KPI Clave: Costo por unidad de valor

• Costo por transacción: Gasto total en TI ÷ transacciones procesadas al mes. Si gastas S/ 50,000 en TI y procesas 1 millón de transacciones, costo = S/ 0.05/transacción.
• Costo por usuario activo: Si tienes 100 usuarios activos internos y S/ 15,000 en costos TI/mes = S/ 150/usuario/mes.
• Costo por línea de negocio: ¿Cuánto de tu presupuesto TI va a "ventas" vs "operaciones" vs "finanzas"?
• Costo total por propietario (TCO): Licencia + mantenimiento + energía + personal. Una máquina que cuesta S/ 10,000 de compra, cuesta S/ 3,000/año de mantenimiento por 4 años = TCO total = S/ 22,000.

¿Por qué importa a la gerencia?

El CEO pregunta: "¿Nuestro costo de tecnología está en línea con el sector?" Si gastas 5% de ingresos en TI y el promedio en tu industria es 3%, algo está mal. Si gastas 1%, probablemente estés subespecificado.

Meta recomendada para PYMES (por ingresos):

• Retail/E-commerce: 3-5% de ingresos en TI.
• Manufactura: 2-4%.
• Servicios profesionales: 5-8%.
• Finanzas: 6-10%.

Si una PYME de S/ 3,000,000 anuales gasta S/ 150,000 en TI, es 5% (está bien para retail). Si gasta S/ 50,000 (1.7%), probablemente está subespecificada.

5. Riesgo y seguridad: ¿Estamos expuestos a ataques o falla regulatoria?

KPI Clave: Vulnerabilidades, cumplimiento, auditorías

• Vulnerabilidades críticas sin parchar: Si un scanner de seguridad encuentra 50 vulnerabilidades críticas y 0 están parcheadas, es un riesgo ENORME. ¿Cuántas tienen solución dentro de 24 horas?
• Cumplimiento de facturación electrónica (SUNAT): ¿Puedes producir reportes de auditoría de cambios en comprobantes? ¿Log de quién facturó qué y cuándo?
• Acceso no autorizado detectado: Número de intentos de acceso fallidos repetidos, logins desde IPs sospechosas, acceso fuera de horario a datos sensibles.
• Cumplimiento de backups: ¿Qué porcentaje de datos críticos están respaldados? Mínimo 100% para datos críticos.
• Auditoría de cambios: ¿Cada cambio en producción está documentado, autorizado y puede revertirse?

¿Por qué importa a la gerencia?

Una multa de SUNAT por falta de auditoría de facturación = S/ 10,000 a S/ 100,000. Un ataque ransomware que cifra tus datos = pérdida total de negocio. Un backup que no funciona cuando lo necesitas = pérdida de años de información.

Meta recomendada para PYMES:

• Cero vulnerabilidades críticas sin parchear (máximo 7 días para parchar).
• 100% de cumplimiento SUNAT en auditoría de facturas.
• 100% de datos críticos respaldados, 1 backup verificado restaurable/mes.
• 100% de cambios en producción documentados.

Comparación de enfoques: Métricas tradicionales vs Métricas de negocio

Métrica Tradicional (TI)	Lo que gerencia oye	Métrica de Negocio (mejor)	Acción resultante
99.95% uptime	Confusión	Máx 2.2 horas caída/mes, costo de caída = S/ 100K/hora	"Invirtamos en backup de infraestructura"
MTTR 30 minutos	¿Eso está bien?	Incidente promedio impacta S/ 50K de ingresos por hora	"Necesito alertas automáticas a los 2 minutos"
Latencia p95 200ms	Desconoce el impacto	Cada 100ms extra = 2% menos conversiones (S/ 30K/mes perdidos)	"Optimicemos la BD o escalemos servidores"
Error rate 0.5%	¿Cuánto es eso en dinero?	1 de 200 transacciones falla, cuesta 2 horas de soporte por fallo = S/ 40 por error	"Implementemos testing automático más exhaustivo"
TI cuesta 3% de ingresos	OK, supongo	Benchmarks: e-commerce debería gastar 4-5%, estamos bajo-especificados	"Aprobamos presupuesto para nueva infraestructura"
30 vulnerabilidades críticas	¿Debería preocuparme?	Riesgo de ataque = exposición de 2M de registros de clientes, multa potencial SUNAT S/ 50K	"Presionemos para parchear en 24 horas"

Dashboard recomendado: Los 10 KPIs que tu CEO debería ver

Actualización: Diaria (excepto metas que son mensuales)

#	KPI	Cómo se calcula	Meta para PYME típica	Si baja de meta, acción
1	Uptime sistemas críticos	% tiempo que ERP/web/app está disponible	99.5%	Reunión de crisis, investigar causa raíz
2	MTTR promedio	Tiempo de recuperación incidentes críticos	Menos de 30 min	Mejorar documentación, runbooks, alertas automáticas
3	Latencia p95	% transacciones responden en menos de 300ms	95% bajo 300ms	Auditoría de BD, caché, optimizaciones
4	Error rate en producción	% transacciones que fallan (5xx errors)	Menor a 0.1%	Rollback de cambio reciente, fix crítico
5	Defectos escapen a producción	Bugs encontrados en producción vs testing	Máximo 10% de defectos	Mejorar testing, code review, QA process
6	Vulnerabilidades críticas sin parchear	Número de CVEs críticas pendientes de arreglo	Cero (máx 7 días para parchar)	Parching de emergencia, pedir fondos adicionales
7	% Datos críticos respaldados	Cobertura de backups 3-2-1 (3 copias, 2 medios, 1 off-site)	100%	Ampliar política de backups
8	Costo por transacción	Gasto TI anual / transacciones procesadas	Según industria (3-5% ingresos)	Optimizar infraestructura o aumentar precio
9	Tiempo de despliegue (deployment)	Promedio horas desde "código listo" a "en producción"	Menos de 2 horas (idealmente minutos)	Implementar CI/CD, automatizar pruebas
10	Adopción de nuevas funciones	% usuarios activos usando features nuevas dentro de 30 días	Mayor a 60%	Mejorar documentación, capacitación, UX

Caso real: Empresa de distribución en Arequipa (80 empleados)

La situación inicial:

El gerente de TI presentaba mensualmente:

• "Tenemos 99.8% de uptime" (parecía excelente).
• "Procesamos 50,000 transacciones/día" (impresionante número).
• "Los servidores tienen 45% de utilización" (en principio, bueno).

Pero el CEO vio un problema diferente:

• Cada caída (aunque fuera 0.2% del tiempo) ocurría durante el pico de pedidos en la tarde. Resultado: Pérdidas de S/ 80K cada vez (20 pedidos perdidos × S/ 4,000/pedido).
• La facturación electrónica demoraba 5 segundos en confirmar. Los operarios se quejaban. Tasa de error en ingreso de datos: 8% (debería ser menor a 1%).
• Un malware pasó por el sistema sin ser detectado durante 3 días. Los backups no fueron restaurados correctamente. Perdieron 2 días de datos de cobranza.

La solución (KPIs de negocio implementados en 4 semanas):

• Cambio de métrica: No "99.8% uptime", sino "máximo 2 incidentes críticos/mes, cada uno impacta S/ 80K".
• Latencia p95 en facturación bajó a 1 segundo con caché y BD optimizada.
• Error rate en facturación bajó a 0.5% con validaciones automáticas.
• Test de restore de backup cada 2 semanas (no solo "existe un backup").
• Vulnerabilidades: escaneo automático 1x/mes, parching dentro de 48 horas.

Resultados en 6 meses:

• Incidentes críticos: de 3/mes a 1/mes (ahorro S/ 160K anual).
• Error rate facturación: de 8% a 0.8% (menos devoluciones, menos auditoría manual).
• Tiempo de facturación: de 5s a 1s (operarios 30% más rápidos).
• Confianza en backups: 100% (verificados restaurables).
• Invulnerabilidades críticas: 0 sin parchear (pasaron auditoría SUNAT sin comentarios).

Inversión:

• Optimización BD: S/ 5,000 (pago único).
• Caché (Redis): S/ 300/mes.
• Herramienta de monitoreo (New Relic): S/ 800/mes.
• Tiempo personal TI: 80 horas (ya incluidas en nómina).
• Total año 1: S/ 10,600.
• ROI: (S/ 160K ahorrado + 30% productividad + cero multas SUNAT) / S/ 10,600 = 15x en el primer año.

Gobernanza de KPIs de TI: Roles y proceso

Roles clave:

• CEO/Dueño: Establece metas estratégicas, aprueba inversiones en base a ROI.
• CTO/Gerente TI: Reporta el estado de KPIs, propone mejoras, asigna recursos.
• Lead Técnico (infraestructura, desarrollo): Responsable de ejecutar mejoras, investigar desviaciones.
• Product Manager: Monitorea KPIs de adopción y satisfacción de usuario.

Cadencia de revisión:

• Diaria: Alertas automáticas en rojo (uptime bajo, error rate alto, vulnerabilidades nuevas). Acción inmediata.
• Semanal: Reunión técnica con equipo TI. ¿Hay tendencias preocupantes?
• Mensual: Reporte a ejecutivos. Comparar contra metas, identificar brechas, aprobar acciones.
• Trimestral: Revisión de tendencias a largo plazo, re-calibrar metas según contexto.

Errores comunes al implementar KPIs de TI

1. Demasiadas métricas.

Si muestras 50 KPIs, el CEO no va a tomar ninguna decisión. Máximo 10 KPIs, enfocados en lo que importa al negocio.

2. KPIs que nadie puede controlar.

Si tu KPI es "aumentar transacciones/mes" pero eso depende de ventas, no de TI, fracasarás. El equipo responsable debe tener control sobre el resultado.

3. Metas poco realistas o sin contexto.

"99.99% uptime" es lindo de oír pero cuesta S/ 500K/año en infraestructura redundante. Para una PYME, 99.5% es más realista. Define metas donde inversión = beneficio.

4. No conectar KPIs con dinero.

"Latencia p95 bajo 500ms" vs "Cada 100ms extra cuesta S/ 30K/mes en conversiones perdidas". Cuál te mueve más como CEO? El segundo. Convierte KPIs en dinero.

5. Medir pero no actuar.

Dashboard hermoso pero nadie hace nada si un KPI baja. Cada KPI rojo debe tener propietario y plan de acción en 24 horas.

6. Ignorar la tendencia.

Un KPI puede estar "en meta" pero con tendencia a bajar. "99.5% uptime en mes 1, 99.3% en mes 2, 99.1% en mes 3". Eso es tendencia mala. Monitorea la dirección, no solo el valor.

Implementación en 8 semanas

Semana 1-2: Alineación y selección de KPIs

• Reunión con CEO: ¿Cuáles son las 5 cosas que más te preocupan de TI?
• Mapeo: Para cada preocupación, ¿hay un KPI que la mida?
• Seleccionar máximo 10 KPIs iniciales.

Semana 3-4: Baseline y herramientas

• Medir estado actual de cada KPI (¿dónde estamos hoy?).
• Seleccionar herramientas de monitoreo (Grafana, New Relic, DataDog, Prometheus).
• Conectar fuentes de datos.

Semana 5-6: Metas y alertas

• Definir meta para cada KPI (realista, alcanzable, medible).
• Configurar alertas automáticas (rojo = acción inmediata).
• Documentar qué hacer si cada KPI baja.

Semana 7-8: Reporte y governance

• Crear dashboard ejecutivo (CEO-friendly).
• Entrenar a equipo en cómo reportar y actuar.
• Ir en vivo.

Herramientas recomendadas para monitoreo y KPIs

Herramienta	Mejor para	Costo (S//mes para PYME)
Grafana	Monitoreo infraestructura, métricas técnicas	S/ 0 - 1,500 (open source + cloud)
Prometheus	Recolección de métricas (complemento con Grafana)	S/ 0 (open source)
New Relic	APM (monitoreo aplicaciones), uptime, errores	S/ 500 - 3,000
Datadog	Observabilidad completa (logs, métricas, traces)	S/ 1,000 - 5,000
Sentry	Error tracking, alertas de bugs en producción	S/ 0 - 2,000
Uptime Robot	Monitoreo uptime de sitios/APIs	S/ 0 - 600
Kibana (Elastic)	Análisis de logs, búsqueda	S/ 1,000 - 4,000

Conclusión: Los KPIs de TI son KPIs de negocio

Hace años, TI era un "cost center" (centro de costo). Hoy, TI es un diferenciador competitivo. Tu infraestructura, velocidad, confiabilidad y seguridad directamente impactan ingresos.

Por eso los KPIs de TI no deben hablarse en "porcentajes de uptime" o "latencias en milisegundos". Deben hablarse en dinero:

• "Cada incidente crítico cuesta S/ 100K en ingresos perdidos. Este mes tuvimos 2, ahorramos S/ 200K con infraestructura redundante."
• "Cada segundo de latencia extra cuesta S/ 1,500/mes. Optimizamos la BD y nos ahorramos S/ 9,000."
• "La vulnerabilidad que no parcheamos habría costado S/ 1M si nos hubiera atacado. Gastamos S/ 10K en el fix."

Cuando hablas así, el CEO entiende. Y aprueba presupuesto.

Checklist: ¿Estás listo para tus KPIs de TI?

• ¿Sabes cuál es el costo (en dinero) de una caída de tu sistema?
• ¿Monitoreas latencia en producción en tiempo real?
• ¿Tienes alertas automáticas para eventos críticos?
• ¿Sabes tu porcentaje de errores en producción?
• ¿Hay reunión mensual donde TI reporta KPIs al CEO?
• ¿Cada KPI rojo tiene propietario y plan de acción?

Si contestaste sí a 4 de 6, estás en buen camino. Si contestaste no a todas, es hora de empezar.