ANEXO 40

Implementación por fases, backlog y plan de desarrollo FARO Connect

Este anexo corresponde a la Fase 12 — Construcción e implementación, etapa “Roadmap, backlog, MVP y plan de desarrollo”. Es la capa que convierte toda la arquitectura conceptual y técnica de FARO Connect en un plan concreto para construirlo.

Hasta el Anexo 39, FARO ya tiene definido:

arquitectura técnica,
frontend,
backend,
base de datos,
pipeline de datos,
motores,
IA,
workflow,
seguridad,
auditoría,
aprendizaje,
recalibración.

El Anexo 40 responde:

¿Por dónde se empieza, qué se construye primero, qué se deja para después, cuánto debe abarcar el MVP y cómo se organiza el desarrollo sin morir aplastado por la propia ambición?

Porque FARO es grande. Muy grande. Y justamente por eso hay que construirlo con orden quirúrgico.

1. Objetivo del anexo

El objetivo del Anexo 40 — Implementación por fases, backlog y plan de desarrollo es definir cómo llevar FARO Connect desde concepto a producto funcional.

Debe responder:

1. Qué se construye primero.
2. Qué entra en el MVP.
3. Qué queda fuera del MVP.
4. Qué módulos son críticos.
5. Qué módulos pueden esperar.
6. Qué backlog técnico necesita.
7. Qué backlog funcional necesita.
8. Qué entregables mostrar a un socio técnico.
9. Qué entregables mostrar a un inversor.
10. Qué entregables mostrar a un cliente piloto.
11. Qué riesgos controlar.
12. Qué equipo se necesita.
13. Cómo validar avance real.
14. Cómo evitar construir un monstruo inmanejable.

La prioridad es clara:

Primero columna vertebral. Después inteligencia. Después sofisticación. Después escala.

2. Tesis del Anexo 40

La tesis es:

FARO Connect debe construirse por capas, empezando por un MVP sólido que demuestre la cadena completa: dato → KPI → alerta → tensión → diagnóstico → recomendación → acción → responsable → evidencia → Score → reporte.

No sirve construir primero 300 pantallas. No sirve empezar por IA avanzada. No sirve hacer un dashboard hermoso sin motor. No sirve prometer Neural si todavía no se carga bien un Excel.

El MVP debe demostrar la tesis central:

FARO toma datos dispersos,
los ordena,
los interpreta,
detecta problemas,
sugiere qué hacer,
crea acciones,
asigna responsables,
mide ejecución,
calcula Score
y reporta a Dirección.

Con eso ya se puede convencer a un socio técnico serio. Lo demás escala desde ahí.

3. Principio rector de implementación

No construir todo FARO de una vez. Construir una versión mínima, pero completa en su lógica.

MVP chico no significa superficial.

Un MVP FARO debe ser:

pequeño en alcance,
serio en arquitectura,
claro en flujo,
demostrable en pantalla,
defendible técnicamente,
ampliable sin rehacer todo.

Error típico:

Hacer muchas pantallas lindas,
pero sin pipeline, sin reglas, sin acciones, sin evidencia y sin Score real.

Eso sería demo estética. FARO necesita demo ejecutiva.

4. La cadena mínima que debe funcionar

El MVP debe demostrar esta cadena completa:

Excel / carga manual
        ↓
RAW
        ↓
Staging
        ↓
Normalización básica
        ↓
Maestros mínimos
        ↓
Modelo ejecutivo
        ↓
KPIs
        ↓
Señales
        ↓
Alertas
        ↓
Tensiones
        ↓
Diagnóstico
        ↓
Prioridad
        ↓
Recomendación
        ↓
Acción
        ↓
Responsable
        ↓
Workflow
        ↓
Evidencia
        ↓
Seguimiento
        ↓
FARO Score
        ↓
Reporte ejecutivo

Si esa cadena funciona, FARO existe.

Aunque tenga pocos KPIs. Aunque tenga pocas tensiones. Aunque tenga pocas acciones.

La cadena vale más que la cantidad.

5. Qué debe demostrar el MVP

El MVP debe poder mostrar un caso realista como este:

Se carga un Excel de ventas, stock y cobranza.

FARO detecta:
ventas suben,
margen baja,
descuento sube,
cobranza empeora.

FARO genera:
tensión: crecimiento no rentable.

FARO recomienda:
auditar descuentos,
priorizar cobranza,
simular comisión.

FARO crea acciones:
Gerente Comercial audita descuentos.
Finanzas prioriza cobranza.
Dirección debe aprobar política comercial.

FARO mide:
acciones abiertas,
acciones vencidas,
evidencia cargada,
impacto en Score.

FARO reporta:
la empresa crece, pero con margen y caja tensionados.

Ese caso vende el concepto. Eso es mucho más potente que mostrar 80 gráficos sin relato.

6. Fase 0 — Preparación estratégica

Antes de programar, hay que cerrar definiciones.

6.1 Objetivo

Preparar el terreno para que el desarrollo no arranque con ambigüedad.

6.2 Entregables

1. Documento funcional maestro.
2. Tabla completa del flujo FARO.
3. Anexos 1-40 ordenados.
4. Casos de uso iniciales.
5. Modelo MVP definido.
6. Alcance fuera del MVP.
7. Glosario FARO.
8. Diccionario de datos mínimo.
9. Lista inicial de KPIs.
10. Lista inicial de tensiones.
11. Lista inicial de acciones.
12. Lista inicial de reportes.

6.3 Decisión clave

Elegir el primer caso vertical.

Recomendación:

Primer vertical demo:
empresa comercial / insumos / retail con ventas, stock, compras, cobranza y acciones.

Motivo:

Es suficientemente complejo para mostrar valor,
pero no tan regulado como salud o financiero puro.

7. Fase 1 — Base técnica del sistema

Objetivo

Construir la base tecnológica mínima.

Incluye:

frontend base,
backend base,
base de datos,
usuarios,
empresas,
roles,
permisos básicos,
auditoría mínima,
estructura modular.

