ANEXO 30

Responsables, roles y RACI FARO

Este anexo corresponde a la Fase 8 — Ejecución, etapa “Responsables y RACI”. Es la capa donde FARO Connect asigna responsables claros a acciones, alertas, tensiones, diagnósticos, recomendaciones, simulaciones y decisiones.

Hasta el Anexo 29, FARO ya puede crear acciones concretas. Ahora falta una pregunta crítica:

¿Quién responde realmente por cada cosa?

Porque una acción sin responsable es una intención. Una acción con responsable, vencimiento y evidencia empieza a ser gestión.

1. Objetivo del anexo

El objetivo del Anexo 30 — Responsables, roles y RACI FARO es definir cómo FARO asigna:

Responsable
Aprobador
Consultados
Informados
Escalamiento
Sustitutos
Dueño del dato
Dueño del proceso
Dueño de la decisión

Ejemplo simple:

Acción:
Auditar descuentos mayores al 8%.

R — Responsable:
Gerente Comercial.

A — Aprobador:
Dirección.

C — Consultados:
Finanzas, Administración, RRHH.

I — Informados:
Vendedores, Gerencia General.

Vencimiento:
72 horas.

Evidencia:
Informe de descuentos y propuesta de política.

Esto evita el clásico “pensé que lo veía otro”. Frase corta, costo alto.

2. Tesis del Anexo 30

La tesis es:

FARO Connect no puede dirigir si no sabe quién debe responder por cada alerta, tensión, diagnóstico, recomendación y acción.

Un sistema de dirección necesita accountability.

No alcanza con detectar:

Caja baja.
Margen deteriorado.
Stock crítico.
Acciones vencidas.
Comisión desalineada.

FARO debe decir:

Quién responde.
Quién aprueba.
Quién debe colaborar.
Quién debe enterarse.
Cuándo escala.
A quién escala.
Qué evidencia debe presentar cada rol.

Sin eso, FARO sería un sistema inteligente hablando al vacío.

3. Qué es RACI

RACI es una matriz de responsabilidad.

Ejemplo:

Acción:
Revisar crédito de cliente grande moroso.

R:
Finanzas.

A:
Dirección.

C:
Comercial, Administración.

I:
Gerencia General.

Regla sana:

Una acción puede tener varios consultados, pero debe tener un solo responsable principal.

Si hay tres responsables principales, no hay responsable. Hay comité.

4. Diferencia entre responsable, aprobador y consultado

Ejemplo de mala asignación:

Responsable: Comercial / Finanzas / Dirección.

Eso es ambiguo.

Ejemplo FARO:

R: Finanzas.
A: Dirección.
C: Comercial.
I: Gerencia General.

Mucho mejor. Menos poesía, más ejecución.

5. Tipos de responsables FARO

FARO debería distinguir distintos tipos de responsables.

6. Estructura de roles FARO

FARO debe tener una tabla de roles, no solo nombres de personas.

Ejemplo:

{
  "role_code": "ROLE_COMMERCIAL_MANAGER",
  "role_name": "Gerente Comercial",
  "area": "Comercial",
  "can_approve": false,
  "can_execute": true,
  "can_escalate": true,
  "default_superior_role": "Dirección",
  "backup_role": "Jefe Comercial"
}

Por qué roles y no solo personas:

Las personas cambian.
Los cargos permanecen.
Las reglas deben asignarse por rol y luego mapearse a personas reales.

Ejemplo:

Regla:
Stock crítico → Responsable de Compras.

Asignación real:
Responsable de Compras = Laura Pérez.

7. Estructura estándar RACI FARO

Cada evento relevante debe tener RACI.

{
  "entity_type": "action",
  "entity_code": "ACT_COMMERCIAL_DISCOUNT_AUDIT",
  "raci": {
    "R": ["ROLE_COMMERCIAL_MANAGER"],
    "A": ["ROLE_DIRECTION"],
    "C": ["ROLE_FINANCE_MANAGER", "ROLE_HR_MANAGER"],
    "I": ["ROLE_GENERAL_MANAGER"]
  },
  "escalation": {
    "after_due_hours": 72,
    "escalate_to": "ROLE_GENERAL_MANAGER"
  }
}

8. Campos obligatorios de responsabilidad

9. Regla de oro: un solo R principal

