ANEXO 16

Relaciones entre datos FARO

Este anexo corresponde a la Fase 4 — Estructura, etapa “Relaciones entre datos”. Es una de las capas más importantes de FARO Connect, porque permite que el sistema deje de mirar indicadores aislados y empiece a entender causa, impacto, dependencia, tensión y efecto cruzado entre áreas.

1. Objetivo del anexo

El objetivo del Anexo 16 — Relaciones entre datos es definir cómo FARO Connect conecta variables de distintas áreas para entender qué impacto tiene una cosa sobre otra.

La pregunta central es:

¿Qué pasa en la empresa cuando una variable cambia?

Ejemplo:

Descuento aumenta
→ margen baja
→ comisión puede mantenerse alta
→ cobranza puede empeorar
→ caja se tensiona
→ stock rota más rápido
→ compras se vuelven urgentes
→ FARO Score baja

Esto es clave porque una empresa no funciona por indicadores separados. Funciona como sistema.

2. Tesis del Anexo 16

La tesis es:

FARO Connect debe entender relaciones entre datos, no solo datos.

Un dashboard tradicional muestra:

Ventas: +18%
Margen: -7 puntos
Cobranza: +10 días
Stock crítico: alto

FARO debe decir:

La empresa está vendiendo más, pero con menor margen, peor cobranza y mayor presión de stock. La tensión probable es crecimiento no rentable con impacto comercial, financiero y operativo.

Esa es la diferencia entre mirar números y dirigir.

3. Qué es una relación entre datos

Una relación entre datos es una conexión lógica, matemática, operativa o causal entre dos o más variables.

Ejemplo:

Variable A: descuento promedio
Variable B: margen bruto

Relación:
si descuento promedio sube y el costo se mantiene, el margen bruto tiende a bajar.

Otro ejemplo:

Variable A: stock actual
Variable B: venta promedio diaria
Variable C: plazo de reposición

Relación:
si los días de cobertura son menores al plazo de reposición, existe riesgo de quiebre de stock.

4. Diferencia entre dato, KPI, relación y tensión

La relación es la base para detectar tensiones.

Sin relaciones, FARO solo ve números. Con relaciones, FARO empieza a entender la empresa.

5. Tipos de relaciones FARO

FARO debería manejar distintos tipos de relaciones.

6. Qué debe conectar FARO

FARO debe poder conectar:

KPIs entre sí.
KPIs con áreas.
KPIs con responsables.
KPIs con tensiones.
Tensiones con acciones.
Acciones con resultados.
Resultados con FARO Score.
Datos con procesos.
Procesos con decisiones.
Decisiones con ejecución.
Ejecución con aprendizaje.

Ejemplo:

KPI: margen bruto
Área: Comercial
Relacionado con: Finanzas, Stock, Compras
Tensiones posibles: crecimiento no rentable, margen deteriorado, comisión desalineada
Acciones posibles: auditar descuentos, revisar costos, ajustar comisiones
Score afectado: Score Comercial, Score Financiero, Score Global

7. Mapa base de relaciones FARO

Una biblioteca inicial debería contemplar:

300 a 800 relaciones causa-impacto iniciales.

Escalable a:

2.000+ relaciones por industria, módulo, KPI, tensión, acción y contexto.

Ejemplo de volumen inicial:

8. Estructura estándar de una relación FARO

Cada relación debe tener una ficha estructurada.

{
  "relation_id": "REL_COM_FIN_001",
  "name": "Descuento afecta margen",
  "source_variable": "descuento_promedio",
  "target_variable": "margen_bruto",
  "relation_type": "causal_directa",
  "direction": "negativa",
  "areas": ["Comercial", "Finanzas"],
  "description": "Cuando el descuento promedio aumenta, el margen bruto tiende a disminuir si el costo se mantiene.",
  "conditions": [
    "costo_unitario_estable",
    "precio_lista_constante"
  ],
  "related_kpis": [
    "descuento_promedio",
    "margen_bruto",
    "ventas_netas"
  ],
  "related_tensions": [
    "margen_deteriorado",
    "crecimiento_no_rentable"
  ],
  "confidence": 0.90,
  "industry_scope": ["construction_supplies", "retail", "manufacturing"],
  "actions": [
    "auditar_descuentos_altos",
    "revisar_politica_comercial"
  ]
}

9. Dirección de la relación

Una relación puede ser positiva, negativa o mixta.

10. Relaciones comerciales

11. Relaciones financieras

12. Relaciones de stock y compras

13. Relaciones RRHH

14. Relaciones operativas

15. Relaciones de dirección

