Diseño de Procesos y SOPs Que No Caducan en Notion

El trimestre pasado hice una auditoría en un workspace de Notion con 47 documentos. Treinta y uno fueron archivados. No "marcados para revisión." Archivados. Desaparecidos de la barra lateral. El equipo no lo notó durante dos semanas, y cuando lo hizo, tres personas me dieron las gracias.

Ese es el estado real de la mayoría de la documentación de Ops. Se hereda un workspace con cuarenta y tantos SOPs repartidos entre Notion, Confluence y un Google Drive al que nadie tiene el enlace. A los seis meses, aproximadamente el 73% ha divergido del proceso real. El autor dejó la empresa hace dos trimestres. Los nuevos empleados reciben la versión "real" de forma verbal de quien esté disponible ese martes. El documento existe para el teatro de las auditorías. Nadie lo abre.

Este playbook explica lo que hago en su lugar. El SOP de 1 página, los recorridos en vídeo con Loom, un ritmo de revisión de 90 días y un diagnóstico de documentos fantasma que indica cuál es el 60% de la biblioteca a eliminar antes de que empiece el siguiente trimestre. Nada de esto es teórico. Lo he ejecutado en tres equipos de Ops y el mismo patrón se repite: reducir la biblioteca a la mitad, duplicar la lectura de lo que queda.

El SOP de 1 Página (y Qué Se Elimina)

Un SOP que funciona tiene cinco campos. Solo cinco. Si está escribiendo un sexto, está escribiendo un documento de formación, no un SOP, y debería colocarlo en otro lugar.

Esta es la plantilla literal que pego en cada nuevo documento:

# {Nombre del proceso}

**Propósito** (1 frase): Por qué existe y qué se rompe si no se ejecuta.
**Responsable**: {Persona con nombre y apellido, no un equipo}
**Última revisión**: {YYYY-MM-DD}
**Próxima revisión**: {YYYY-MM-DD + 90 días}

## Pasos
1. {Verbo de acción + objeto + herramienta}
2. {...}
3. {...}

## Criterios de éxito
- {Resultado medible 1}
- {Resultado medible 2}

## Escalada
Si {condición de activación}, contacte a {persona} en {plazo}.

Cabe en una página impresa. Es deliberadamente simple. Sin capturas de pantalla, sin tablas de contexto, sin "antecedentes y justificación." Esas cosas pertenecen a una wiki, a un Loom o a una reunión de inicio. No aquí.

Qué se elimina y por qué:

Secciones de antecedentes. "Este proceso se diseñó para abordar un incidente de 2024 en el que..." A nadie le importa. El SOP es para la persona que hace el trabajo hoy. Si necesita el historial, preguntará.

Árboles de decisión con más de una rama. Si su SOP tiene condicionales anidados, son dos SOPs haciéndose pasar por uno. Divídalo.

Capturas de pantalla incrustadas de la interfaz de la herramienta. Las capturas se quedan obsoletas más rápido que el proceso que documentan. Salesforce cambia el color de un botón y su SOP parece escrito por alguien que no ha iniciado sesión en todo el año. Use un Loom. Más sobre eso a continuación.

Cajas de "consejos útiles" y "puntos de atención". Si es lo suficientemente importante para resaltarlo, es un paso. Si no es un paso, es ruido.

El campo de criterios de éxito es el que la mayoría de los Ops Managers omiten y el que más importa. "Ejecutar el cierre mensual" no es un proceso. "Ejecutar el cierre mensual de modo que todas las conciliaciones bancarias muestren variación cero y el GL esté bloqueado antes del 5.º día hábil" sí es un proceso. Los criterios indican si el proceso funcionó. Sin ellos, no puede saber cuándo el SOP está roto.

Documentación con Loom Primero: 5 Minutos Valen Más que 8 Páginas

Este es el orden en el que escribo SOPs ahora, y es el opuesto de lo que hacía antes:

1. Grabo un Loom de mí mismo ejecutando el proceso de principio a fin. Entre cinco y ocho minutos.
2. Lo veo a 1,5x. Anoto dónde me detengo, dónde me salto un paso, dónde me corrijo.
3. Escribo el SOP de 1 página a partir de esas notas.
4. Incruto el Loom en la parte superior del documento.

El Loom es la fuente de verdad. El documento de una página es el índice. Eso parece al revés porque nos han entrenado a pensar en los documentos escritos como autoritativos, pero la matemática es sencilla: un recorrido de cinco minutos se ve. Un documento de ocho páginas se hojea buscando el apartado que el lector cree necesitar y luego se cierra.

Los datos de visualizaciones lo confirman. En el último equipo que gestioné, nuestros diez SOPs principales por vistas de Loom promediaban 14 reproducciones por trimestre. Los mismos SOPs como documentos de Notion promediaban 3 visitas a la página y 22 segundos de tiempo en pantalla. Las personas veían el vídeo, hacían el trabajo y no abrían el documento.

Algunas reglas que sigo para el Loom:

• Empiece con el desencadenante. "Hago esto porque me llegó una renovación de proveedor al correo." No "Hola a todos, hoy vamos a hablar de..."
• Muestre la pantalla, no la cara. La cámara web consume tiempo y atención. El trabajo está en la pantalla.
• Narre las decisiones, no los clics. "Estoy marcando esto para el equipo legal porque la cláusula de renovación automática supera los 30 días." No "Ahora voy a hacer clic en el botón de comentarios."
• Vuelva a grabar si supera los 6 minutos. Si se excedió, es que saltó un paso de planificación. Inténtelo de nuevo.
• Vuelva a grabar en cada cambio de proceso. No edite el Loom anterior. Grabe uno nuevo y reemplace el incrustado. La versión anterior queda en su biblioteca de Loom como registro histórico.

El enfoque de Loom primero también corrige algo de lo que nadie habla: la maldición del escritor. Cuando escribe el SOP primero, describe el proceso que cree que ocurre. Cuando lo graba primero, documenta el proceso que realmente ocurre. Esos casi nunca son el mismo documento. El Loom impone honestidad.

El Ritmo de Revisión de 90 Días

Cada SOP de mi biblioteca tiene dos campos de fecha: última_revisión y próxima_revisión. La próxima revisión siempre es 90 días después. No "anualmente." No "cuando sea necesario." Noventa días, en el calendario, con una notificación.

En el plazo de los 90 días, el responsable designado hace una de estas tres cosas:

1. Vuelve a ejecutar el proceso. Lo ejecuta de verdad. Detecta la desviación en tiempo real.
2. Confirma que no hay cambios. Actualiza última_revisión a hoy. Desplaza próxima_revisión 90 días más. Hecho en dos minutos.
3. Edita el documento y vuelve a grabar el Loom. Tarda 30 minutos. Vale la pena.

La regla que hace que esto funcione: si se pierden dos ciclos de revisión, el documento se archiva, no se "actualiza más tarde." Seis meses sin que un responsable lo toque es una señal fuerte de que nadie lo necesita. Si alguien sí lo necesita, archivarlo genera un mensaje en Slack de alguien, y ahora sabe quién lo usa realmente. Reinstate, reasigne, establezca una revisión a 90 días.

Mantengo la consulta de auditoría como una vista guardada en Notion. Tres columnas: nombre del SOP, responsable, días desde la última revisión. Ordenar de forma descendente. Todo lo que supere 180 días está en el bloque. La ejecuto al final de cada trimestre, archivo los que no tienen vida y envío al equipo una nota de una línea: "Esta semana archivé 9 SOPs. Si busca uno y no está, escríbame."

En dos años ejecutando este ritmo, he recibido exactamente cuatro "escríbame". De esos, dos eran personas que buscaban un documento que había sido reemplazado por uno más reciente (los redirigí). Dos eran archivos erróneos genuinos (los repuse). Cuarenta y tantos documentos desaparecieron sin una sola queja.