FARO debe permitir varios colaboradores, pero un solo responsable principal.

Ejemplo correcto:

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

Ejemplo débil:

R: Comercial, Finanzas, RRHH, Dirección

Eso parece integrador, pero no sirve. En la práctica, nadie se siente dueño.

Regla FARO:

Una acción = un responsable principal.
Una decisión sensible = un aprobador claro.
Una tensión sistémica = un líder de resolución.

10. Matriz RACI por tipo de evento

11. Responsables por área

11.1 Comercial

Responsabilidades típicas:

ventas
margen
descuentos
clientes
canales
vendedores
política comercial
mix de productos
comisiones comerciales junto con RRHH/Finanzas

Eventos típicos:

margen bajo
descuento alto
cliente poco rentable
crecimiento no rentable
comisión desalineada
canal no rentable

RACI ejemplo:

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

11.2 Finanzas

Responsabilidades típicas:

caja
cobranza
mora
pagos
deuda
flujo operativo
presupuesto
gastos
rentabilidad financiera

Eventos típicos:

caja bajo mínimo
cobranza lenta
cliente moroso
gasto desalineado
flujo negativo
canje con riesgo financiero

RACI ejemplo:

R: Responsable de Finanzas
A: Dirección
C: Comercial, Administración
I: Gerencia General

11.3 Stock / Inventario

Responsabilidades típicas:

stock actual
stock físico
diferencias de inventario
mínimos
máximos
rotación
stock crítico
stock inmovilizado
redistribución

Eventos típicos:

stock crítico
stock mal compuesto
diferencia físico-sistema
stock inmovilizado
quiebre de producto clave

RACI ejemplo:

R: Responsable de Stock
A: Gerencia Operativa / Dirección
C: Compras, Comercial
I: Sucursales

11.4 Compras

Responsabilidades típicas:

proveedores
órdenes de compra
plazos
costos de reposición
compras urgentes
proveedores alternativos
negociación
abastecimiento

Eventos típicos:

proveedor crítico
compras reactivas
costo creciente
cobertura insuficiente
órdenes pendientes

RACI ejemplo:

R: Responsable de Compras
A: Dirección
C: Stock, Finanzas, Comercial
I: Sucursales

11.5 RRHH

Responsabilidades típicas:

dotación
ausentismo
productividad
roles
costo laboral
comisiones junto con Comercial/Finanzas
accountability
estructura

Eventos típicos:

comisión desalineada
costo laboral alto
ausentismo operativo
productividad baja
dependencia de persona clave

RACI ejemplo:

R: RRHH
A: Dirección
C: Finanzas, Responsable de área
I: Gerencia General

11.6 Operaciones

Responsabilidades típicas:

cumplimiento operativo
SLA
entregas
reclamos
procesos
cuellos de botella
capacidad
reprocesos

Eventos típicos:

SLA incumplido
reclamos recurrentes
demoras crecientes
cuello de botella
operación no sostiene promesa comercial

RACI ejemplo:

R: Responsable Operativo
A: Gerencia General
C: Comercial, Stock, Logística
I: Dirección

11.7 Data Owner / Sistemas

Responsabilidades típicas:

calidad de datos
integraciones
maestros
trazabilidad
normalización
fuentes
actualización
confiabilidad

Eventos típicos:

costos incompletos
productos sin maestro
clientes duplicados
stock desactualizado
fuente inconsistente
KPI con baja confianza

RACI ejemplo:

R: Data Owner
A: Dirección / Gerencia General
C: Área dueña del dato, Sistemas
I: Usuarios afectados

12. RACI por KPIs

Cada KPI crítico debe tener dueño.

Ejemplo:

Código conceptual:

def responsable_kpi(kpi_code):
    mapa = {
        "ventas_netas": "Gerente Comercial",
        "margen_bruto": "Comercial / Finanzas",
        "caja_disponible": "Finanzas",
        "dias_cobranza": "Finanzas",
        "stock_critico": "Stock / Compras",
        "comision_sobre_margen": "Comercial / RRHH",
        "acciones_vencidas": "Gerencia General",
        "calidad_datos": "Data Owner"
    }

    return mapa.get(kpi_code, "Responsable no definido")

13. RACI por tensiones

Las tensiones suelen involucrar varias áreas. Por eso necesitan un líder claro.

14. RACI por recomendaciones sensibles

