Políticas, procesos y documentación interna

Los procesos no documentados existen solo en la cabeza de alguien—y se van cuando esa persona se va. La IA te ayuda a capturar y estandarizar conocimiento crítico.

Por qué documentar procesos

Sin documentación	Con documentación
Cada quien hace diferente	Consistencia garantizada
Dependencia de personas	Conocimiento transferible
Errores variables	Errores prevenibles
Difícil de escalar	Listo para crecer
Training lento	Onboarding rápido

Tipos de documentación operacional

Tipo	Propósito	Longitud
SOP	Paso a paso para ejecutar	1-5 páginas
Política	Reglas y lineamientos	1-2 páginas
Checklist	Verificación rápida	1 página
Playbook	Guía completa de área	10+ páginas
Runbook	Respuesta a incidentes	Variable

Crear SOPs efectivos

Template de SOP:

Crea un SOP (Standard Operating Procedure) para:

PROCESO: [Nombre del proceso]
ÁREA: [Departamento]
FRECUENCIA: [Diario/semanal/según demanda]
DUEÑO DEL PROCESO: [Rol responsable]

ESTRUCTURA DEL SOP:

1. ENCABEZADO
   - Título del SOP
   - Versión y fecha
   - Dueño/autor
   - Última revisión

2. PROPÓSITO
   - ¿Por qué existe este proceso?
   - ¿Qué resultado produce?
   - ¿Por qué importa hacerlo correctamente?

3. ALCANCE
   - ¿A quién aplica?
   - ¿Qué situaciones cubre?
   - ¿Qué NO cubre este SOP?

4. PRERREQUISITOS
   - Accesos necesarios
   - Información requerida
   - Aprobaciones previas

5. PROCEDIMIENTO PASO A PASO

   5.1 [FASE 1: Nombre]

   Paso 1: [Acción específica]
   - Descripción detallada
   - Herramienta: [Sistema/app]
   - Tiempo estimado: [X min]
   - Output esperado: [Qué produces]

   Paso 2: [Acción]
   [Misma estructura]

   ⚠️ PUNTO DE DECISIÓN:
   - Si [condición A]: Ir a paso X
   - Si [condición B]: Ir a paso Y

   5.2 [FASE 2: Nombre]
   [Continuar...]

6. VERIFICACIÓN
   - ¿Cómo sabes que lo hiciste bien?
   - Checklist de calidad
   - Métricas de éxito

7. TROUBLESHOOTING
   | Problema | Causa probable | Solución |
   |----------|---------------|----------|

8. EXCEPCIONES
   - Casos especiales
   - A quién escalar
   - Cómo documentar excepciones

9. DOCUMENTOS RELACIONADOS
   - Links a otros SOPs
   - Templates necesarios
   - Sistemas involucrados

10. HISTORIAL DE CAMBIOS
    | Fecha | Versión | Cambio | Autor |

Convertir conocimiento tácito en SOP:

Un experto me describió este proceso informalmente:

"[Descripción informal del experto]"

Convierte esto en un SOP formal que:
1. Capture todos los pasos implícitos
2. Explicite las decisiones que toma automáticamente
3. Documente el "por qué" de cada paso
4. Identifique puntos de decisión
5. Agregue verificaciones de calidad
6. Incluya troubleshooting común

Pregunta lo que necesites clarificar para que el SOP
sea completo y usable por alguien nuevo.

Checklists operacionales

Crear checklist:

Crea un checklist para:

TAREA: [Nombre de la tarea]
FRECUENCIA: [Cuándo se usa]
USUARIO: [Quién lo usará]

FORMATO:

[ ] Paso 1 - [Acción]
    ├─ Detalles: [Info adicional si necesaria]
    └─ Verificación: [Cómo saber que está correcto]

[ ] Paso 2 - [Acción]
    [Igual...]

[ ] ⚠️ CRÍTICO: [Paso que no se puede saltar]

[ ] Paso final - [Acción]

VERIFICACIÓN FINAL:
[ ] [Pregunta de validación 1]
[ ] [Pregunta de validación 2]

