Sales Cockpit · 4 movimientos comerciales identificados
Expansión de alcance
211.259incidentes
Gancho de apertura El 99,1% del volumen está fuera del alcance actual de Kyndryl — 211.259 incidentes que hoy atienden otros equipos.
MTTR promedio 39,0 h · 188 clusters sin cobertura Kyndryl.
Automatización rápida
3.531incidentes
Gancho de apertura 4 patrones con solución repetitiva identificada — listos para propuesta de autoservicio y runbooks en semanas, no meses.
MTTR bajo en todos. Impacto inmediato y demostrable.
Estabilización estructural
673.000horas
Gancho de apertura No es soporte más rápido — es deuda técnica acumulada en plataformas críticas que ya cuesta más de 670.000 horas al período.
El gasto operativo no baja sin intervención estructural.
Observabilidad y gobierno
117.078incidentes
Gancho de apertura Antes de automatizar a escala hay un problema de visibilidad: el 54,94% del universo no tiene aplicativo asignado.
Sin trazabilidad no hay clasificación automática ni ownership claro.

Contexto del análisis: Marzo 2025 a Enero 2026

Dónde se concentra el esfuerzo operativo y qué capacidad se puede recuperar

En el período analizado, el dataset acumula 213.105 incidentes y 975.586 días laborales (jornadas de 8 horas) de gestión. Leído como narrativa operativa, muestra tres señales útiles para una conversación comercial: la demanda se concentra en frentes específicos, la carga operativa es entendible y la oportunidad puede priorizarse de forma gradual.

Brecha de trazabilidad
54,94%
o 117.078 incidentes sin aplicativo asignado.
Concentración del dolor
32,54%
del volumen cae en solo 8 clusters.
Capacidad consumida
975.586
Días de gestión en el período.
Oportunidad de automatizar
6.836
incidentes con patrón repetitivo identificado.

Resumen de hallazgos

Cuatro lecturas que conviene dejar claras antes de entrar a detalle de plataformas o soluciones.

Hallazgo principal
Existen 117.078 incidentes sin aplicativo asignado.

Los incidentes que no tienen aplicativo asignado, además del efecto operativo, indican una brecha de clasificación, ownership y observabilidad que conviene cerrar.

Concentración
69.351 de los incidentes pertenecen a solo 8 clusters.

Estos incidentes se agrupan en los 8 clusters principales. Equivalen al 32,54% del volumen y al 30,57% del total de horas.

Esfuerzo acumulado
7,8 M
Horas de resolución de incidentes en este periodo.

horas de resolución en el período. Más que un volumen de tickets, representa capacidad operativa ya consumida.

Agenda estructural
831,9 k h
Equivale al 10,66% del total de horas de resolución.

horas concentradas en 8 aplicaciones candidatas a estabilización o modernización. Parte del gasto operativo proviene de deuda técnica.

Lectura detallada de los hallazgos

Tres observaciones que conviene articular con claridad en la conversación comercial.

Observación 1 · Brecha de trazabilidad

Contexto para la primera parte de la conversación.

Hay 117.078 incidentes (54,94%) no tienen aplicativo asignado. La operación no solo atiende tickets, también trabaja con una brecha de contexto y ownership.
Accion: antes de automatizar a escala, conviene fortalecer trazabilidad, clasificación y observabilidad.

Observación 2 · El volumen tiene un mapa claro
El 14,71% del volumen total se concentra en 8 aplicaciones (31.356 incidentes). Existe un bloque concreto donde el dolor se repite.
Accion: priorizar este frente permite mostrar impacto temprano sin intervenir todo el landscape.
31.356 incidentes 14,71% del total 516,2 k horas
Observación 3 · El tiempo se distribuye de forma asimétrica
El 20,11% de las horas totales se concentra en Gestion de la Propiedad Activos Fijos (1.569.558 horas con 4.151 incidentes). Aqui el problema principal no es cantidad de tickets, sino complejidad estructural.
Accion: tratar este frente como agenda de estabilizacion y modernizacion, no solo de atencion reactiva.
4.151 incidentes 20,11% de horas MTTR 426,7 h

Lectura del tiempo perdido

Una sola historia en tres pasos: magnitud total, traducción operativa y bloque accionable.

Paso 1
Capacidad ocupada total
975.586 dias
7.804.684 h del periodo

Capacidad operativa total consumida en el periodo analizado.

Paso 2
Capacidad ocupada no prioritaria
677.314 dias
5.418.510 h

Resto de capacidad consumida fuera del bloque inicial de intervencion.

Paso 3
Capacidad prioritaria
298.272 dias
2.386.174 h en 8 clusters

Bloque de mayor impacto para intervenir primero y recuperar capacidad.