Hay recomendaciones que requieren aprobación humana sí o sí.

Regla:

FARO puede sugerir. Las decisiones sensibles las aprueba un humano con rol formal.

15. Asignación automática de responsables

FARO puede asignar responsables automáticamente usando reglas.

Ejemplo:

def asignar_raci_por_evento(event_type, event_code):
    reglas = {
        "margin_critical": {
            "R": ["Gerente Comercial"],
            "A": ["Dirección"],
            "C": ["Finanzas", "Compras"],
            "I": ["Administración"]
        },
        "cash_below_minimum": {
            "R": ["Finanzas"],
            "A": ["Dirección"],
            "C": ["Comercial"],
            "I": ["Gerencia General"]
        },
        "stock_critical": {
            "R": ["Stock", "Compras"],
            "A": ["Dirección"],
            "C": ["Comercial", "Finanzas"],
            "I": ["Sucursal"]
        },
        "data_quality_critical": {
            "R": ["Data Owner"],
            "A": ["Dirección"],
            "C": ["Área dueña del dato", "Sistemas"],
            "I": ["Usuarios afectados"]
        }
    }

    return reglas.get(event_code)

Pero ojo: FARO debería asignar rol, y luego resolver persona.

Rol: Gerente Comercial.
Persona actual: Juan Pérez.

16. Resolución de rol a persona

Código conceptual:

def resolver_usuario_por_rol(role_code, company_id, branch_id=None):
    # Busca primero responsable específico por sucursal.
    usuario = buscar_responsable_especifico(role_code, company_id, branch_id)

    if usuario:
        return usuario

    # Si no hay, busca responsable general.
    usuario = buscar_responsable_general(role_code, company_id)

    if usuario:
        return usuario

    return None

Regla:

Si no existe persona asignada al rol, FARO debe crear alerta de responsabilidad no definida.

Porque una acción sin persona asignada nace renga.

17. Responsabilidad por sucursal

En empresas con varias sucursales, FARO debe distinguir:

responsable corporativo
responsable por sucursal
responsable regional
responsable funcional

Ejemplo:

Stock crítico en Sucursal San Juan:

R:
Responsable de Stock San Juan.

A:
Gerente Operativo / Dirección.

C:
Compras central, Comercial San Juan.

I:
Gerencia General.

Código:

def asignar_responsable_sucursal(evento):
    if evento["area"] == "stock" and evento.get("branch_id"):
        return {
            "R": f"Responsable Stock {evento['branch_id']}",
            "A": "Gerencia Operativa",
            "C": ["Compras Central", "Comercial Sucursal"],
            "I": ["Gerencia General"]
        }

    return None

18. Responsabilidad por dato

Cada fuente crítica debe tener Data Owner.

Ejemplo:

{
  "data_domain": "costos_productos",
  "data_owner": "Compras",
  "data_steward": "Administración",
  "approver": "Finanzas",
  "quality_threshold": 0.90
}

19. Responsabilidad por calidad de datos

Cuando un KPI tiene baja confianza, FARO debe saber quién corrige la fuente.

Ejemplo:

Problema:
Margen no confiable por costos incompletos.

R:
Compras / Data Owner.

A:
Finanzas / Dirección.

C:
Comercial, Sistemas.

I:
Gerencia General.

Código:

def asignar_responsable_calidad_datos(data_issue):
    mapa = {
        "costos_incompletos": {
            "R": "Compras / Data Owner",
            "A": "Finanzas",
            "C": ["Comercial", "Sistemas"],
            "I": ["Gerencia General"]
        },
        "stock_desactualizado": {
            "R": "Stock",
            "A": "Gerencia Operativa",
            "C": ["Compras", "Sistemas"],
            "I": ["Comercial"]
        },
        "clientes_duplicados": {
            "R": "Administración",
            "A": "Finanzas",
            "C": ["Comercial", "Sistemas"],
            "I": ["Gerencia General"]
        }
    }

    return mapa.get(data_issue)

20. Matriz de escalamiento

FARO debe escalar cuando una acción no avanza.

Código:

def regla_escalamiento(priority, hours_overdue):
    if priority == "P1" and hours_overdue >= 0:
        return "Dirección"

    if priority == "P2" and hours_overdue >= 24:
        return "Responsable superior"

    if priority == "P3" and hours_overdue >= 72:
        return "Responsable de área"

    if priority == "P4" and hours_overdue >= 168:
        return "Comité de área"

    return None