Backlog técnico

Resultado esperado

Usuario puede entrar.
Sistema sabe a qué empresa pertenece.
Sistema tiene estructura base.
Se puede empezar a cargar información.

8. Fase 2 — Ingesta de datos

Objetivo

Permitir que FARO reciba datos.

Para MVP:

carga Excel,
carga CSV,
carga manual simple.

No arrancar con 15 integraciones. Primero carga controlada.

Fuentes MVP

ventas,
stock,
clientes,
productos,
cobranza,
compras básicas,
empleados/vendedores básicos.

Backlog

Ejemplo de payload de carga

{
  "source_type": "excel",
  "source_name": "ventas_mayo",
  "company_id": "COMP_001",
  "uploaded_by": "USER_001",
  "detected_columns": [
    "fecha",
    "cliente",
    "producto",
    "cantidad",
    "precio",
    "descuento",
    "vendedor"
  ]
}

9. Fase 3 — RAW, staging y normalización mínima

Objetivo

Ordenar datos sin perder trazabilidad.

Debe existir

RAW: dato original.
Staging: dato limpio pero no definitivo.
Normalizado: dato asociado a maestros.

Backlog

Regla

El dato que no se puede normalizar no debe desaparecer. Debe quedar como pendiente.

Código conceptual:

def normalize_or_flag(raw_value, master_table):
    match = find_match(raw_value, master_table)

    if match:
        return {
            "normalized_id": match["id"],
            "status": "normalized"
        }

    return {
        "normalized_id": None,
        "status": "pending_normalization",
        "raw_value": raw_value
    }

10. Fase 4 — Maestros mínimos

Objetivo

Crear entidades base para que FARO entienda la empresa.

Maestros MVP:

productos,
clientes,
vendedores,
sucursales,
áreas,
proveedores básicos,
familias de productos,
responsables.

Backlog

Criterio de aceptación

Una venta cargada debe poder asociarse a:
producto,
cliente,
vendedor,
sucursal.

Si no, los KPIs salen flojos.

11. Fase 5 — Modelo ejecutivo MVP

Objetivo

Crear las tablas fact mínimas.

Facts MVP:

fact_sales
fact_inventory
fact_accounts_receivable
fact_purchases_basic
fact_actions
fact_kpi_measurements

Backlog

Ejemplo fact_sales

CREATE TABLE fact_sales (
    sale_id TEXT PRIMARY KEY,
    company_id TEXT NOT NULL,
    branch_id TEXT,
    sale_date DATE NOT NULL,
    customer_id TEXT,
    product_id TEXT,
    seller_id TEXT,
    quantity NUMERIC,
    gross_amount NUMERIC,
    discount_amount NUMERIC,
    net_amount NUMERIC,
    cost_amount NUMERIC,
    gross_margin_amount NUMERIC,
    gross_margin_rate NUMERIC,
    created_at TIMESTAMP DEFAULT now()
);

12. Fase 6 — Biblioteca inicial de KPIs

Objetivo

Calcular los primeros KPIs ejecutivos.

No hace falta arrancar con 360 KPIs. Para MVP conviene iniciar con 25 a 40 KPIs bien elegidos.

KPIs MVP recomendados

Comercial

ventas netas,
ventas por sucursal,
ventas por vendedor,
margen bruto,
descuento promedio,
ticket promedio,
ventas por familia,
clientes activos.

Finanzas

caja disponible manual/inicial,
cuentas por cobrar,
deuda vencida,
días de cobranza,
mora por cliente,
cobranza estimada.

Stock

stock actual,
stock crítico,
días de cobertura,
stock inmovilizado,
rotación básica,
quiebres estimados.

Ejecución

acciones abiertas,
acciones vencidas,
acciones cerradas,
acciones con evidencia,
tiempo promedio de cierre.

Score

score comercial,
score financiero,
score stock,
score ejecución,
FARO Score básico.

13. Fase 7 — Señales y alertas MVP

Objetivo

Detectar cambios relevantes.

Señales iniciales:

ventas suben,
ventas bajan,
margen baja,
descuento sube,
cobranza empeora,
stock crítico,
stock inmovilizado,
acción vencida,
datos incompletos.

Alertas iniciales:

margen bajo,
descuento alto,
caja/cobranza en riesgo,
stock crítico,
cliente moroso importante,
acción P1 vencida,
datos insuficientes para diagnóstico.

Código ejemplo:

def detect_discount_alert(discount_rate, threshold=0.08):
    if discount_rate > threshold:
        return {
            "alert_code": "HIGH_DISCOUNT",
            "severity": "medium",
            "message": "Descuento promedio por encima del umbral."
        }

    return None

14. Fase 8 — Tensiones MVP

Objetivo

Demostrar que FARO no solo ve alertas aisladas, sino contradicciones de negocio.

Tensiones iniciales recomendadas:

1. Crecimiento no rentable.
2. Caja débil con ventas altas.
3. Stock crítico con demanda activa.
4. Stock inmovilizado con caja tensionada.
5. Comisión desalineada con margen.
6. Cliente grande riesgoso.
7. Compras reactivas.
8. Dirección sin ejecución.
9. Datos insuficientes para decidir.
10. Proveedor crítico.

Código ejemplo:

def tension_growth_not_profitable(ctx):
    conditions = [
        ctx["sales_growth"] > 0.10,
        ctx["margin_delta"] < -0.03,
        ctx["discount_delta"] > 0.02
    ]

    if sum(conditions) >= 3:
        return {
            "tension_code": "GROWTH_NOT_PROFITABLE",
            "severity": "high",
            "confidence": 0.82
        }

    return None

15. Fase 9 — Diagnóstico ejecutivo MVP

Objetivo

Traducir tensiones en lectura ejecutiva.

Ejemplo:

Tensión:
Crecimiento no rentable.

Diagnóstico:
La empresa está creciendo en ventas, pero con deterioro de margen. El aumento de descuentos y la cobranza más lenta indican que el crecimiento puede estar consumiendo rentabilidad y caja.

