Mantener fuera los datos malos

🌐 También en 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Français (Canada) · Deutsch (Schweiz)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés

Módulo 2 de 6 del capítulo Calidad y gobierno de datos, capítulo 5 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: El gobierno de datos se diseña dentro de la organización · Siguiente: Conoce tus datos

La pregunta que responde este módulo: ¿Cómo mantienes buenos los datos, y cómo los mantienes así?

Hay dos formas de lidiar con los datos malos: impedir que entren o limpiarlos después. Harás un poco de ambas. Pero, si puedo elegir, prefiero evitar el problema antes que montar una organización para limpiarlo para siempre. Duplicados, identificadores malos, información que falta, valores no estándar, usuarios que cambian campos de los que es dueño otro sistema, integraciones que sobrescriben datos buenos con malos: todo eso se convierte en el proyecto de limpieza de alguien. Así que la pregunta de diseño es ¿qué datos malos puedo razonablemente mantener fuera desde el principio? Y “razonablemente” importa, porque la respuesta no es bloquear cada campo hasta que el sistema sea inutilizable.

“Suficientemente bueno” es una definición del negocio

Antes de impedir los datos malos, define los buenos. No hay una sola definición. Bueno puede significar lo bastante completo para ejecutar el proceso, lo bastante exacto para decidir, lo bastante actual para la carga de trabajo, lo bastante consistente para combinarlo con otros sistemas, lo bastante único para saber de qué cliente hablamos, lo bastante estándar para la automatización, lo bastante rastreable para saber de dónde vino. Depende de los datos. Si Steve Trucking está facturando a un socio minorista, la identidad legal del socio tiene que estar bien. Si un representante anota algo después de una reunión, nadie necesita un comité que apruebe cada frase. “Suficientemente bueno” es una definición del negocio; el arquitecto la vuelve medible y cumplible.

Evita los errores costosos

No todo campo malo merece la misma atención. Me importan sobre todo los errores con consecuencias más adelante. Un cliente duplicado significa dos historiales de ventas, dos historiales de servicio, dos conjuntos de contactos, dos ID externos, dos integraciones sincronizando la misma empresa, dos versiones en el almacén de datos y en Data 360 y, al final, un agente decidiendo qué cliente es el real. Eso es mucho más caro que una errata en una descripción. Así que no empieces por “¿cómo validamos cada campo?”. Empieza por ¿qué datos malos crean el mayor problema de negocio o de arquitectura? y pon ahí los controles más fuertes.

¿Abierta o cerrada?

La creación de cuentas es el ejemplo clásico. ¿Debería poder crear cuentas cada vendedor? Mi respuesta: depende del gobierno que rodea a los datos. Para la mayoría de las organizaciones pequeñas y medianas, la creación abierta está bien. Un representante conoce a un prospecto, crea la cuenta y se pone a trabajar; para eso está el CRM. Las reglas de duplicados, la información obligatoria y los responsables de datos gestionan la calidad. No agrego un proceso de aprobación pesado solo porque el gobierno suena responsable.

Ahora cambia el panorama. El cliente legal se mantiene como dato maestro en el ERP, entra en Salesforce con un identificador del ERP, y el ERP es la referencia. Ahora la creación abierta significa dos formas de crear la misma entidad gobernada. Cuando el ERP y un representante crean la misma empresa, ¿cuál gana, qué identificador usan las integraciones, qué registro guarda el historial? La creación abierta deja de ser una cuestión de facilidad de uso y se convierte en una cuestión de datos maestros. Cuando las cuentas se mantienen como datos maestros en un ERP o se sincronizan con él, cierra la creación.

Pero cerrarla por completo también falla. El representante ha conocido a un prospecto que no está en el ERP y quiere abrir una oportunidad, y el modelo de gobierno dice “no hay cuenta para ti”. Así que espera tres días a Finanzas, o vincula la oportunidad a la cuenta equivocada, o guarda el prospecto en un campo de notas o en una hoja de cálculo. Protegimos el modelo de datos y dañamos el negocio.