21. Sustitutos y backups

FARO debe contemplar ausencias.

Ejemplo:

Responsable:
Gerente Comercial.

Backup:
Jefe Comercial.

Si el responsable no acepta en 24 horas:
asignar backup o escalar.

Código:

def asignar_backup_si_no_responde(accion, horas_sin_aceptar):
    if horas_sin_aceptar >= 24 and accion.get("backup_role"):
        return {
            "new_responsible_role": accion["backup_role"],
            "reason": "responsable_no_acepto_en_plazo"
        }

    return None

22. Capacidad y sobrecarga de responsables

FARO debe detectar si alguien tiene demasiadas acciones críticas.

def detectar_sobrecarga(responsable, acciones):
    p1 = sum(1 for a in acciones if a["priority"] == "P1")
    p2 = sum(1 for a in acciones if a["priority"] == "P2")

    if p1 >= 3 or p1 + p2 >= 8:
        return {
            "responsable": responsable,
            "alerta": "sobrecarga_de_responsable",
            "accion_sugerida": "reasignar_prioridades_o_escalar"
        }

    return None

Lectura ejecutiva:

El problema no es solo que haya muchas acciones.
El problema es que todas caigan sobre la misma persona.

Eso no es accountability; es cuello de botella con nombre y apellido.

23. Mapa de responsabilidad por empresa

FARO debe permitir configurar:

empresa
sucursal
área
rol
persona
jerarquía
backup
permisos

Ejemplo:

{
  "company_id": "COMP_001",
  "branch_id": "BRANCH_SAN_JUAN",
  "area": "Stock",
  "role": "Responsable de Stock",
  "user": "Carlos López",
  "superior_role": "Gerente Operativo",
  "backup_user": "María Torres"
}

24. Permisos por rol

No todos pueden ver o aprobar todo.

Ejemplo:

{
  "role": "Gerente Comercial",
  "permissions": [
    "view_alerts",
    "accept_actions",
    "close_actions",
    "view_commercial_data",
    "override_recommendation"
  ]
}

25. Acciones que requieren aprobador

FARO debe marcar automáticamente acciones sensibles.

Código:

def requiere_aprobacion(action_code):
    acciones_sensibles = {
        "CHANGE_COMMISSION_POLICY": "Dirección",
        "BLOCK_CUSTOMER_CREDIT": "Dirección / Finanzas",
        "APPROVE_EXCHANGE_DEAL": "Directorio",
        "CHANGE_CREDIT_POLICY": "Dirección",
        "MASS_PRICE_CHANGE": "Dirección",
        "CHANGE_SCORE_RULES": "Dirección / Directorio"
    }

    return acciones_sensibles.get(action_code)

26. Registro de aceptación de responsabilidad

FARO debería exigir que el responsable acepte la acción.

Estados:

Assigned
Accepted
Rejected with reason
Reassigned
Escalated

Ejemplo:

{
  "action_id": "ACT_001",
  "assigned_to": "Gerente Comercial",
  "accepted_at": "2026-05-28T10:00:00",
  "acceptance_status": "accepted"
}

Si rechaza:

{
  "action_id": "ACT_001",
  "status": "rejected",
  "reason": "No corresponde al área Comercial; requiere datos de Finanzas.",
  "suggested_responsible": "Finanzas"
}

Regla:

Rechazar una acción debe exigir motivo. Sin motivo, es fuga elegante.

27. Reasignación de acciones

FARO debe permitir reasignar, pero con trazabilidad.

Código:

def reasignar_accion(action_id, old_responsible, new_responsible, reason):
    return {
        "action_id": action_id,
        "old_responsible": old_responsible,
        "new_responsible": new_responsible,
        "reason": reason,
        "requires_log": True
    }

Motivos posibles:

responsable incorrecto
sobrecarga
ausencia
cambio organizativo
acción corresponde a otra área
decisión superior

28. RACI y FARO Score

La responsabilidad también debe impactar el score.

Ejemplo:

Código:

