El consejo que ya conoces es correcto. Asigna un propietario. Empieza por lo pequeño. Vinculalo a un problema empresarial. Compra software que se ajuste.
Pero eso no es donde fracasan los programas. Fracasan en la mecánica subyacente: ese momento específico cuando una entrada de catálogo falla y nadie la corrige, la reunión donde dos departamentos descubren que entienden "cliente" de formas distintas, la factura que llega cuando tu volumen de datos se triplica. Este artículo trata sobre esos momentos, porque es ahí donde una implementación de gobernanza de datos realmente se gana o se pierde.
La Predicción que Vale la Pena Leer Cuidadosamente
Gartner predice que para 2027, el 80% de las iniciativas de gobernanza de datos y análisis fracasarán. Se cita en todas partes, por lo general sin la parte que importa. Es una previsión, no un resultado medido, y Gartner da una causa específica: los programas fracasan porque carecen de una crisis real o manufacturada alrededor de la cual organizarse.
Léelo como un diagnóstico. La gobernanza configurada para satisfacer una auditoría no tiene una crisis detrás, así que produce políticas que nadie hace cumplir. La gobernanza configurada para detener un problema que actualmente le cuesta dinero a alguien se utiliza, porque alguien la está vigilando.
La cifra a menudo repetida de que los datos deficientes cuesta a una organización $12,9 millones al año merece el mismo cuidado. Es una estimación de 2020, aún recitada como actual, sin una metodología publicada detrás del número redondo. Úsala para fijar la dirección, no para dimensionar un presupuesto. Tu propia tasa de duplicación y horas de retrabajo son mejor evidencia que un promedio de cinco años, y recopilarlas es lo primero útil que hace un programa.
El Ciclo de Obsolescencia que Mata los Catálogos
Aquí está el fracaso que describí en una línea la última vez, mostrado en su totalidad, porque la línea oculta el problema completo.
Un catálogo es un conjunto de afirmaciones sobre tus datos: qué significa un campo, de dónde viene, quién lo posee. Esas afirmaciones quedan obsoletas en el momento en que un sistema fuente cambia. Aparece una nueva columna. Una definición se modifica. Un pipeline se redirige. Para mantenerse verdadero, cada uno de esos cambios tiene que reflejarse en el catálogo.
Si ese reflejo es manual, alguien tiene que notar el cambio, abrir la herramienta y editar la entrada. Ese trabajo compite con todo lo demás en su plato, y no tiene fecha límite. Así que se pospone. Algunas entradas quedan obsoletas. Alguien encuentra una entrada incorrecta, pierde confianza y deja de consultar el catálogo. Una vez que dejan de consultarlo, nadie nota la siguiente entrada incorrecta, y la desviación se acelera. Para el mes seis, el catálogo describe un sistema que ya no existe.
Un catálogo no fracasa de golpe. Fracasa una entrada desatendida a la vez, y la primera entrada incorrecta que un usuario encuentra es la que le enseña a dejar de confiar en él.
La solución es la automatización: recopilación de metadatos, detección de cambios de esquema, entradas que se actualizan a sí mismas cuando la fuente se mueve. Eso cuesta dinero. El dinero necesita un patrocinador. Y un patrocinador solo aparece cuando el programa está vinculado a una crisis que alguien le importa. Por eso la predicción de Gartner y el catálogo obsoleto son el mismo problema con dos caras. Sin crisis, sin patrocinador. Sin patrocinador, sin automatización. Sin automatización, mantenimiento manual. El mantenimiento manual se descuida en el primer trimestre ocupado.
Así que no compres un catálogo que mantendrás a mano. Compra la capacidad de mantenerlo actualizado, o gobierna un alcance más pequeño que realmente puedas mantener verdadero.
Cuando Dos Departamentos Poseen "Cliente"
Esta reunión decide si la gobernanza es real, y la mayoría de implementaciones nunca la planifican.
Ventas significa una cuenta, una empresa que te compra, mientras que finanzas significa una entidad legal que paga facturas, que podría ser una empresa matriz que cubre tres cuentas de Ventas. Marketing significa una persona, un contacto nombrado que abrió un correo electrónico. La misma palabra lleva tres definiciones en tres sistemas, y cada una es correcta dentro del departamento que la usa.
El conflicto surge el día que alguien construye un informe en los tres y los recuentos de clientes no coinciden. O una ejecución de deduplicación fusiona dos registros que nunca fueron lo mismo, porque la regla asumía una definición de "cliente" y los datos contenían tres.
Un propietario no resuelve esto declarando un ganador. El mecanismo es más estrecho y más útil. El propietario fuerza las definiciones a escribirse, lo cual por sí solo termina con la mitad de la confusión, ya que los tres equipos por lo general no sabían que no estaban de acuerdo. Luego, el propietario toma una decisión estructural: ¿es "cliente" un concepto con un atributo de tipo, o tres entidades separadas vinculadas por relaciones, una cuenta que pertenece a una entidad pagadora y contiene contactos? Esa decisión de modelado es la gobernanza real. Todo lo que viene después, como deduplicación, informes y acceso, fluye de ella.
La gobernanza no es el documento de política. Es tener una persona con la autoridad para terminar un argumento que de otro modo regresaría cada trimestre.
La razón para resolver esto antes de comprar software es que la respuesta forma lo que necesitas que el software haga. Tres entidades vinculadas necesitan una herramienta con un modelo de datos relacional flexible. Un concepto plano necesita mucho menos. Compra primero, y podrías comprar una herramienta que no pueda representar la estructura en la que tu propio negocio funciona.
En trabajos que hemos visto en datos de productos y proveedores, el mismo patrón aparece un nivel abajo: un "proveedor" en adquisiciones es un "vendedor" en finanzas y un "fabricante" en el registro del producto, y los tres se mantenían en hojas de cálculo separadas que silenciosamente no coincidían. Consolidarlos en un modelo de datos con relaciones definidas es menos una tarea de software que una decisión sobre cuál de esas tres vistas es la fuente de verdad. La herramienta solo hace cumplir la decisión una vez que se toma.
Lee el Modelo de Precios, No la Lista de Características
Las listas de características convergen. Los modelos de precios son donde se oculta el costo a largo plazo, y te castigan de una forma específica: casi todos los modelos gravan lo que significa que tu programa está funcionando.
La gobernanza tiene éxito cubriendo más datos, conectando más sistemas y consiguiendo que más personas participen. Mira lo que cada eje de precios hace con ese éxito.
- Por registro.
Como ejemplo trabajado, supongamos que una herramienta cuesta una tarifa fija por cada 10.000 registros gestionados, y comienzas con 40.000 registros de productos. La factura es pequeña. La gobernanza funciona, así que incorporas datos de clientes y asimila un catálogo de adquisición, y ahora estás en 400.000 registros. El costo es diez veces lo que te registraste, y para entonces tus flujos de trabajo e integraciones se asientan encima de la herramienta, así que irte es caro. - Por fuente o conector.
Comienzas gobernando cuatro sistemas. El éxito significa extender la gobernanza en toda la propiedad, y dos años después estás pagando por veinte conectores. - Por asiento.
Se ve barato hasta que recuerdas que la gobernanza solo funciona cuando los administradores en cada departamento pueden actuar. Cuanto más se expande el programa, más asientos compras.
Cada eje te cobra más precisamente conforme tienes éxito. El movimiento no es encontrar un modelo sin costo. Es elegir el eje que puedes predecir y controlar. Si tu recuento de registros es volátil y tu lista de fuentes es estable, el precio por fuente es más seguro, y lo inverso también es cierto.
Sobre el software en sí, el mercado se divide en dos. Las grandes suites empresariales como Collibra e Informatica manejan catalogación amplia y linaje en patrimonios complejos, con precios y personal para coincidir. Para datos maestros como productos, proveedores y datos de referencia, las plataformas de código abierto son un punto de entrada más ligero. AtroCore es una, con un modelo de datos configurable, acceso basado en roles e historial de cambios que cubren la mecánica de gobernanza central sin un contrato empresarial; se sienta junto a opciones como Apache Atlas y OpenMetadata, cada una más fuerte en un trabajo diferente. Selecciona dos o tres y pruébalas con la prueba a continuación antes de comprometerte con cualquier modelo de precios.
Lo que una Prueba Piloto Expone que una Demostración Oculta
Una demostración de vendedor se ejecuta en datos del vendedor, y los datos del vendedor están limpios. Esa es toda la razón por la que la demostración se ve impecable y te dice casi nada.
En su lugar, ejecuta la prueba piloto en tus peores registros. Para deduplicación, eso significa alimentar la herramienta con tu lista real de clientes o proveedores, la que tiene "Acme Inc," "Acme, Inc." y "ACME INCORPORATED" como tres filas, más los errores tipográficos, los códigos de país faltantes y la empresa que legítimamente opera bajo dos nombres. Luego etiqueta manualmente algunos cientos de esas filas para que sepas la respuesta correcta, y mide la herramienta contra ellas.
Salen dos números. Cuántos duplicados reales capturó y cuántos registros distintos fusionó incorrectamente. Una fusión falsa es la peligrosa, porque destruye datos al combinar dos clientes que nunca fueron lo mismo, y una demostración limpia nunca la expondrá. Esos dos números te dicen si el motor de coincidencia funciona en tus datos. Nada de lo que el vendedor muestre hará eso.
Haz lo mismo para cualquier mecánica que importe más en tu caso: un cambio de esquema que el catálogo tiene que captar, un flujo de trabajo de aprobación bajo una carga realista, una regla de acceso con un caso extremo real. Prueba la cosa que se romperá, no la cosa que tiene buena demostración.
La implementación de gobernanza de datos se reduce a un puñado de estas mecánicas. Mantén el catálogo verdadero, resuelve las definiciones antes de modelar, fija el precio para el crecimiento que esperas, y prueba la herramienta en tus datos más sucios. Haz eso bien, y el consejo genérico se cuida a sí mismo.