El camino intermedio: un tipo de registro provisional

Este es el camino intermedio que me gusta. Deja que ventas cree la cuenta con un tipo de registro específico, de prospecto o provisional, y controla su conversión al tipo gobernado. Ventas captura la empresa y empieza a vender. El registro dice claramente: todavía no está establecido en el sistema con la autoridad. Luego un proceso controlado lo convierte: Finanzas lo aprueba, o una integración lo envía al ERP, que lo empareja con un cliente existente o crea uno nuevo y devuelve el identificador de referencia. Ahora el registro cruza una frontera, provisional → gobernado, que es muy distinto de que dos sistemas creen cada uno lo que creen que es el registro maestro.

El tipo de registro es el mecanismo que enseño. Uses lo que uses, haz visible el estado en los datos: de dónde vino el registro, si ya cruzó la frontera, quién puede cambiarlo ahora y el identificador que lo vincula con el sistema con la autoridad. El ID de cliente del ERP que solo existe después de la conversión es la señal más clara de todas.

Un tipo de registro para cada flujo

Pon todo el flujo en una sola imagen y verás por qué funciona. Los clientes y los productos entran desde el ERP. Las oportunidades y sus partidas salen y se convierten en los pedidos del ERP. ¿Y las cuentas? Algunas entran, otras salen. Así que un patrón común que he visto en distintas implementaciones son dos tipos de registro en Cuenta, uno para cada dirección. Una cuenta de Ventas nace en Salesforce: los representantes la crean, la editan, le venden, y cuando se convierte en cliente se envía al ERP. Una cuenta de ERP (yo la he llamado Cliente, o simplemente SAP) nace en el ERP y entra por la integración. Nadie crea ese tipo de registro excepto la integración, y sus campos de datos maestros (nombre legal, direcciones, condiciones de pago) son de solo lectura para los usuarios. El tipo de registro te dice en qué dirección fluye el registro, así que la dirección de la gestión maestra está ahí mismo, en el registro.

Click to enlarge

Un tipo de registro para cada flujo: las cuentas de Ventas salen, las cuentas de ERP entran.

Esto no elimina el caso difícil. Un representante convierte un prospecto de Steve’s Plumbing, pero Steve’s Plumbing ya existe como cuenta de ERP, y de algún modo la comprobación de duplicados no lo detectó. Ahora estás fusionando, cambiando el padre de los registros hijos y decidiendo qué registro sobrevive (capítulo 6, módulo 3).

Y no te quedes atascado en el tipo de registro en sí. Normalmente evito los tipos de registro salvo que haya un motivo fuerte para usarlos. Los usé aquí porque, antes de Dynamic Forms, el tipo de registro elegía el formato de página, y un formato mostraba los campos del ERP como de solo lectura. Con Dynamic Forms, las reglas de visibilidad pueden mostrar y ocultar campos según el valor de un campo, un campo puede ser de solo lectura en una página concreta, y la propia Salesforce dice que Dynamic Forms reduce la cantidad de formatos de página y tipos de registro que necesitas (Break Up Your Record Details with Dynamic Forms (opens in a new tab); Required and Read-Only Fields in Dynamic Forms (opens in a new tab)). Pero solo lectura en una página es solo lectura en esa página: la API, una carga de datos o una integración pueden seguir escribiendo el campo. El cumplimiento real es la seguridad a nivel de campo o una regla de validación; la validación en la interfaz no es validación de datos (capítulo 3, módulo 9). Los tipos de registro siguen ganándose su lugar cuando los dos tipos de cuenta necesitan valores de lista de selección o procesos de negocio distintos. Lo que sí importa es que algún campo diga claramente de dónde vino el registro: la propia clave del ERP, un indicador de datos maestros o una lista de selección de origen. Luego controla la posibilidad de edición a partir de ese campo.

Click to enlarge

De provisional a gobernado: ventas empieza a vender de inmediato; solo el proceso con la autoridad hace gobernado el registro.

Protege el registro gobernado