def impacto_responsabilidad_score(evento):
    mapa = {
        "accion_aceptada_en_tiempo": 1,
        "accion_cerrada_con_evidencia": 3,
        "accion_critica_vencida": -5,
        "accion_rechazada_sin_motivo": -2,
        "accion_sin_responsable": -3,
        "tension_sin_lider": -4
    }

    return mapa.get(evento, 0)

29. RACI y workflow

El RACI alimenta el workflow.

Ejemplo:

R:
recibe tarea, carga evidencia, actualiza estado.

A:
aprueba cierre o decisión sensible.

C:
recibe solicitud de información.

I:
recibe notificación o resumen.

Flujo:

Acción creada
→ asignada al R
→ R acepta
→ C aporta datos
→ R ejecuta
→ R carga evidencia
→ A aprueba cierre
→ I recibe resultado
→ FARO mide impacto

30. RACI y comités

FARO puede generar agenda de comité según responsables.

Ejemplo:

Comité Comercial:
- margen bajo
- descuentos altos
- clientes poco rentables

Comité Financiero:
- caja
- cobranza
- gastos
- canjes

Comité Operativo:
- stock
- compras
- proveedores
- reclamos

Comité de Dirección:
- tensiones P1/P2
- acciones vencidas críticas
- decisiones sensibles

Código conceptual:

def asignar_comite(evento):
    mapa = {
        "comercial": "Comité Comercial",
        "finanzas": "Comité Financiero",
        "stock": "Comité Operativo",
        "compras": "Comité Operativo",
        "direccion": "Comité de Dirección"
    }

    return mapa.get(evento["area"], "Comité de Dirección")

31. RACI por industria

31.1 Construcción / insumos

Roles clave:

Dirección
Gerencia General
Gerente Comercial
Responsable de Finanzas
Responsable de Stock
Responsable de Compras
Responsable de Sucursal
RRHH
Administración
Data Owner
Legal externo si aplica

Eventos particulares:

canjes
referidos
ventas a obra
stock crítico por familia
comisiones comerciales
fletes
cuentas corrientes
proveedores críticos

RACI ejemplo — canje:

R: Finanzas / Dirección
A: Directorio
C: Comercial, Legal, Administración
I: Gerencia General

RACI ejemplo — referidos:

R: Comercial
A: Dirección
C: Finanzas, Administración
I: Gerencia General

31.2 Retail

Roles clave:

Gerente Comercial
Gerente de Sucursal
Stock
Compras
Marketing
Finanzas
Operaciones

Eventos:

promociones
merma
quiebre producto estrella
stock lento
ticket promedio

31.3 Logística

Roles clave:

Operaciones
Flota
Mantenimiento
Finanzas
Comercial
Seguridad

Eventos:

ruta no rentable
SLA incumplido
combustible alto
mantenimiento reactivo
flota ociosa

31.4 Hotelería

Roles clave:

Revenue Management
Operaciones
Recepción
Mantenimiento
Finanzas
Comercial

Eventos:

ocupación alta con tarifa baja
canal caro
RevPAR bajo
reclamos
mantenimiento diferido

32. Tabla SQL de roles

CREATE TABLE roles (
    role_id TEXT PRIMARY KEY,
    role_code TEXT NOT NULL,
    role_name TEXT NOT NULL,
    company_id TEXT,
    area_id TEXT,
    role_type TEXT,
    can_execute BOOLEAN DEFAULT true,
    can_approve BOOLEAN DEFAULT false,
    can_validate BOOLEAN DEFAULT false,
    can_escalate BOOLEAN DEFAULT false,
    active BOOLEAN DEFAULT true,
    created_at TIMESTAMP DEFAULT now(),
    updated_at TIMESTAMP DEFAULT now()
);

33. Tabla SQL de usuarios y roles

CREATE TABLE user_roles (
    user_role_id TEXT PRIMARY KEY,
    user_id TEXT NOT NULL,
    role_id TEXT NOT NULL,
    company_id TEXT,
    branch_id TEXT,
    area_id TEXT,
    is_primary BOOLEAN DEFAULT true,
    is_backup BOOLEAN DEFAULT false,
    active BOOLEAN DEFAULT true,
    assigned_at TIMESTAMP DEFAULT now()
);

34. Tabla SQL de matriz RACI