Backlog:

16. Fase 10 — Recomendaciones MVP

Objetivo

Que FARO sugiera acciones razonables.

Recomendaciones iniciales:

auditar descuentos,
priorizar cobranza,
revisar margen por vendedor,
validar stock físico,
emitir reposición preventiva,
bloquear cierre por datos incompletos,
simular comisión,
evaluar proveedor alternativo,
revisar cliente moroso,
crear política de descuento.

Ejemplo:

def recommendations_for_growth_not_profitable(ctx):
    recs = ["auditar_descuentos"]

    if ctx.get("collection_days_high"):
        recs.append("priorizar_cobranza")

    if ctx.get("commission_misaligned"):
        recs.append("simular_comision")

    return recs

17. Fase 11 — Acciones y responsables MVP

Objetivo

Convertir recomendaciones en acciones concretas.

Acciones MVP:

Auditar descuentos altos.
Priorizar cobranza de clientes críticos.
Validar stock físico.
Activar reposición preventiva.
Completar costos faltantes.
Revisar margen por vendedor.
Simular comisión.
Evaluar canje.
Revisar cliente grande moroso.
Cerrar acción vencida con evidencia.

Cada acción debe tener:

responsable,
prioridad,
vencimiento,
estado,
evidencia requerida,
origen.

Ejemplo payload:

{
  "action_code": "ACT_COMMERCIAL_DISCOUNT_AUDIT",
  "title": "Auditar descuentos mayores al umbral",
  "responsible_role": "ROLE_COMMERCIAL_MANAGER",
  "priority_level": "P2",
  "due_hours": 72,
  "required_evidence": [
    "listado_operaciones",
    "analisis_margen",
    "propuesta_correccion"
  ]
}

18. Fase 12 — Workflow simple MVP

Objetivo

Controlar estados básicos.

Estados MVP:

created
assigned
accepted
in_progress
waiting_evidence
completed
closed
overdue

No meter 25 estados al principio. Los estados deben ser suficientes para mostrar control sin complicar uso.

Backlog

Código:

def update_action_status(action, new_status):
    allowed = {
        "created": ["assigned"],
        "assigned": ["accepted", "in_progress"],
        "accepted": ["in_progress"],
        "in_progress": ["waiting_evidence", "completed"],
        "waiting_evidence": ["completed"],
        "completed": ["closed"],
        "overdue": ["in_progress", "closed"]
    }

    if new_status not in allowed.get(action["status"], []):
        raise ValueError("Transición no permitida")

    action["status"] = new_status
    return action

19. Fase 13 — Evidencia MVP

Objetivo

No permitir cierre sin prueba.

Tipos MVP:

archivo,
comentario estructurado,
aprobación,
KPI recalculado,
reporte generado.

Regla MVP:

Toda acción P1/P2 requiere evidencia para cerrar.

Backlog:

20. Fase 14 — FARO Score MVP

Objetivo

Mostrar un Score ejecutivo simple pero defendible.

Componentes MVP:

Score Comercial
Score Financiero
Score Stock
Score Ejecución
Score Calidad de Datos

Fórmula MVP:

FARO Score =
Comercial × 25%
+ Financiero × 25%
+ Stock × 20%
+ Ejecución × 20%
+ Calidad de datos × 10%

Código:

def faro_score_mvp(comercial, financiero, stock, ejecucion, calidad_datos):
    return round(
        comercial * 0.25 +
        financiero * 0.25 +
        stock * 0.20 +
        ejecucion * 0.20 +
        calidad_datos * 0.10,
        2
    )

Debe mostrar:

score actual,
variación,
drivers positivos,
drivers negativos,
confianza,
foco recomendado.

21. Fase 15 — Reporte ejecutivo MVP

Objetivo

Generar el primer reporte FARO.

Reporte MVP:

1. FARO Score.
2. Resumen ejecutivo.
3. Principales KPIs.
4. Tensiones activas.
5. Alertas críticas.
6. Acciones abiertas.
7. Acciones vencidas.
8. Decisiones pendientes.
9. Foco recomendado.

Ejemplo de salida:

La empresa muestra crecimiento comercial, pero con deterioro de margen y presión de cobranza. FARO detecta tensión de crecimiento no rentable. La prioridad es auditar descuentos y priorizar cobranza antes de seguir empujando volumen.

Eso ya vende.

22. Fase 16 — IA explicativa MVP

Objetivo

Usar IA para redactar mejor, no para inventar lógica.

Casos MVP:

explicar diagnóstico,
redactar resumen ejecutivo,
explicar FARO Score,
resumir acción,
redactar reporte semanal.

No usar IA para:

calcular Score,
inventar KPIs,
aprobar acciones,
cambiar reglas,
ver datos sin permiso.

Prompt base:

Actúa como analista ejecutivo FARO.

Con base únicamente en el payload recibido, redacta una explicación ejecutiva clara.

No inventes datos.
No agregues causas no presentes.
Distingue hechos, hipótesis y recomendaciones.
Usa lenguaje profesional, directo y accionable.

23. Fase 17 — Seguridad MVP

Objetivo

Evitar que el MVP nazca inseguro.

Debe incluir:

usuarios,
roles,
permisos básicos,
company_id en todas las tablas,
auditoría de acciones críticas,
control de acceso a reportes,
control de evidencia,
soft delete.

Roles MVP:

Dirección
Gerencia General
Comercial
Finanzas
Stock
Admin FARO
Solo lectura

Permisos MVP:

view_dashboard
view_kpis
view_financial_data
create_action
close_action
upload_evidence
view_reports
admin_users

24. Fase 18 — Auditoría MVP

Objetivo

Registrar lo importante.

Auditar:

login,
carga de archivos,
cambio de estado de acción,
cierre de acción,
carga de evidencia,
generación de reporte,
cambio de regla,
cambio de Score,
exportación.

Tabla mínima:

CREATE TABLE audit_logs (
    audit_id TEXT PRIMARY KEY,
    company_id TEXT,
    user_id TEXT,
    action_type TEXT NOT NULL,
    entity_type TEXT,
    entity_id TEXT,
    old_value JSONB,
    new_value JSONB,
    reason TEXT,
    created_at TIMESTAMP DEFAULT now()
);

25. Backlog MVP completo por épicas

25.1 Épica: Core

Crear empresa.
Crear sucursal.
Crear área.
Crear usuario.
Asignar rol.
Login.
Dashboard base.

25.2 Épica: Datos

Cargar Excel.
Guardar RAW.
Procesar staging.
Validar columnas.
Normalizar productos.
Normalizar clientes.
Normalizar vendedores.
Mostrar errores.

25.3 Épica: KPIs

Calcular ventas.
Calcular margen.
Calcular descuento.
Calcular cobranza.
Calcular stock crítico.
Calcular acciones vencidas.
Guardar mediciones.

25.4 Épica: Motor FARO

Detectar señales.
Generar alertas.
Detectar tensiones.
Generar diagnóstico.
Priorizar.
Recomendar.

25.5 Épica: Ejecución

Crear acción.
Asignar responsable.
Cambiar estado.
Controlar vencimiento.
Subir evidencia.
Cerrar acción.

25.6 Épica: Score

Calcular Score comercial.
Calcular Score financiero.
Calcular Score stock.
Calcular Score ejecución.
Calcular FARO Score.
Explicar drivers.

25.7 Épica: Reportes

Reporte semanal.
Resumen ejecutivo.
Lista de prioridades.
Acciones abiertas.
Acciones vencidas.
Tensiones activas.
PDF opcional.

25.8 Épica: IA

Explicar diagnóstico.
Redactar resumen ejecutivo.
Explicar Score.
Resumir acciones.
Auditar interacciones IA.

25.9 Épica: Seguridad

Roles.
Permisos.
Company isolation.
Audit logs.
Acceso por área.

26. Historias de usuario MVP

Historia 1 — Cargar ventas

Como usuario administrador,
quiero cargar un Excel de ventas,
para que FARO pueda calcular KPIs comerciales.

Criterio de aceptación:

El archivo queda guardado en RAW.
Las filas pasan a staging.
Las ventas válidas pasan a fact_sales.
Los errores quedan visibles.

Historia 2 — Ver margen

Como gerente comercial,
quiero ver margen bruto por período,
para entender si las ventas son rentables.

Criterio:

Se muestra venta neta.
Se muestra costo.
Se muestra margen bruto.
Se muestra variación contra período anterior.

Historia 3 — Detectar tensión

Como gerente general,
quiero que FARO detecte crecimiento no rentable,
para actuar antes de que el problema impacte caja.

Criterio:

Si ventas suben, margen baja y descuento sube,
FARO crea tensión de crecimiento no rentable.

Historia 4 — Crear acción

Como usuario de Dirección,
quiero convertir una recomendación en acción,
para asignarla a un responsable.

Criterio:

La acción tiene responsable, prioridad, vencimiento y evidencia requerida.

Historia 5 — Cerrar con evidencia

Como responsable de acción,
quiero subir evidencia,
para cerrar correctamente una tarea.

Criterio:

No se puede cerrar P1/P2 sin evidencia.

Historia 6 — Ver FARO Score

Como dueño o director,
quiero ver el FARO Score,
para entender el estado general de la empresa.

Criterio:

Se muestra Score,
variación,
drivers positivos,
drivers negativos,
confianza,
foco recomendado.

27. Sprints sugeridos

Sprint 0 — Diseño técnico y setup

Entregables:

repositorios,
stack,
DB inicial,
estructura carpetas,
auth base,
modelo de permisos,
wireframe dashboard.

Sprint 1 — Core + carga Excel

Entregables:

login,
empresa,
usuarios,
upload Excel,
RAW,
staging,
validación básica.

Sprint 2 — Maestros + facts

Entregables:

productos,
clientes,
vendedores,
fact_sales,
fact_inventory,
fact_accounts_receivable.

Sprint 3 — KPIs iniciales

Entregables:

ventas,
margen,
descuento,
stock crítico,
cobranza,
acciones vencidas.

Sprint 4 — Alertas + tensiones

Entregables:

señales,
alertas,
tensión crecimiento no rentable,
tensión caja débil,
tensión stock crítico.

Sprint 5 — Diagnóstico + recomendaciones

Entregables:

diagnóstico ejecutivo,
priorización,
recomendaciones iniciales,
IA explicativa básica.

Sprint 6 — Acciones + workflow

Entregables:

crear acción,
asignar responsable,
estado,
vencimiento,
acciones abiertas/vencidas.

Sprint 7 — Evidencia + cierre

Entregables:

subir evidencia,
validar evidencia,
bloquear cierre sin evidencia,
historial.

Sprint 8 — FARO Score

Entregables:

scores parciales,
FARO Score MVP,
drivers,
confianza básica.

Sprint 9 — Reporte ejecutivo

Entregables:

reporte semanal,
resumen ejecutivo,
prioridades,
acciones,
tensiones,
Score.

Sprint 10 — Seguridad, auditoría y demo

Entregables:

permisos,
audit logs,
datos demo,
flujo completo,
presentación técnica,
demo navegable.

28. Criterio de MVP terminado

El MVP está listo cuando se pueda hacer esta demo:

1. Cargar Excel.
2. Ver datos procesados.
3. Ver KPIs.
4. Ver alerta.
5. Ver tensión.
6. Ver diagnóstico.
7. Ver recomendación.
8. Crear acción.
9. Asignar responsable.
10. Subir evidencia.
11. Cerrar acción.
12. Ver FARO Score.
13. Ver reporte ejecutivo.

Si falta alguno de esos pasos, el MVP está incompleto.

Puede estar simple, pero debe estar entero.

29. Qué NO entra en el MVP

Para evitar delirio de alcance, dejar fuera inicialmente:

integraciones ERP complejas,
bancos automáticos,
WhatsApp automático completo,
ML avanzado,
grafos complejos,
benchmark externo,
multiempresa holding avanzado,
recalibración automática,
simulaciones profundas,
app mobile nativa,
SSO enterprise,
150.000 nodos reales,
market intelligence,
automatización legal,
BI complejo.

No porque no sean importantes. Sino porque antes hay que demostrar el corazón.

30. Versión piloto después del MVP

El piloto debe usar datos de una empresa real o semi-real.

Objetivo:

validar si FARO ayuda a dirigir,
no solo si funciona técnicamente.

Debe probar:

carga de datos,
calidad de datos,
KPIs,
alertas,
tensiones,
acciones,
responsables,
evidencia,
Score,
reporte.

Duración sugerida:

4 a 8 semanas.

Métricas de éxito piloto:

tiempo de carga,
KPIs calculados,
alertas útiles,
acciones creadas,
acciones cerradas,
acciones vencidas,
calidad del reporte,
claridad para Dirección,
feedback usuario,
valor percibido.

31. Backlog post-MVP

Después del MVP, avanzar por módulos.

Módulo 1 — Más KPIs

ampliar biblioteca de KPIs,
KPIs por industria,
KPIs por área,
KPIs compuestos,
umbrales configurables.

Módulo 2 — Más tensiones

biblioteca de 100 tensiones,
luego 300,
luego 1000 si corresponde.

Módulo 3 — Simulaciones

simulación descuentos,
simulación comisión,
simulación caja,
simulación stock,
simulación canjes.

Módulo 4 — RACI avanzado

responsables,
aprobadores,
consultados,
informados,
backups,
sobrecarga.

Módulo 5 — Reportes avanzados

reporte Directorio,
reporte por área,
reporte por sucursal,
reporte de excepción.

Módulo 6 — Aprendizaje

efectividad acciones,
precisión simulaciones,
falsos positivos,
falsos negativos.

Módulo 7 — Recalibración

candidatos,
aprobación,
versionado,
backtesting,
rollback.

32. Equipo mínimo recomendado

MVP básico

1 líder producto / negocio
1 backend developer
1 frontend developer
1 data engineer part-time
1 UX/UI designer part-time
1 QA part-time

MVP más serio

1 product owner
1 tech lead
1 backend developer
1 frontend developer
1 data engineer
1 UX/UI designer
1 QA
1 analista funcional

Enterprise / Neural

arquitecto software
data engineer senior
ML engineer
security engineer
backend team
frontend team
QA automation
product manager
domain experts por industria

Para la etapa actual, lo crítico es:

un socio técnico que entienda arquitectura, datos, producto y negocio. No solo alguien que programe pantallas.

33. Perfil ideal del socio técnico

Debe poder entender:

arquitectura modular,
bases de datos,
pipelines,
APIs,
seguridad,
workflow,
reglas de negocio,
IA aplicada,
producto SaaS,
escalabilidad,
costos,
trade-offs.

Señales positivas:

pregunta por el modelo de datos,
pregunta por RAW/staging,
pregunta por seguridad,
pregunta por trazabilidad,
pregunta por MVP,
pregunta qué NO hacer primero.

Señales de alerta:

quiere hacer todo con IA,
quiere empezar por pantallas,
quiere hacer microservicios desde el día uno,
no pregunta por datos,
no pregunta por permisos,
no pregunta por costos,
no sabe explicar cómo escalaría.

34. Material para mostrar al socio técnico

Para convencerlo técnicamente, preparar:

1. Mapa general FARO.
2. Tabla completa dato → acción → Score.
3. Anexos 1-40.
4. Arquitectura técnica.
5. Backlog MVP.
6. Casos de uso.
7. Modelo de base de datos inicial.
8. Ejemplo de KPI.
9. Ejemplo de tensión.
10. Ejemplo de acción.
11. Ejemplo de Score.
12. Ejemplo de reporte.
13. Mockup visual.
14. Roadmap.
15. Qué se necesita de él.

Frase clara:

No necesito que me digas si se puede hacer un dashboard. Necesito que me digas cómo construir un sistema de dirección modular, seguro, auditable y escalable empezando por un MVP realista.

35. Material para mostrar a inversor

A un inversor no se le muestra todo el detalle técnico.

Mostrar:

problema,
solución,
diferencial,
mercado,
producto,
MVP,
arquitectura defendible,
roadmap,
modelo comercial,
equipo necesario,
avance logrado,
próximos hitos.

Mensaje:

FARO Connect transforma datos dispersos en dirección accionable.
No reemplaza al ERP ni al BI: se ubica arriba como capa ejecutiva de lectura, decisión, acción y seguimiento.

36. Material para cliente piloto

Al cliente no hay que saturarlo con arquitectura.

Mostrar:

qué problema resuelve,
qué datos necesita,
qué reportes entrega,
qué acciones genera,
qué responsabilidades ordena,
qué decisiones mejora,
qué esfuerzo requiere,
qué beneficio esperado tiene.

Demo ideal:

“Cargamos tus ventas, stock y cobranza.
FARO te muestra qué está pasando,
qué riesgo tenés,
qué acción tomar,
quién debe responder
y cómo evoluciona tu Score.”

37. Criterios de aceptación por módulo

Ingesta

Carga archivo.
Guarda RAW.
Valida columnas.
Muestra errores.
Procesa filas válidas.

KPIs

Calcula correctamente.
Guarda resultado.
Muestra fórmula.
Muestra confianza.
Permite recalcular.

Alertas

Se dispara con regla clara.
Tiene severidad.
Tiene origen.
Tiene estado.
Puede cerrarse con motivo.

Tensiones

Cruza más de una variable.
Muestra áreas afectadas.
Muestra KPIs asociados.
Tiene confianza.
Puede generar diagnóstico.

Acciones

Tiene responsable.
Tiene vencimiento.
Tiene prioridad.
Tiene estado.
Requiere evidencia.

Score

Tiene fórmula.
Tiene drivers.
Tiene confianza.
Tiene historial.
No es arbitrario.

38. Riesgos de implementación

39. Priorización MoSCoW

