Reunión estructurada para definir si una empresa puede ingresar al modelo FARO Connect, con qué datos, con qué esfuerzo, con qué riesgos y con qué alcance inicial. Esta pieza es la especificación formal del workshop; coexiste con Anexo 1 como nota original.
El Workshop Discovery es una reunión única estructurada de 90 a 150 minutos que levanta la información mínima necesaria para determinar si una empresa puede ingresar al modelo FARO Connect, con qué datos, con qué esfuerzo, con qué riesgos y con qué alcance inicial.
FARO Connect no empieza por hacer pantallas ni por preguntar qué dashboard quiere el cliente. Empieza por entender la cadena completa: cómo funciona la empresa, qué decisiones toma la dirección, qué datos existen, dónde viven, qué tan confiables son, qué tensiones reales se repiten, qué acciones deberían dispararse, quién debe responder y qué evidencia permite cerrar una acción.
El workshop valida si esta cadena puede construirse para el cliente y por dónde conviene empezar:
Tesis operativa. FARO Connect transforma datos dispersos en dirección ejecutiva accionable. Si un dato no termina en una decisión o en una acción, probablemente es ruido. El Discovery valida si esa cadena puede construirse con los datos reales de la empresa, en cuánto tiempo y con qué riesgo técnico, organizacional y comercial.
Al finalizar el workshop, FARO debe poder producir 10 mapas de salida (sección 03), una recomendación de alcance MVP, un score de readiness, un mapa de riesgos y una lista concreta de muestras de datos a solicitar. La pieza acompaña a Anexo 1 del pack (nota original): este documento es la spec formal del workshop, mientras Anexo 1 funciona como referencia histórica.
La distinción importa porque define qué preguntas hacer, qué tiempo asignar y qué expectativa generar. Confundir el Discovery con una reunión comercial genérica o un diagnóstico exhaustivo es la forma más rápida de quemar el contacto y la oportunidad.
Al finalizar el workshop, FARO debe poder completar estos 10 entregables. Cada uno conecta con un activo o catálogo posterior del pack FARO Connect.
Empresas, sucursales, áreas y responsables. Estructura inicial multiempresa/multisucursal.
FARO-PL-001ERP, Excel, bancos, POS, CRM, WhatsApp, APIs, documentos. Inventario preliminar con dueño y formato.
FARO-PL-016Decisiones semanales y mensuales de dirección. Frecuencia, responsable, datos necesarios, riesgo.
FARO-DOC-001-S1Indicadores que la empresa ya mira o debería mirar. Existencia, fuente, frecuencia, umbral.
FARO-KPI-MVPProblemas recurrentes por área expresados en lenguaje del cliente, antes de convertirlos en tensiones.
FARO-DOLORTensiones detectables con datos disponibles, mapeadas contra el catálogo canónico TNS-001..TNS-030.
FARO-CFG-001Acciones posibles por tensión, con responsable natural, aprobador, SLA y evidencia requerida.
FARO-ACTNivel de madurez y confiabilidad por fuente. Recomendación de automatización, validación o carga manual.
FARO-DQQué módulos activar primero, qué usuarios usarán el sistema, qué reporte ejecutivo entregar.
FARO-MVP-001Red flags técnicos, organizacionales y comerciales del piloto. Severidad y mitigación recomendada.
FARO-RISK-001El workshop requiere un set mínimo de participantes para que tenga sentido. Faltar la dirección o no tener responsable de sistemas convierte la reunión en levantamiento parcial; pedir presencia masiva la convierte en reunión política.
Dos personas. Una dirige, la otra captura.
Cinco roles. Sin alguno, el discovery queda cojo.
Solo si aplican al modelo del cliente.
Regla práctica de convocatoria. Si el dueño no viene, suspender. Si el responsable de sistemas no viene, traer su número y hacer una llamada al medio. Sin esas dos voces, lo que se levanta es opinión, no diagnóstico.
La versión ejecutiva sirve como primera reunión con cliente, socio técnico o piloto candidato. La versión profunda se usa cuando el cliente ya está interesado, hay piloto formal o se necesita diagnóstico ampliado. Cambia el tiempo por bloque; el contenido se mantiene coherente.
Reunión inicial donde el cliente todavía evalúa si entra. Foco en alcance, fuentes y dolores principales.
| Minutos | Bloque | Tiempo |
|---|---|---|
| 00-10 | Apertura y contexto | 10 min |
| 10-25 | Empresa, estructura y decisiones | 15 min |
| 25-45 | Fuentes de datos y sistemas | 20 min |
| 45-70 | Dolores, tensiones y KPIs | 25 min |
| 70-80 | Acciones, responsables y evidencia | 10 min |
| 80-90 | Alcance MVP y próximos pasos | 10 min |
Diagnóstico ampliado con bloques separados para procesos, calidad del dato, reportes actuales y seguridad.
| Minutos | Bloque | Tiempo |
|---|---|---|
| 00-10 | Apertura y marco de confidencialidad | 10 min |
| 10-30 | Modelo de negocio y estructura | 20 min |
| 30-50 | Áreas, procesos y responsables | 20 min |
| 50-75 | Sistemas, fuentes y calidad del dato | 25 min |
| 75-95 | KPIs, decisiones y reportes actuales | 20 min |
| 95-120 | Dolores, alertas y tensiones | 25 min |
| 120-135 | Acciones, workflow y evidencia | 15 min |
| 135-145 | Seguridad, accesos y restricciones | 10 min |
| 145-150 | Alcance MVP y cierre | 5-15 min |
Cuándo elegir cada una. Versión ejecutiva si no hay NDA firmado o si el cliente está evaluando otros proveedores en paralelo. Versión profunda solo cuando hay compromiso de seguir adelante con el piloto y la dirección bloquea agenda. Forzar versión profunda en cliente no comprometido es perder tiempo y prestigio.
El facilitador FARO no improvisa. Estas reglas y frases son la herramienta operativa para mantener foco, separar percepción de evidencia y no prometer automatizaciones sin validar fuentes.
Nada de "cuéntame de la empresa". Sí: "¿cuántas sucursales operan hoy?", "¿qué ERP usan?".
"Más o menos bien" no entra en la minuta. Repreguntar hasta obtener dato, ejemplo o caso.
"Dame un caso de esta semana", "¿cuándo fue la última vez que pasó?". El ejemplo separa relato de realidad.
Cada vez que aparezca un indicador o problema, preguntar dónde se registra hoy. Sistema, planilla o "nadie lo carga".
Toda decisión mencionada debe tener nombre y apellido. Sin responsable claro no hay tensión accionable.
Distinguir quién decide de quién ejecuta. Muchas tensiones se rompen porque se confunden esos dos roles.
Toda acción discutida debe tener evidencia de cierre posible. Sin evidencia, queda como relato.
"Yo siento que" no es lo mismo que "el sistema muestra". Marcar ambos pero distinguirlos en la minuta.
El cliente puede querer algo que el dato actual no soporta. Marcarlo, no prometerlo.
Sin haber visto muestra de datos, no se promete conexión, alerta ni automatización. Compromisos en blanco se pagan caros.
"Perfecto, ¿eso hoy dónde se registra?"
"¿Quién lo mira todas las semanas?"
"¿Qué pasa si ese dato llega mal?"
"¿Quién se entera primero?"
"¿Quién debería actuar?"
"¿Cuál sería la evidencia de cierre?"
"¿Eso es un problema ocasional o se repite?"
"¿Puede salir de un sistema o alguien lo arma a mano?"
"¿La dirección decide con ese dato o se entera tarde?"
"¿Ese KPI se usa para mirar o para accionar?"
"Dame un ejemplo concreto de esta semana."
"¿Cuánto dinero estiman que cuesta ese problema?"
"¿Qué pasaría si nada cambia en seis meses?"
"Si tuvieran que elegir uno solo, ¿cuál priorizan?"
"¿Eso lo ven en el sistema o lo intuyen por experiencia?"
El cliente se va a desviar. Es natural y, dosificado, hasta útil. Lo importante es saber retomar sin cortar el vínculo. Tres patrones típicos y cómo cortarlos:
El Discovery se prepara con una solicitud formal de información enviada al cliente al menos 48 horas antes. Esa solicitud tiene una lista corta de pedidos útiles y una lista igual de importante de cosas que nunca se piden en esta etapa.
Principio rector. Para el Discovery alcanza con muestras, estructuras y campos. Pedir más es generar fricción, asustar al cliente y abrir exposición innecesaria de FARO a custodia de datos sensibles antes de tener acuerdo formal. La regla: muestra anonimizada antes que dataset completo.
Cada bloque tiene objetivo claro, preguntas concretas y un ejemplo real basado en Empresa Demo Cuyo S.A. (la empresa demo del pack FARO Connect). El ejemplo muestra qué preguntó FARO y qué respondió la empresa, para calibrar profundidad esperada.
FARO: ¿Cuántas sucursales operan y cómo se distribuye la facturación?
Empresa: 3 sucursales en Mendoza, San Juan y San Luis. La de Mendoza concentra el 55 % de la facturación pero deja menos margen que la de San Luis.
FARO: ¿Cuál es el principal cuello de botella hoy?
Empresa: Stock. Vendemos pero no tenemos lo que más rota. Compramos tarde y caro.
FARO: ¿Qué ERP usan y qué exporta?
Empresa: Bejerman para administración. Exporta CSV de ventas y stock. Cobranza se concilia a mano en Excel todos los lunes.
FARO: ¿Hay IDs únicos para clientes?
Empresa: Sí, pero varios clientes están duplicados con razón social distinta. Estimamos 12-15 % de duplicación.
FARO: ¿Qué decisión toman todas las semanas que les genera más fricción?
Empresa: Autorizar descuentos. Los vendedores piden, comercial aprueba sin ver margen, finanzas se entera cuando ya está facturado.
FARO: ¿Qué alerta les gustaría recibir antes de que se autorice un descuento alto?
Empresa: Que el sistema avise si el descuento deja la venta por debajo del margen objetivo del SKU. Hoy nadie lo ve.
FARO: ¿Qué problema cuesta plata todos los meses?
Empresa: Vendemos más pero no queda plata. Comercial dice que es porque compras compra caro. Compras dice que es porque comercial autoriza descuentos sin política.
FARO: ¿Quién debería enterarse primero cuando eso ocurre?
Empresa: La dirección. Hoy nos enteramos cuando cierra el mes y ya es tarde.
TNS-001..TNS-030.Dolor expresado: "Vendemos más pero no queda plata."
Tensión FARO: Crecimiento no rentable. Ventas suben, margen baja, descuentos suben.
Mapeo canónico: TNS-001 · Crecimiento no rentable (severidad High, área Comercial).
Detectable con datos actuales: Sí (Bejerman exporta ventas, descuentos y margen por SKU).
Tensión: Crecimiento no rentable.
Acción sugerida: Revisar política de descuentos por vendedor y producto.
Responsable: Gerente Comercial. Aprobador: Dirección. SLA: 7 días.
Evidencia requerida: Nueva matriz de descuentos aprobada por dirección (EVD-007).
Pregunta: ¿Quién controla margen en tiempo real?
Respuesta: Nadie. Lo mira el contador cuando cierra el mes.
Diagnóstico FARO: Vacío de responsabilidad en control de margen. La tensión TNS-001 no tiene owner natural hoy; el piloto debe asignar uno explícitamente antes de activar la regla.
EVD-001 Documento cargado (PDF, Excel, acta).EVD-002 Captura de sistema (screenshot ERP/CRM).EVD-003 Registro de aprobación (gerente/director).EVD-005 Orden emitida (OC, pedido, solicitud).EVD-007 Cambio de política (nueva regla o procedimiento).EVD-010 Reunión documentada (acta con decisiones).EVD-011 Cliente o proveedor contactado (registro de gestión).EVD-012 Validación de dirección (cierre aprobado por autoridad).Pregunta: ¿Cómo prueban hoy que cerraron una negociación con un cliente moroso?
Respuesta: Mail del cliente con compromiso de pago. A veces planilla con fecha de promesa.
Diagnóstico FARO: Evidencia existe pero está dispersa. El piloto puede capturarla como EVD-011 (cliente contactado) sin pedir nada nuevo a la empresa.
Tabla de trazabilidad entre los 8 bloques del workshop y los 10 mapas de salida. Sirve al facilitador para confirmar cobertura antes de cerrar la reunión y al analista para ordenar la minuta posterior.
| Entregable | Bloque(s) que lo alimenta | Qué se completa | Activo destino |
|---|---|---|---|
| Mapa de empresa | B01 B07 | Empresas, sucursales, áreas, responsables reales y formales. | FARO-PL-001 |
| Inventario de fuentes | B02 | Sistemas, formato, frecuencia, dueño, acceso y calidad percibida. | FARO-PL-016 |
| Mapa de decisiones | B03 | Decisiones semanales y mensuales con frecuencia, responsable, datos necesarios, riesgo. | FARO-DOC-001-S1 |
| Mapa de KPIs | B02 B03 | KPIs actuales + KPIs candidatos MVP con fuente, frecuencia, umbral y responsable. | FARO-KPI-MVP |
| Mapa de dolores | B04 | Problemas recurrentes por área, en lenguaje del cliente, con ejemplo real. | FARO-DOLOR |
| Mapa de tensiones candidatas | B04 B05 | Conversión dolor → tensión mapeada contra catálogo canónico TNS-001..TNS-030. | FARO-CFG-001 |
| Mapa de acciones | B06 | Acciones posibles por tensión con responsable, aprobador, SLA y evidencia. | FARO-ACT |
| Calidad de datos | B02 | Madurez y confiabilidad por fuente. Recomendación: automatizar / validar / manual. | FARO-DQ |
| Alcance MVP | B03 B05 B06 | Módulos a activar, usuarios, reportes, exclusiones, plazo estimado. | FARO-MVP-001 |
| Riesgos del piloto | B02 B07 | Red flags técnicos, organizacionales y comerciales con severidad y mitigación. | FARO-RISK-001 |
| Mapa de evidencia | B06 B08 | Tipos de evidencia disponibles vs requeridos por acción. Brecha a cerrar. | FARO-EVD |
Estos errores no son hipotéticos. Aparecen recurrentemente cuando un facilitador improvisa o cuando el cliente arrastra la reunión hacia una zona cómoda. Identificarlos a tiempo es la diferencia entre minuta útil y reunión amable sin resultado.
El facilitador abre slides corporativas, muestra pantallas y pierde 40 minutos vendiendo en lugar de descubrir. Resultado: el cliente queda impresionado pero FARO no levantó la información que necesita.
Cómo evitarloDemo va antes (en la reunión comercial) o después (en la segunda reunión). Durante el Discovery, cero slides corporativas.
"Tenemos buena información", "el ERP exporta todo", "el equipo está alineado". Frases que suenan bien y no significan nada. Sin ejemplos concretos, todo queda como percepción.
Cómo evitarloRepreguntar siempre: "¿dame un caso real?", "¿cuándo fue la última vez?", "¿dónde está ese dato?".
El cliente describe un problema y el facilitador dice "eso FARO lo automatiza". Sin haber visto una muestra de datos, esa promesa puede no cumplirse y rompe la confianza al iniciar el piloto.
Cómo evitarloDecir siempre: "vamos a validarlo con muestra de datos en la próxima reunión".
Si el dueño falta, las prioridades reales no aparecen. Las áreas optimizan por su propia métrica y la dirección queda sin voz. El alcance MVP que sale del workshop no representa la urgencia real.
Cómo evitarloConfirmar presencia del dueño 48 h antes. Si no puede, reprogramar.
Por presión de tiempo, el facilitador omite el bloque de calidad. Resultado: las tensiones candidatas asumen datos limpios que en realidad están sucios. El piloto arranca y choca contra duplicados, fechas mal cargadas y stock negativo.
Cómo evitarloCalidad de datos nunca se omite. Si falta tiempo, cortar profundidad de otros bloques pero no este.
El facilitador pide claves, datos bancarios completos o nómina con sueldos para "tener todo a mano". El cliente se asusta, FARO queda expuesto a custodia de datos sin acuerdo y se rompe el vínculo de confianza.
Cómo evitarloSeguir la lista de la sección 07. Muestras y estructuras, nunca claves ni datos personales.
El facilitador anota frases narrativas del cliente sin convertirlas en tensiones detectables por datos. La minuta queda como reporte periodístico, no como spec de implementación. FARO no puede arrancar a configurar reglas.
Cómo evitarloBloque 05 obligatorio: cada dolor del bloque 04 sale mapeado contra el catálogo TNS canónico.
El workshop termina sin acordar qué módulos activar primero. FARO se va a "armar la propuesta" y el cliente queda esperando. La energía del Discovery se diluye en una semana.
Cómo evitarloÚltimos 10-15 minutos siempre dedicados a cerrar alcance MVP, aunque sea preliminar y sujeto a revisión técnica.
Dentro de las 48 a 72 horas posteriores al workshop, FARO debe producir una minuta ejecutiva y enviar al cliente una lista clara de próximos pasos. Sin este paso, la información levantada se pierde y la oportunidad se enfría.
cliente: Empresa Demo Cuyo S.A. fecha: 2026-05-31 duración: 120 min (versión profunda) facilitador: Equipo FARO readiness: 72 / 100 → preparación media · piloto acotado perfil_empresa: industria: Distribución insumos sucursales: 3 (Mendoza · San Juan · San Luis) empleados: 45 modelo: Crédito B2B (60-90 días) fuentes_prioritarias_mvp: - ventas (Bejerman · CSV diario · alta calidad) - stock (Bejerman · CSV diario · media calidad) - cobranza (Excel manual · semanal · media calidad) tensiones_candidatas_mvp: - TNS-001 Crecimiento no rentable (detectable Sí) - TNS-002 Descuento fuera de política (detectable Sí) - TNS-004 Venta sin conversión a caja (detectable Sí) - TNS-005 Mora crítica por cliente (detectable Parcial) - TNS-006 Stock crítico alta rotación (detectable Sí) alcance_mvp_recomendado: modulos: ventas · margen · descuentos · stock · cobranza usuarios: Dirección · Comercial · Finanzas (3 roles) reporte: Reporte ejecutivo semanal duracion: 8 semanas piloto riesgos_principales: - Duplicación clientes ~12% (limpieza previa) - Sin responsable de margen (asignar antes de activar TNS-001) - Cobranza solo Excel (validar repetibilidad de export) # Próximos pasos en sección 11 de la spec.
Plantillas que el facilitador puede llevar impresas o digitales al workshop. Se publican como descargables del pack FARO Connect (Excel + PDF). Listadas aquí como referencia operativa.
Plantilla A4 para imprimir y completar durante la reunión. Incluye los 10 mapas en formato compacto y bloque final de próximos pasos.
Descargar · PDF / DOCXExcel con estructura formal multiempresa, sucursales, áreas y responsables. Pestaña separada para grupo económico si aplica.
Descargar · XLSXExcel con matriz de decisiones críticas: frecuencia, responsable, datos necesarios, fuente actual, riesgo si se decide mal, FARO puede asistir.
Descargar · XLSXEstado de las plantillas. Los archivos físicos viven en descargas/ del pack NDA y se sirven desde plantillas-oficiales.html. Esta sección documenta el contrato funcional de cada plantilla; los binarios se publican como parte del paquete de entrega al iniciar el piloto.
El Discovery no vive solo. Estos son los puntos donde se consume, se ejecuta o se extiende dentro del pack FARO Connect.
Runbook operativo del piloto post-Discovery. Define cómo se ejecutan los 10 mapas de salida durante las 8 semanas siguientes. En construcción.
Playbooks específicos por industria piloto. Adaptan preguntas del Bloque 01 y tensiones del Bloque 05 según vertical del cliente.
15 industrias con procesos típicos y dolores frecuentes. Insumo para calibrar el Bloque 04 (dolores) según vertical.
Contrato de datos formal. El inventario de fuentes del Bloque 02 se convierte en este contrato cuando se firma el piloto.
Catálogo canónico TNS-001..TNS-030. El Bloque 05 mapea dolores del cliente contra estos códigos para definir reglas del piloto.
Backlog de implementación MVP. Las salidas del workshop se cargan acá como tareas priorizadas para el equipo técnico FARO.
Anexo 1 del pack contiene la nota original del Discovery. Esta pieza es la spec formal; Anexo 1 se mantiene como referencia histórica.
Diagnóstico ejecutivo de empresa cliente. Usa los códigos TNS levantados durante el Discovery como base de evaluación.
Este documento es la spec formal del Workshop Discovery FARO Connect. La pieza siguiente (runbook-implementacion-piloto) define cómo se ejecutan los 10 mapas de salida durante las 8 semanas del piloto. Pasá al hub para ver el resto del pack o seguí con el catálogo canónico de tensiones.
→ Volver al hub modelos NDA