Un proyecto de inteligencia artificial sin un responsable de negocio —alguien cuyo objetivo anual dependa de que ese proceso funcione mejor— no llega a producción. Puede tener un modelo excelente, un equipo competente y presupuesto suficiente, y aun así detenerse, porque cuando llegue el momento de decidir sobre las excepciones, de defender la fase siguiente o de aceptar un cambio en cómo trabaja un equipo, no habrá nadie con autoridad e incentivo para hacerlo.
Es la causa de fracaso menos técnica y más frecuente.
En la mayoría de los proyectos hay un patrocinador ejecutivo: alguien que aprobó el presupuesto y aparece en el comité de seguimiento. No es lo mismo.
Rol | Qué hace | Qué no hace |
|---|---|---|
Patrocinador | Aprueba presupuesto y da cobertura política | Decidir sobre casos concretos |
Dueño de negocio | Responde del resultado del proceso | Escribir código |
Responsable técnico | Construye y opera el sistema | Decidir qué es aceptable para el negocio |
Usuario clave | Aporta el conocimiento real del proceso | Priorizar entre departamentos |
Los cuatro papeles son necesarios. El que falta casi siempre es el segundo, y su ausencia se nota en tres momentos concretos del proyecto.
Cuando aparecen las excepciones. Alguien tiene que decidir qué se automatiza y qué escala a una persona. Es una decisión de negocio con implicaciones de riesgo, no una elección técnica.
Cuando hay que cambiar cómo trabaja un equipo. El rediseño del flujo de trabajo es lo que produce el retorno, y también lo que genera resistencia. Sin autoridad de negocio, esa resistencia gana.
Cuando toca defender la siguiente fase. El paso de piloto a producción exige presupuesto adicional y una decisión de riesgo. Un responsable técnico puede argumentarlo; solo un responsable de negocio puede firmarlo.
No es un fallo de nadie: es la deriva natural. La iniciativa suele nacer en innovación o en sistemas, porque son quienes conocen la tecnología. El área de negocio colabora, pero no lo siente suyo, porque su objetivo anual está en otra parte.
El resultado es un proyecto que técnicamente funciona y que nadie reclama. Cuando llega la revisión presupuestaria, compite en desventaja frente a iniciativas con un director detrás defendiéndolas.
La señal de alarma es fácil de detectar: si al preguntar «¿de quién es este proyecto?» la respuesta es un departamento y no una persona, el proyecto está en riesgo con independencia de su calidad técnica.
El dueño es quien sufre el problema, no quien conoce la solución. Si el proyecto reduce el tiempo de gestión de expedientes, el dueño es el director de operaciones, no el de sistemas.
Su objetivo debe cambiar. Si el proceso mejora un 30% y su objetivo anual sigue siendo el mismo, no hay incentivo real. La propiedad se demuestra en la ficha de objetivos, no en el acta del comité.
Debe tener autoridad sobre el proceso completo. Si el proceso atraviesa tres departamentos y el dueño solo manda en uno, las decisiones se bloquearán en las fronteras.
Debe poder parar el proyecto. Es la prueba definitiva de propiedad. Quien no puede cancelarlo tampoco puede defenderlo.
No hace falta reorganizar nada. Tres pasos:
Identificar en qué línea del presupuesto aparecería el beneficio. Si el proyecto reduce el coste de gestión de un departamento, ese departamento tiene el dueño natural.
Proponerle la propiedad con la métrica incluida. No «¿te haces cargo de este proyecto?», sino «si esto funciona, tu coste por expediente baja un X; ¿te comprometes con ese número?».
Trasladar la decisión de continuidad. A partir de ahí, quien decide si el proyecto sigue no es tecnología.
Si nadie acepta la propiedad en esas condiciones, es una señal valiosa: probablemente el proyecto no resuelve un problema que a alguien le duela lo suficiente. Descubrirlo en la semana tres es mucho más barato que descubrirlo en el mes catorce.
Para una dirección con varias iniciativas de IA en marcha, hay una revisión que cuesta una reunión y ordena la cartera entera: por cada proyecto, nombra a la persona cuyo bonus se ve afectado si sale bien.
Los proyectos que tienen ese nombre son los que llegarán a producción. Los que no lo tienen son candidatos a convertirse en pilotos permanentes, y conviene decidir ahora si se les asigna dueño o se cierran.
Ambas decisiones son mejores que dejarlos donde están.
Es la persona cuyo objetivo depende de que el proceso afectado funcione mejor y que responde del resultado, no de la implantación de la herramienta. Se diferencia del patrocinador ejecutivo, que aprueba presupuesto y da cobertura, y del responsable técnico, que construye y opera el sistema.
Porque en tres momentos críticos no hay quien decida: cuando aparecen las excepciones y hay que determinar qué se automatiza, cuando hay que cambiar cómo trabaja un equipo, y cuando toca defender el presupuesto del paso a producción frente a otras iniciativas.
Quien sufre el problema, no quien conoce la solución. Si el proyecto reduce el tiempo de gestión de expedientes, el dueño es el director de operaciones. Además debe tener autoridad sobre el proceso completo y capacidad de parar el proyecto.
Comprobando que el objetivo anual de esa persona cambia con el resultado del proyecto. La propiedad se demuestra en la ficha de objetivos, no en el acta del comité de seguimiento.
Cuatro: qué nivel de acierto es aceptable dado el coste del error, qué casos se automatizan y cuáles escalan a una persona, qué cambia en la forma de trabajar del equipo, y cuál es el umbral por debajo del cual el proyecto se detiene.
Identificar en qué línea de presupuesto aparecería el beneficio, ofrecer la propiedad a ese responsable junto con la métrica comprometida, y trasladarle la decisión de continuidad. Si nadie acepta en esas condiciones, es señal de que el proyecto no resuelve un problema suficientemente doloroso.
¿Tus proyectos de IA tienen dueño o solo tienen presupuesto? Ayudamos a definir el caso de negocio, la métrica y la propiedad antes de construir nada. Dos horas de análisis, sin compromiso. Parlons-en →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