Must have

carga datos,
RAW,
staging,
maestros mínimos,
KPIs,
alertas,
tensiones básicas,
diagnóstico,
acciones,
responsables,
workflow,
evidencia,
Score,
reporte.

Should have

IA explicativa,
permisos por área,
reportes por sucursal,
Action Guides,
RACI básico,
calidad de datos.

Could have

simulaciones,
notificaciones,
PDF,
WhatsApp,
más industrias,
más KPIs,
más tensiones.

Won’t have en MVP

ML avanzado,
auto-recalibración,
grafos complejos,
ERP automático completo,
SSO enterprise,
app mobile nativa.

40. Priorización RICE

Fórmula:

RICE =
Reach × Impact × Confidence / Effort

Código:

def rice_score(reach, impact, confidence, effort):
    if effort == 0:
        return 0

    return round((reach * impact * confidence) / effort, 2)

Ejemplo:

Lectura:

Primero carga Excel, KPIs, acciones y Score.
Después WhatsApp y ML.

De sentido común, pero con fórmula. Siempre ayuda cuando alguien se enamora de una feature brillante e inútil para el momento.

41. Definition of Done FARO

Una tarea no está terminada porque “anda en mi máquina”.

Debe cumplir:

funciona,
tiene validación,
tiene manejo de errores,
respeta permisos,
registra auditoría si corresponde,
tiene prueba básica,
no rompe flujo anterior,
se ve bien en UI,
tiene criterio de aceptación cumplido.

Definition of Done técnica:

código mergeado,
tests pasan,
migración aplicada,
endpoint documentado,
UI validada,
audit log si corresponde,
datos demo probados,
sin errores críticos.

42. Datos demo iniciales

Para mostrar FARO, crear empresa demo.

Nombre sugerido:

Grupo Andina Obras

Rubros:

cemento,
hierro,
sanitarios,
grifería,
pisos,
revestimientos,
instalaciones.

Sucursales:

Mendoza,
San Juan,
Central.

Casos demo:

ventas suben pero margen baja,
stock crítico en cemento,
cliente grande moroso,
descuento alto por vendedor,
acción vencida,
costo faltante,
canje pendiente,
referido con comisión alta.

Esto permite mostrar toda la cadena.

43. Dataset demo mínimo

Tablas demo:

productos: 50
clientes: 80
ventas: 1.000
stock: 50 productos x 3 sucursales
cobranza: 80 clientes
vendedores: 8
acciones: 20
alertas: 15
tensiones: 5

No hace falta Big Data. Hace falta buen relato.

44. Caso demo principal

Situación

Ventas suben 18%.
Margen baja de 28% a 21%.
Descuento sube de 6% a 12%.
Días de cobranza suben de 32 a 43.
Stock crítico en productos tractores.

FARO detecta

Tensión: crecimiento no rentable.
Prioridad: P2 alta.
Confianza: 0.84.

FARO recomienda

auditar descuentos,
priorizar cobranza,
simular comisión,
validar stock crítico.

FARO crea acciones

Gerente Comercial: auditar descuentos.
Finanzas: priorizar cobranza.
Stock/Compras: activar reposición.
Dirección: aprobar política comercial.

FARO Score

Score inicial: 66.
Después de acciones: 74 simulado.

Este caso es el pitch.

45. Demo navegable ideal

Pantallas mínimas:

1. Login.
2. Dashboard ejecutivo.
3. FARO Score.
4. KPIs principales.
5. Tensión detectada.
6. Diagnóstico.
7. Recomendaciones.
8. Acciones.
9. Evidencia.
10. Reporte ejecutivo.

Orden de demo:

Primero impacto visual.
Después lógica.
Después técnica.

No al revés.

46. Plan de validación con socio técnico

Preguntas que debe poder responder:

1. ¿La arquitectura es construible?
2. ¿Qué stack recomienda?
3. ¿Qué simplificaría?
4. ¿Qué riesgos ve?
5. ¿Qué haría primero?
6. ¿Qué costo técnico estima?
7. ¿Qué perfiles necesita?
8. ¿Qué demoraría más?
9. ¿Qué parte es más difícil?
10. ¿Qué parte puede ser MVP?

Preguntas trampa sanas:

¿Qué NO construirías ahora?
¿Qué parte puede romper todo si se diseña mal?
¿Cómo protegerías los datos?
¿Cómo harías el Score defendible?
¿Cómo evitarías que la IA invente?

Si responde bien, entiende el proyecto.

47. Plan de validación con usuario real

Validar con 3 tipos de usuario:

dueño / director,
gerente general,
responsable de área.

Preguntas:

¿Entendés qué está pasando?
¿Te queda claro qué hacer?
¿Confiás en el Score?
¿La acción está bien definida?
¿El reporte te sirve para reunión?
¿Qué dato falta?
¿Qué alerta sobra?
¿Qué decisión tomarías con esto?

La pregunta más importante:

¿Esto te ayudaría a dirigir mejor la empresa?

Si la respuesta no es sí, hay que corregir.

48. Métricas de éxito del MVP

Técnicas

archivo cargado correctamente,
KPIs calculados,
alertas generadas,
acciones creadas,
Score calculado,
reporte generado,
sin errores críticos.

Producto

usuario entiende el diagnóstico,
usuario entiende la recomendación,
usuario crea acción,
usuario ve valor en Score,
usuario usaría reporte en reunión.

Negocio

cliente acepta piloto,
socio técnico valida factibilidad,
inversor entiende diferencial,
se puede presupuestar desarrollo completo.

49. Costos a estimar

El plan debe estimar costos por categoría.

diseño UX/UI,
frontend,
backend,
base de datos,
data engineering,
IA,
infraestructura,
QA,
seguridad,
mantenimiento.

Costos variables:

hosting,
base de datos,
storage,
IA tokens,
email,
WhatsApp,
observabilidad,
backups.

Para vender o buscar socio, no hace falta precisión quirúrgica inicial. Sí hace falta saber qué rubros existen. No hay peor sorpresa que descubrir costos después de prometer precio.

