# MPB-HIORGS-Replicacion-Playbook-v01 **MasterPlaybook — Replicación post-Lab del SO-HiORG · "Red de EmpowerTeamsX"** **Cómo se replica el SO-HiORG dentro de un cliente una vez que el Lab del equipo #1 está cerrado y estable. Define los dos modelos canónicos (A y B), la auditoría EL del ecosistema instalado, el rol del Sherpa Guide post-certificación y la cadencia operativa de equipos subsiguientes.** --- | Campo | Valor | |---|---| | **Asset ID** | MPB-HIORGS-Replicacion-Playbook-v01 | | **Tipo** | MPB — MasterPlaybook | | **Room** | PB-HiOrg — Hyperintelligent Org | | **IntelliBank** | IB-EL-EmpowerLabs | | **SubBank** | PB-EL-Project-Bank / PB-HiOrg-Hyperintelligent Org | | **Owner** | Victor Heredia | | **Sponsor** | Victor Heredia | | **Runners** | Sherpa Guide certificado (Victor en cliente cero · Jesús/Gustavo certificados a partir de v02) | | **Versión** | v01 | | **Fecha de creación** | 2026-04-25 | | **Última actualización** | 2026-04-25 | | **Estado** | Activo — v01 firme tras D-014 | | **Documentos padre** | CP-HIORGS-Producto-Estrategia-v01 + CP-HIORGS-Producto-Catalogo-v01 | | **Documentos hermanos** | MPB-HIORGS-Lab40-Playbook-v01 (a producir), CP-HIORGS-Solucion-Arquitectura-v01 | | **Continúa desde** | D-014 cerrada en MIN-HIORGS-RoomProductizacion-v01 + tier pricing #3+ ratificado 2026-04-25 | | **Tags** | [masterplaybook, replicacion, post-Lab, Modelo-A, Modelo-B, Train-the-Trainers, EmpowerTeamsX, certificacion-ecosistema, Sherpa-Guide, gate-auditoria] | --- ## 0. Propósito de este playbook Este MasterPlaybook existe para resolver una pregunta operativa concreta: > *Cuando el Lab del equipo #1 cerró estable y el cliente quiere "más" — más equipos, más asientos, más áreas activadas — ¿qué pasos exactos sigue el Sherpa Guide, qué pasa con EL central, qué pricing aplica, qué se certifica, y qué pasa cuando el cliente quiere correr Labs por sí solo?* Es el playbook que se ejecuta una vez que el cliente está en M3+ del Acompañamiento (SKU 2.1) y ha solicitado expansión interna (SKUs 1.2, 1.3, 1.4 del catálogo). Cubre dos modelos de replicación canónicos derivados de D-014: - **Modelo A — EL facilita los Labs subsiguientes.** Equipo #2 al 50–60% del Lab inicial · equipos #3+ al 30–40%. - **Modelo B — Train-the-Trainers.** El cliente certifica facilitadores internos bajo gate de certificación EL del ecosistema instalado. Y la frontera entre ambos: cuándo se queda con A, cuándo se mueve a B, y cómo se vive la "Red de EmpowerTeamsX" (D-014) — la fase post-Lab donde el cliente ya no es "implementación" sino "ecosistema operando con vida propia". --- ## 1. Conceptos canónicos del playbook ### 1.1 ¿Qué es la Red de EmpowerTeamsX? Es la fase del cliente en la que el SO-HiORG ya no se está instalando — está instalado y replicándose. Cada equipo dentro del cliente que tiene el ecosistema operando es un nodo activo. Conectados, son la **Red de EmpowerTeamsX** del cliente: el modo de operar instalado, vivo, replicándose con cadencia propia. El nombre se canonizó en T-1 (2026-04-25) como continuidad con el legado EmpowerTeams + sufijo X. La metáfora cliente-facing se mantiene **abierta** — los equipos pueden manifestarse como factorías, células, proyectos, o cualquier otra forma operativa que el cliente identifique. El playbook no fija una sola forma de "qué es un EmpowerTeamX en operación". ### 1.2 ¿Cuándo deja un cliente de ser "implementación" para ser "Red"? Cuando se cumplen las **3 condiciones de Red activa**: 1. ≥ 1 Lab cerrado con rúbrica firmada. 2. Ecosistema instalado en M3+ del Acompañamiento (SKU 2.1) con telemetría estable. 3. ≥ 1 conversación de expansión iniciada (decisión Modelo A o Modelo B sobre el equipo #2). Antes de eso → cliente en "Implementación · Lab #1". Después → cliente en "Red en formación". ### 1.3 ¿Qué cambia con la Red activa? - El Sherpa Guide cambia de "facilitador del Lab" a "guía de la Red" — rol de evolución del ecosistema, no de instalación. - EL central interviene menos en la operación diaria del ecosistema · más en cadencias estratégicas (auditorías · re-certificaciones · evolución de método). - El cliente entra al ritmo de **expansión interna como motor de crecimiento** del ecosistema (Capa 3 del pricing). --- ## 2. Modelo A — EL facilita los Labs subsiguientes ### 2.1 Cuándo aplicar Modelo A - Cliente con SO-HiORG instalado y estable en equipo #1 (M3+ Acompañamiento). - Cliente que **NO** quiere o **NO** puede sostener facilitadores internos certificados (capacidad operativa limitada · prefiere outsourcing del método · sin recursos para invertir en Modelo B). - Cliente con horizonte de 1-3 equipos adicionales en los próximos 12-24 meses (no escala masiva). - Tier económico: el cliente prefiere pagar Lab por Lab que invertir en programa de certificación. ### 2.2 Roles en Modelo A | Rol | Responsabilidad | Quién | |---|---|---| | Sherpa Guide responsable | Conduce el Lab del equipo nuevo | Mismo Sherpa Guide del equipo #1 (continuidad) o Sherpa Guide certificado del pool EL | | Detonador | Conduce Fase 0 del equipo nuevo (scoping del proyecto, autorización IT, alineación con CIO/CEO) | Detonador EL · puede ser el mismo Sherpa Guide en doble rol | | Account Lead del cliente | Mantiene relación general post-Lab del equipo #1 | Account Lead del cliente (SKU 2.1) | | Sponsor del equipo nuevo (en el cliente) | Líder operativo del equipo nuevo · habilita acceso · valida proyecto vivo | Persona del cliente — debe cumplir criterios T-5 sobre el equipo nuevo | | Comprador (en el cliente) | Aprueba Lab del equipo nuevo · firma | CIO/CEO/dueño · mismo o nuevo según política del cliente | ### 2.3 Pasos del Modelo A — equipo #2 **Paso 1 — Conversación de expansión (M3-M6 del cliente · 2-4 semanas)** Dispara: cliente o Account Lead identifica equipo + proyecto candidato. Sherpa Guide o Detonador inicia conversación de scoping. Acciones: - Validar las 3 condiciones T-5 sobre el equipo nuevo (criterios CP-Estrategia §2.1). - Identificar y validar el proyecto vivo del equipo nuevo (horizonte 3-12 meses). - Validar autoridad del Sponsor del equipo nuevo y línea de aprobación del comprador. - Decisión Go/No-Go preliminar. Salida: brief de scoping del equipo #2 + propuesta comercial con pricing 50–60% del Lab inicial. **Paso 2 — Ratificación de pricing (1 semana)** Sherpa Guide propone rango 50% vs 60% basado en complejidad del proyecto del equipo nuevo (criterios de ajuste en CP-Catálogo §6.2). Victor ratifica. Salida: pricing firme + términos de pago + contrato del Lab equipo #2 firmado. **Paso 3 — Lab equipo #2 (40 días)** Ejecutado con MPB-Lab40-Playbook (a producir), con dos diferencias respecto al Lab #1: - **Reutilización del Corp-Brain-OS instalado.** No se construye uno nuevo — se extiende. Onboarding del equipo nuevo aprovecha estructura existente. - **WORX patrones reutilizados con adaptaciones.** El Sherpa Guide identifica qué patrones del equipo #1 aplican y cuáles requieren adaptación al equipo nuevo. Salida: rúbrica de calidad firmada del equipo #2 + ecosistema integrado con el del equipo #1 + telemetría agregada. **Paso 4 — Acompañamiento M1-M12 del equipo #2 (12 meses)** Se incorpora bajo el SKU 2.1 del cliente (subscription se ajusta para reflejar el equipo nuevo). Account Lead del cliente lo absorbe sin rompimiento de cadencia. ### 2.4 Pasos del Modelo A — equipos #3, #4, #N Iguales a equipo #2 con tres diferencias: 1. **Pricing 30–40% del Lab inicial** (no 50–60%) — ratificado @Victor 2026-04-25. 2. **Curva de aprendizaje madura del Sherpa Guide en este cliente** — Lab puede acortarse a 30 días si scoping muestra integración rápida (decisión Sherpa Guide + Victor). 3. **Conversación obligatoria sobre Modelo B a partir del equipo #4.** No es opcional. Si el cliente está en cola de equipos #4+, Sherpa Guide y Account Lead deben presentar formalmente la opción Modelo B antes de cerrar el contrato del equipo #4. ### 2.5 Kill criteria de Modelo A Detener Modelo A y derivar a otra ruta si: - Equipo nuevo NO cumple las 3 condiciones T-5 → derivar a Piloto Accidental (SKU 0.2) o no-venta. - Cliente quiere ritmo de Labs más rápido del que EL puede sostener (≥ 4-6 Labs/año concurrentes en el mismo cliente) → conversación obligatoria de Modelo B. - Sherpa Guide identifica resistencia operativa del nuevo equipo en scoping → plan de detonación correctivo o no-Lab hasta resolver resistencia. --- ## 3. Modelo B — Train-the-Trainers ### 3.1 Cuándo aplicar Modelo B - Cliente con ≥ 2 Labs cerrados bajo Modelo A y ecosistema estable. - Cliente con **pipeline interno de equipos #4+ que justifique inversión en certificación** (típicamente clientes grandes con muchas divisiones, o clientes con visión de 2+ años de expansión). - Cliente con **cuerpo operativo capaz de sostener facilitadores internos** (típicamente requiere 3-6 personas dedicables, área de transformación o área operativa con presupuesto formativo). - Cliente que ve valor en **convertir el método en capacidad propia**, no solo en consumirlo de EL. ### 3.2 La promesa de Modelo B (cliente-facing) > *"En lugar de pagarnos cada Lab, instalamos en tu organización la capacidad de correr Labs propios. Te certificamos facilitadores internos, certificamos tu ecosistema, y entras a la Red de EmpowerTeamsX como nodo certificado: con métodos puestos a punto y resultados que respaldamos."* ### 3.3 Componentes del programa Modelo B 1. **Currículum de certificación de facilitadores internos** (6-12 semanas). 2. **Auditoría EL del ecosistema instalado** (gate obligatorio · SKU 1.5). 3. **Acompañamiento del primer Lab corrido por facilitadores certificados** (tutela · Sherpa Guide EL en sombra · 40 días). 4. **Re-certificación anual obligatoria** (auditoría EL anual · SKU 1.5). 5. **Acceso a actualizaciones del método y comunidad de Sherpa Guides certificados** (canal cerrado). ### 3.4 Pasos del Modelo B **Paso 0 — Conversación de elegibilidad (1-2 semanas)** - Account Lead + Victor evalúan elegibilidad del cliente: - ≥ 2 Labs Modelo A cerrados · estabilidad operativa M3+ ambos. - Pipeline interno de equipos · justificación económica. - Capacidad operativa para sostener facilitadores. - Voluntad del CIO/CEO de invertir en programa. Salida: Go/No-Go elegibilidad + propuesta comercial Modelo B con fees (certificación + auditoría inicial + acompañamiento + re-certificación anual). **Paso 1 — Auditoría EL del ecosistema instalado (gate · 1-2 semanas)** Ejecutado por Sherpa Guide senior + Victor o delegado. Cubre: - **Salud de las 3 capas instaladas en el cliente** (Corp-Brain-OS · WORX · SherpaX). - **Evidencia de adopción real** del equipo #1 y equipo #2 (no demo · no piloto). - **Telemetría operativa** disponible y en patrón. - **Documentación interna del cliente** sobre cómo opera con el ecosistema. Salida: reporte canónico de salud + decisión PASS / PASS-CON-REMEDIACIÓN / FAIL. - **PASS** → continúa al Paso 2. - **PASS-con-remediación** → cliente ejecuta plan de remediación (60-90 días) → re-auditoría → si pasa, continúa. - **FAIL** → no se activa Modelo B. Cliente se mantiene en Modelo A. Conversación honesta con el cliente sobre por qué. **Si el cliente intenta saltarse el gate** → respuesta canónica: el gate es la integridad del producto. Sin auditoría, no hay certificación. Sin certificación EL del ecosistema, el cliente no puede ostentar "ejecución certificada SO-HiORG" y EL no responde por resultados de los Labs corridos por sus facilitadores. **Paso 2 — Programa de certificación de facilitadores (6-12 semanas)** Cohorte 3-6 personas del cliente. Currículum cubre: - Filosofía + 5 capas problema + 3 pilares + 3 fases del SO-HiORG. - Método del Lab de 40 días (basado en MPB-Lab40-Playbook). - Detonación · scoping · arranque sobre proyectos vivos. - Operación del Corp-Brain-OS · evolución · troubleshooting. - Operación de WORX · adaptación a equipos diversos. - Operación de SherpaX · onboarding · evolución. - Rúbricas de calidad · criterios de detención · cadencias post-Lab. - Auditoría interna del ecosistema (anticipo de re-certificación anual). Modalidad: combinación de talleres EL + estudio de casos + sombra del Sherpa Guide EL en cadencias del cliente + ejercicios sobre proyectos del cliente. Evaluación final: rúbrica de certificación firmada por equipo EL. Salida: facilitadores internos certificados (registro EL). **Paso 3 — Primer Lab corrido por facilitadores certificados (tutela · 40 días)** El primer Lab que el cliente ejecuta con sus facilitadores certificados se corre **bajo tutela EL**: - Sherpa Guide EL presente en cadencias clave (kick-off · revisión semanal · cierre). - Sherpa Guide EL en sombra del Sherpa Guide del cliente (no interviene salvo desviación crítica). - Rúbrica de calidad firmada por **ambos** Sherpa Guides al cierre. Si el primer Lab tutorado pasa la rúbrica → Modelo B activo. Cliente entra a la Red de EmpowerTeamsX como nodo certificado. Si NO pasa la rúbrica → plan de remediación + segundo Lab tutorado. Si falla dos Labs tutorados → revocación de certificación · cliente vuelve a Modelo A. **Paso 4 — Operación Modelo B en régimen (steady state)** Cliente corre Labs internos por sí solo. Cadencias EL: - **Auditoría EL anual del ecosistema** (re-certificación · SKU 1.5). - **Comunidad de Sherpa Guides certificados** — canal cerrado, evolución del método, intercambio de aprendizajes. - **Cadencia trimestral de check-in operativo** (1 hora · revisión de telemetría agregada · señales tempranas de dilución). - **Acceso a actualizaciones del método** (versiones nuevas de WORX · evolución de SherpaX · evolución del Corp-Brain-OS). ### 3.5 Re-certificación anual Al cumplirse 12 meses de Modelo B activo: 1. Auditoría EL del ecosistema (SKU 1.5). 2. Evaluación operativa de los facilitadores certificados (los Labs que corrieron · rúbricas · resultados). 3. Renovación de acceso a método y comunidad. Si la re-certificación falla → plan de remediación 60-90 días → re-auditoría. Sin remediación → revocación de certificación. ### 3.6 Kill criteria de Modelo B - Auditoría inicial FAIL → Modelo B no se activa. - Dos Labs tutorados fallidos consecutivos → revocación de certificación · cliente vuelve a Modelo A. - Telemetría agregada del cliente muestra dilución sistémica (adopción cayendo · WORX desviado · SherpaX abandonado) → conversación correctiva + plan de remediación. - Cliente no re-certifica anualmente → revocación. ### 3.7 Calibración económica Modelo B Pricing del Modelo B se calibra para que **el cliente NO encuentre arbitraje barato contra Modelo A en horizonte 24 meses**. Lo correcto: si el cliente proyecta ≥ 4-6 Labs en 24 meses, Modelo B es más eficiente que pagar 4-6 veces el descuento Modelo A. Si proyecta menos, Modelo A es más eficiente. Esto evita que un cliente con 2-3 equipos en pipeline elija Modelo B "para ahorrarse" — Modelo B no es más barato, es **diferente**: convierte el método en capacidad interna, lo que tiene valor estructural distinto. --- ## 4. Auditoría EL del ecosistema instalado (SKU 1.5 · gate y recurrencia) ### 4.1 Función dual de la auditoría - **Gate inicial Modelo B** — sin esto no se activa el tier Train-the-Trainers. - **Re-certificación anual Modelo B** — gate de renovación. - **Sello de salud opcional Modelo A** — clientes que quieren un check anual aunque no estén en Modelo B. ### 4.2 Componentes de la auditoría (1-2 semanas) **Componente 1 — Salud técnica de las 3 capas (3-5 días)** - **Corp-Brain-OS:** crecimiento de XDocs · cobertura de fuentes vivas · queries/mes · hit rate · latencia · drift de calidad de respuestas · estado del sistema de retroalimentación. - **WORX:** procesos del equipo en patrón vs. procesos identificados · evolución de los patrones desde el Lab · cadencias activas vs. abandonadas. - **SherpaX:** seats activos / contratados · tasa de uso real · tareas ejecutadas/mes · NPS interno · drift en uso esperado vs. real. **Componente 2 — Adopción operativa (2-3 días)** - Entrevistas con miembros del equipo (sample del equipo #1 + #2) — uso real, no declarativo. - Observación de cadencias internas del cliente — se siguen los rituales del WORX o degeneraron. - Revisión de conversaciones agregadas con SherpaX (con consentimiento cliente) — patrones de uso real. **Componente 3 — Documentación y método (1-2 días)** - ¿El cliente tiene su propio playbook de operación con el ecosistema o depende de EL para todo? - ¿Hay documentación interna de procesos del WORX adaptados al cliente? - ¿Los facilitadores certificados (si Modelo B) tienen rúbricas claras? **Componente 4 — Reporte y decisión (1-2 días)** - Reporte canónico de salud (formato fijo · plantilla EL). - Recomendaciones de remediación priorizadas (si aplica). - Decisión PASS / PASS-CON-REMEDIACIÓN / FAIL. - Sello de certificación si pasa (válido 12 meses). ### 4.3 Quién ejecuta la auditoría - **Senior Sherpa Guide EL** (no el mismo del Lab original — independencia para detectar dilución). - **Victor o delegado senior** firma el reporte final. - Apoyo opcional de Implementation Lead para Componente 1 (parte técnica). --- ## 5. Rol del Sherpa Guide post-certificación Una vez el cliente está en Red activa (con o sin Modelo B), el Sherpa Guide EL cambia de modo: ### 5.1 Modo "guía de la Red" vs. modo "facilitador del Lab" | Dimensión | Facilitador del Lab (M0) | Guía de la Red (M3+) | |---|---|---| | Foco temporal | 40 días intensos | 12 meses ambientales | | Frecuencia de presencia | Diaria | Cadencias semanales/quincenales | | Tipo de intervención | Instalación · scoping · capacitación | Evolución · troubleshooting · revisión | | Relación con equipos del cliente | Operativa directa | Estratégica + soporte selectivo | | Métricas que sigue | Avance del Lab · rúbrica al final | Salud agregada del ecosistema · expansión · NPS | | Decisiones que toma | Operativas del Lab | De evolución del ecosistema · escalamiento a Victor | ### 5.2 Responsabilidades del Sherpa Guide en Red activa - **Cadencias regulares con el cliente** (mensual M1-M3, trimestral M4+). - **Revisión de telemetría agregada** y detección temprana de degradación. - **Conversaciones de expansión** cuando el cliente identifica equipo + proyecto candidato (Modelo A) o cuando el cliente cumple criterios de elegibilidad para Modelo B. - **Tutela del primer Lab Modelo B** (si aplica) en sombra del Sherpa Guide del cliente. - **Escalamiento a Victor** ante decisiones estructurales: cambios de pricing fuera de rango canónico, casos especiales no previstos, señales de dilución del método, oportunidades de evolución del producto. ### 5.3 Frontera entre Sherpa Guide EL y facilitadores certificados del cliente (Modelo B) Una vez Modelo B activo, los facilitadores certificados del cliente corren los Labs internos. El Sherpa Guide EL **NO interviene** en la operación diaria de esos Labs (eso anularía la promesa de Modelo B). Su intervención post-Modelo B se limita a: - Cadencias de método y comunidad (canal cerrado de Sherpa Guides certificados). - Auditoría anual de re-certificación. - Apoyo en escalamientos críticos (dilución detectada · cliente solicita ayuda explícita). --- ## 6. Cadencia operativa de equipos #2 / #3+ ### 6.1 Ritmo recomendado de Labs en Modelo A | Tiempo desde Lab #1 | Equipo concurrente | Cumplido por | |---|---|---| | M0 | Equipo #1 en Lab | Lab inicial · SKU 1.1 | | M3-M6 | Conversación equipo #2 | Sherpa Guide + Account Lead | | M6-M9 | Lab equipo #2 (40 días) | Sherpa Guide · SKU 1.2 | | M9-M12 | Acompañamiento conjunto + conversación equipo #3 | SKU 2.1 ajustado | | M12-M15 | Lab equipo #3 (40 o 30 días) | Sherpa Guide · SKU 1.3 | | M15+ | Conversación obligatoria Modelo B (si pipeline justifica) | Account Lead + Victor | Este es ritmo recomendado, no obligatorio. Cliente puede pausar entre Labs si el ecosistema necesita estabilizarse o si la operación demanda ritmo más lento. Ritmo más rápido (≥ 2 Labs concurrentes) requiere conversación de capacidad EL. ### 6.2 Capacidad EL para Modelo A concurrente - 1 Sherpa Guide certificado puede sostener: 1 Lab activo + 2-3 Acompañamientos M1-M12 simultáneamente. - A partir de 2 Labs concurrentes en el mismo cliente → 2 Sherpa Guides asignados (uno por Lab) + Account Lead común. - Si cliente solicita ≥ 3 Labs concurrentes → conversación obligatoria de Modelo B. ### 6.3 Decisión Modelo A vs Modelo B en el horizonte 24 meses Regla canónica: **a partir del equipo #4, conversación obligatoria sobre Modelo B con el cliente**. La decisión final es del cliente, pero EL la presenta formalmente. Heurística: - 1-3 equipos en horizonte 24 meses → Modelo A (eficiente · sin sobrecosto de certificación). - 4-6 equipos en horizonte 24 meses → Modelo B (eficiente · convierte método en capacidad interna). - ≥ 7 equipos en horizonte 24 meses → Modelo B obligatorio para sostener calidad sin saturar capacidad EL. --- ## 7. Riesgos canónicos del playbook y mitigaciones ### 7.1 Riesgo de dilución de método (alto · Modelo B) Mitigación: gate de auditoría EL del ecosistema instalado obligatorio · re-certificación anual · revocación si falla · telemetría agregada compartida con EL · canal cerrado de Sherpa Guides certificados con cadencias regulares. ### 7.2 Riesgo de "cliente eterno en Modelo A" (medio) Cliente con muchos equipos que prefiere Modelo A indefinidamente → satura capacidad EL · canibaliza tiempo de instalación de clientes nuevos. Mitigación: regla canónica de conversación obligatoria Modelo B a partir del equipo #4 · cap de capacidad por cliente acordado en contrato (≤ 3 Labs concurrentes salvo Modelo B). ### 7.3 Riesgo de canibalización entre Sherpa Guides EL y facilitadores certificados (medio · Modelo B post) Si EL sigue interviniendo operativamente en Labs post-Modelo B → la promesa de Modelo B se rompe (cliente paga certificación pero sigue dependiendo de EL). Mitigación: frontera operativa explícita en §5.3 · cláusula contractual. ### 7.4 Riesgo de drift en pricing por casos especiales (bajo-medio) Si los rangos 50–60% / 30–40% se estiran caso por caso → catálogo deja de ser referencia. Mitigación: ajustes a la baja requieren aprobación Victor · si el patrón se repite ≥ 3 veces, propuesta de canonización en CP-Catálogo v02. ### 7.5 Riesgo de auditoría laxa (alto · Modelo B) Si la auditoría EL pasa clientes que no merecen pasar → la certificación deja de tener valor estructural. Mitigación: senior Sherpa Guide independiente del Lab original · firma de Victor o delegado · plantilla canónica · criterios duros · derecho de FAIL claro. --- ## 8. Métricas de éxito de la replicación ### 8.1 Métricas por cliente (vista cliente) - Tiempo M0 → equipo #2 activado (objetivo: M6-M9). - Equipos activos / equipos en pipeline (vista vivencial del cliente). - Salud agregada del ecosistema (auditoría anual). - NPS de la Red interna del cliente. ### 8.2 Métricas por producto (vista EL) - % de clientes Modelo A que migran a Modelo B en horizonte 24 meses (señal de éxito Modelo B). - % de clientes Modelo B que aprueban re-certificación anual (señal de calidad de certificación). - # de Sherpa Guides certificados externos activos (capacidad EL ampliada). - # de equipos certificados totales en la Red (escala global de la Red de EmpowerTeamsX). - Net Revenue Retention por cliente con Red activa (M12+). ### 8.3 Métricas de salud del playbook - # de revocaciones de certificación / año (señal de drift · debería ser bajo pero ≥ 0 — cero indica auditoría laxa). - # de Labs tutorados fallidos en primer intento (señal de calidad del programa de certificación). - Tiempo promedio de auditoría inicial (debería estabilizarse en 7-10 días). --- ## 9. Casos canónicos de uso de este playbook **Caso A — Cliente Posta-rename con SO-HiORG instalado en equipo de Operaciones:** - M3+ post-Lab → conversación equipo #2 (área comercial) → Modelo A 50–60% del Lab inicial → Lab equipo #2 corrido por mismo Sherpa Guide → ecosistema integrado. - M9+ → conversación equipo #3 (área de servicio al cliente) → Modelo A 30–40%. - M15+ → conversación Modelo B si proyectan equipos #4-#6 en próximos 12 meses. **Caso B — Cliente BioPappel con SO-HiORG instalado y visión de transformación operativa amplia:** - M3+ post-Lab → equipo #2 Modelo A. - M9+ → equipo #3 Modelo A + conversación elegibilidad Modelo B. - M12+ → si elegibilidad PASS y cliente acepta → activación Modelo B + cohorte de 4 facilitadores certificados. - M18+ → primer Lab tutorado por facilitadores del cliente. - M24+ → cliente en Modelo B en régimen · re-certificación al M24+12. **Caso C — Cliente que solicita Modelo B prematuro (M3-M6 post-Lab #1):** - Respuesta canónica: NO. Modelo B requiere ≥ 2 Labs cerrados Modelo A. La auditoría no puede certificar lo que aún no se demostró replicable. - Conversación honesta: "Hagamos primero equipo #2 en Modelo A. Si la replicación funciona, conversamos Modelo B al cierre del equipo #2." **Caso D — Cliente con auditoría FAIL:** - Reporte detallado de qué falla y por qué. - Plan de remediación 60-90 días con apoyo de Sherpa Guide EL. - Re-auditoría tras remediación. - Si re-auditoría también FAIL → no Modelo B · cliente sigue en Modelo A · conversación franca sobre causas estructurales. --- ## 10. Cierre Este MasterPlaybook queda firme en v01 al cierre del bloque tripleta (CP-Estrategia + CP-Catálogo + MPB-Replicación) con VoBo de Victor. Próxima revisión esperada: tras el primer cliente que llegue al Modelo B en régimen (proyección 2027-2028) o tras 2-3 ejecuciones exitosas de Modelo A con equipos #2-#3 que permitan refinar capacidades de EL y rangos de pricing. **Documentos relacionados que destraba este playbook al cerrarse:** - MPB-HIORGS-Lab40-Playbook-v01 (próxima pieza canónica) — usa este playbook como referencia para los Labs subsiguientes Modelo A. - PLAN-HIORGS-Productizacion-Sprint-v01 — plan de 3-6 semanas que incluye las primeras certificaciones de Sherpa Guide EL internos (Jesús/Gustavo). - CAS-EL-LabPraxis-ArquitecturaProducto-v01 — captura del aprendizaje del room (D-012/013/014 + tensiones T-1 a T-5). --- *MPB-HIORGS-Replicacion-Playbook-v01 · IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-HiOrg-Hyperintelligent Org/ · 2026-04-25* *MasterPlaybook de Replicación post-Lab del SO-HiORG. Cristaliza D-014 (dos modelos Modelo A · Modelo B) + tier pricing #3+ ratificado @Victor 2026-04-25. Sigue MePB-XX-MasterPlaybook-Schema-v01.*