FIRMA/COMPLETADO:
Fecha: ___________
Ejecutado por: ___________
Revisado por: ___________

El checklist debe caber en 1 página para ser práctico.

Checklist de cierre (diario/mensual):

Crea un checklist de cierre de [período]:

CONTEXTO:
- Área: [Departamento]
- Frecuencia: [Diario/semanal/mensual]
- Responsable: [Rol]

CHECKLIST DE CIERRE [PERÍODO]:

TAREAS OPERATIVAS:
[ ] [Tarea 1]
[ ] [Tarea 2]
[ ] [Tarea 3]

VALIDACIONES:
[ ] [Verificación 1]
[ ] [Verificación 2]

REPORTES:
[ ] [Reporte 1] enviado a [destinatario]
[ ] [Reporte 2] actualizado

PREPARACIÓN PARA SIGUIENTE PERÍODO:
[ ] [Tarea de preparación 1]
[ ] [Tarea de preparación 2]

ESCALACIONES PENDIENTES:
[ ] Ninguna / [ ] Lista:

NOTAS:
_______________________

Completado: [fecha/hora]
Por: [nombre]

Playbooks de área

Estructura de playbook:

Crea la estructura de un playbook para el área de [área]:

PROPÓSITO:
Documento completo de referencia para el equipo de [área]

AUDIENCIA:
- Nuevos miembros del equipo
- Miembros existentes (referencia)
- Áreas relacionadas

ESTRUCTURA SUGERIDA:

PARTE 1: INTRODUCCIÓN AL ÁREA
1.1 Misión y objetivos del área
1.2 Estructura del equipo
1.3 KPIs y métricas clave
1.4 Stakeholders principales

PARTE 2: PROCESOS CORE
2.1 [Proceso principal 1]
    - Overview
    - SOP detallado
    - Templates
2.2 [Proceso principal 2]
    [Igual...]
2.3 [Proceso principal 3]

PARTE 3: HERRAMIENTAS Y SISTEMAS
3.1 Stack tecnológico
3.2 Guías por herramienta
3.3 Accesos y permisos

PARTE 4: COMUNICACIÓN
4.1 Canales y cuándo usarlos
4.2 Reuniones recurrentes
4.3 Reportes y frecuencia
4.4 Escalaciones

PARTE 5: TROUBLESHOOTING
5.1 Problemas comunes
5.2 Árbol de decisiones
5.3 Contactos de escalación

PARTE 6: RECURSOS
6.1 FAQ
6.2 Glosario
6.3 Links útiles
6.4 Historial de cambios

Para cada sección, indica:
- Quién debería escribir el contenido
- Prioridad (crítico/importante/nice to have)
- Frecuencia de actualización

Runbooks para incidentes

Template de runbook:

Crea un runbook para responder a:

INCIDENTE: [Tipo de incidente]
SEVERIDAD: [Crítico/Alto/Medio/Bajo]
TIEMPO DE RESPUESTA ESPERADO: [X minutos/horas]

RUNBOOK:

1. DETECCIÓN
   - ¿Cómo sabemos que ocurrió?
   - Alertas automáticas: [Lista]
   - Síntomas visibles: [Lista]

2. EVALUACIÓN INICIAL (primeros 5 min)
   [ ] Confirmar el incidente
   [ ] Evaluar impacto (usuarios afectados)
   [ ] Clasificar severidad
   [ ] Notificar a: [Lista de personas/canales]

3. DIAGNÓSTICO
   [ ] Verificar [sistema 1]: [cómo]
   [ ] Verificar [sistema 2]: [cómo]
   [ ] Revisar logs: [dónde]
   [ ] Identificar causa probable

4. RESOLUCIÓN

   SI es [Causa A]:
   [ ] Paso 1: [acción]
   [ ] Paso 2: [acción]
   [ ] Verificar: [cómo]

   SI es [Causa B]:
   [ ] Paso 1: [acción]
   [ ] Paso 2: [acción]
   [ ] Verificar: [cómo]

