Negocio & IT condenados a trabajar juntos
Margen Oculto · septiembre 2026
Nadie era responsable del dato. Hasta que todo dejó de cuadrar.
El caso real que explica por qué el Data Owner es la figura que más falta en las empresas — y por qué sin ella ninguna inversión en tecnología va a resolver tu problema de reporting.
Margen Oculto · 16 min de lectura
Hace un tiempo me encontré frente a uno de esos proyectos que parecen simples sobre el papel. Una empresa con facturación recurrente, contratos de cinco años con sus clientes, un CRM para la parte comercial y un ERP para la parte financiera y operativa.
La empresa acababa de ser comprada por un fondo de inversión. Y el fondo quería cinco KPIs claros cada mes: facturación, costes, nuevos contratos, EBITDA y churn.
Cinco métricas. Dos sistemas. Un reporting que tenía que cuadrar.
Lo que parecía un proyecto técnico de integración de sistemas se convirtió en algo mucho más complejo. Y la lección que me llevé no tiene nada que ver con la tecnología.
El problema que nadie había visto.
El primer paso técnico fue relativamente sencillo. Introdujimos un campo en el ERP — el número de contrato — para poder cruzarlo con el CRM. Una conexión limpia entre los dos sistemas.
Pero cuando empezamos a ver los datos, algo no cuadraba.
Los comerciales metían la información de los contratos de formas distintas. Cada uno con su criterio. Cada uno adaptando el sistema a su realidad operativa. Unos ponían el número de contrato de una forma, otros de otra. Unos rellenaban campos que otros dejaban vacíos. Unos usaban campos para cosas que no eran exactamente para lo que estaban diseñados.
No era mala voluntad. Era el resultado predecible de dos mundos que habían funcionado en paralelo durante años sin que nadie hubiera definido exactamente cómo debía entrar cada dato.
El problema no era el sistema. Era el gap entre cómo estaba diseñado y cómo lo usaba la gente.
IT había construido una estructura. Negocio tenía una realidad operativa. Y nadie había sentado a los dos juntos para asegurarse de que encajaban.
El momento en que el director financiero perdió la paciencia.
"Quien no meta los datos como yo digo... se va a la puta calle."
Lo dijo en una reunión. Y la sala se quedó en silencio.
Entiendo la frustración. Llevábamos semanas viendo informes que no cuadraban. El fondo esperaba cinco KPIs fiables. Y cada vez que generábamos un reporte, alguien encontraba una discrepancia que lo invalidaba.
Pero la amenaza, aunque comprensible, no resolvía el problema de fondo.
Porque el problema no era que los comerciales no quisieran meter bien los datos. Era que nadie había definido exactamente qué significaba "meter bien los datos" para cada tipo de contrato, con cada tipo de excepción, en cada situación posible.
Ahí está la clave. Los datos no son un problema de IT. Son un problema de negocio. Porque las decisiones que se toman con esos datos — de inversión, de estrategia, de pricing, de personal — las toma negocio, no IT.
Y cuando negocio no se implica en cómo nace el dato, acaba tomando decisiones con información que nadie puede garantizar que sea correcta.
Por qué negocio tiene que implicarse en el dato.
Este es el punto que más resistencia genera cuando lo planteo en las empresas. "Eso es cosa de IT." "Nosotros nos dedicamos a vender." "Que lo arregle el sistema."
Pero hay una realidad que no cambia independientemente de la tecnología que se use:
El dato nace en negocio. Lo introduce una persona de negocio — un comercial, un operador, un agente de atención al cliente. Lo introduce con el contexto de una operación real, con todas sus particularidades y excepciones. Y si esa persona no sabe exactamente cómo debe entrar ese dato, o si el sistema no está adaptado a su realidad, el dato entrará mal.
IT puede construir el mejor sistema del mundo. Puede crear validaciones, campos obligatorios, listas desplegables. Pero no puede sustituir el criterio de la persona que entiende la operación real.
La solución: el Data Owner.
Lo que resolvió el proyecto no fue una mejora técnica. Fue una decisión organizativa.
Elegimos a un comercial. Alguien que conocía perfectamente la operación — cómo se negociaban los contratos, qué excepciones aparecían, qué información era crítica para cada tipo de cliente — y que al mismo tiempo entendía qué necesitábamos en el BI para que los reportes cuadraran.
Le dimos un rol formal: Data Owner del proceso comercial.
Y su trabajo era coordinar cuatro partes que hasta entonces nunca habían hablado entre sí de forma estructurada.
El Data Owner era el punto de contacto entre todos. El traductor. El árbitro cuando había conflicto entre lo que pedía el BI y lo que era posible en la operación real.
Qué hace exactamente un Data Owner.
El concepto de Data Owner existe en la literatura de gobierno del dato desde hace años. Pero en la práctica, especialmente en empresas medianas, es una figura que casi nunca está formalizada. Se asume que "alguien" se encarga de que los datos estén bien. Y ese "alguien" no existe.
Estas son las responsabilidades concretas que asumió el Data Owner en este proyecto — y que cualquier empresa debería tener cubiertas para cada proceso crítico:
Por qué es tan difícil de implementar.
Si el concepto es tan claro, ¿por qué tan pocas empresas tienen Data Owners formalizados?
Hay tres razones que aparecen siempre.
Cómo implementarlo en una empresa mediana.
No hace falta una estructura corporativa de gobierno del dato para que esto funcione. En una empresa mediana, el proceso puede ser mucho más simple y directo.
Identificar los procesos críticos.
No todos los datos tienen el mismo impacto. El primer paso es identificar qué procesos generan los datos que más se usan para tomar decisiones — facturación, contratos, clientes, operaciones, incidencias. Esos son los procesos que necesitan un Data Owner. Empieza por el más crítico y ve ampliando.
Elegir a la persona correcta.
El Data Owner ideal no es el más técnico ni el más senior. Es el que mejor conoce la operación real — cómo se negocian los contratos, qué excepciones aparecen, qué información es crítica — y que tiene suficiente credibilidad entre sus compañeros para que le escuchen cuando dice cómo hay que hacer las cosas. En el caso del proyecto, fue un comercial con experiencia y respeto dentro del equipo.
Definir el rol formalmente.
El Data Owner no puede ser una responsabilidad informal que alguien asume sin reconocimiento. Tiene que estar definido explícitamente: qué se espera de esa persona, qué autoridad tiene para tomar decisiones sobre el dato, a quién reporta y cómo se mide su trabajo. Sin formalización, la responsabilidad desaparece en cuanto hay presión operativa.
Documentar las definiciones de dato.
Para cada campo crítico: qué significa, qué valores son válidos, cómo se maneja cada excepción posible. Esta documentación no tiene que ser un manual de 100 páginas — tiene que ser clara, accesible y actualizable. Una wiki interna, un documento compartido, lo que funcione en esa empresa. Lo importante es que exista y que todos sepan dónde está.
Establecer una rutina de revisión.
El Data Owner tiene que revisar periódicamente la calidad de los datos bajo su responsabilidad. No tiene que hacerlo manualmente — un dashboard de calidad del dato que muestre campos vacíos, valores anómalos y registros inconsistentes puede automatizar gran parte de ese trabajo. Lo importante es que alguien lo mire regularmente y actúe cuando algo falla.
El resultado cuando funciona.
En el proyecto del fondo de inversión, cuando el comercial asumió el rol de Data Owner y se estableció la metodología, el cambio fue visible en semanas.
La lección que va más allá de este caso.
Este proyecto era de integración de sistemas para un fondo de inversión. Pero el problema que resolvió — nadie es responsable de cómo entra el dato — es exactamente el mismo que encuentro en empresas de distribución, en manufactureras, en empresas de servicios.
No importa el sector. No importa el tamaño. No importa la tecnología que usen.
Cuando nadie es el dueño del dato, el dato se degrada. Lentamente, silenciosamente, hasta que alguien intenta tomar una decisión importante y descubre que los números no cuadran.
Y entonces la solución que se busca casi siempre es tecnológica: un nuevo sistema, una mejor integración, más automatización. Cuando la solución que se necesita es organizativa: alguien que sea responsable de que la información entre bien desde el primer momento.
Puedes tener el mejor stack tecnológico del mercado. Puedes tener Power BI conectado al ERP y al CRM. Puedes tener dashboards en tiempo real con todos los KPIs que el negocio necesita.
Pero si nadie es responsable de cómo entra el dato en los sistemas, todo eso mostrará basura con muy buena presentación.
Si la respuesta no es inmediata — o si hay procesos donde esa responsabilidad no está clara — ahí está el origen de tus problemas de reporting.
Y probablemente también parte de tu problema de margen.
Comentarios
Publicar un comentario