CREATE TABLE raci_matrix (
    raci_id TEXT PRIMARY KEY,
    entity_type TEXT NOT NULL,
    entity_code TEXT NOT NULL,
    company_id TEXT,
    industry_id TEXT,
    area_id TEXT,
    responsible_roles JSONB,
    accountable_roles JSONB,
    consulted_roles JSONB,
    informed_roles JSONB,
    backup_roles JSONB,
    escalation_roles JSONB,
    active BOOLEAN DEFAULT true,
    version TEXT DEFAULT '1.0',
    created_at TIMESTAMP DEFAULT now(),
    updated_at TIMESTAMP DEFAULT now()
);

35. Tabla SQL de asignaciones

CREATE TABLE responsibility_assignments (
    assignment_id TEXT PRIMARY KEY,
    entity_type TEXT NOT NULL,
    entity_id TEXT NOT NULL,
    company_id TEXT,
    branch_id TEXT,
    area_id TEXT,
    responsible_user_id TEXT,
    responsible_role_id TEXT,
    accountable_user_id TEXT,
    accountable_role_id TEXT,
    consulted_users JSONB,
    informed_users JSONB,
    backup_user_id TEXT,
    escalation_user_id TEXT,
    assignment_status TEXT DEFAULT 'assigned',
    accepted_at TIMESTAMP,
    rejected_at TIMESTAMP,
    rejection_reason TEXT,
    created_at TIMESTAMP DEFAULT now(),
    updated_at TIMESTAMP DEFAULT now()
);

36. Tabla SQL de permisos

CREATE TABLE role_permissions (
    permission_id TEXT PRIMARY KEY,
    role_id TEXT NOT NULL,
    permission_code TEXT NOT NULL,
    permission_scope TEXT,
    active BOOLEAN DEFAULT true,
    created_at TIMESTAMP DEFAULT now()
);

Ejemplos de permission_code:

view_financial_data
view_hr_data
approve_sensitive_decision
close_action
validate_data_quality
edit_thresholds
edit_business_rules
assign_responsible
override_recommendation

37. Motor de asignación de responsables

Flujo recomendado:

Evento creado
→ identificar tipo de evento
→ buscar RACI aplicable
→ resolver rol a persona
→ validar permisos
→ asignar responsable
→ notificar
→ esperar aceptación
→ activar backup si no acepta
→ escalar si vence

Código conceptual:

def motor_responsables(evento, raci_matrix):
    raci = buscar_raci(evento, raci_matrix)

    if not raci:
        return {
            "status": "missing_raci",
            "alert": "No existe matriz RACI para este evento."
        }

    responsable = resolver_usuario_por_rol(
        role_code=raci["R"][0],
        company_id=evento["company_id"],
        branch_id=evento.get("branch_id")
    )

    if not responsable:
        return {
            "status": "missing_responsible",
            "alert": "No hay usuario asignado al rol responsable."
        }

    return {
        "responsible": responsable,
        "raci": raci,
        "status": "assigned"
    }

38. Validación de RACI

FARO debe validar que toda acción importante tenga RACI completo.

Código:

def validar_raci(raci):
    errores = []

    if not raci.get("R"):
        errores.append("falta_responsable")

    if not raci.get("A"):
        errores.append("falta_aprobador")

    if len(raci.get("R", [])) > 1:
        errores.append("multiples_responsables_principales")

    return {
        "valid": len(errores) == 0,
        "errors": errores
    }

Regla:

P1 y P2 no deberían existir sin R y A definidos.

39. Ejemplo completo: crecimiento no rentable

Diagnóstico

Crecimiento no rentable.

Acciones

Auditar descuentos.
Revisar comisión.
Priorizar cobranza.
Analizar margen por vendedor.

RACI

R:
Gerente Comercial.

A:
Dirección.

C:
Finanzas, RRHH, Stock.

I:
Administración, Gerencia General.

Escalamiento

Si no acepta en 24 hs:
escalar a Gerencia General.

Si vence en 72 hs:
escalar a Dirección.

40. Ejemplo completo: caja bajo mínimo

Diagnóstico

Caja bajo mínimo operativo.

RACI

R:
Finanzas.

A:
Dirección.

C:
Comercial, Administración.

I:
Gerencia General.

Regla

Prioridad P1.
Vencimiento 24 hs.
Escalamiento inmediato si no hay avance.

41. Ejemplo completo: stock crítico

Diagnóstico

Riesgo futuro de stock crítico.

RACI

R:
Compras.