Una vez que el cliente vuelve del ERP, su ID del ERP, su nombre legal, su identificador fiscal y sus datos de facturación son atributos gobernados. ¿Debería cambiarlos el representante? No, si el ERP es su dueño. Es la política del módulo 1 necesitando su punto de cumplimiento: el ID del ERP de solo lectura, la identidad legal controlada, mientras el representante sigue editando el territorio, las notas de la relación y las clasificaciones propias de Salesforce. El objetivo no es una cuenta intocable. Es una línea clara entre los datos de los que es dueño Salesforce y los datos que Salesforce referencia. (El prefijo erp_ del capítulo 4 hace visible esa línea en el esquema.)

Lo que obtienes al final es un golden record que en realidad es un híbrido. Los campos de datos maestros del ERP entran: nombre legal, direcciones de facturación y de envío, condiciones de pago. Luego Salesforce añade sus propios campos, que nunca vuelven: una calificación de ventas, la fecha del último pedido, prácticamente todo lo que usa marketing. La misma cuenta, dos tipos de campo, y cada tipo tiene un único origen.

Lo más difícil son las bidireccionales. Digamos que un representante necesita que el nombre legal en el ERP cambie de Steve’s Plumbing a Steve’s Plumbing LLC. En esos mismos cinco minutos, alguien en el ERP lo cambia a Steve’s Plumbing L.L.C. ¿Qué cambio gana? Esta es la mentalidad: si un campo se gestiona como maestro en el ERP, no estás cambiando el campo, estás pidiendo que lo cambien. Decide qué pasa cuando la solicitud choca: gana el ERP, la solicitud se rechaza si el valor cambió mientras tanto, o espera a que una persona lo resuelva. Y decide si los campos relacionados viajan juntos como un solo cambio o uno por uno. El capítulo 6 lleva las colisiones más lejos (Bucles y colisiones).

Detén los duplicados en la puerta

Los duplicados se multiplican. Detecta uno antes de que se cree y es un problema pequeño. Encuéntralo dos años después, con oportunidades, casos, contactos, facturas, integraciones y analítica colgando de los dos, y es uno grande. El módulo 7 del capítulo 3 cubrió los mecanismos (reglas de coincidencia, reglas de duplicados, ID externos únicos), así que no los volveré a enseñar. La pregunta de gobierno es ¿dónde tenemos que impedir la duplicación, y dónde la toleraremos y la resolveremos después? Un prospecto de marketing informal puede vivir con ambigüedad. Un cliente gobernado por el ERP con transacciones financieras, no.

Estandariza lo que leen las máquinas

El texto libre es maravilloso para las personas y terrible cuando un sistema tiene que interpretarlo. Pon Arizona, AZ, Ariz., zona de Phoenix y Suroeste en un campo que determina las rutas y tienes un problema de calidad. Si un valor determina la automatización, la integración, los informes, la seguridad, la asignación o la acción de un agente, piensa bien qué tan estándar tiene que ser. No todo campo de texto se convierte en lista de selección, pero distingue la información que leen las personas de la información con la que deciden las máquinas. La segunda merece un control más fuerte.

No dejes que los campos obligatorios creen datos falsos

Decidimos que un campo importa y lo hacemos obligatorio. El usuario no sabe la respuesta, el sistema no le deja continuar, así que escribe N/A, Desconocido, 999999 o test@test.com. El campo está completo; los datos son basura. Antes de exigir algo, pregunta si el usuario lo sabe realmente en ese momento. Si no, exígelo más adelante en el proceso, deja que lo aporte otro sistema, usa el estado provisional u ofrece un Desconocido explícito cuando desconocido es una respuesta legítima. Una regla de validación puede hacer cumplir una política. No puede hacer que alguien sepa lo que no sabe.

Cada frontera de datos necesita una decisión de calidad