Puntos de entrada sugeridos

Tres frentes defendibles como primer alcance.

Mesa N1
10,17%
21.682 incidentes. Es el frente más natural para estandarización, autoservicio y shift-left.
Big Data y ATM
12.329
La combinación de volumen y horas altas los ubica en la agenda de estabilización operativa.
Observabilidad
117.078
54,94% del total sin aplicativo asignado constituye un frente por sí mismo.

Aplicaciones con mayor visibilidad operativa

Cuando la aplicación tiene equipo responsable identificado, la conversación se vuelve accionable. Los responsables específicos se omiten en esta vista para proteger la privacidad; se incluyen en el anexo entregable.

NU4390001 · MFA Alphanumeric
6.209
Frente más visible en volumen, aunque no el más pesado en horas. Equipo responsable asignado.
MTTR 5,3 h Autenticación
AS0058001 · ZTNA
5.782
El patrón apunta a conectividad, sesión y WARP. Equipo responsable asignado.
MTTR 7,2 h Conectividad
AP0004001 · Directorio Activo On Premise
4.537
Frente con potencial para autoservicio de grupos y desbloqueos. Equipo responsable asignado.
MTTR 8,9 h Accesos
AW0988001 · Sqoop
189,8 k h
Caso donde el peso está en el tiempo perdido y no en el volumen. 4.161 incidentes con MTTR 49,3 h. Equipo responsable asignado.
4.161 incidentes MTTR 49,3 h Batch / ETL
NU0214001 · Sucursal Virtual Negocios Web
103,9 k h
Frente con foco en datos, validaciones y sincronización. Equipo responsable asignado.
2.681 incidentes MTTR 39,7 h
NU4770001 · Servicios de Impresión
3.118
El patrón apunta a configuración, impresión y periféricos. Equipo responsable asignado.
MTTR 11,3 h Periféricos
AW0183001 · Who is Who
2.566
Concentración en configuración, imágenes y scanback. Equipo responsable asignado.
MTTR 4,6 h Configuración
AW0434001 · Murex Core
2.302
Combina accesos, demoras y jobs sobre tiempo máximo. Equipo responsable asignado.
MTTR 26,9 h Core / procesos

Distribución entre Kyndryl y otros equipos

Ayuda a separar el alcance actual de Kyndryl y el espacio donde otros equipos concentran el dolor operativo.

Volumen atendido por Kyndryl
1.846
Menor volumen, mayor complejidad: respaldos TSM, permisos e integraciones Helix, Sterling/MFT, integración de datos y certificados o clusters MQ.
MTTR 57,3 h 22 clusters Helix TSM MQ / Sterling
Volumen fuera del alcance actual de Kyndryl
211.259
Concentra el volumen masivo en alertas sin falla real, indisponibilidad de acceso, bloqueos MFA, ZTNA, batch, AD y patrones repetitivos de bajo valor.
MTTR 39,0 h 188 clusters MFA ZTNA Batch / Bizagi
Top cluster Kyndryl · Helix / Innovation
244
Cluster más visible dentro de Kyndryl: permisos, consultas e integraciones. MTTR promedio 91,0 h; 22.119,5 h acumuladas.
MTTR 91,0 h 22.119,5 h Helix / Smart IT
Top cluster Kyndryl · Respaldos TSM
192
Fallas de respaldo con MTTR promedio de 62,2 h. Frente claro para automatización correctiva y estabilización.
MTTR 62,2 h 11.943,8 h TSM
Top cluster externo · Fallas batch
2.467
Cluster dominante fuera de Kyndryl. MTTR promedio 76,6 h. Agrupa eventos batch, alertas y validaciones manuales.
MTTR 76,6 h 188.865,6 h Batch
Top cluster externo · Bizagi
2.303
Combina acceso, datos y casos pegados. MTTR promedio 48,9 h. Uno de los frentes más claros para estabilización fuera de Kyndryl.
MTTR 48,9 h 112.563,5 h Bizagi

Principales clusters operativos

Cada tarjeta muestra el cluster, su peso relativo y ejemplos reales del campo texto_combinado. El detalle se despliega al hacer clic, para mantener la vista inicial limpia.

Fallas e intermitencias en procesos batch

2.467
1,16% del total · 188.865,6 h · MTTR 76,6 h

Uno de los clusters más pesados en tiempo de resolución.

Ver ejemplos
Mezcla eventos batch, alertas que requieren validación y fallos por dependencias o intermitencia.
Ejemplo 1: evento de collector con intermitencia de dominio y confirmación manual de servicio.
Ejemplo 2: alerta reportada que termina validándose como sitio operativo.

Bizagi · Indisponibilidad y casos pegados

