Skip to content
Variables duplicadas con distintos nombres en distintas reglas o modelos.Falta de jerarquización: no se distingue lo crítico de lo accesorio.Mezcla de variables técnicas, de negocio y métricas en el mismo nivel conceptual.Omisión estructural de variables de contexto o latentes que no aparecen en historias de usuario.
Variables causales: tipo_operacion → monto_esperado → diferencia_netaVariable latente: riesgo_discrepancia (inferida, no observable directamente)Variable de contexto: banco_origen (externa, no modificable)Variable proxy: similitud_referencia (aproxima identidad de transaccion) 
Si el output del proyecto informara una decision que afecta ingresos, margen, capital de trabajo o riesgo operativo: usar version completa.En caso de duda, usar version completa. La inversion es de 90 minutos; el costo del retrabajo es siempre mayor.
Mejor práctica en Identificación de variables
Protocolo estructurado para equipos de BDS: clasificación MECE, mapeo causal y criterios de calidad accionables.
Qué producirás con este protocolo
Una sesión de trabajo de 90 minutos con analistas, experto de dominio y dueño del proceso genera:
• Un mapa causal () de las reglas de negocio principales del dominio.
• La clasificación MECE de cada variable identificada, con su tipo y jerarquía.
• Un registro de variables descartadas y la razón de descarte.
Resultado: variables que emergen del consenso estructurado, no de la disponibilidad espontánea de ejemplos.
I. Problem actual
Por qué el enfoque no estructurado es costoso
La identificación de variables se realiza de forma no estructurada, basada en la disponibilidad de datos dentro de las historias de usuario y en la memoria reciente del analista.
Este enfoque activa el sesgo de disponibilidad (Kahneman, 2011): se seleccionan variables recordadas fácilmente de casos recientes, omitiendo otras estructuralmente relevantes. Las fallas documentadas son:
Costos del error
Falla
Consecuencia
Impacto
Variables redefinidas a mitad del análisis
Retrabajo de reglas y modelos
Horas-analista perdidas; retraso en entrega
Correlaciones espurias tomadas como causas
Decisiones mal calibradas
Falsos positivos/negativos en matching o riesgo
Bajo poder explicativo del modelo
Escalaciones frecuentes al equipo
Mayor carga operativa en revisión manual
Inconsistencia entre reglas
Resultados contradictorios entre dominios
Desconfianza del negocio en el sistema
There are no rows in this table
II: Marco de clasificación de variables
Cómo tipificar cada variable antes de medirla
Clasificar antes de medir evita confundir correlación con palanca de negocio. Usar una variable proxy como si fuera causa directa es el error más frecuente y costoso en modelos de negocio.
Clasificación bidimensional
Dimensión
Tipo
Definición
Ejemplo
Controlabilidad
3
De decisión
Controladas directamente por el sistema
match_score, status, regla aplicada
De contexto
Externas, no modificables por el sistema
banco, cuenta, tipo de CFDI
De ruido
Errores de medición o variaciones aleatorias
Variaciones de formato en nombre
Observabilidad
3
Directas
Medibles sin inferencia
monto, fecha, RFC
Proxies
Aproximaciones a la variable real
similitud_nombre como proxy de identidad
Latentes
No observables; requieren inferencia
riesgo de fraude, solvencia implícita
Regla clave de aplicación
Nunca usar una variable proxy como palanca de acción directa sin validar su relación causal con la variable latente que representa.
Nunca asumir que una variable de contexto puede convertirse en variable de decisión sin rediseño del sistema.
III. Protocolo de identificación
Los 5 pasos obligatorios — con inputs, outputs y responsables
Cada paso tiene un entregable concreto. Un paso está completo cuando su output puede revisarse independientemente del siguiente.
Paso 1 · Mapeo de causalidad (DAG)
*
Detalle
Input
Descripción del problema de negocio o regla a modelar (story, brief o reunión inicial)
Actividad
Construir un Grafo Acíclico Dirigido (DAG) que explicite las relaciones supuestas entre variables antes de seleccionar features. Seguir el enfoque de Pearl (2016).
Output
Diagrama DAG con nodos (variables) y aristas con direccion causal anotada
Responsable
Analista de datos, con participación del experto de dominio
Tiempo estimado
20-30 min en sesion colaborativa
Criterio de completitud
Toda variable en el DAG tiene al menos una arista entrante o saliente justificada en texto
There are no rows in this table
Ejemplo: dominio de conciliacion bancaria
Paso 2 · Revision de omisión
*
Detalle
Input
DAG generado en el Paso 1
Actividad
Aplicar el checklist de variables tipicamente ignoradas por dominio (ver tabla adjunta). Verificar contra cada categoria.
Output
Lista de variables omitidas detectadas, con justificacion de inclusion o descarte explícito
Responsable
Analista de datos
Tiempo estimado
15 min
Criterio de completitud
Cada categoria del checklist tiene al menos una decision documentada (incluir / descartar / no aplica)
There are no rows in this table
Checklist de variables frecuentemente omitidas
Categoria
Preguntas clave
Ejemplo
Contexto externo
¿Hay condiciones externas que afectan el resultado sin ser controlables?
Calendario fiscal, feriados bancarios, tipo de cambio
Temporalidad
¿El momento o secuencia importa? ¿Hay variables de ciclo?
Antiguedad de la transaccion, dia del mes, hora del registro
Variables latentes economicas
¿Hay un constructo implicito que el modelo deberia capturar?
Riesgo de fraude, capacidad de pago, intencionalidad
Calidad del dato
¿Hay variaciones de formato, duplicidades o valores nulos sistematicos?
RFC con distintos formatos, nombres con abreviaturas
Variables de ruido conocidas
¿Que factores generan variacion aleatoria no explicable?
Errores de captura, retrasos en sincronizacion de sistemas
There are no rows in this table
Paso 3 · Jerarquización por impacto economico
*
Detalle
Input
Lista consolidada de variables del DAG + omisiones incorporadas
Actividad
Priorizar variables usando el criterio: varianza explicada x consecuencia economica del error. No todas las variables tienen el mismo peso en la decision final.
Output
Tabla de variables rankeadas por prioridad (Alta / Media / Baja), con justificacion del criterio
Responsable
Analista de datos + dueno del proceso
Tiempo estimado
15-20 min
Criterio de completitud
Toda variable Alta tiene consecuencia economica del error documentada en terminos de negocio
There are no rows in this table
Criterio de prioridad
Alta: Variable que, si se omite o mal clasifica, genera decision incorrecta con consecuencia economica directa (fraude no detectado, conciliacion errada, rechazo incorrecto).
Media: Variable que mejora precision pero su omision no genera error critico.
Baja: Variable con varianza marginal o redundante con otra de mayor prioridad.
Paso 4 · Validación cruzada con experto de dominio
*
Detalle
Input
DAG + tabla de variables jerarquizadas
Actividad
El experto de dominio revisa el DAG para detectar relaciones causales erroneas, variables omitidas y supuestos invalidos. Se separa conocimiento tacito del analitico.
Output
DAG validado con anotaciones del experto; lista de supuestos explicitados
Responsable
Experto de dominio (valida); analista (documenta)
Tiempo estimado
15-20 min
Criterio de completitud
El experto firma el DAG (aprobacion explicita, no solo revision)
There are no rows in this table
Paso 5 · Agrupacion en entidades de negocio
*
Detalle
Input
Lista validada de variables
Actividad
Agrupar variables por entidad de negocio segun el dominio: archivo, transaccion, CFDI, matching, pagador. Esto facilita trazabilidad y reutilizacion entre proyectos.
Output
Diccionario de variables organizado por entidad, con tipo (segun Seccion II), prioridad y responsable de mantenimiento
Responsable
Analista de datos
Tiempo estimado
10 min
Criterio de completitud
Toda variable pertenece a exactamente una entidad (MECE); ninguna variable esta sin clasificar
There are no rows in this table
V. Criterios de calidad
KPIs del proceso con umbrales y frecuencia de revision
Estas métricas miden si el protocolo se está aplicando correctamente. No son opcionales en proyectos de alta criticidad.
Criterios
KPI
Fórmula
Umbral aceptable
Alerta
Frecuencia
% variables con hipotesis causal
(Variables con arista DAG justificada) / Total
> 80%
< 60%: revisar DAG
Por proyecto
Tasa de redeficion post-analisis
(Variables que cambian tipo despues del 1er borrador) / Total
< 15%
> 25%: falla de protocolo
Por iteracion
Cobertura contexto vs. decision
# variables contexto / # variables decision
Documentado (no hay 1:1 obligatorio)
0 variables de contexto: revision obligatoria
Por proyecto
% duplicidad eliminada
Variables unicas post / Variables crudas iniciales
> 90%
< 80%: diccionario incompleto
Por proyecto
Completitud de datos criticos
% registros no nulos en variables de prioridad Alta
> 95%
< 90%: riesgo de modelo
Mensual
There are no rows in this table
V. Decisiones estratégicas
Trade-offs resueltos con postura por defecto
Cada trade-off incluye la recomendación por defecto del equipo BDS y la condicion para desviarse de ella.
Decision 1: ¿Estandarizar protocolo completo o mantener enfoque ad hoc?
*
Protocolo completo (recomendado)
Ad hoc (excepción)
Cuando aplica
Proyectos de produccion, modelos que afectan decisiones economicas, dominios nuevos
Exploracion inicial, pruebas de concepto, demos sin impacto operativo
Ventaja
Rigor, escalabilidad, trazabilidad, reduccion de retrabajo
Velocidad inicial
Riesgo
Mayor inversion de tiempo en setup (compensado en iteraciones posteriores)
Deuda analitica: retrabajo garantizado en produccion
Postura BDS
Usar protocolo completo por defecto
Requiere aprobacion explicita del lider de proyecto
There are no rows in this table
Decision 2: ¿Incluir variables latentes?
*
Incluir (recomendado)
Excluir
Cuando aplica
Variable latente tiene consecuencia economica documentada (ej. riesgo, solvencia)
Variable latente no tiene proxy confiable ni experto que la valide
Ventaja
Mayor poder explicativo; modelos mas robustos
Menor complejidad de inferencia
Riesgo
Requiere modelo de inferencia adicional; mayor costo de mantenimiento
Modelo omite factor estructural; correlaciones espurias mas probables
Postura BDS
Incluir si hay al menos un proxy observable y validacion de experto
Documentar la exclusion y su justificacion en el diccionario de variables
There are no rows in this table
Decision 3: ¿Quien valida el mapa causal?
*
Con experto de dominio (recomendado)
Sólo equipo analítico
Cuando aplica
Siempre en proyectos de produccion o nuevos dominios
Dominios ya validados con DAG documentado y reutilizable
Ventaja
Captura conocimiento tacito; reduce riesgo de omision estructural
Menor costo de tiempo
Riesgo
Costo de coordinacion (15-20 min adicionales)
Supuestos causales invalidos no detectados
Postura BDS
Experto valida en toda sesion de 90 min
Excepcion solo si DAG previo aplica y esta documentado
There are no rows in this table
VI. Cuando aplicar version ligera
Criterio de escalamiento del protocolo
No todo proyecto requiere los 5 pasos completos. El criterio de escalamiento evita sobre-ingenieria y sub-rigor.
Condiciones
Condición del proyecto
Version recomendada
Pasos requeridos
Produccion / impacto economico directo
Completa
Pasos 1, 2, 3, 4, 5
Dominio nuevo sin DAG previo
Completa
Pasos 1, 2, 3, 4, 5
Iteracion sobre dominio ya documentado
Intermedia
Pasos 1 (actualizar DAG), 3, 5
Exploracion / PoC sin impacto operativo
Ligera
Paso 1 (DAG simplificado) + Paso 5 (agrupacion basica)
Demo o prototipo interno
Minima
Solo clasificacion MECE (Seccion II) sin DAG formal
There are no rows in this table
Regla de escalamiento
Materiales relacionados:
Referencias
DAMA International. (2017). DAMA-DMBOK: Data Management Body of Knowledge (2nd ed.). Technics Publications.
Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux.
Pearl, J., Glymour, M., & Jewell, N. P. (2016). Causal Inference in Statistics: A Primer. Wiley.
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.