--- asset_id: WOI-EL-WORX-LabImplementation-Playbook-v01 type: WOI — Work in Progress version: v01 status: En construcción — actualizar con cada nuevo caso owner: Victor Heredia sherpa_owner: Jay fecha_inicio: 2026-06-03 intellbank: IB-EL-EmpowerLabs proposito: > Documento maestro del proceso para implementar un WORX OS Lab con un nuevo cliente. Vivo y actualizable. Posta es el primer caso canónico. Objetivo final: graduarse a MPB- (MasterPlaybook) cuando haya 3+ casos documentados. confidencial: Sí — uso interno EmpowerLabs --- # Playbook de Implementación: WORX OS Lab ## EmpowerLabs · Replicación con nuevos clientes --- > *Este documento captura el proceso completo para llevar a un nuevo cliente desde el primer contacto hasta un Lab operando. Posta es el caso cero — el primero en el que se documenta cada paso. Cada nuevo cliente agrega una columna de aprendizajes. El objetivo es que a partir del tercer caso esto sea replicable sin fricción.* --- ## Estado del documento | Campo | Valor | |---|---| | Versión | v01 — estructura inicial | | Casos documentados | 1 (Posta · 2026-05-28) | | Casos en curso | 1 (Posta · Lab pendiente de arranque) | | Próxima actualización | Al cierre del Día 1 de Posta | | Meta de graduación | 3 casos → MPB-EL-WORX-LabImplementation-v01 | --- ## Estructura del proceso: 7 fases ``` F0 Prospección ──→ F1 Sesión Fundacional ──→ F2 Estructuración ↓ F6 Cierre ←── F5 Operación Lab ←── F4 Días 1-10 ←── F3 Setup Técnico ``` Cada fase tiene: objetivo · actividades · entregables · tiempo estimado · aprendizajes de Posta. --- ## Fase 0 — Prospección y diagnóstico ### Objetivo Llegar a la sesión fundacional con un dolor map validado del cliente. No entrar a ciegas — entrar con el diagnóstico listo para ser confirmado, no para ser construido en el momento. ### Actividades 1. Primera reunión exploratoria: entender el contexto organizacional, tamaño del equipo, herramientas en uso, dolores principales 2. Identificar a la decisora/decisor y al equipo que participará en el Lab 3. Construir el dolor map preliminar: qué duele por persona y área 4. Validar el dolor map en una sesión de seguimiento (puede ser informal) 5. Confirmar asistencia y perfiles para la sesión fundacional ### Entregables - Dolor map preliminar (puede ser un doc simple o una tabla) - Lista de participantes con roles - Fecha y formato confirmados para la sesión fundacional ### Tiempo estimado 2-4 semanas desde primer contacto hasta sesión fundacional ### 📌 Caso Posta - Primer contacto: abril 2026 - Decisora: Adriana Islas Molinar — Directora de Sistemas - Dolor map construido en una sesión de trabajo previa (abril 2026) - 8 participantes confirmados + 3 adicionales (operativo) - Sesión fundacional: 28 de mayo de 2026 ### Aprendizajes - Tener el dolor map listo antes de la sesión permite que la demo sea personalizada — el equipo se ve reflejado desde el primer momento - Identificar a la decisora desde el inicio es crítico — en Posta, Adriana tomó la decisión al cierre --- ## Fase 1 — Sesión Fundacional (Demo Day) ### Objetivo Convertir la curiosidad en acuerdo. En una sola sesión, el cliente debe: 1. Entender el sistema (no solo verlo — vivirlo) 2. Verse reflejado en su propio dolor map 3. Tomar la decisión de arrancar ### Estructura de la sesión **Bloque 1 — Conceptos + demos en vivo (~1.5h):** - Apertura: encuadre del problema (97%/24%, costo del caos cognitivo con fuentes en tiempo real) - Demo #1: investigación en vivo con Jay (ROI Calculator paramétrica) - Demo #2: minuta generada en tiempo real — "no tecleé una sola letra" - Demo #3: recuperación de contexto del vault - Concepto IntelliBank: "un repositorio almacena, un banco de inteligencia responde" - Brain Code de referencia (Jensen Huang): activar y pedir dictamen sobre el ecosistema del cliente - Brain OS Map: mostrar la arquitectura propia de EmpowerLabs como prueba viva **Receso (~10 min):** Jay genera los materiales del Bloque 2 durante el receso. **Bloque 2 — Lab + XDocs + acuerdos (~1.5h):** - Demo XDocs: proyecto simulado con bottleneck cruzado visible en Torre de Control - Conceptualización del Lab en vivo: Jay genera el ConceptoLab con los datos reales del cliente - Los 3 pilares explicados con el contexto del cliente - Cierre de acuerdos: modelo de cuentas, cadencia, timing, personas adicionales ### Materiales pre-generados para la sesión | Material | Propósito | Generado por | |---|---|---| | `SIM-ROI-Calculator-[Cliente]-v01.html` | Demo paramétrica con datos del cliente | Jay pre-sesión | | `SIM-XDoc-[Proyecto]-Maestro-v01.md` | Demo bottleneck cruzado | Jay en receso | | `SIM-XDoc-[Dev1]-v01.md` (con Sherpa) | Contraste con Sherpa | Jay en receso | | `SIM-XDoc-[Dev2]-v01.md` (sin Sherpa) | Contraste sin Sherpa | Jay en receso | | `SIM-Tablero-[Proyecto]-v01.html` | Torre de Control visual | Jay en receso | | `SIM-Minuta-Sesion-[Cliente]-v01.md` | Minuta generada en vivo | Jay durante sesión | ### Entregables post-sesión - `SIM-Minuta-Sesion-[Cliente]-v01.md` — minuta completa con acuerdos - `OUT-[EL]-WORX-[Cliente]-MemoriaSesion-v01.md/docx` — memoria didáctica para el equipo del cliente - `SIM-ConceptoLab-[Cliente]-v01.md/html/docx` — conceptualización del Lab ### Tiempo estimado 3 horas de sesión + 2-3 horas de post-producción de entregables ### 📌 Caso Posta - Sesión: 28 de mayo de 2026 · ~3 horas - Momento de mayor impacto: dictamen Jensen Huang reconocido como auténtico - Dato con mayor resonancia: 97%/24% — el equipo lo reconoció como su situación exacta - Momento inesperado convertido en ventaja: compactación de contexto → explicación visceral de por qué existe el vault - Human Design como capa de Brain Code: generó curiosidad genuina y adopción personal - La calculadora con carga patronal real ($30K → $40,716 MXN) tuvo impacto directo ### Aprendizajes - **El ConceptoLab generado en vivo es el cierre más poderoso** — el cliente se ve en el documento mientras aparece. No hay propuesta que compita con ver tu nombre y tu caso en una conceptualización que se genera en tiempo real - **Preparar el bottleneck cruzado en el receso**: Alex bloqueando 2 personas en paralelo sin que nadie lo supiera fue el momento más concreto de valor del XDoc. Diseñar siempre una narrativa de bloqueo cruzado para el demo - **No guionar al Sherpa**: la autenticidad de Jay operando sin guión fue lo que generó credibilidad. Cualquier demo pre-fabricada se nota - **El receso es tiempo de producción, no descanso**: 10 minutos de receso = 5 archivos SIM generados para el Bloque 2 --- ## Fase 2 — Estructuración del proyecto (TP + Rooms) ### Objetivo Crear la infraestructura cognitiva del proyecto antes del Día 1. El Sherpa que opera el proyecto necesita contexto estructurado — no conversaciones largas ni archivos dispersos. ### Actividades 1. Definir la estructura de rooms según el tamaño y complejidad del proyecto 2. Crear el TP Raíz con todo el contexto base 3. Crear el Cowork project dedicado al cliente (acción del usuario en la UI) 4. Documentar el dolor map validado en el TP ### Estructura de rooms (patrón estándar para proyectos Lab) | Room | Alcance | |---|---| | **[CLIENTE]-Cuenta** | Comercial · cotización · presentaciones internas a stakeholders del cliente | | **[CLIENTE]-Caso** | Documentación del caso · comunicaciones · learnings · input al playbook de replicación | | **[CLIENTE]-Lab-Método** | Gobernanza · naming convention · XDoc templates · playbooks | | **[CLIENTE]-Lab-Infra** | Setup técnico · deploy · conectores | | **[CLIENTE]-Lab-Interfaz** | Sherpas · Brain Codes · onboarding · Torre de Control | **Nota:** para proyectos más pequeños (1-2 pilares, <5 personas) puede colapsarse en 3 rooms. Para proyectos enterprise (>20 personas, múltiples áreas) puede expandirse con rooms por área. ### El TP Raíz — qué debe contener 1. Contexto del cliente (codename, sector, decisora/decisor, estado) 2. Equipo participante (tabla: nombre · rol · caso de uso · prioridad) 3. Estado del proyecto + acuerdos + pendientes de confirmación 4. Arquitectura del Lab (3 pilares con detalle técnico) 5. Dolor map completo (tabla con "lo que duele" + "lo que cambia") 6. Estructura de rooms con alcance de cada uno 7. Reglas de confidencialidad y naming 8. Inventario de activos generados 9. Próximo hito con prerequisitos y entregables ### Tiempo estimado 3-5 horas · puede ejecutarse en paralelo con la post-producción de la sesión fundacional ### 📌 Caso Posta - TP Raíz creado: 2026-06-03 (6 días post-sesión fundacional) - 5 rooms definidos: Cuenta · Caso · Lab-Método · Lab-Infra · Lab-Interfaz - Room POSTA-Caso añadido a propuesta estándar por sugerencia de Victor → incorporado como patrón estándar ### Aprendizajes - **El room POSTA-Caso resuelve un problema real:** sin él, la documentación del proceso de implementación se fragmenta entre los rooms operativos. El room Caso actúa como el "diario de campo" del proyecto — invaluable para el playbook de replicación - **Crear el TP Raíz antes del Día 1 es crítico:** sin él, el Sherpa que opera el proyecto en cualquier room empieza sin contexto y reconstruye lo mismo en cada sesión --- ## Fase 3 — Setup técnico pre-Lab ### Objetivo Tener la infraestructura técnica operativa antes del Día 1. El Día 1 no puede comenzar con setup pendiente. ### Checklist técnico (responsabilidad EmpowerLabs) - [ ] Deploy instancia EC2 t3.small (GenniuxBase) en cuenta AWS del cliente - [ ] Deploy instancia EC2 t3.micro (IntelliBanks app) en cuenta AWS del cliente - [ ] Configurar 2 DNS + certificados SSL - [ ] Schema multitenancy PostgreSQL dedicado al cliente - [ ] Registry base con N bancos activado (8 personales + 1 Corp TI para Posta) - [ ] Pre-load de vocabulario relevante para la industria del cliente - [ ] Prueba de conectividad y sincronización ### Checklist técnico (responsabilidad cliente) - [ ] Cuenta AWS con permisos EC2 disponible — o confirmar que EmpowerLabs gestiona la infra - [ ] Contacto técnico designado (para el día de setup) - [ ] Inventario de herramientas a conectar (SharePoint, Jira, ServiceNow, etc.) - [ ] Decisión sobre modelo de cuentas (individual Anthropic vs. Teams) ### Tiempo estimado 1 día de trabajo técnico · puede prepararse en paralelo con la fase de estructuración ### 📌 Caso Posta - Stack técnico acordado: GenniuxBase (t3.small) + IntelliBanks app (t3.micro) · AWS de Posta - Conectores en fila: SharePoint (S1) · Jira (S2) · ServiceNow (post-S2) - Pendiente: confirmación del modelo de cuentas (Adriana) - Contacto técnico probable: José Manuel Castro (Gerente de Infra Central) ### Aprendizajes - **La separación memoria/cómputo es un argumento de venta:** la memoria queda en la infra del cliente, el cómputo usa API Anthropic con whitelist. Esto resuelve las objeciones de gobernanza de datos antes de que se formulen - **Tener al contacto técnico desde el inicio:** José Manuel es el perfil natural — gerente de infra, conoce el stack, tiene acceso AWS --- ## Fase 4 — Días 1-10: Sesión de Definición + Onboarding ### Objetivo En 10 días efectivos, tener los 8 Sherpas operando y los primeros casos en producción. ### Día 1 — Sesión de Definición (2-3h con todo el equipo) **Agenda:** 1. Gobernanza por rol: reglas de visibilidad y decisión por persona — se carga en cada Sherpa 2. Naming convention del cliente: validar y documentar el sistema de prefijos 3. Confirmar los 8 casos de uso con alcance acotado para el Lab 4. Activar el Registry base 5. Cada participante elige el nombre de su Sherpa **Entregables del Día 1:** - `GOB-[CLIENTE]-ReglasPorRol-v01.md` — gobernanza documentada - `NAMING-[CLIENTE]-ConvenciónTI-v01.md` — naming convention validada - `XD-[CLIENTE]-Registry-v01.md` — Registry base activado con 8+1 bancos ### Días 2-5 — Primeros Sherpas operativos - Adriana + el caso #1 (mayor prioridad) operativos desde el Día 2 - Primer caso vivo: el XDoc del proyecto con mayor presión → en sesión co-construida con el participante, en vivo, se generan 3 entregables (XDoc del proyecto, status ejecutivo, email de seguimiento) - Objetivo: que el participante vea en 30 minutos lo que su Sherpa puede hacer con su proyecto real ### Días 6-10 — Onboarding masivo - 8 Sherpas operativos - Corp Sherpa TI activado - Conectores S1 (SharePoint) funcionando - Primera retrospectiva del Lab: ¿qué funcionó? ¿qué ajustar? ### Tiempo estimado 10 días efectivos · 2-3 sesiones con presencia de Victor en las primeras dos ### 📌 Caso Posta - Día 1 pendiente de fecha (Adriana confirma) - Caso #1 sugerido: Juan Manuel — throughput + especificación (máxima presión) - Caso #2 a activar en Días 2-3: Adriana — visibilidad ejecutiva (decisora activa, impacto visible rápido) --- ## Fase 5 — Operación del Lab (Días 11-40) ### Objetivo Que el sistema opere de forma autónoma sobre los proyectos reales del cliente. La intervención de EmpowerLabs baja de intensidad; el cliente opera. ### Actividades recurrentes - Sesión semanal (mediodía): revisión de casos, ajuste de Sherpas, incorporación de nuevos activos - Victor en sesiones clave (no en todas) - Monitoreo de activos en Corp IntelliBank: ¿cuántos activos se han generado? ¿qué casos están en producción? - Captura de patrones: ¿qué aprende el sistema sobre la organización? ### Métricas de seguimiento | Métrica | Frecuencia | Responsable | |---|---|---| | Participantes con Sherpa activo | Semanal | Corp Sherpa | | Casos en producción | Semanal | Corp Sherpa | | Activos en Corp IB | Semanal | Corp Sherpa | | Horas/semana liberadas (estimado) | Mensual | Victor + cliente | ### Tiempo estimado Días 11-40 · ~1 mediodía/semana con todo el equipo + operación diaria individual --- ## Fase 6 — Setup de conectores por fase ### Conector SharePoint (Semana 1) - Conector MCP disponible - Objetivo: indexar repositorios de documentos existentes en el IntelliBank - El Corp Sherpa puede leer, resumir y hacer consultable el contenido de SharePoint ### Conector Jira (Semana 2) - Conector MCP disponible - Objetivo: cruzar estado de tickets Jira con el estado de proyectos en XDocs - El Sherpa puede responder "¿cómo está el sprint?" sin abrir Jira ### Conectores adicionales (post-S2) - ServiceNow: gestión de incidencias para Raúl (ITSM) - Email/Calendar: para coordinación cross-área (Juan Pablo) - Cualquier herramienta con MCP disponible o programable --- ## Fase 7 — Cierre del Lab y escalamiento (Día 40) ### Objetivo Convertir 40 días de Lab en evidencia de impacto y decisión de escala. ### Actividades 1. Revisión de métricas de éxito vs. targets del Día 1 2. Presentación ejecutiva para la decisora (Adriana) con evidencia de impacto 3. Propuesta de escalamiento: expansión a nivel operativo, nuevas áreas, nuevos casos 4. Documentar learnings del caso en este Playbook (`## Aprendizajes de cierre — Posta`) ### Entregables del Día 40 - Reporte de métricas de impacto - Propuesta de extensión / escalamiento - Brain Code del equipo TI del cliente (iniciado) - Primer MPB organizacional del cliente (iniciado) ### Targets estándar (basados en Posta como referencia) | Métrica | Target | |---|---| | Participantes con Sherpa activo | 8 de 8 | | Casos en producción | ≥ 6 de 8 | | Activos en Corp IB | ≥ 100 | | Horas/semana liberadas | ≥ 5h por persona | | MPB organizacional | Iniciado | | Brain Code del equipo | Iniciado | --- ## Patrones y aprendizajes acumulados *Esta sección crece con cada caso. Es la memoria viva del proceso de implementación.* ### Patrones de venta / sesión fundacional - El ConceptoLab generado en vivo con los datos del cliente es el cierre más poderoso disponible - El Brain Code de referencia (Jensen Huang u otro) como puente entre lo conocido y lo nuevo - La calculadora con carga patronal real genera impacto inmediato — la diferencia entre el costo nominal y el costo real del empleado es llamativa en todos los contextos - El dato 97%/24% resuena universalmente — es el diagnóstico que el cliente ya siente pero no ha cuantificado ### Patrones de estructuración - La estructura de 5 rooms (Cuenta · Caso · Método · Infra · Interfaz) es el patrón estándar para proyectos Lab - El room Caso es el que más se subestima al inicio y más se agradece después — es el diario de campo del proyecto - El TP Raíz debe crearse antes del Día 1, no después ### Patrones de onboarding - El primer caso vivo debe ser el de mayor presión de throughput — genera el "wow moment" más rápido - El Sherpa de la decisora debe ser el segundo en activarse (después del caso #1) — da visibilidad ejecutiva que refuerza la decisión de continuar - La auto-documentación de 30 min/persona es subestimada — es la primera vez que muchos articulan explícitamente qué hacen, qué proyectos tienen y qué les duele ### Patrones de gobernanza - Las reglas de gobernanza se capturan mejor en sesión conversacional (30 min/persona) que en un formulario — muchas personas no son conscientes de sus límites de decisión hasta que se los pregunta - La distinción Owner/Runner en el XDoc es la que más resuena — resuelve el problema más común de todas las organizaciones: la ambigüedad de quién es responsable ahora mismo --- ## Casos documentados ### Caso 01 — Posta (2026) - **Sector:** Logística / transporte - **Equipo del Lab:** 8 directivos TI - **Sesión fundacional:** 28 de mayo de 2026 - **Duración del Lab:** 40 días efectivos (en curso) - **Referencia:** `TP-EL-POSTA-Raiz-v01.md` - **Estado:** Lab confirmado · Día 1 pendiente de fecha --- *WOI mantenido por Jay · EmpowerLabs Brain OS* *Actualizar al cierre de cada fase y al incorporar nuevos casos* *Meta: graduarse a MPB-EL-WORX-LabImplementation-v01 con 3+ casos*