5. COMUNICACIÓN DURANTE INCIDENTE
   - Status page: [link]
   - Canal de updates: [canal]
   - Template de comunicación: [incluir]
   - Frecuencia de updates: [cada X min]

6. POST-RESOLUCIÓN
   [ ] Confirmar que todo funciona
   [ ] Comunicar resolución
   [ ] Documentar qué pasó y qué se hizo
   [ ] Programar postmortem si aplica

7. ESCALACIÓN
   Si no se resuelve en [X tiempo]:
   - Escalar a: [persona/equipo]
   - Contacto: [info]
   - Contexto a proporcionar: [lista]

8. POSTMORTEM (si aplica)
   Template a usar: [link]
   Deadline: [X días después del incidente]

Documentar decisiones

Template de ADR (Architecture Decision Record):

Documenta esta decisión para referencia futura:

DECISIÓN: [Qué se decidió]
FECHA: [Cuándo]
PARTICIPANTES: [Quiénes]

ADR FORMAT:

TÍTULO: [Nombre descriptivo de la decisión]

ESTADO: [Propuesta/Aceptada/Deprecada/Reemplazada]

CONTEXTO:
¿Cuál era la situación? ¿Qué problema teníamos?

OPCIONES CONSIDERADAS:
Opción A: [Descripción]
- Pros: [Lista]
- Cons: [Lista]

Opción B: [Descripción]
- Pros: [Lista]
- Cons: [Lista]

Opción C: [Descripción]
- Pros: [Lista]
- Cons: [Lista]

DECISIÓN:
Elegimos [Opción X] porque [razones principales].

CONSECUENCIAS:
- Positivas: [Lista]
- Negativas: [Lista]
- Riesgos: [Lista]

MÉTRICAS DE ÉXITO:
¿Cómo sabremos si fue buena decisión?

REVISIÓN:
¿Cuándo revisaremos esta decisión?

Mejores prácticas

Para documentación efectiva:

Revisa esta documentación y mejórala:

[Tu documentación actual]

EVALÚA Y MEJORA:

1. CLARIDAD
   - ¿Un nuevo empleado puede seguirla?
   - ¿Hay jerga sin explicar?
   - ¿Los pasos son específicos o vagos?

2. COMPLETITUD
   - ¿Faltan pasos que asumimos obvios?
   - ¿Están las excepciones documentadas?
   - ¿Hay troubleshooting suficiente?

3. USABILIDAD
   - ¿Es fácil de navegar?
   - ¿Está actualizada?
   - ¿El formato es escaneable?

4. MANTENIBILIDAD
   - ¿Es fácil de actualizar?
   - ¿Quién es responsable?
   - ¿Hay versión y fecha?

Sugiere mejoras específicas para cada área.

Ejercicio práctico

Documenta un proceso de tu equipo:

PASO 1: Elige un proceso crítico
[Uno que si alguien se va, se pierde el conocimiento]

PASO 2: Entrevista al experto
- ¿Cómo lo haces?
- ¿Qué errores son comunes?
- ¿Qué decisiones tomas en el camino?

PASO 3: Crea el SOP con IA
[Usa el template]

PASO 4: Valida con el experto
- ¿Falta algo?
- ¿Algo está mal?
- ¿Agregarías tips?

PASO 5: Testea con alguien nuevo
- ¿Puede ejecutar siguiendo el SOP?
- ¿Dónde se atora?
- ¿Qué preguntas tiene?

Puntos clave de esta lección

• Documenta procesos antes de que el experto se vaya
• SOPs efectivos incluyen el "por qué", no solo el "qué"
• Checklists son para verificación, SOPs para aprendizaje
• Actualiza documentación regularmente o se vuelve inútil
• Testea con alguien nuevo para validar completitud

Próximo módulo

En el último módulo aprenderás a crear tu librería personal de prompts—organizar y escalar todo lo aprendido.

---

Quiz de comprensión

1. ¿Cuál es la diferencia entre un SOP y un checklist?
2. ¿Qué debe incluir un runbook de incidentes?
3. ¿Por qué es importante documentar decisiones además de procesos?