Últimamente vengo conversando con varios líderes de procesos y operaciones, y hay una situación que aparece con bastante frecuencia.
La conversación suele empezar más o menos así:
“David, en mi empresa nos asignan ir solucionando dolor por dolor. El problema es que, cuando terminamos de resolver uno, aparece otro proceso que empieza a fallar. Y el ciclo nunca termina”.
Detrás de esta situación normalmente aparecen razones bastante conocidas: cada área trabaja con sus propias prioridades, existen silos entre equipos, el presupuesto es limitado y Tecnología tiene capacidad para atender solo dos o tres iniciativas realmente importantes al mismo tiempo.
El resultado es una organización que mejora, sí, pero muchas veces de manera reactiva.
Se resuelve el problema que más ruido genera.
Después el siguiente.
Y después el siguiente.
Mientras tanto, pueden existir otros procesos acumulando riesgos, retrabajos, controles manuales, dependencias entre personas o problemas de capacidad que todavía no son suficientemente visibles como para entrar en la agenda.
El problema de transformar mirando solo el dolor visible
Trabajar sobre los problemas más urgentes no está mal. En muchas ocasiones es inevitable.
El problema aparece cuando esa se convierte en la única forma de gestionar la transformación operacional.
Si una organización analiza sus procesos únicamente cuando algo falla, resulta muy difícil responder algunas preguntas bastante importantes:
- ¿Estamos realmente trabajando sobre los procesos más críticos?
- ¿Tenemos problemas similares repitiéndose en distintas áreas?
- ¿Existen riesgos relevantes que todavía no se han materializado?
- ¿Estamos utilizando nuestra limitada capacidad tecnológica en las iniciativas correctas?
- ¿Tenemos procesos dependiendo excesivamente de conocimiento que reside en unas pocas personas?
- ¿Quién es realmente responsable de que cada proceso evolucione?
Para responder esas preguntas necesitamos levantar un poco la mirada.
No necesariamente necesitamos realizar estudios de seis meses ni auditorías exhaustivas de cada proceso. En muchos casos, necesitamos primero construir una buena visión del conjunto.
Una alternativa: evaluar rápido, pero evaluar todo
Un enfoque que vale la pena probar consiste en realizar evaluaciones relativamente rápidas, pero completas y de alto nivel, de todos los procesos relevantes de la organización.
No se trata de documentar cada excepción ni revisar cada línea de código.
La primera pregunta debería ser mucho más sencilla: ¿qué tan sano está este proceso?
Para responderla se pueden evaluar algunas dimensiones comunes:
- Qué tan manual es el proceso y cuánto depende de personas o archivos.
- Qué riesgos relevantes existen y qué controles los mitigan.
- Qué nivel de medición y seguimiento tiene.
- Qué documentación soporta actualmente su operación.
- Si los roles, responsabilidades y ownership están realmente claros.
- Qué tan preparada está su tecnología para soportar el volumen y crecimiento esperado.
- Qué problemas, retrabajos o dependencias existen con otros procesos.
El objetivo no es obtener una evaluación perfecta. El objetivo es conseguir suficiente información para poder comparar procesos entre sí y decidir dónde vale realmente la pena intervenir.
Y aquí aparece una diferencia importante frente a muchos ejercicios tradicionales.
No necesitamos convertir cada evaluación inicial en una evaluación exhaustiva de riesgos, una revisión profunda de arquitectura, un análisis de seguridad de código o un levantamiento detallado de procedimientos.
Todo eso puede ser necesario después. Pero primero necesitamos saber dónde mirar con mayor profundidad.
El reto no es solamente diagnosticar
También he visto evaluaciones que generan decenas de matrices, scores y diagramas que posteriormente nadie utiliza.
Por eso creo que este ejercicio debería estar conectado directamente con un mecanismo de gobierno.
Una opción es establecer un comité interno —o complementarlo con especialistas externos cuando sea necesario— donde diferentes perspectivas puedan evaluar los procesos de manera conjunta.
Operaciones puede observar capacidad, eficiencia y puntos de quiebre.
Riesgos puede identificar exposiciones relevantes.
Tecnología puede evaluar sostenibilidad, obsolescencia e integraciones.
Seguridad puede advertir vulnerabilidades.
Procesos puede analizar estandarización, ownership y madurez.
Finanzas puede ayudar a entender dónde existe mayor impacto económico.
La conversación deja entonces de ser únicamente:
“¿Por qué este proceso funciona así?”
y empieza a convertirse en:
“Con lo que sabemos hoy, ¿qué deberíamos hacer con este proceso y qué tan prioritario es frente al resto?”
Ese cambio parece pequeño, pero modifica completamente el propósito del diagnóstico.
Hay una condición: el ejercicio tiene que terminar
Existe, sin embargo, un riesgo importante: convertir el diagnóstico en un proyecto permanente.
Si una organización tarda un año y medio en evaluar sus procesos, probablemente cuando termine el ejercicio parte de la información ya habrá cambiado.
Las estructuras organizacionales cambian. Los responsables cambian. La estrategia cambia. Aparecen nuevas tecnologías. Se modifican las prioridades.
Y cada cambio puede generar nuevas decisiones sobre dónde invertir la capacidad de transformación.
Por eso, este tipo de evaluación debería tener una meta agresiva: conseguir una primera visión completa de la organización en uno o dos trimestres.
No perfecta. Completa.
Después podrá profundizarse donde realmente exista una razón para hacerlo.
Lo importante aparece cuando podemos ver el mapa completo
Una vez que todos los procesos han pasado por criterios relativamente homogéneos, aparece algo extremadamente valioso: una matriz de salud o madurez operacional.
Ya no tenemos únicamente una lista de proyectos. Tenemos una visión de los procesos, sus principales riesgos, problemas, dependencias y niveles de madurez.
Y entonces podemos contrastar ambas cosas.
Por un lado¿Dónde están nuestros principales problemas operativos?
Por otro¿Dónde estamos invirtiendo actualmente nuestra capacidad de transformación?
Cuando ambas respuestas coinciden, probablemente estamos priorizando razonablemente bien. Cuando no coinciden, aparece una conversación que vale mucho la pena tener.
En mi experiencia, este tipo de evaluaciones ejecutivas tiene además una característica interesante: aun sin entrar inicialmente en un análisis exhaustivo, una gran parte de las conclusiones suele mantenerse cuando posteriormente se profundiza el diagnóstico.
En los ejercicios en los que he participado, diría que cerca del 90% de las primeras evaluaciones de riesgo o madurez realizadas con equipos experimentados terminan siendo razonablemente precisas.
No porque una evaluación de alto nivel reemplace un análisis especializado.
Sino porque quienes operan, administran y soportan los procesos normalmente conocen bastante bien dónde están los problemas. Lo que muchas veces falta es sentarlos alrededor de la misma mesa, aplicar criterios comunes y observar el sistema completo.
Y algunas soluciones pueden ser sorprendentemente simples
Una de las cosas que más me sigue llamando la atención es cuántos problemas pueden resolverse simplemente entendiendo mejor lo que ya existe dentro de la organización.
A veces no hace falta desarrollar una nueva aplicación. Ni implementar inteligencia artificial. Ni contratar una gran plataforma.
Hay procesos cuyo principal problema es que dos áreas nunca acordaron claramente quién hacía qué.
Hay controles que ya existen, pero otra área desconoce que existen.
Hay información disponible que otro equipo sigue generando manualmente.
Hay herramientas compradas por la organización que apenas se utilizan.
Hay actividades duplicadas porque cada área diseñó su propia solución.
En estos casos, el diagnóstico no genera valor por el documento producido. Genera valor porque hace visibles conexiones que antes nadie estaba observando.
También cambia la conversación sobre presupuesto
Tener una visión completa tiene otro beneficio importante. Permite sustentar mucho mejor dónde realmente se necesitan recursos.
En lugar de solicitar presupuesto diciendo:
“Necesitamos más capacidad para mejorar procesos”,
podemos mostrar que existen determinados procesos con altos niveles de riesgo, dependencia manual, crecimiento de volumen o problemas de control que requieren intervención.
Quizá la organización no apruebe todo el presupuesto solicitado. Eso probablemente seguirá ocurriendo.
Pero incluso un presupuesto reducido puede orientarse con mucha mayor precisión hacia los puntos donde generará mayor impacto.
Y eso es especialmente importante cuando Tecnología solamente puede priorizar unas pocas iniciativas cada año.
Diagramar no es el objetivo. Automatizar tampoco.
Quisiera cerrar con dos ideas que a veces pueden parecer contradictorias.
Sí: diagramar procesos por sí solo agrega poco valor.
Una organización no debería diagramar procesos únicamente para poder decir que están documentados o para estar preparada ante una auditoría.
Pero eso no significa que documentar no sea importante.
La documentación permite mantener el conocimiento de la empresa, entender dependencias, facilitar cambios y reducir la dependencia de determinadas personas.
De la misma manera, automatizar un proceso tampoco debería ser considerado automáticamente un resultado.
Podemos lanzar una automatización, celebrar que entró a producción y descubrir algunos meses después que casi nadie la utiliza, que el proceso continúa teniendo los mismos problemas o que simplemente trasladamos una ineficiencia desde una persona hacia un sistema.
El valor aparece cuando esa automatización realmente reduce tiempos, costos, errores o riesgos y ayuda a conseguir los objetivos de la organización.
Y ambos puntos —documentación y transformación— terminan conectándose con un mismo concepto: gobierno de procesos.
Las organizaciones necesitan un rol, equipo o mecanismo que asegure que los procesos tengan ownership. Que exista claridad sobre quién responde por su evolución. Que los esfuerzos de transformación se asignen donde realmente generan valor. Que los proyectos no terminen con una implementación tecnológica, sino con resultados. Y que el conocimiento de cómo funciona la empresa permanezca disponible incluso cuando las personas, las estructuras y las prioridades cambien.
Porque probablemente hay algo que continuará siendo cierto durante los próximos años:
las organizaciones van a seguir cambiando.La diferencia es que cada vez lo harán más rápido.
Y mientras más rápido cambia una empresa, más importante se vuelve tener claridad sobre cómo funcionan, quién gobierna y hacia dónde deben evolucionar sus procesos.