Voy a decir algo que va contra buena parte del discurso técnico que domina las charlas de Business Intelligence: el verdadero cliente de un proyecto de datos es el área de operaciones, no la de IT. Y cuando ese orden se invierte, el proyecto casi siempre se resiente.
Lo digo después de varios años viendo proyectos nacer y, algunos, apagarse. El patrón es tan consistente que dejé de sorprenderme: el éxito de un proyecto de datos depende más de quién, del lado del negocio, se lo apropia, que de la herramienta elegida. La tecnología importa, pero no es la que decide el resultado.
Quiero contarte por qué, con la conversación que veo en casi todos los arranques, tres historias compuestas de proyectos que cambiaron al cambiar el sponsor, y cómo se reparte bien la responsabilidad para que esto no falle.
La conversación típica del kickoff
Casi todos los proyectos arrancan igual. En la reunión inicial, del lado del cliente, aparece IT como interlocutor principal. Tiene sentido en apariencia: es un proyecto de datos, suena técnico, que lo lleve sistemas. Y ahí empieza el problema.
Porque cuando IT lidera, la conversación gira hacia lo técnico: qué base de datos, qué conector, qué frecuencia de actualización. Todo necesario, pero ninguna de esas preguntas es la que decide si el tablero va a servir. La pregunta que decide es otra: ¿qué decisión de la operación vas a tomar distinto cuando tengas esto? Y esa pregunta la responde quien vive la operación, no quien administra los sistemas.
Por eso, cuando entro a un kickoff, lo primero que pido es que en la mesa esté la persona de operaciones que va a usar el tablero para decidir. Si no está, sé que el proyecto arranca con el pie cambiado.
Tres historias que cambiaron al cambiar el sponsor
Lo que sigue son historias compuestas, armadas con patrones de varios proyectos reales y con los datos cambiados por confidencialidad. No son clientes puntuales identificables, pero el patrón es real.
La primera: una distribuidora donde el proyecto lo llevaba IT. Tableros impecables, actualizados, técnicamente perfectos. Nadie los usaba. Cuando el gerente de operaciones tomó la posta y pidió que el tablero respondiera a sus tres preguntas del lunes, en pocas semanas el mismo tablero pasó a ser el centro de la reunión semanal. No cambió la herramienta. Cambió el dueño.
La segunda: una empresa de maquinaria donde el sponsor era el dueño, pero delegaba todo en sistemas. El proyecto avanzaba lento porque cada definición de negocio (qué se considera una venta cerrada, cómo se cuenta un service) quedaba esperando que alguien con criterio de negocio respondiera. Cuando el responsable de operaciones se sentó a definir esas reglas, el proyecto se destrabó en días.
La tercera: una importadora donde IT y operaciones se pasaban la pelota. IT decía que faltaban definiciones del negocio, operaciones decía que era un tema técnico. El proyecto estuvo varado meses. Se destrabó cuando acordamos algo simple: operaciones es el dueño de qué se mide y para qué, IT es el dueño de cómo se conecta y se sostiene. Cada uno en lo suyo.
Qué pierde un proyecto cuando IT es el dueño único
Cuando IT es el único dueño, el proyecto pierde tres cosas, y las tres son caras.
Pierde foco en la decisión. IT, naturalmente, optimiza lo técnico. Sin un dueño de negocio, el tablero termina mostrando lo que es fácil de mostrar, no lo que la operación necesita decidir.
Pierde adopción. Y esto no es una opinión mía: TARGIT y BARC vienen marcando para 2026 que el sponsor de negocio correlaciona con mayor adopción de BI. Cuando el equipo ve que su jefe de operaciones decide con el tablero, lo adopta. Cuando lo ve como “el proyecto de sistemas”, lo ignora.
Pierde evolución. Las prioridades del negocio cambian, y quien sabe que cambiaron es operaciones, no IT. Sin un dueño de negocio atento, el tablero envejece sin que nadie lo note hasta que ya no sirve.
Esto no significa que IT sobre. Significa que IT acompaña en lo técnico, y el sponsor principal tiene que ser del negocio. Es una frase que repito tanto que ya es parte de cómo trabajamos.
Cómo se reparte bien la responsabilidad
La solución no es sacar a IT. Es repartir bien, y dejarlo claro desde el primer día.
Operaciones es el dueño del qué y del para qué: qué se mide, qué decisión se va a tomar, qué significa cada número en términos del negocio. Es el cliente real del proyecto.
IT es el dueño del cómo: cómo se conectan las fuentes, cómo se sostiene la actualización, cómo se cuida la seguridad. Es un socio imprescindible, no el cliente.
La dirección es el sponsor que respalda: da la prioridad, libera el tiempo del equipo y, sobre todo, usa el resultado a la vista de todos, que es lo que hace que el resto lo adopte.
Cuando ese reparto está claro desde el kickoff, el proyecto fluye. Eso es BI aterrizado a tu operación: un tablero cuyo dueño es quien vive la operación y decide con él, con IT sosteniendo la parte técnica.
FAQ: lo que se pregunta una empresa al armar el equipo del proyecto
¿Estás diciendo que IT no debería participar?
Para nada. IT es imprescindible en la parte técnica. Lo que digo es que no debería ser el dueño único ni el cliente del proyecto. El sponsor principal tiene que ser del negocio.
¿Y si en mi empresa IT siempre lideró estos proyectos?
Es lo más común, y es justamente donde más veo proyectos que no se adoptan. Vale la pena sumar un dueño de operaciones desde el arranque, sin sacar a IT de su rol técnico.
¿Quién debería estar en el kickoff?
La persona de operaciones que va a decidir con el tablero, IT para la parte técnica, y alguien de dirección que respalde. Si falta el primero, conviene frenar y sumarlo antes de avanzar.
¿Esto aplica a una empresa chica sin área de IT formal?
Sí, y hasta es más claro. En una empresa chica, el dueño de operaciones suele ser también quien decide todo. Mejor todavía: el cliente del proyecto está identificado desde el día uno.
Próximo paso
Si estás por arrancar un proyecto de datos o tienes uno que no termina de despegar, antes de mirar la herramienta vale revisar quién es el dueño. Si el proyecto vive en IT y operaciones lo mira de afuera, ahí suele estar el problema.
Podemos hacerte un diagnóstico inicial sin costo de 30 minutos para revisar cómo está repartida la responsabilidad de tu proyecto y qué ajustar para que se adopte, con un plan operativo en 48 horas. BI aterrizado a tu operación, con el dueño correcto desde el primer día.