Esa proporción dice todo sobre cuántos de sus SOPs hacen trabajo real.

El Diagnóstico del "SOP Fantasma"

Un SOP fantasma es un documento que existe en su workspace pero no existe en la realidad cotidiana del equipo. Son la categoría más numerosa en la mayoría de las bibliotecas de Ops, y la auditoría para encontrarlos tarda aproximadamente una hora.

Tres señales, cualquiera de las cuales es suficiente:

Responsable sin vínculo con la organización actual. El campo del responsable nombra a alguien que dejó la empresa, cambió de equipo o nunca confirmó que lo era. Si no puede etiquetar a un empleado actual en el documento, es un fantasma.

Última edición de hace más de 180 días. Medio año sin que nadie lo toque, en un proceso que supuestamente está "activo." O el proceso no ha cambiado (poco frecuente, en mi experiencia) o nadie lo está verificando. En cualquier caso, el documento no se mantiene.

Cero enlaces entrantes y cero vistas recientes. Si ningún otro documento, ningún checklist de incorporación y ningún mensaje de Slack de los últimos 90 días enlaza a este SOP, no forma parte de ningún workflow. Existe de forma aislada. Es un fantasma.

La versión más rápida de la auditoría es verbal. Elija tres personas del equipo. Pregúntele a cada una: "Si ahora mismo necesitara hacer X, ¿dónde mirarías?" Si nombran el SOP, está vivo. Si dicen "le preguntaría a Jamie," el documento está muerto y Jamie es el SOP real. Reemplace el documento con un Loom de Jamie antes de que Jamie se vaya.

Una vez hice esto en un workspace de 47 documentos. Veintiocho fallaron en las tres señales. Tres más fallaron en dos de tres. Archivé 31 documentos en una sola tarde. El equipo se movió más rápido el mes siguiente, no más despacio, porque los resultados de búsqueda ya no estaban saturados de coincidencias fantasma.

Plantilla o Personalizado: Cuándo Reutilizar, Cuándo Escribir desde Cero

No todos los procesos merecen un SOP personalizado. Algunos procesos son estándar, y escribir un documento nuevo para ellos es en sí misma una forma de desperdicio.

Use una plantilla para:

• Checklists de incorporación. Configuración IT para nueva contratación, solicitudes de acceso a software, recorridos del primer día. El patrón es idéntico entre roles; solo cambia la lista de accesos.
• Revisiones de proveedores. Fecha de renovación, valor del contrato, responsable, última verificación de rendimiento, plazo de cancelación. Cinco campos, cada proveedor.
• Respuesta a incidentes. Niveles de gravedad, rotación de guardia, tiempos de escalada, plantilla de análisis post-incidente. El marco es reutilizable; el detalle del incidente va en el post-mortem.
• Cierre mensual. Las mismas cuentas, las mismas conciliaciones, la misma fecha de bloqueo. Rellene las variaciones.

Escriba desde cero para:

• Cualquier cosa interfuncional. Un proceso que toca Ventas, Finanzas y el equipo Legal tiene entregas que son únicas para la estructura de su empresa. Una plantilla ocultará los puntos de fricción que importan.
• Cualquier cosa con una entrega real. "Ventas pasa el trato a Incorporación." ¿Dónde viven los datos? ¿Quién avisa a quién? ¿Cuál es el SLA de respuesta? Las plantillas no conocen sus herramientas.
• Cualquier cosa que afecte los ingresos. Del presupuesto al cobro, aprobaciones de contratos, revisión del deal desk. El costo de un SOP genérico que omite su matriz de aprobaciones son días de retrabajo. Personalizado siempre.

El criterio abreviado que uso: si puedo imaginar el mismo SOP funcionando en tres empresas distintas con ediciones mínimas, aplico una plantilla. Si el proceso está determinado por su stack tecnológico específico, su estructura de equipo específica o su modelo de ingresos específico, lo escribo desde cero.