Las personas no son la única fuente de datos malos; las integraciones los producen más rápido. Llega el manifiesto de un socio minorista con unos cientos de líneas. Unas pocas tienen códigos postales no válidos, un par nombran un centro de distribución desconocido, dos repiten la misma referencia de pedido. ¿Qué pasa? ¿Rechazar el archivo completo? ¿Aceptar las líneas buenas y devolver las malas? ¿Cargarlo todo y limpiar después? ¿Poner en cuarentena las excepciones? ¿A quién se avisa, y cómo se entera el socio de lo que falló? No hay una respuesta universal, pero tiene que haber una. El capítulo 4 dijo que cada flecha necesita un mecanismo. Agrega: cada frontera de datos necesita una decisión de calidad: qué aceptamos, qué rechazamos o ponemos en cuarentena, y quién es dueño de la excepción.

Click to enlarge

Cada frontera de datos necesita una decisión de calidad.

Los datos históricos son distintos

RouteDesk guarda ocho años del historial de Steve Trucking, y su calidad varía según el centro de distribución. ¿Deberíamos limpiar los ocho años con el estándar de hoy antes de moverlos? Probablemente no de forma automática. ¿Para qué son: las operaciones diarias, la consulta, los reclamos, los informes, el análisis de tendencias? ¿Todo tiene que estar en Salesforce, o algo puede quedarse en otro lugar? El capítulo de migración profundiza. La idea de gobierno: el historial no necesita automáticamente el mismo estándar que los datos activos. Si vas a tomar decisiones a partir de él, la calidad importa. Si lo conservas para consultarlo, puede bastar otro estándar. Conoce el propósito antes de gastar una fortuna en limpiar el pasado.

Mide aquello sobre lo que alguien va a actuar

El gobierno nunca termina, así que necesitas ver cuándo baja la calidad: tasas de duplicados que suben, más registros en cuarentena, más rechazos de integración, valores de relleno que se extienden, más solicitudes de excepción, informes que ya no cuadran. Pero no construyas 150 métricas para ignorar 143. En Steve Trucking, quizá sean las entregas sin una referencia de socio válida, las entregas sin una dirección utilizable, las referencias de pedido repetidas, los mensajes de socios rechazados, las cuentas atascadas en el estado provisional. Un tablero lleno de círculos verdes no significa que los datos sean buenos. Mide aquello sobre lo que alguien está dispuesto a actuar.

Más allá del examen: lo que cambia la IA. Los datos malos se convierten cada vez más en acciones malas. Una persona podría notar que un número de teléfono parece incorrecto antes de llamar; un agente simplemente usa el valor que le dan. Los clientes duplicados, los estados desactualizados, los valores obligatorios falsos y los identificadores equivocados se convierten directamente en el mensaje equivocado o en la actualización equivocada. Eso aumenta el valor de la prevención. No elimina la necesidad de responsables de datos.

Lo que decide aquí un arquitecto

• Qué fallos de calidad hacen el daño suficiente para justificar controles preventivos.
• Si los registros gobernados se crean libremente, solo desde el sistema con la autoridad o mediante un camino de provisional a gobernado.
• De qué atributos es dueño Salesforce y cuáles solo referencia.
• Qué pasa con los datos de entrada que no pasan las comprobaciones (aceptar, rechazar o poner en cuarentena) y quién es dueño de la excepción.
• Qué señales de calidad se miden, para que los responsables vean cuándo baja.

Nunca evitarás cada registro malo. El trabajo no son datos perfectos; es evitar que los datos malos evitables se conviertan en datos caros. Detén el duplicado antes de que tenga dos años de historial. Protege el identificador antes de que diez integraciones dependan del equivocado. Deja que ventas cree el prospecto, pero no finjas que es el cliente gobernado hasta que lo sea. Y cuando algo malo se cuele, asegúrate de que alguien pueda verlo, hacerse cargo de ello y arreglarlo.

Explora

• Ayuda de Salesforce, Things to Know About Duplicate Rules (opens in a new tab) (en inglés), consultado el 2026-10-14.
• Ayuda de Salesforce, Break Up Your Record Details with Dynamic Forms (opens in a new tab) y Required and Read-Only Fields in Dynamic Forms (opens in a new tab) (en inglés), consultado el 2026-10-14.