Cómo medir una transformación digital más allá del conteo de proyectos

Muchas transformaciones digitales se reportan igual que una campaña de marketing: número de iniciativas lanzadas, sistemas implementados, usuarios capacitados, licencias activadas. Son datos fáciles de contar y cómodos de presentar en comité. El problema es que no dicen nada sobre si la operación cambió. Un proyecto puede estar "cerrado" y el proceso seguir ejecutándose con las mismas planillas, los mismos correos de coordinación y los mismos errores de traspaso entre áreas.

Medir una transformación digital, en términos útiles para un gerente TI o una jefatura de operaciones, es construir observabilidad sobre el proceso: poder responder con evidencia si el flujo de punta a punta se comporta distinto, si las tareas manuales ceden, si los sistemas efectivamente se hablan entre sí y si la trazabilidad mejora o se rompe en algún punto. Este artículo se enfoca en esa capa de instrumentación, no en el reporte de portafolio.

Qué implica medir una transformación digital más allá del conteo de proyectos

Contar proyectos mide actividad, no efecto. Un portafolio con veinte iniciativas en curso puede convivir con un proceso central que sigue dependiendo de una planilla compartida y de una persona que "sabe cómo hacerlo". Al revés, una transformación con pocos proyectos visibles puede estar moviendo indicadores operativos de forma sostenida.

La diferencia clave es qué se observa:

• Actividad: cuántas iniciativas hay, en qué fase están, cuánto presupuesto consumen, cuántos usuarios pasaron por capacitación.
• Efecto operativo: cómo se comporta el proceso después del cambio. Cuánto tarda un trámite de punta a punta, cuántas veces se reingresa el mismo dato, cuántos handoffs entre áreas requieren intervención humana, cuántos eventos quedan sin registro.

La actividad es necesaria para gestionar el portafolio, pero no sirve como evidencia de transformación. El efecto operativo es lo que permite decir si algo cambió en la forma de trabajar. Y para observarlo hace falta instrumentación: puntos de captura en el flujo, no reportes armados a mano al cierre del mes.

Un error común es tratar la medición como una capa de reporting posterior. Si los datos se reconstruyen manualmente cada vez que hay que presentar avances, la propia medición se vuelve un proceso fragmentado más. La observabilidad útil se diseña junto con el proceso, no después.

Señales técnicas que conviene observar

No se trata de instrumentar todo, sino de elegir pocas señales que reflejen si el proceso está cambiando de verdad. Estas son las que suelen dar más información por unidad de esfuerzo.

Trazabilidad de punta a punta. ¿Se puede reconstruir el recorrido completo de una solicitud, un pedido o un incidente sin preguntarle a nadie? La señal no es "tenemos logs", sino si un evento se puede seguir desde su origen hasta su cierre cruzando los sistemas involucrados. Cuando la trazabilidad se corta en un handoff, aparece el clásico "eso lo maneja el área X por correo". Ese corte es un indicador en sí mismo.

Tareas manuales residuales. No se eliminan todas, y no todas conviene eliminarlas. Lo relevante es observar cuáles persisten y por qué: reingreso de datos entre sistemas, validaciones que se hacen a ojo, conciliaciones en planilla, aprobaciones que dependen de que alguien revise una bandeja. Si después de digitalizar un proceso esas tareas siguen ahí en la misma proporción, el cambio fue de interfaz, no de flujo.

Integración efectiva entre sistemas. Que exista una integración no significa que esté operando como se esperaba. Conviene observar frecuencia de ejecución, volumen de registros intercambiados, errores y reintentos, y cuántos casos terminan resueltos por intervención manual. Una integración que falla en silencio y se corrige a mano cada semana es, en la práctica, una tarea manual disfrazada.

Comportamiento de los flujos operativos. Tiempos de ciclo de punta a punta, no por etapa aislada. Colas que se acumulan en un punto específico. Variabilidad: un proceso que a veces tarda horas y a veces días suele indicar dependencias no resueltas. Tasa de reprocesos y de excepciones. Estos indicadores se leen mejor como tendencia que como valor puntual.