Una nota práctica: los SOPs de plantilla van en una carpeta _plantillas. Cuando alguien necesita un checklist de incorporación para un nuevo rol, duplica la plantilla y personaliza los campos específicos del rol. La plantilla en sí es de solo lectura. Esto evita la deriva lenta en la que el SOP de incorporación de cada equipo se convierte en un copo de nieve ligeramente diferente a lo largo de 18 meses.

Reglas de Responsabilidad: Una Persona, Nunca "El Equipo"

"El equipo de Ops es dueño de esto" significa que nadie es dueño de esto. He visto el mismo patrón en cada empresa: un documento lista un equipo como responsable, el equipo rota, el documento se deteriora, y al cabo de 12 meses el documento dice una cosa y el proceso hace otra.

La regla es: una persona con nombre por SOP, sin excepciones. Nombre y apellido en el campo del responsable. Si dejan la empresa, el SOP se reasigna en el mismo ticket de proceso de salida que revoca su acceso. Ningún SOP sin un responsable actual se integra en el workspace. Si está revisando un nuevo documento y el campo del responsable dice "Operaciones" o "Pendiente," devuélvalo.

Esto suena burocrático. No lo es. Es la única regla que crea responsabilidad. El responsable designado es la persona que:

• Vuelve a ejecutar el proceso cada 90 días.
• Vuelve a grabar el Loom cuando algo cambia.
• Recibe el aviso en Slack cuando falla.
• Aprueba las ediciones de cualquier otra persona.

Cuando la responsabilidad es compartida, nada de eso ocurre. Cuando se asigna a una persona, todo ocurre, porque el nombre del responsable figura en el documento y nadie quiere ser quien tenga el SOP que falló en producción.

Un patrón que uso para que esto se consolide: en la revisión trimestral del equipo, cada responsable designado recibe una lista de sus SOPs y sus fechas de revisión. Me toma unos diez minutos generarla. La lista es pública. Nadie quiere ser quien tenga tres revisiones atrasadas. En dos trimestres, la tasa de atrasos bajó del 40% a menos del 10% en el equipo donde lo apliqué, sin ningún otro cambio de proceso que no fuera la visibilidad.

Un segundo patrón para SOPs grandes que abarcan genuinamente varias personas: designe un responsable principal y un suplente. El principal hace la revisión de 90 días. El suplente es a quien se avisa si el principal está de vacaciones o en una reunión. Dos nombres. No cinco. No "el equipo."

Si solo se lleva una regla de este playbook, que sea esta. El formato de 1 página es útil. El enfoque de Loom primero es útil. El ritmo de 90 días es útil. Ninguno de ellos funciona sin un responsable designado que sepa que el SOP es suyo.

Cómo Se Ve Esto en la Práctica

Tres meses después de empezar a aplicar esto en el último equipo, el workspace pasó de 47 SOPs a 19. Las vistas de Loom por SOP se triplicaron. Los mensajes de Slack de "¿dónde encuentro el documento de X?" bajaron a aproximadamente uno a la semana, desde una base de cinco o seis al día. Dos nuevas contrataciones se incorporaron durante su primer mes usando solo los Looms y los documentos de una página, sin recorridos de acompañamiento de miembros senior del equipo.

El trabajo no es escribir más documentos. El trabajo es mantener menos documentos mejores, con una persona designada en cada uno, revisados cada 90 días y archivados sin ceremonia cuando se quedan en silencio. La mayoría de los equipos de Ops tienen demasiada documentación y muy poco mantenimiento. Cambie la proporción.

Más Información

• Descripción del puesto de Operations Manager: el JD de referencia con la definición completa del rol, KPIs y rúbrica de entrevista
• Sus primeros 30/60/90 días como nuevo Ops Manager: dónde encajan las auditorías de SOPs en su plan de incorporación
• Un día en la vida de un Operations Manager: cómo encaja el trabajo de documentación en el ritmo semanal
• Mediación interfuncional: cómo escribir SOPs para entregas que abarcan varios equipos