16. Modelo de grafo FARO

Las relaciones entre datos pueden representarse como un grafo.

Nodo = dato, KPI, área, proceso, responsable, tensión o acción.
Arista = relación entre nodos.
Peso = fuerza de la relación.
Dirección = sentido del impacto.
Confianza = calidad de evidencia.

Ejemplo:

descuento_promedio
    ↓ relación negativa
margen_bruto
    ↓ relación con
crecimiento_no_rentable
    ↓ genera
auditar_descuentos_altos
    ↓ asignada a
gerente_comercial

17. Estructura de grafo en JSON

{
  "nodes": [
    {
      "id": "KPI_DESCUENTO_PROMEDIO",
      "type": "kpi",
      "area": "Comercial"
    },
    {
      "id": "KPI_MARGEN_BRUTO",
      "type": "kpi",
      "area": "Comercial"
    },
    {
      "id": "TENSION_CRECIMIENTO_NO_RENTABLE",
      "type": "tension",
      "area": "Comercial-Finanzas"
    },
    {
      "id": "ACTION_AUDITAR_DESCUENTOS",
      "type": "action",
      "area": "Comercial"
    }
  ],
  "edges": [
    {
      "from": "KPI_DESCUENTO_PROMEDIO",
      "to": "KPI_MARGEN_BRUTO",
      "relation": "negative_impact",
      "weight": 0.85
    },
    {
      "from": "KPI_MARGEN_BRUTO",
      "to": "TENSION_CRECIMIENTO_NO_RENTABLE",
      "relation": "contributes_to",
      "weight": 0.90
    },
    {
      "from": "TENSION_CRECIMIENTO_NO_RENTABLE",
      "to": "ACTION_AUDITAR_DESCUENTOS",
      "relation": "suggests_action",
      "weight": 0.80
    }
  ]
}

18. Modelo SQL para relaciones

Una tabla simple de relaciones podría ser:

CREATE TABLE faro_relations (
    relation_id TEXT PRIMARY KEY,
    source_entity_type TEXT NOT NULL,
    source_entity_id TEXT NOT NULL,
    target_entity_type TEXT NOT NULL,
    target_entity_id TEXT NOT NULL,
    relation_type TEXT NOT NULL,
    direction TEXT,
    weight NUMERIC,
    confidence NUMERIC,
    area_scope JSONB,
    industry_scope JSONB,
    conditions JSONB,
    active BOOLEAN DEFAULT true,
    created_at TIMESTAMP DEFAULT now(),
    updated_at TIMESTAMP DEFAULT now()
);

Ejemplo:

INSERT INTO faro_relations (
    relation_id,
    source_entity_type,
    source_entity_id,
    target_entity_type,
    target_entity_id,
    relation_type,
    direction,
    weight,
    confidence
)
VALUES (
    'REL_001',
    'kpi',
    'descuento_promedio',
    'kpi',
    'margen_bruto',
    'causal_directa',
    'negativa',
    0.85,
    0.90
);

19. Peso de relación

No todas las relaciones tienen la misma fuerza.

Ejemplo:

Descuento → margen: peso 0.90
Clima → venta retail: peso 0.35
Stock crítico → venta perdida: peso 0.75
Tareas vencidas → reincidencia: peso 0.80

20. Confianza de relación

La confianza depende de la calidad de los datos y de la evidencia histórica.

Confianza de relación =
calidad de datos × 35%
+ evidencia histórica × 25%
+ validación experta × 20%
+ consistencia sectorial × 20%

Código:

def confianza_relacion(calidad_datos, evidencia_historica, validacion_experta, consistencia_sectorial):
    return round(
        calidad_datos * 0.35 +
        evidencia_historica * 0.25 +
        validacion_experta * 0.20 +
        consistencia_sectorial * 0.20,
        2
    )

Lectura:

21. Relación no es causalidad automática

Esto hay que explicarlo bien ante un CTO o socio técnico.

FARO puede detectar relaciones, pero no debe afirmar causalidad fuerte sin evidencia suficiente.

Ejemplo:

Ventas suben y margen baja.

Eso puede deberse a:

mayores descuentos,
suba de costos,
cambio de mix,
cliente de bajo margen,
error de costo,
promoción,
canal más caro.

Por eso FARO debe usar lenguaje prudente:

Relación probable.
Causa posible.
Tensión detectada.
Confianza media.
Requiere validación.

No hay que vender magia. Hay que vender arquitectura seria.

22. Relación temporal

Algunas relaciones no ocurren en el mismo momento.

Ejemplo:

Venta hoy
→ cobranza en 30 días
→ impacto en caja futura

Otro ejemplo:

Compra urgente hoy
→ costo sube hoy
→ margen baja cuando se venda

FARO debe guardar relaciones con delay temporal.

{
  "relation_id": "REL_SALES_CASH_001",
  "source": "ventas_netas",
  "target": "caja_disponible",
  "relation_type": "temporal",
  "expected_lag_days": 30,
  "direction": "positiva_condicional",
  "condition": "cliente_cobra_en_plazo"
}

23. Fórmula de impacto esperado

FARO puede estimar impacto entre variables.

Ejemplo simple:

Impacto esperado =
variación variable origen × peso relación × confianza

Código:

def impacto_esperado(variacion_origen, peso_relacion, confianza):
    return round(variacion_origen * peso_relacion * confianza, 4)

Ejemplo:

Descuento sube 5 puntos.
Peso relación descuento → margen = 0.85.
Confianza = 0.90.

Impacto esperado aproximado = 0.05 × 0.85 × 0.90 = 0.03825

Lectura:

La suba de descuento podría explicar aproximadamente 3,8 puntos de deterioro de margen, sujeto a validación.

24. Relaciones entre KPIs principales

Comercial ↔ Finanzas

Comercial ↔ Stock

Stock ↔ Compras

RRHH ↔ Comercial

Dirección ↔ Ejecución

25. Relaciones y tensiones FARO

Una tensión nace cuando varias relaciones se activan al mismo tiempo.

Ejemplo: crecimiento no rentable

Ventas ↑
+ descuento ↑
+ margen ↓
+ días de cobranza ↑
= crecimiento no rentable

Regla conceptual:

def detectar_tension_crecimiento_no_rentable(ctx):
    relaciones_activas = []

    if ctx["ventas_variacion"] > 0.15:
        relaciones_activas.append("ventas_crecen")

    if ctx["descuento_variacion"] > 0.04:
        relaciones_activas.append("descuento_presiona_margen")

    if ctx["margen_variacion"] < -0.05:
        relaciones_activas.append("margen_deteriorado")

    if ctx["dias_cobranza_variacion"] > 7:
        relaciones_activas.append("caja_futura_tensionada")

    if len(relaciones_activas) >= 3:
        return {
            "tension": "crecimiento_no_rentable",
            "relaciones_activas": relaciones_activas,
            "severidad": "alta"
        }

    return None

26. Relaciones y recomendaciones

Las relaciones permiten que las recomendaciones no sean genéricas.

Ejemplo:

Si margen baja por descuento:
revisar política comercial.

Si margen baja por costo:
revisar proveedor o precio de compra.

Si margen baja por mix:
revisar foco comercial.

Si margen baja por comisión:
rediseñar variable comercial.

Código conceptual:

def recomendar_por_causa(causa_probable):
    recomendaciones = {
        "descuento_alto": "revisar_politica_de_descuentos",
        "costo_alto": "renegociar_proveedor_o_actualizar_precio",
        "mix_bajo_margen": "redirigir_foco_comercial",
        "comision_desalineada": "redisenar_formula_de_comision"
    }

    return recomendaciones.get(causa_probable, "revisar_causa_con_direccion")

Esto es clave: FARO no debe decir siempre “revisar margen”. Debe decir qué parte del sistema revisar.

27. Relaciones y FARO Score

Las relaciones permiten explicar por qué sube o baja el score.

Ejemplo:

FARO Score baja 8 puntos porque:
- margen cayó,
- descuentos subieron,
- cobranza empeoró,
- hay acciones vencidas,
- la tensión crecimiento no rentable sigue abierta.

Código simple:

def explicar_score(componentes):
    causas = []

    if componentes["margen"] < 0:
        causas.append("margen_deteriorado")

    if componentes["cobranza"] < 0:
        causas.append("cobranza_empeorada")

    if componentes["acciones"] < 0:
        causas.append("acciones_vencidas")

    if componentes["tensiones"] < 0:
        causas.append("tensiones_abiertas")

    return causas

El score no debe ser un número misterioso. Tiene que tener relato técnico y ejecutivo.

28. Relaciones por industria

Construcción / insumos

Retail

Salud

Logística

Hotelería

29. Relación con datos externos

En versiones avanzadas, FARO puede sumar datos externos.

Ejemplo:

Tipo de cambio sube
→ costo reposición importado sube
→ margen futuro baja si precio no se ajusta
→ alerta de actualización de precios

30. Motor de relaciones FARO

El motor de relaciones debería hacer cinco cosas:

1. Leer KPIs y variables.
2. Detectar relaciones activas.
3. Evaluar peso y confianza.
4. Agrupar relaciones en tensiones.
5. Sugerir acciones según causa probable.

Flujo:

KPIs
→ relaciones activas
→ patrón detectado
→ tensión probable
→ diagnóstico
→ prioridad
→ recomendación
→ acción

Código conceptual:

def motor_relaciones(contexto, relaciones):
    relaciones_activas = []

    for relacion in relaciones:
        if evaluar_condiciones(relacion, contexto):
            relaciones_activas.append(relacion)

    tensiones = detectar_tensiones_desde_relaciones(relaciones_activas)

    recomendaciones = generar_recomendaciones(tensiones)

    return {
        "relaciones_activas": relaciones_activas,
        "tensiones": tensiones,
        "recomendaciones": recomendaciones
    }

31. Ejemplo completo: crecimiento no rentable

Datos

Ventas: +18%
Margen: 28% → 21%
Descuento promedio: 6% → 12%
Días de cobranza: 32 → 42
Comisión: +15%

Relaciones activas

Ventas ↑ → comisión ↑
Descuento ↑ → margen ↓
Días de cobranza ↑ → caja futura ↓
Comisión ↑ + margen ↓ → incentivo desalineado

Tensión detectada

Crecimiento no rentable

Diagnóstico FARO

La empresa crece en ventas, pero ese crecimiento está deteriorando margen, caja futura e incentivos comerciales.

Acción sugerida

Auditar operaciones con descuento mayor al 8%.
Revisar comisión para incluir margen y cobranza.
Priorizar cobranza de clientes de alto volumen.

Responsable

R: Gerente Comercial
A: Dirección
C: Finanzas, RRHH, Stock
I: Administración

32. Ejemplo completo: stock mal compuesto

Datos

Stock total: +22%
Rotación: -15%
Quiebres productos clave: 8 casos
Stock inmovilizado: +30%

Relaciones activas

Stock total ↑ + rotación ↓ → capital parado
Quiebres ↑ → pérdida comercial
Stock inmovilizado ↑ → caja atrapada

Tensión detectada

Stock mal compuesto

Diagnóstico FARO

La empresa tiene más capital en inventario, pero no necesariamente en los productos correctos. Hay sobrestock en productos lentos y faltantes en productos críticos.

Acción sugerida

Bloquear compras de baja rotación.
Priorizar reposición de productos críticos.
Revisar mix de stock por sucursal.

33. Ejemplo completo: dirección sin ejecución

Datos

Decisiones tomadas: 24
Acciones creadas: 15
Acciones vencidas: 8
Problemas reincidentes: 5
Acciones cerradas sin impacto medido: 10

Relaciones activas

Decisiones ↑ sin acciones suficientes → baja ejecución
Acciones vencidas ↑ → score ejecución ↓
Reincidencia ↑ → aprendizaje débil
Cierres sin medición → falsa resolución

Tensión detectada

Dirección sin ejecución

Diagnóstico FARO

La empresa toma decisiones, pero no logra convertirlas en ejecución medible. Se cierran tareas sin validar impacto y los problemas vuelven.

Acción sugerida

Activar workflow obligatorio con responsable, vencimiento, KPI afectado y medición posterior.

34. Herramientas posibles

35. Riesgos si no existe esta capa

36. Output final del Anexo 16

Al finalizar este anexo, FARO debe tener definido:

1. Biblioteca inicial de relaciones causa-impacto.
2. Tipos de relaciones FARO.
3. Relaciones entre KPIs.
4. Relaciones entre áreas.
5. Relaciones entre procesos.
6. Relaciones entre datos y tensiones.
7. Relaciones entre tensiones y acciones.
8. Relaciones entre acciones y FARO Score.
9. Modelo de grafo FARO.
10. Peso de relaciones.
11. Confianza de relaciones.
12. Relaciones temporales.
13. Reglas para activar relaciones.
14. Reglas para agrupar relaciones en tensiones.
15. Relaciones específicas por industria.
16. Modelo de explicación causal.
17. Matriz de riesgo si la relación está activa.
18. Herramientas técnicas sugeridas.
19. Versionado de relaciones.
20. Base para aprendizaje futuro.

37. Conexión con otros anexos

Las relaciones entre datos son la capa que permite que FARO Connect entienda la empresa como sistema. Conectan KPIs, áreas, procesos, responsables, tensiones, acciones y score para explicar causa-impacto. Sin esta capa, FARO solo muestra indicadores; con esta capa, FARO interpreta qué está pasando y qué puede pasar después.