La forma de leerlos importa tanto como la señal. Un tiempo de ciclo que baja puede deberse a una mejora real o a que se está midiendo solo la parte automatizada y dejando fuera el tramo manual. Antes de celebrar una mejora, conviene verificar que la medición cubre el mismo alcance que antes.

Errores frecuentes y límites al medir

Indicadores de vanidad. Número de usuarios activos en una plataforma, cantidad de dashboards publicados, porcentaje de procesos "digitalizados" según un inventario interno. Se ven bien y no dicen si el proceso mejoró. El riesgo es que empiecen a gestionarse como si fueran el objetivo.

Métricas sin línea base. Si no se midió el proceso antes de intervenirlo, cualquier número posterior es interpretable de cualquier manera. No siempre es posible reconstruir una línea base perfecta, pero sí acordar un punto de partida razonable antes de seguir avanzando, aunque sea aproximado y documentado como tal.

Datos fragmentados entre áreas. Cada equipo mide su parte con su propia definición, y nadie puede hablar del proceso completo. Esto es especialmente problemático cuando la transformación cruza sistemas legados y plataformas nuevas: si el dato se corta en la frontera entre ambos, la medición hereda la fragmentación que la transformación debía resolver.

Sobreinterpretar una métrica. Un solo indicador rara vez explica el estado de un proceso. La tasa de automatización sin contexto de excepciones, o el tiempo promedio sin mirar la distribución, llevan a conclusiones equivocadas. Conviene leer señales en conjunto y aceptar que algunas preguntas no tienen respuesta con los datos disponibles.

Límites reales. No todo es medible con el mismo esfuerzo. Instrumentar un proceso crítico puede requerir cambios en los sistemas de origen que no están en el alcance actual. En esos casos, es más honesto declarar el límite que fabricar un indicador sustituto que no refleja el flujo real. La observabilidad también tiene costo operativo: capturar, almacenar y mantener datos exige esfuerzo sostenido.

Criterio práctico para aplicarlo en una operación real

La medición útil empieza por elegir pocas señales y sostenerlas en el tiempo. Un punto de partida razonable:

1. Elegir uno o dos procesos críticos, no todo el mapa. Idealmente aquellos donde el dolor es visible: procesos fragmentados, con tareas manuales intensivas y baja trazabilidad de punta a punta.
2. Definir el alcance de la medición de forma explícita: dónde empieza y dónde termina el flujo que se va a observar. Esto evita comparaciones engañosas más adelante.
3. Identificar los puntos de captura en los sistemas que ya existen. En muchos casos no hace falta instrumentación nueva: se trata de usar mejor lo que los sistemas ya registran (eventos, timestamps, estados, logs de integración).
4. Acordar una línea base, aunque sea aproximada, y dejarla documentada con su alcance y sus limitaciones.
5. Revisar tendencia, no valor puntual. Un mes aislado dice poco. La señal está en la dirección y en la consistencia.
6. Usar los datos para decidir, no para reportar. Si un indicador no cambia ninguna decisión, probablemente no vale el costo de mantenerlo.

Este enfoque se conecta directamente con el trabajo de Transformación Digital: la observabilidad no es una capa final del proyecto, sino parte de cómo se diseña el cambio desde el inicio. Cuando la medición se piensa junto con el proceso, los indicadores reflejan la operación; cuando se agrega al final, reflejan lo que fue fácil contar.

Un criterio útil para saber si la medición está bien planteada: ¿podría alguien fuera del equipo, con acceso a los datos, reconstruir el estado del proceso sin pedir explicaciones? Si la respuesta es no, probablemente lo que hay es un reporte, no observabilidad.

En el contexto normativo local, la preparación frente a marcos como la Ley 21.719 refuerza la necesidad de trazabilidad y control sobre el tratamiento de datos, pero conviene tratarlo como un motivo adicional para instrumentar bien los flujos, no como una garantía de cumplimiento. La medición aporta evidencia; la evaluación de cumplimiento es un trabajo aparte.