A:
Gerencia Operativa / Dirección.

C:
Stock, Comercial, Finanzas.

I:
Sucursal afectada.

Backup

Si Compras no responde:
Responsable de Stock activa validación y escala.

42. Ejemplo completo: datos insuficientes

Diagnóstico

Margen no confiable por costos incompletos.

RACI

R:
Data Owner / Compras.

A:
Finanzas.

C:
Comercial, Sistemas.

I:
Gerencia General.

Criterio

No se debe aprobar cambio comercial fuerte hasta corregir datos críticos.

43. Ejemplo completo: canje

Diagnóstico

Canje pendiente de evaluación.

RACI

R:
Finanzas / Dirección.

A:
Directorio.

C:
Comercial, Legal, Administración.

I:
Gerencia General.

Regla

No se aprueba canje sin:
valuación,
liquidez,
riesgo legal,
costo financiero,
comparativo contra venta normal.

44. RACI explicado para socio técnico

La explicación técnica es:

El módulo RACI no es una agenda de contactos.
Es una capa de gobierno que conecta:

1. Eventos detectados.
2. Roles funcionales.
3. Personas reales.
4. Permisos.
5. Aprobaciones.
6. Escalamiento.
7. Evidencia.
8. Score.
9. Auditoría.

FARO no solo dice “hay que hacer algo”. FARO sabe quién debe hacerlo, quién lo aprueba, a quién consulta y a quién informa.

45. Prompt interno para IA explicativa

La IA puede redactar el RACI para el usuario, pero no debe inventar responsables.

Actúa como analista ejecutivo FARO.

Con base únicamente en el payload estructurado recibido, redacta la asignación de responsables en formato claro.

No inventes personas ni roles.
Incluye:
1. responsable principal,
2. aprobador,
3. consultados,
4. informados,
5. vencimiento,
6. escalamiento,
7. evidencia esperada.

Payload:
{raci_payload}

Regla:

La matriz RACI define. La IA solo explica.

46. Testing de responsables y RACI

Test RACI válido

def test_raci_valido():
    raci = {
        "R": ["Gerente Comercial"],
        "A": ["Dirección"],
        "C": ["Finanzas", "RRHH"],
        "I": ["Administración"]
    }

    resultado = validar_raci(raci)

    assert resultado["valid"] is True

Test sin responsable

def test_raci_sin_responsable():
    raci = {
        "R": [],
        "A": ["Dirección"],
        "C": ["Finanzas"],
        "I": []
    }

    resultado = validar_raci(raci)

    assert resultado["valid"] is False
    assert "falta_responsable" in resultado["errors"]

Test múltiples responsables

def test_raci_multiples_responsables():
    raci = {
        "R": ["Comercial", "Finanzas"],
        "A": ["Dirección"],
        "C": [],
        "I": []
    }

    resultado = validar_raci(raci)

    assert resultado["valid"] is False
    assert "multiples_responsables_principales" in resultado["errors"]

47. Errores comunes en responsabilidades

48. Riesgos si no existe esta capa

49. Output final del Anexo 30

Al finalizar este anexo, FARO debe tener definido:

1. Catálogo de roles FARO.
2. Personas asignadas por rol.
3. Responsables por área.
4. Responsables por sucursal.
5. Responsables por KPI.
6. Responsables por dato.
7. Responsables por alerta.
8. Responsables por tensión.
9. Responsables por diagnóstico.
10. Responsables por acción.
11. Matriz RACI por evento.
12. Aprobadores por decisión sensible.
13. Consultados e informados.
14. Backups y sustitutos.
15. Permisos por rol.
16. Reglas de aceptación.
17. Reglas de rechazo con motivo.
18. Reglas de reasignación.
19. Reglas de escalamiento.
20. Detección de sobrecarga.
21. Impacto en FARO Score.
22. Tablas SQL de roles, permisos y RACI.
23. Motor de asignación de responsables.
24. Testing de RACI.
25. Auditoría de responsabilidad.

50. Conexión con otros anexos

El módulo de Responsables y RACI FARO define quién ejecuta, quién aprueba, quién debe ser consultado y quién debe ser informado para cada KPI, alerta, tensión, diagnóstico, recomendación, Action Guide y acción. Es la capa que convierte tareas en accountability real, con permisos, vencimientos, backups, escalamiento y trazabilidad.