2.303
1,08% del total · 112.563,5 h · MTTR 48,9 h

Conviven indisponibilidad de acceso, datos de usuario y casos que no avanzan.

Ver ejemplos
Bizagi aparece como una mezcla de acceso, activación manual y lentitud funcional.
Ejemplo 1: reporte que tarda demasiado o sale vacío y termina con recomendación operativa.
Ejemplo 2: usuario con error unknown que requiere activación formal.

SVN · Inconsistencias de datos y sincronización

1.357
0,64% del total · 156.376,6 h · MTTR 115,2 h

Menor volumen, pero con uno de los MTTR más altos. El frente es calidad de datos y sincronización.

Ver ejemplos
Errores de registro, roles inconsistentes y necesidad de cambio técnico o parametrización.
Ejemplo 1: cliente no puede completar proceso por error de validación en API.
Ejemplo 2: inconsistencia de rol que obliga sincronización con MDM.

Reejecución y monitoreo de procesos batch

1.329
0,62% del total · 57.313,5 h · MTTR 43,1 h

Cluster con solución repetitiva: validar, esperar o reejecutar.

Ver ejemplos
La operación vuelve a reprocesar, esperar antecesores o monitorear hasta cierre.
Ejemplo 1: datafix con grupo de bases de datos mientras el proceso se valida.
Ejemplo 2: proceso demorado por antecesores que termina OK sin cambio estructural.

Fallas recurrentes ZTNA / Cloudflare WARP

1.203
0,56% del total · 6.117,6 h · MTTR 5,1 h

Alto volumen, bajo MTTR y solución repetitiva. Perfil adecuado para autosanación.

Ver ejemplos
El usuario no conecta, pierde sesión o debe restablecer credenciales cifradas.
Ejemplo 1: no conecta ZTNA para Bizagi o Sufipro.
Ejemplo 2: páginas inaccesibles hasta reautenticación y restablecimiento.

Office 365 / Teams · Accesos y MFA

921
0,43% del total · 15.295,2 h · MTTR 16,6 h

Se mueve entre permisos, grupos y cliente Teams, con alta automatización posible.

Ver ejemplos
La mayoría de casos gira en torno a restricciones de acceso, menús que no aparecen o falta de grupos.
Ejemplo 1: carpeta o módulo sin grupos disponibles para el usuario.
Ejemplo 2: Teams requiere reinstalación por error de configuración local.

Reseteo recurrente de MFA

920
0,43% del total · 3.321,4 h · MTTR 3,6 h

Patrón simple y repetitivo. Candidato fuerte para autoservicio guiado.

Ver ejemplos
Usuario cambia dispositivo, pierde la app o queda bloqueado y solicita reset.
Ejemplo 1: restablecimiento por eliminación de la aplicación de autenticación.
Ejemplo 2: reconfiguración completa con guía para Microsoft Authenticator.

Alertas Dynatrace sin afectación real

748
0,35% del total · 14.605,1 h · Monitoreo

El hallazgo no es el incidente, sino la oportunidad de afinar observabilidad y reducir ruido.

Ver ejemplos
Alertas que se validan y cierran sin afectación real.
Ejemplo 1: al validar no se identifica afectación del servicio.
Ejemplo 2: acción innecesaria o pico transitorio sin impacto.

Frentes con oportunidad de automatización

Patrones repetidos que el propio historial señala como candidatos a industrialización.

Reinicio y activación por indisponibilidad de acceso
1.568
Patrón claro para runbooks: servicio, estado de instancia, activación de usuario y reconexión guiada.
Bloqueo MFA y reenrolamiento
920
Candidato a autoservicio con validación de identidad y guía de reenrolamiento.
Reejecución batch por dependencias
823
La repetición del mismo remedio sugiere autocorrección, reintento controlado y orquestación.
ZTNA / WARP
818
Sesión expirada, cliente fuera de estado y reautenticación conforman un bloque ideal para remediación guiada.

Frentes con agenda de estabilización o modernización

Cuando el objetivo deja de ser reducir tickets simples y pasa a ser reducir deuda operativa estructural.

Sqoop
189,8 k h
El patrón batch, ETL y dependencia entre procesos sugiere hardening de plataforma más que soporte reactivo.
Informatica Intelligent Cloud Service
104,3 h
El MTTR promedio refleja complejidad técnica sostenida.
Bizagi Go y Bizagi Generador
180,6 k h
Acceso, activación, roles e indisponibilidad dibujan una deuda operativa concreta.
Sucursal Virtual, Contact Center, Murex y Finacle
303,5 k h
Datos, sincronización, jobs y dependencias entre plataformas críticas conforman un frente claro de estabilización.