Procedimiento operativo de 30 a 60 días para llevar un cliente desde el primer workshop hasta el reporte ejecutivo con Score calculado, sin improvisar, sin perder trazabilidad y sin convertir el piloto en una aventura artesanal.
Este runbook (FARO-DOC-002) define el procedimiento operativo para implementar un piloto de FARO Connect en 30 a 60 días. No es un cronograma flexible: es la cadena dura que evita que el piloto arranque con entusiasmo y termine con veinte Excels, tres reuniones y cero trazabilidad.
Un piloto FARO no busca construir todo el producto. Busca demostrar, con datos reales o semirreales, que FARO puede convertir información dispersa en dirección ejecutiva accionable. La validación mínima es una cadena indivisible que cualquier dirección puede recorrer mentalmente sin saltos:
Si esa cadena no ocurre, no hay piloto: hay presentación. Si ocurre, FARO deja de ser “otro dashboard prometido” y se vuelve, en el lenguaje del director, “ya entiendo qué está pasando, por qué importa, quién debe actuar y cómo eso afecta la salud real de la empresa”.
El piloto debe demostrar, como mínimo, 5 tensiones ejecutivas, 1 reporte semanal completo y FARO Score calculado con su explicación. Todo lo demás es alcance opcional. La regla operativa: arrancar acotado, cerrar con evidencia. El entusiasmo del cliente es bueno; el descontrol del alcance es la receta clásica para un piloto que termina sin decisión.
Este documento se apoya sobre la guía de Workshop Discovery (entrada del flujo), el contrato de datos (qué exigir al cliente para recibir muestras), los 5 playbooks de industria (qué priorizar según vertical), el backlog MVP (qué se construye en cada fase) y el pipeline interactivo (vista visual del flujo). Cierra con comunicación de cierre del piloto.
Cliente demo usado en este runbook. Cada fase incluye un ejemplo concreto de qué se hizo en Empresa Demo Cuyo S.A. (caso de referencia anonimizado del pack NDA). Permite que el equipo de implementación vea no solo qué hacer en abstracto, sino qué quedó realmente cargado, calculado y reportado al final del piloto.
FARO entra al piloto enfocado en módulos de mayor valor ejecutivo y menor complejidad técnica. Ampliar alcance es la forma más común de matar el piloto: cada módulo extra suma 1 fuente, 3 KPIs, 1 regla y al menos 1 ciclo de validación.
| Módulo | En piloto | Motivo |
|---|---|---|
| Empresas / sucursales / áreas | Sí | Base organizativa para multiempresa desde el inicio. |
| Usuarios / roles / responsables | Sí | Sin responsables no hay acciones; sin acciones no hay cierre. |
| Productos | Sí | Necesario para cruzar ventas, margen y stock. |
| Clientes | Sí | Necesario para ventas y cobranza. |
| Ventas | Sí | Fuente primaria de desempeño comercial. |
| Margen | Sí | Clave para detectar crecimiento no rentable. |
| Descuentos | Sí | Tensión comercial recurrente. |
| Stock | Sí | Impacta venta, capital inmovilizado y quiebres. |
| Cobranza | Sí | Conecta venta con caja. |
| Acciones | Sí | Diferencia FARO de un dashboard. |
| Evidencia | Sí | Cierre real, no relato. |
| FARO Score | Sí | Síntesis ejecutiva consumible. |
| Reporte semanal | Sí | Entregable directivo cierre de ciclo. |
| IA explicativa controlada | Opcional | Solo si hay datos confiables; nunca antes de las reglas. |
| Simulación avanzada | No | Requiere histórico validado y modelo estable. |
| Peer comparison | No | Requiere base comparativa multiempresa. |
| Recalibración automática | No | Requiere aprendizaje posterior con dataset estable. |
| Integración total ERP / API | No obligatorio | Primero validar flujo mínimo con CSV / XLSX controlado. |
El piloto se considera técnicamente “completo” cuando al final del recorrido la dirección ve, en una sola lectura de 5 minutos:
Si alguno de estos umbrales no se cumple, el piloto pasa a estado “extender” antes que a “cerrar”. Cerrar un piloto sin objetivo mínimo demostrable destruye credibilidad ejecutiva más rápido que cualquier otro error operativo.
Los roles se asignan antes de Fase 0. Sin sponsor interno cliente y sin líder de implementación FARO, el piloto no arranca: pausa hasta resolver.
| Rol | Responsabilidad |
|---|---|
| Sponsor FARO | Define alcance, cuida posicionamiento y toma decisiones comerciales. |
| Líder de implementación | Coordina el piloto, agenda, entregables y seguimiento. |
| Analista de negocio | Traduce dolores en KPIs, tensiones y acciones. |
| Data analyst | Revisa archivos, campos, calidad y mapeos. |
| Data engineer | Diseña carga RAW, staging y normalización. |
| Backend developer | Implementa APIs, reglas, motor evaluador y persistencia. |
| Frontend developer | Implementa bandejas, vistas y reporte visual. |
| QA / tester | Valida KPIs, reglas, datos esperados y regresiones. |
| Responsable seguridad | Revisa accesos, roles, datos sensibles y auditoría. |
| Dirección FARO | Aprueba salida ejecutiva y mensajes al cliente. |
| Rol | Responsabilidad |
|---|---|
| Sponsor interno | Autoriza piloto, prioriza y destraba bloqueos. |
| Responsable sistemas | Entrega accesos, exportaciones o muestras. |
| Responsable adm. / finanzas | Valida cobranza, facturación, bancos y caja. |
| Responsable comercial | Valida ventas, descuentos, clientes y vendedores. |
| Responsable stock / compras | Valida stock, productos, proveedores y reposición. |
| Usuarios responsables | Reciben acciones y prueban flujo operativo. |
| Dirección cliente | Evalúa reporte, score, tensiones y utilidad ejecutiva. |
R Responsable ejecutor · A Aprobador · C Consultado · I Informado
| Actividad | Dir. FARO | Líder impl. | Data eng. | Backend | Frontend | Cliente téc. | Cliente neg. |
|---|---|---|---|---|---|---|---|
| Definir alcance | A | R | C | C | C | C | C |
| Ejecutar workshop | C | R | C | I | I | C | A |
| Completar inventario | I | R | C | I | I | C | A |
| Recibir muestras | I | R | C | I | I | A | C |
| Diseñar modelo SQL | I | C | R | C | I | C | I |
| Cargar RAW | I | C | R | C | I | C | I |
| Normalizar staging | I | C | R | C | I | C | C |
| Calcular KPIs | C | R | C | R | I | I | C |
| Configurar reglas | C | R | C | R | I | I | C |
| Crear UI piloto | C | C | I | C | R | I | C |
| Generar reporte | A | R | C | C | C | I | C |
| Validar resultados | A | R | C | C | C | C | A |
| Cierre piloto | A | R | I | I | I | C | A |
Si alguno de los pre-requisitos marcados Requerido no está cumplido, el piloto no arranca. No se compensan entre sí: no hay forma de cubrir falta de sponsor interno con mejor stack técnico, ni viceversa.
FARO-PL-016)Regla del piso. El cliente debe poder entregar muestras estables de al menos 3 dominios de datos (típicamente ventas + productos + cobranza o stock). Sin esos tres, FARO no puede demostrar la cadena dato→reporte: queda en monitoreo de una vertical, lo cual no es piloto sino prueba de concepto.
El piloto recorre 11 fases ordenadas. Cada fase tiene actividades, outputs, checklist, duración sugerida y responsables claros del lado FARO y del lado cliente. Las fases no se solapan en serio: una fase mal cerrada contamina las siguientes.
Recibir archivos, validar estructura y guardar copia RAW intacta. Ver detalle ↓
Definir entidades, tablas RAW / staging, KPIs y tensiones MVP. Ver detalle ↓
Conservar datos originales sin alterarlos, con trazabilidad de lote. Ver detalle ↓
Aplicar reglas explícitas de limpieza con DQ status auditable. Ver detalle ↓
Calcular KPIs MVP y detectar señales con umbrales explícitos. Ver detalle ↓
Convertir señales en tensiones ejecutivas con responsable y workflow. Ver detalle ↓
Revisar con dirección cliente si genera lectura útil, no solo datos correctos. Ver detalle ↓
Decidir continuidad: continuar, extender, pausar, rechazar. Ver detalle ↓
Cronograma sugerido 30 días. Semana 1 cubre fases 0-3 (relevamiento + datos). Semana 2 cubre fases 4-6 (modelo + carga + staging). Semana 3 cubre fases 7-8 (KPIs + tensiones + workflow). Semana 4 cubre fases 9-11 (reporte + validación + cierre). Para 60 días, cada bloque se duplica en holgura, no en alcance.
Sin sponsor interno, sin alcance preliminar y sin carpeta segura, el piloto arranca arrastrando deuda organizativa. Esta fase parece administrativa: en realidad evita el 70% de los problemas de las fases técnicas.
Asegurar que el piloto no arranque desordenado. El equipo FARO no toca un dato hasta tener sponsor confirmado, responsables identificados, NDA enviado, código de cliente asignado y entorno de trabajo definido.
/clientes/{company_code}/.company_code normalizado (ej. EMP001, CUYO-001).company_code asignado.listo_para_discovery.Sponsor confirmado (dirección general), responsable técnico de sistemas asignado, NDA firmado a 48 horas del primer contacto, alcance v0 acotado a Comercial + Finanzas + Stock con tres sucursales activas, código CUYO-001 asignado, carpeta segura creada en drive controlado y sandbox local listo para recibir muestras. Sin nombres personales: solo roles.
El Discovery ejecuta la guía FARO-DOC-001 · Workshop Discovery MVP (PENDIENTE de publicar). El objetivo no es hacer entrevistas extensas, sino obtener una primera lectura ejecutiva del negocio que permita priorizar fuentes, KPIs y tensiones candidatas.
Identificar las decisiones que la dirección toma tarde o a ciegas, los KPIs que existen pero no generan acción, los responsables que deberían actuar ante cada tensión y la evidencia que demostraría cierre real. Ese material alimenta todas las fases siguientes.
FARO-DOC-001-R · Minuta Discovery firmada por sponsor.FARO-PL-001 · Mapa inicial empresa / áreas / sucursales.FARO-PL-016 · Inventario preliminar de fuentes.FARO-KPI-MVP · Lista de KPIs candidatos MVP.FARO-TNS-MVP · Lista de tensiones candidatas MVP.FARO-RISK-001 · Riesgos / red flags iniciales.Workshop de 3 horas con dirección + responsable comercial + responsable de finanzas. Se identificaron 7 decisiones críticas (de las cuales 3 P1: política de descuentos por vendedor, priorización de cobranza, reposición de stock crítico). 6 tensiones candidatas alineadas con el catálogo MVP: TNS-001 (crecimiento no rentable), TNS-002 (descuento fuera de política), TNS-004 (venta sin caja), TNS-005 (mora crítica), TNS-006 (stock crítico) y TNS-009 (acciones vencidas). Red flag inicial: el ERP exporta ventas en XLSX pero con encabezados inconsistentes mes a mes.
El inventario es donde se cae el optimismo de la fase Discovery: muchas fuentes prometidas no existen como archivo estable, no tienen responsable definido o están en formatos no apto para MVP. Mejor descubrirlo acá que en Fase 5.
Completar FARO-PL-016 con todas las fuentes relevantes del piloto, su responsable, su accesibilidad, su frecuencia, su calidad preliminar y su clasificación operativa (A automatizable / B semi / C manual controlada / D no apta).
FARO-PL-016 · Inventario completo al 70% mínimo.Inventario cerrado al 85% con 9 fuentes relevadas. Clasificación final: 3 fuentes B (ventas, productos y stock vía export XLSX semanal), 2 fuentes C (clientes y cobranza en planilla manual controlada), 1 fuente A (bancos vía API del banco), 3 fuentes D excluidas (RRHH no maduro, compras sin diccionario estable, proveedores con datos sensibles fuera de NDA). Bloqueo registrado: encabezados del export de ventas cambian de nombre mes a mes — se acordó contrato de columnas estable a partir de la Fase 4.
Recibir archivos parece trivial. En la práctica, el 80% de los pilotos que se complican lo hacen acá: archivos por WhatsApp con datos sensibles, versiones que se pisan, encoding roto, sin trazabilidad de quién entregó qué. Las 10 reglas de recepción no son recomendación: son política.
Recibir archivos de muestra para validar estructura, calidad, campos y posibilidad de carga. Cada archivo recibido genera un registro de ingestión con responsable, fecha, hash y validación inicial; copia RAW se preserva intacta, todo análisis se hace sobre copia.
{company_code}_{source}_{periodo}_{version}_{fecha}.{ext}CUYO-001_ventas_2026-01_v01_2026-05-30.xlsx/clientes/{code}/00_admin/, /01_discovery/, /02_fuentes/, /03_raw_samples/, /04_mapping/, /05_staging_tests/, /06_kpis/, /07_rules/, /08_reports/, /09_evidence/, /10_delivery/.muestras_recibidas por archivo (YAML / JSON).apto_mapping: true / false por archivo.Se recibieron 6 archivos del periodo 2026-01 a 2026-04 vía drive corporativo: ventas, productos, clientes, stock, cobranza y bancos. Todos guardados como RAW con hash sha256 en /clientes/CUYO-001/03_raw_samples/. Anonimización aplicada a clientes (razón social → ID alfanumérico). Archivo de cobranza marcado warning (faltaban fechas de vencimiento en el 12% de los registros). Resto aptos para mapping. Tiempo total de recepción + validación: 3 días.
El diseño técnico no busca la arquitectura definitiva: busca el modelo más simple que sostenga la cadena dato → reporte. Multi-empresa desde el inicio (company_id + roles), validación en capa de schema, reglas en YAML/JSON declarativo (nunca hardcodeadas).
Definir las entidades base (companies, products, fact_sales, tensions, etc.), las tablas RAW y staging, los KPIs MVP, las tensiones MVP del catálogo canónico, el workflow de acciones y los permisos por rol.
PostgreSQL como estándar MVP. Soporta jsonb (RAW), arrays (códigos canónicos), tipos UUID y políticas RLS para multiempresa.
S3 / Supabase Storage / GCS para producción; local para demo. Archivos originales preservados con hash.
FastAPI / Node / monolito modular según equipo. Separación clara entre capa ingestión, capa reglas y capa API.
Celery / RQ / BullMQ / cron según stack. Idempotentes y reprocesables desde RAW.
Next.js / React. Bandeja de tensiones, vista de KPIs y reporte semanal mínimos.
JSON Schema / Zod en API + constraints SQL. Doble capa para que ningún dato inválido llegue a staging.
YAML / JSON declarativo. Prohibido hardcodear umbrales en código de aplicación.
Explicativa controlada. No decide, no inventa, no rellena datos faltantes.
company_id en cada tabla + roles + RLS futuro. Multiempresa desde el inicio, aunque el piloto tenga una sola empresa.
companies · empresa / cliente.branches · sucursales.areas · áreas funcionales.users + roles + permissions.products · maestro productos.customers · maestro clientes.suppliers · maestro proveedores.employees · empleados / vendedores.raw_ingestions · lotes RAW.raw_records · registros originales.staging_records · registros normalizados.fact_sales, fact_stock, fact_receivables.kpi_snapshots · KPIs calculados por período.signal_log + rule_evaluations.tensions + actions + evidence.score_snapshots + reports.Modelo SQL en PostgreSQL con 24 tablas (8 maestros + 4 RAW/staging + 5 facts + 4 reglas/tensiones/acciones + 3 reportes/score). KPIs MVP definidos: 9 (3 comerciales, 3 financieros, 3 stock). Tensiones MVP seleccionadas: 6 del catálogo canónico (TNS-001/002/004/005/006/009). Reglas escritas en YAML declarativo con umbrales explícitos. Mapeo fuente → staging definido por columna. Riesgo técnico documentado: el campo fecha del export de ventas viene como string en 3 formatos distintos.
La carga RAW conserva los datos originales tal cual llegaron. Nunca se modifica el archivo original; nunca se corrige el payload. Esa disciplina es la base de la trazabilidad: cualquier KPI debe poder explicar de qué lote RAW se derivó y por qué.
Cargar cada archivo en raw_ingestions (un lote por archivo) + raw_records (un registro por fila original con payload jsonb). Generar hash, registrar usuario y timestamp, mantener trazabilidad hasta staging y facts.
payload original en jsonb.source_id).ingestion_id).received · archivo recibido.stored · archivo almacenado en RAW storage.parsed · archivo leído correctamente.failed_parse · error al leer (encoding, formato, etc.).loaded_raw · registros cargados en tabla RAW.rejected · archivo rechazado por validación.quarantined · aislado por riesgo de seguridad.ready_staging · listo para pasar a staging.| Tabla | Campo | Tipo | Descripción |
|---|---|---|---|
raw_ingestions | ingestion_id | UUID | ID único de lote. |
company_id | UUID | Empresa propietaria del lote. | |
source_id | UUID | Fuente origen (FARO-PL-016). | |
file_name + file_type + file_hash | text | Archivo + extensión + checksum sha256. | |
received_at + uploaded_by | timestamp + UUID | Trazabilidad de quién y cuándo. | |
records_count + status + error_message | integer + text + text | Cuenta + estado actual + error si aplica. | |
raw_records | raw_record_id | UUID | ID único de registro. |
ingestion_id | UUID | FK a lote. | |
company_id | UUID | Empresa (heredada de lote). | |
row_number | integer | Fila original en archivo. | |
payload | jsonb | Registro original sin modificar. | |
dq_status + dq_errors | text + jsonb | ok / warning / error / fatal + detalle de errores detectados. |
6 lotes cargados en RAW con un total de 18.420 registros (ventas 14.200, productos 1.840, clientes 920, stock 980, cobranza 450, bancos 30). Hash sha256 generado por archivo y guardado en metadatos del lote. 12 registros marcados warning (faltan fechas de vencimiento) y 3 registros marcados fatal (monto vacío). Todo el payload original preservado en raw_records.payload. Tiempo total de carga: 2 días.
Staging no es "limpiar a mano". Es aplicar reglas explícitas, repetibles y auditables. Toda transformación queda documentada (fecha, moneda, IDs maestros) con DQ status asignado por registro: ok, warning, error o fatal.
Aplicar transformaciones típicas (fechas a ISO, monedas a numérico, productos a IDs maestros, descuentos a fracción, cálculo de margen si falta) y asignar a cada registro un DQ status auditable. Los registros fatales se excluyen del cálculo; los warning se procesan con marca; los error se revisan caso por caso.
30/05/2026 → 2026-05-30$ 1.250,50 → 1250.50Cemento 50kg → product_idJUAN PEREZ SRL → customer_idM. Lopez → employee_idSJ → branch_idF A-0001-000123 → document_number10% → 0.10ok · registro válido → procesar.warning · error menor no bloqueante → procesar con marca.error · error relevante corregible → revisar o corregir.fatal · no puede procesarse → excluir hasta resolver.| Regla | Severidad |
|---|---|
| Fecha vacía en venta | fatal |
| Monto de venta vacío | fatal |
| Producto no identificado | error |
| Cliente no identificado | warning / error según caso |
| Vendedor no identificado | warning |
| Margen negativo | warning / error |
| Descuento mayor al máximo permitido | warning |
| Stock negativo | error |
| Factura sin vencimiento | error |
| Pago sin factura asociada | warning / error |
staging_sales · ventas normalizadas.staging_products · productos normalizados.staging_customers · clientes normalizados.staging_stock · stock normalizado.staging_receivables · cobranzas normalizadas.staging_purchases · compras normalizadas.staging_employees · vendedores / empleados.staging_suppliers · proveedores.De los 18.420 registros RAW: 17.890 quedaron ok (97.1%), 480 warning (faltaba vendedor o cliente), 47 error (stock negativo o factura sin vencimiento) y 3 fatal excluidos del cálculo. Mapeo a 7 tablas staging completo. Resumen de calidad por fuente publicado y validado con responsable comercial y de finanzas. Tiempo total de staging: 5 días.
Las últimas cinco fases consumen lo construido en 0-6 y lo transforman en lectura ejecutiva: KPIs calculados → tensiones detectadas → reporte ejecutivo con Score → validación de dirección → decisión de continuidad. Cada fase mantiene la misma estructura (actividades, outputs, checklist, gate, ejemplo Cuyo).
Un KPI es una medición. Una señal es una variación o condición que merece atención. Esta fase calcula los 8-12 KPIs mínimos del MVP por dimensión (empresa, sucursal, vendedor cuando aplica) y genera el log de señales que alimenta la Fase 8.
KPI-SAL-001 Ventas netas · KPI-SAL-002 Margen bruto · KPI-SAL-003 Descuento promedio · KPI-SAL-004 Venta por vendedor.KPI-FIN-001 Días de cobranza · KPI-FIN-002 Mora vencida · KPI-FIN-003 Cobranza sobre facturación.KPI-STK-001 Stock crítico · KPI-STK-002 Cobertura de stock · KPI-STK-003 Stock inmovilizado.KPI-COM-001 Variación de costo · KPI-OPS-001 Acciones vencidas.| Campo | Descripción |
|---|---|
kpi_snapshot_id | ID único del snapshot. |
company_id | Empresa. |
kpi_code | Código KPI canónico. |
period_start / period_end | Inicio / fin del período medido. |
dimension_type / dimension_id | Empresa / sucursal / área / responsable + su ID. |
value / reference_value / delta | Valor actual / referencia / variación. |
status | ok / warning / critical. |
confidence_score | Confianza del cálculo (0-1). |
calculated_at | Timestamp del cálculo. |
10 KPIs calculados por empresa + por sucursal (3 sucursales activas) + por vendedor en KPIs comerciales. Confianza promedio 0.86 (lastrada por la fuente cobranza con histórico parcial). 14 señales generadas en signal_log, de las cuales 9 con severidad relevante para alimentar Fase 8.
FARO no debe alertar por cada número raro. Debe detectar combinaciones de señales que representen una tensión ejecutiva del catálogo canónico. Cada tensión disparada genera una acción con responsable, SLA, evidencia requerida e impacto en Score.
Principio clave. Ejemplo: Ventas suben + Margen baja + Descuento sube + Cobranza se estira = Tensión TNS-001 "Crecimiento no rentable". No es un alertón sobre descuento, es una lectura ejecutiva sobre la salud del crecimiento.
| Código | Tensión | Señales combinadas |
|---|---|---|
TNS-001 | Crecimiento no rentable | Ventas suben + margen baja + descuento sube |
TNS-002 | Venta sin caja | Ventas altas + cobranza baja + mora alta |
TNS-003 | Stock crítico comercial | Ventas altas + cobertura baja |
TNS-004 | Stock inmovilizado | Stock alto + rotación baja |
TNS-005 | Descuento fuera de política | Descuento alto + margen bajo |
TNS-006 | Reposición reactiva | Stock crítico + compras urgentes |
TNS-007 | Cliente de alto riesgo | Compra alta + mora alta |
TNS-008 | Vendedor erosiona margen | Venta alta + descuento alto + margen bajo |
TNS-009 | Acciones sin cierre | Acciones vencidas + sin evidencia |
TNS-010 | Dirección sin visibilidad | Datos atrasados + reportes manuales |
| Estado | Criterio de entrada | Criterio de salida |
|---|---|---|
| Nueva | Tensión detectada | Responsable asignado |
| En análisis | Responsable revisando | Acción definida |
| En ejecución | Acción en marcha | Evidencia cargada |
| En verificación | Evidencia cargada | Evidencia aprobada |
| Cerrada | Cierre aprobado | Medición posterior |
| Vencida | SLA vencido | Reprogramar o escalar |
| Escalada | Riesgo alto o vencimiento | Dirección decide |
| Rechazada | Falso positivo | Justificación obligatoria |
6 tensiones disparadas en el periodo: 2 críticas (mora crítica por cliente, caja proyectada insuficiente para una sucursal), 3 altas (crecimiento no rentable global, vendedor erosiona margen en zona norte, stock crítico en SKU rotativo), 1 media (acciones vencidas en mantenimiento). Cada tensión con responsable asignado por rol, SLA de 5-10 días y evidencia requerida. Workflow probado con 3 usuarios cliente reales.
Sintetizar el estado del piloto en una lectura ejecutiva clara. El FARO Score no es promedio simple: refleja salud comercial, rentabilidad, caja, stock, ejecución de acciones, calidad de datos y riesgo, ponderados según contexto. El reporte semanal traduce el Score en lenguaje de dirección.
Score inicial 64/100 (rojo en caja, amarillo en margen, verde en comercial volumen). Reporte semanal con 6 tensiones priorizadas, 4 acciones críticas vencidas (3 de cobranza, 1 de stock crítico), confianza promedio 0.86 explícita por sección, 3 recomendaciones de dirección (revisar política de descuentos, priorizar cobranza top-10, reasignar stock SKU rotativo a sucursal norte). Reporte entregado en PDF + vista web del producto.
El piloto puede tener datos perfectos y aun así fracasar si la dirección cliente no encuentra la lectura útil. Esta fase confronta el output contra la pregunta dura: ¿esto me sirve para decidir esta semana? Sin esa validación no hay continuidad razonable.
Dirección validó 5 de 6 tensiones como útiles (1 marcada para ajuste de umbral). 8 de 10 KPIs aprobados sin cambios; 2 con ajuste de fórmula (margen por familia y cobertura de stock). Score aprobado en su lógica de pesos. Reporte semanal validado como entregable directivo. Recomendación: continuar a fase paga con expansión a una sucursal adicional y conectar API del banco.
Cerrar el piloto con evidencia, aprendizajes y decisión comercial / técnica. No se cierra el piloto sin propuesta de siguiente paso ni sin informe final firmado por sponsor cliente y dirección FARO.
El piloto mostró valor; cliente decide producción + expansión.
Faltan datos pero hay potencial: extender 30 días con datos faltantes.
Fuente inicial no alcanzó; piloto se rehace con dataset alternativo.
Cliente no tiene madurez organizativa para usar el output.
Datos o sponsor insuficientes; no hay base para producción.
Resultado ejecutivo con métricas vs criterios de éxito.
Fuentes usadas, pendientes y bloqueos remanentes.
Indicadores aprobados por dirección cliente.
Tensiones útiles + falsos positivos descartados.
Seguimiento, cierre y evidencia documentada.
Antes / después con explicación ejecutiva.
Qué falta resolver para producción.
Qué construir después y en qué orden.
Plan recomendado: módulos, integraciones, plazo y precio.
Decisión: continuar a fase paga. Score evolucionó de 64 a 71 al cierre (acciones de cobranza top-10 cerradas, política de descuentos ajustada). Roadmap acordado: ampliar a las 5 sucursales, conectar API del banco como fuente A, agregar módulo Compras en el trimestre siguiente. Propuesta comercial firmada con plazo de implementación de 60 días para la fase 2.
El runbook es uniforme; los énfasis cambian. Las cinco industrias canónicas del pack tienen patrones distintos de fuentes disponibles, tensiones probables y velocidad típica del piloto. Ver detalle pleno en playbooks-5-industrias.html.
TNS-001TNS-002TNS-009TNS-010TNS-006TNS-007TNS-008TNS-022TNS-001TNS-002TNS-003TNS-006TNS-013TNS-002TNS-004TNS-018TNS-022TNS-024TNS-001TNS-004TNS-005TNS-006TNS-016Empresa Demo Cuyo S.A. corresponde al perfil Agroindustria / insumos con presencia retail multi-sucursal, lo que explica la combinación de tensiones TNS-001 (crecimiento no rentable estacional), TNS-004 (venta sin caja por financiación a productor) y TNS-006 (stock crítico en SKU rotativo de campaña).
El piloto cierra con un paquete documental y técnico unificado. Sin ese paquete, el piloto no se cierra: se diluye. Y sin opciones de expansión claras, el cliente no decide en la ventana caliente posterior al reporte final.
Decisiones, dolores, KPIs candidatos y red flags firmados por sponsor.
Fuentes relevadas con clasificación A/B/C/D y responsable por fuente.
Mapeo completo para reproducibilidad de la carga.
Resumen por fuente: ok / warning / error / fatal por regla.
RACI definitiva por proceso operativo.
Reporte ejecutivo entregado en el ciclo del piloto.
Resultados vs criterios de éxito + decisión de continuidad.
DDL completo para el modelo entidades MVP.
Políticas de aislamiento por company_id.
Carga inicial reproducible para el cliente piloto.
Reglas declarativas versionadas (no hardcodeadas).
Base para conectores A/B/C de cada fuente.
Motor que enriquece tensiones con metadatos del catálogo canónico.
Tests reproducibles sobre dataset demo + datos cliente.
Conjunto reproducible para validar regresiones futuras.
El piloto se considera exitoso ejecutivamente si la dirección puede responder, sin abrir un Excel, las 10 preguntas siguientes:
Cuando la decisión de Fase 11 es continuar a fase paga, las opciones de expansión se ordenan en cuatro capas. El cliente puede combinar capas, pero no debería brincar capa: cada una asume la anterior estabilizada.
Ampliar el alcance organizativo: pasar de 1-3 sucursales piloto a las 5+ activas, sumar áreas no incluidas en MVP (RRHH, mantenimiento, logística).
Reemplazar fuentes B (export manual estable) por fuentes A (API / DB automatizada). Reduce dependencia de personas y frecuencia de errores.
Sumar KPIs de capas P2/P3 de las bibliotecas extendidas, ampliar el catálogo de tensiones activas y profundizar workflow (escalamiento por SLA, aprobadores múltiples).
Una vez datos confiables y reglas estables, activar IA explicativa controlada y simulación de escenarios. Nunca antes: la IA sobre datos crudos genera humo.
El runbook no vive solo. Estos son los puntos donde consume, alimenta o se valida contra otros documentos del pack NDA.
FARO-DOC-001. Guía operativa del Workshop Discovery (Fase 1). En construcción.
Playbooks por vertical: fuentes típicas, tensiones probables, énfasis del piloto por industria.
Backlog del MVP que se construye fase a fase. Detalle de tickets y estimación.
Comunicación interna y externa del cierre del piloto. Plantillas de mensajes según decisión de continuidad.
Contrato de datos del MVP: qué exigir al cliente para recibir muestras (Fase 3) y mantener estabilidad de columnas.
Demo ejecutable end-to-end de Empresa Demo Cuyo S.A. para validar el flujo del runbook. En construcción.
Definición de ambientes (local / staging / producción cliente) usados desde Fase 0. En construcción.
Estrategia QA cruzada con cada gate de avance del runbook. En construcción.
Pipeline interactivo de 25 etapas técnicas. Vista visual complementaria de las 11 fases operativas del runbook.
Este documento es la cadena dura del piloto FARO Connect. Pasá al hub para ver el resto del pack, al pipeline interactivo para la vista visual o al catálogo de tensiones MVP para ver qué se mide en cada fase.
→ Volver al hub modelos NDA