50. Riesgo de costo IA

FARO debe medir costo de IA desde el principio.

Ejemplo:

reporte ejecutivo generado con IA,
diagnóstico explicado con IA,
resumen de evidencia con IA.

Controlar:

tokens por empresa,
tokens por usuario,
tokens por reporte,
costo mensual,
límite por plan.

Regla:

IA sin medición de costo es margen bruto suicida con interfaz moderna.

51. Plan de precios relacionado al desarrollo

El roadmap debe conectar con producto comercial.

Starter / Core

carga manual / Excel,
KPIs básicos,
alertas simples,
acciones,
Score básico,
reporte semanal.

Pro

más módulos,
más usuarios,
más KPIs,
tensiones,
recomendaciones,
workflow.

Enterprise

integraciones,
RACI,
evidencia avanzada,
reportes Directorio,
seguridad avanzada.

Neural

simulaciones,
aprendizaje,
recalibración,
benchmarks,
modelos predictivos.

No vender Neural si todavía se entrega Core. Se puede mostrar visión, pero cobrar por lo que existe o está claramente presupuestado.

52. Matriz versión vs módulo

53. Roadmap comercial-técnico

0-3 meses

MVP funcional.
Demo técnica.
Dataset demo.
Primer piloto.

3-6 meses

Piloto real.
Mejora KPIs.
Más tensiones.
Reportes mejores.
Seguridad reforzada.

6-12 meses

Producto Core vendible.
Planes comerciales.
Integraciones iniciales.
Workflow sólido.
Score defendible.

12-18 meses

Enterprise.
Reportes Directorio.
Simulaciones.
Aprendizaje.
Recalibración.

18+ meses

Neural Engine.
Benchmark adaptativo.
Modelos predictivos.
Multiindustria profundo.

54. Orden de construcción recomendado

El orden correcto:

1. Datos.
2. Modelo.
3. KPIs.
4. Reglas.
5. Alertas.
6. Tensiones.
7. Acciones.
8. Workflow.
9. Evidencia.
10. Score.
11. Reportes.
12. IA.
13. Aprendizaje.
14. Recalibración.

El orden incorrecto:

1. IA.
2. Pantallas.
3. Animaciones.
4. Score inventado.
5. Después vemos datos.

Ese segundo camino es más lindo al principio y más caro al final.

55. Arquitectura mínima para no rehacer

Aunque el MVP sea simple, debe respetar estas decisiones:

company_id en todo,
RAW separado,
staging separado,
maestros separados,
facts separados,
audit_logs,
roles/permisos,
acciones con workflow,
Score con fórmula,
IA con payload estructurado,
configuración versionable.

Si eso está desde el inicio, FARO puede crecer.

56. Checklist antes de programar

Antes de escribir código, cerrar:

stack elegido,
repositorio,
estructura de módulos,
modelo inicial DB,
flujo MVP,
dataset demo,
pantallas MVP,
roles MVP,
KPIs MVP,
tensiones MVP,
acciones MVP,
fórmula Score MVP,
criterios de aceptación,
responsable técnico.

Si no está cerrado, se programa con niebla.

57. Checklist antes de mostrar a socio técnico

Tener listo:

1. Resumen de FARO Connect.
2. Diagrama general.
3. Tabla flujo completo.
4. Anexo arquitectura técnica.
5. Backlog MVP.
6. Roadmap.
7. Pantallas mockup.
8. Caso demo.
9. Preguntas concretas.
10. NDA firmado si corresponde.

No mostrar todo sin marco. Mostrar lo suficiente para que entienda la magnitud, pero con orden y protección.

58. Checklist antes de mostrar a inversor

Tener listo:

problema,
solución,
producto,
demo,
mercado,
modelo comercial,
roadmap,
equipo necesario,
uso de fondos,
avance,
diferencial,
riesgos controlados.

No entrar en 40 anexos completos salvo que sea inversor técnico. El inversor compra claridad, no enciclopedia.

59. Checklist antes de cliente piloto

Tener listo:

qué datos pedimos,
qué entregamos,
cuánto demora,
qué debe hacer el cliente,
qué módulos incluye,
qué no incluye,
cómo se mide éxito,
qué confidencialidad hay,
qué soporte se dará.

Piloto sin alcance claro termina en consultoría infinita con moño SaaS.

60. Plan de documentación

FARO necesita documentación en 4 niveles.

Nivel 1 — Comercial

qué es,
qué resuelve,
beneficios,
planes,
casos de uso.

Nivel 2 — Ejecutivo

cómo se usa,
reportes,
Score,
acciones,
decisiones.

Nivel 3 — Funcional

módulos,
flujos,
roles,
datos,
reglas.

Nivel 4 — Técnico

arquitectura,
API,
DB,
seguridad,
jobs,
deploy,
auditoría.

Los anexos que estamos armando son base para nivel funcional y técnico.

61. Gobierno del proyecto

El desarrollo debe tener gobierno.

Reuniones sugeridas:

revisión semanal de avance,
demo quincenal,
revisión de backlog,
revisión de riesgos,
revisión mensual de roadmap.

Artefactos:

backlog,
tablero Kanban,
documentación,
registro de decisiones,
registro de cambios,
issues,
roadmap.

Herramientas posibles:

Linear,
Jira,
Trello,
Notion,
GitHub Projects.

Para FARO, usaría algo simple y ejecutivo. Nada de burocracia de proyecto para construir un sistema antiburocracia. Sería una ironía bastante cara.

62. Registro de decisiones técnicas

Cada decisión importante debe registrarse.

Ejemplo:

{
  "decision_id": "ADR_001",
  "title": "Usar PostgreSQL como base principal",
  "context": "FARO requiere trazabilidad, relaciones y auditoría.",
  "decision": "PostgreSQL será la base principal del MVP.",
  "alternatives": ["MongoDB", "BigQuery"],
  "status": "approved"
}

Esto se llama ADR: Architecture Decision Record.

Decisiones a registrar:

stack,
base de datos,
auth,
estructura modular,
IA gateway,
modelo de permisos,
storage,
deploy,
colas,
migraciones.

63. Plan de QA

Tipos de pruebas:

pruebas funcionales,
pruebas de carga Excel,
pruebas de KPIs,
pruebas de reglas,
pruebas de workflow,
pruebas de permisos,
pruebas de evidencia,
pruebas de Score,
pruebas de reportes,
pruebas de seguridad básica.

Casos críticos:

usuario sin permiso no ve finanzas,
acción P1 no cierra sin evidencia,
Score no supera 100,
Excel con columnas faltantes no procesa,
dato sin producto queda pendiente,
acción vencida cambia estado,
reporte muestra drivers correctos.

64. Plan de datos de prueba

Crear datasets con errores intencionales:

producto inexistente,
cliente duplicado,
costo faltante,
descuento extremo,
fecha inválida,
stock negativo,
deuda sin cliente,
vendedor no reconocido,
archivo con columna faltante.

Porque el sistema no se prueba con datos perfectos. Los datos perfectos existen en presentaciones, no en empresas.

65. Plan de escalabilidad

Primero diseñar para:

1 empresa,
3 sucursales,
10 usuarios,
50 productos,
1.000 ventas.

Luego escalar a:

10 empresas,
100 usuarios,
10.000 productos,
1.000.000 ventas.

Medidas:

índices,
paginación,
jobs,
cache,
precalcular KPIs,
particionar por fecha si hace falta,
archivar histórico.

No optimizar prematuramente, pero tampoco diseñar como si siempre fueran 500 filas.

66. Plan de seguridad por etapas

MVP

login,
roles,
permisos básicos,
company_id,
audit_logs,
MFA admin opcional.

Pro

permisos por área,
datos sensibles,
exportación auditada,
MFA roles críticos.

Enterprise

SSO,
RLS,
logs avanzados,
tenant isolation,
políticas de retención,
auditoría completa.

67. Plan de IA por etapas

MVP

resumen ejecutivo,
explicación de diagnóstico,
explicación de Score.

Pro

redacción de Action Guides,
resumen de evidencia,
asistente para reportes.

Enterprise

comparación de escenarios,
detección de patrones,
ayuda en aprendizaje.

Neural

modelos predictivos,
recomendaciones adaptativas,
recalibración sugerida avanzada.

Siempre con payload estructurado.

68. Plan de integraciones por etapas

MVP

Excel / CSV.

Pro

Google Sheets,
API simple,
importador ERP manual.

Enterprise

ERP automático,
CRM,
POS,
bancos,
WhatsApp Business,
APIs específicas.

Neural

market data,
benchmarks,
datos externos,
modelos predictivos.

69. Roadmap de bibliotecas FARO

Biblioteca KPIs

MVP: 25-40
Pro: 100-150
Enterprise: 300-400
Neural: 1000+

Biblioteca tensiones

MVP: 10
Pro: 100
Enterprise: 300-500
Neural: 1000+

Biblioteca acciones

MVP: 20-40
Pro: 150
Enterprise: 500
Neural: 1000+

Biblioteca recomendaciones

MVP: 20
Pro: 100
Enterprise: 300
Neural: adaptativas

No cargar 1000 cosas manualmente al principio. Primero diseñar el modelo para soportarlas.

70. Estructura de backlog JSON

Ejemplo:

{
  "epic": "FARO Score MVP",
  "stories": [
    {
      "id": "SCORE-001",
      "title": "Calcular score comercial",
      "priority": "must",
      "acceptance_criteria": [
        "calcula score entre 0 y 100",
        "usa ventas, margen y descuento",
        "guarda resultado histórico"
      ]
    },
    {
      "id": "SCORE-002",
      "title": "Mostrar drivers del score",
      "priority": "must",
      "acceptance_criteria": [
        "muestra drivers positivos",
        "muestra drivers negativos",
        "explica variación"
      ]
    }
  ]
}

71. Tabla SQL opcional para backlog interno

Si FARO quiere gestionar su propio desarrollo:

CREATE TABLE product_backlog_items (
    item_id TEXT PRIMARY KEY,
    epic TEXT NOT NULL,
    title TEXT NOT NULL,
    description TEXT,
    priority TEXT,
    status TEXT DEFAULT 'todo',
    owner TEXT,
    sprint TEXT,
    acceptance_criteria JSONB,
    created_at TIMESTAMP DEFAULT now(),
    updated_at TIMESTAMP DEFAULT now()
);

No hace falta meterlo dentro de FARO al principio. Pero sirve como estructura mental.

72. Entregable final del Anexo 40

Al finalizar este anexo, FARO debe tener definido:

1. Plan de implementación por fases.
2. MVP definido.
3. Qué entra y qué no entra en MVP.
4. Backlog por épicas.
5. Historias de usuario.
6. Sprints sugeridos.
7. Criterios de aceptación.
8. Definition of Done.
9. Dataset demo.
10. Caso demo principal.
11. Demo navegable.
12. Equipo necesario.
13. Perfil de socio técnico.
14. Material para socio técnico.
15. Material para inversor.
16. Material para cliente piloto.
17. Riesgos de implementación.
18. Priorización MoSCoW.
19. Priorización RICE.
20. Roadmap técnico-comercial.
21. Roadmap por versiones.
22. Plan de seguridad.
23. Plan de IA.
24. Plan de integraciones.
25. Plan de QA.
26. Plan de escalabilidad.
27. Plan de documentación.
28. Gobierno del proyecto.
29. Registro de decisiones técnicas.
30. Checklist antes de programar.
31. Checklist antes de demo.
32. Checklist antes de piloto.

73. Conexión con otros anexos

El Anexo 40 define cómo construir FARO Connect por fases: qué entra en el MVP, qué queda para versiones futuras, qué backlog técnico y funcional se necesita, cómo organizar sprints, qué equipo hace falta, cómo validar avance real y cómo transformar la arquitectura FARO en un producto funcional, vendible y escalable.