Orquestar equipos de TI y negocio en automatización
Orquestar equipos de TI y de negocio en un proyecto de automatización significa construir un lenguaje común entre los dos y sostener el alineamiento desde el kick-off hasta la entrega. Lo que traba estos proyectos rara vez es la tecnología. Es la coordinación entre quien conoce el proceso y quien construye la solución.
¿Por qué TI y negocio no hablan el mismo idioma?
El equipo de negocio convive con el dolor diario y quiere una solución rápida. TI piensa en arquitectura, seguridad y mantenimiento a largo plazo. Ninguno está equivocado. El problema aparece cuando cada lado asume que el otro entiende sus prioridades sin que nadie las haya explicado.
Ese desencuentro tiene un precio documentado. El estudio The Essential Role of Communications de PMI muestra que dos de cada cinco proyectos no alcanzan sus objetivos originales, y que la mitad de esos fracasos se relaciona con comunicación ineficaz. En dinero: por cada USD 1.000 millones invertidos, 75 millones quedan en riesgo por fallas de comunicación. La investigación es de 2013, y el patrón que mide se ve igual en los proyectos de hoy.
Cuando un proyecto de automatización se traba, conviene investigar la conversación antes de culpar a la herramienta. La mayoría de las veces el cuello de botella está a mitad de camino entre los dos equipos: requisitos que cambiaron sin aviso y prioridades que cada área entendió distinto.
¿Cómo alinear expectativas antes de la primera automatización?
El trabajo de alineamiento empieza en el kick-off y sigue una secuencia que ahorra retrabajo.
- Mapear los dolores actuales del negocio en detalle, escuchando a quien ejecuta el proceso todos los días.
- Traducir las necesidades en requisitos que los dos lados puedan leer. Si el documento solo le hace sentido a TI, todavía no está listo.
- Validar con todos los involucrados antes de cualquier desarrollo, incluidos límites, riesgos y plazos.
- Dejar las decisiones por escrito para evitar reinterpretaciones tres meses después.
Ese último punto suele ser el más descuidado. Una decisión registrada cierra una discusión; una recordada la reabre cada semana. El mismo cuidado aplica a lo que ya existe: documentar y versionar automatizaciones protege el proyecto cuando quienes lo diseñaron cambian de función.
¿Qué rituales mantienen a los dos equipos en ritmo?
La rutina de cualquier equipo está llena de demandas, y la sincronía entre áreas no ocurre sola. Algunos mecanismos simples resuelven la mayor parte del problema.
- Reuniones cortas y frecuentes entre los principales involucrados, con agenda concreta y seguimiento de los pendientes.
- Tableros visuales que cualquiera pueda leer sin traducción técnica.
- Una revisión conjunta en cada entrega, con feedback franco de los dos lados.
- Espacio para experimentar: errores chicos, corregidos rápido, enseñan más que meses de planificación defensiva.
El formato importa menos que la constancia. Una reunión quincenal que siempre ocurre vale más que una ceremonia semanal que se cancela todo el tiempo.
¿Cuál es el rol del liderazgo en esta orquestación?
En proyectos de automatización, quien lidera carga dos funciones: gestionar el cronograma y traducir entre las áreas cuando aparecen los conflictos. Algunas competencias pesan más que otras en ese rol.
- Comunicación sin jerga restringida a un lado.
- Visión sistémica, para ver más allá del problema inmediato.
- Autoridad para decidir y destrabar impasses.
- Disposición a escuchar el contexto del negocio antes de aceptar cualquier solución técnica.
Cuando el liderazgo se mantiene cerca, los problemas aparecen temprano y cuestan poco. Cuando delega todo y desaparece, los problemas aparecen en la entrega.
¿Por qué el diseño del proceso viene antes que la herramienta?
Detrás de toda automatización que funciona hay un proceso diseñado con quien lo opera a diario. Sistemas prometedores fracasan seguido por una razón simple: automatizan un flujo que no corresponde a cómo trabaja la gente de verdad.
Los datos apuntan en la misma dirección. En la investigación Automation with Intelligence de Deloitte, los procesos inmaduros y fragmentados aparecen por cuarta edición consecutiva como la principal barrera para automatizar a escala, y el 52% de las organizaciones menciona la dificultad de cambiar procesos y formas de trabajo al intentar automatizar de punta a punta.
Un ejemplo hipotético ayuda. Imagina una distribuidora mediana que decide automatizar la aprobación de pedidos. Comercial pide velocidad: aprobación en minutos. TI señala que el límite de crédito del cliente se verifica en un sistema separado, actualizado una vez por día. Si nadie se sienta a rediseñar el flujo en conjunto, la automatización nace aprobando pedidos con datos viejos, y el primer incobrable se vuelve un argumento contra todo el proyecto. Un rediseño conjunto, con una regla de excepción para pedidos por encima de un tope, habría resuelto el impasse antes de la primera línea escrita.
Por eso empezamos cualquier proyecto mapeando cómo ocurre el trabajo hoy, escuchando a quien opera el proceso, antes de discutir tecnología. Si tu operación todavía no tiene esa foto, mapear los cuellos de botella ocultos es un buen punto de partida.
¿Cómo mantener el compromiso después del kick-off?
Perder impulso después del arranque es un reclamo recurrente en proyectos de automatización. El entusiasmo del kick-off dura pocas semanas, los ajustes demoran y los resultados se corren. Algunos mecanismos sostienen el ritmo.
- Dividir el proyecto en entregas más chicas y dar visibilidad a cada una completada.
- Mostrar el impacto de los cambios para el usuario final, con números siempre que se pueda.
- Capacitar en sesiones cortas y prácticas, aprendiendo haciendo. Un buen onboarding de usuarios hace diferencia acá.
- Reconocer abiertamente a quien levantó requisitos, probó y dio feedback, no solo a quien construyó.
Una entrega chica celebrada genera tracción para la siguiente. Un proyecto que solo celebra en el go-live pasa meses sin una victoria visible, y en ese vacío muere el compromiso.
¿Qué herramientas acercan a TI y negocio en el día a día?
La herramienta acá es actor de reparto: su papel es reducir la fricción de mantener a todos informados. Cuatro categorías suelen rendir.
- Portales de autoservicio, que permiten al negocio seguir y disparar procesos sin abrir un ticket.
- Plataformas de workflow visual, que muestran cada etapa del flujo de forma trazable para cualquiera.
- Canales de comunicación asincrónica, con espacio dedicado por proyecto en vez de conversaciones dispersas.
- Automatizaciones por disparador, que unen reglas definidas por el negocio con el monitoreo de TI.
El criterio de elección es el contexto. Una buena herramienta es la que el equipo de negocio puede usar sin depender de TI para cada consulta.
Preguntas frecuentes
Mi empresa no tiene departamento de TI. ¿Esta orquestación aplica?
Sí, y con más razón. Cuando TI es un proveedor o socio externo, alinear expectativas y sostener rituales de revisión es la única forma de mantener el proyecto bajo control. Aplican los mismos mecanismos: requisitos legibles para ambos lados, decisiones por escrito y revisión en cada entrega.
¿Las reuniones frecuentes no van a burocratizar el proyecto?
El costo de una reunión de 20 minutos por semana es chico al lado del costo del desalineamiento que la investigación de PMI cuantifica: la comunicación ineficaz está detrás de la mitad de los proyectos que fracasan. La regla es simple. Si la reunión no produce decisiones ni destraba nada, acórtala o espáciala. Si aparece retrabajo, acércala.
¿Quién debería ser dueño del proyecto: TI o negocio?
El negocio es dueño del resultado, porque el proceso que la automatización atiende le pertenece. TI es dueña de la solución técnica y de su sostenimiento. Funciona bien nombrar una dupla, un responsable de negocio y una contraparte técnica, con autonomía para decidir juntos lo que no necesita subir al directorio.
El siguiente paso
Si tus proyectos de automatización se traban más por desalineamiento que por técnica, el primer movimiento es ver la operación como un todo. Un Diagnóstico de Arquitectura Operacional es una conversación de 30 minutos para mapear dónde se están desencontrando TI y negocio y qué orquestar primero. Agenda un horario.
Lee también
Cases relacionados
¿Reconociste tu operación en este artículo?
Agenda el Diagnóstico de Arquitectura Operacional: 30 minutos para mapear dónde está el cuello de botella de tu operación. Sin compromiso.
Agendar diagnóstico