# PLAN — Tipo de Documento (Plan de Fases)

**Type:** Document Type / Naming Convention
**Domain:** Information Architecture / Project Governance
**Source:** [[Raw/IB-XX-Maestro/IPI-XX-IP-Infraestructura/IPI-XX-BMF-Engine/ARQ-XX-BMF-NamingConvention-v01]]
**Last Updated:** 2026-04-14
**Status:** Active (introduced 2026-04-14 by Victor Heredia)

## Summary
PLAN es una categoría de documento que captura la ejecución secuenciada de un proyecto, implementación o transformación. Tiene owners, entregables por fase, métricas de éxito, timeline y dependencias. Es un documento vivo que se actualiza durante la ejecución. Reemplaza al prefijo provisional FASE- (deprecado 2026-04-14).

## Cuándo usar PLAN

- Plan de implementación de un producto/modelo en un cliente
- Plan de arranque de un proyecto interno con fases secuenciadas
- Roadmap de transformación organizacional con hitos y owners
- Cualquier documento que amarra la ejecución de algo complejo en múltiples fases

## Diferenciación vs. otros prefijos

| Prefijo | Propósito | Relación con PLAN |
|---------|-----------|-------------------|
| **PLB** (Plantilla / PlayBook genérico) | Estructura reusable sin contexto específico | Un PLAN instancia una PLB. La PLB es la receta; el PLAN es la cena del cliente específico. |
| **MePB** (MetaPlaybook) | Codifica metodología canónica replicable | Un PLAN aplica una MePB a un caso concreto. La MePB es la doctrina; el PLAN es la campaña. |
| **SOP** (Standard Operating Procedure) | Protocolo paso a paso para tarea repetible | Un SOP se ejecuta cada vez igual; un PLAN se despliega una sola vez con aprendizajes. |
| **TP** (Transfer Packet) | Empaqueta contexto para transferir | Un TP da continuidad; un PLAN da ejecución. |
| **CP** (Control Panel) | Dashboard de estado operativo | Un CP monitorea; un PLAN dirige. |
| **CAS** (Caso de estudio) | Documenta proyecto ya completado | Un PLAN precede al CAS. El PLAN se ejecuta, el CAS lo capitaliza. |

## Estructura canónica de un PLAN

Todo documento PLAN debe contener:

1. **Header con metadatos** — Asset ID, tipo, versión, status, owner, dependencias
2. **Propósito del documento** — qué amarra, quién lo lee, para qué
3. **Estado actual** — foto del punto de partida (infraestructura, equipo, recursos)
4. **Arquitectura de fases** — tabla resumen con duración y entregable principal por fase
5. **Detalle de cada fase** — objetivo, plan día a día/semana a semana, owners, entregables
6. **Métricas de éxito** — duras (medibles) y blandas (cualitativas)
7. **Gobernanza del documento** — cadencia de actualización, responsable, ubicación
8. **Documentos relacionados** — fuentes primarias, herramientas operativas, outputs
9. **Registro de decisiones** — decisiones tomadas durante el diseño + preguntas abiertas

## Ejemplos canónicos

- `PLAN-EL-HiOrg-ImplementacionEmpowerLabs-v01.md` — Primer PLAN del ecosistema (2026-04-14)

## Migración desde FASE-

Documentos que usaban el prefijo provisional FASE- deben migrarse a PLAN-:

```
FASE-PlaybooksInteligentes → PLAN-XX-PlaybooksInteligentes
```

La migración incluye:
1. Renombrar archivo
2. Actualizar Asset ID en header
3. Actualizar referencias en otros documentos
4. Registrar en CP-XX-IntelliBanks-Registry

## Relationships

- Implements: [[Naming-Convention]]
- Governed by: [[4-Clases-Documentos]] (PLAN pertenece a Clase O — Operativo)
- Related to: [[MetaPlaybooks]], [[IntelliBanks]]
- Owner: [[Victor-Heredia]]

## Open Questions / Gaps

- ¿Qué sucede con un PLAN al completarse? Opciones: (a) archivar como CAS, (b) mantener como referencia histórica, (c) generar versión v-final. Pendiente de definir.
- ¿Cuándo un PLAN genera un SOP replicable? El aprendizaje del PLAN puede codificarse como SOP para ejecuciones futuras.
- Enforcement automático de la estructura canónica (linter) pendiente.