# Estandarización de procesos (SOPs): del ‘así lo hace Juan’ al estándar vivo que sostiene la promesa
Si tu calidad depende de veteranos, tu promesa depende de la suerte.
Yo no defiendo los SOPs por amor al orden. Los defiendo por una razón más incómoda: la empresa no debería depender de “Juan”.
“Juan” puede ser la persona más comprometida y capaz del mundo. El problema no es Juan. El problema es el sistema que lo obliga a ser sistema.
Cuando un proceso vive en la cabeza de alguien:
-
- la variabilidad se cuela sin avisar
-
- la formación se convierte en imitación
-
- el error se repite porque nadie sabe cuál era “la manera correcta”
-
- y la empresa se queda sin defensa cuando hay rotación, bajas o crecimiento.
Este artículo no es un manual para escribir procedimientos. No vas a encontrar plantillas, formatos, auditorías ni “haz esto en cinco pasos”. Lo que sí vas a encontrar es lo que yo uso para diagnosticar si tu estandarización es viva (útil) o muerta (burocrática).
## El síntoma: “cada uno lo hace a su manera”
En operaciones con producto a medida, es normal que haya matices. Pero una cosa es matiz y otra es caos.
Yo detecto el problema cuando aparecen estas frases:
-
- “Depende de quién lo haga.”
-
- “Yo lo hago así porque siempre funcionó.”
-
- “A mí me lo explicaron distinto.”
-
- “Aquí cada uno tiene su truco.”
Traducido: no hay estándar; hay estilos personales.
Y cuando hay estilos personales, el resultado final deja de ser controlable.
## SOP no es burocracia. Es un “contrato interno” de calidad
Un SOP útil no busca describir todo. Busca proteger lo que no te puedes permitir perder:
-
- seguridad
-
- calidad
-
- repetibilidad
-
- y coherencia entre tienda, fábrica e instalación.
Yo lo veo como un contrato interno: “esto es lo mínimo que debe ocurrir para que la promesa salga defendible”.
El riesgo no es no tener documentos. El riesgo es no tener acuerdos operativos.
## El mayor error: SOPs que describen el mundo ideal
He visto SOPs perfectos en papel y muertos en la realidad.
¿Por qué?
-
- porque nadie los usa cuando hay presión
-
- porque están escritos como si la operación no tuviese excepciones
-
- porque son demasiado largos
-
- o porque castigan al que levanta un problema.
Un SOP vivo asume un hecho: el mundo real rompe el guion. Lo que importa es cómo el sistema se defiende cuando eso pasa.
## Señales de “SOP muerto” (y cómo se te come el margen)
Un SOP está muerto cuando:
-
- se consulta solo en auditorías
-
- está escrito para “cumplir” y no para operar
-
- vive en carpetas, no en el puesto
-
- nadie sabe cuál es la última versión
-
- y el cambio se vuelve peligroso (“si lo toco, la lío”).
Lo peor es que un SOP muerto no es neutral: crea falsa seguridad.
La dirección cree que hay control (“tenemos procedimientos”), pero el suelo de fábrica opera por memoria y urgencia.
## Mi criterio: el “estándar mínimo viable”
Yo no persigo el procedimiento perfecto. Persigo un estándar mínimo viable.
¿Qué significa?
Que el SOP protege las partes que, si fallan, disparan:
-
- retrabajo
-
- incidencias
-
- devoluciones
-
- discusiones internas
-
- y promesas rotas con el cliente.
Un estándar mínimo viable:
-
- reduce variabilidad donde duele
-
- y deja flexibilidad donde no rompe la promesa.
## Estándar vivo: cuando el proceso se actualiza por aprendizaje, no por culpa
La estandarización madura no es rígida. Es aprendiente.
La diferencia no está en la carpeta. Está en estas preguntas:
-
- ¿cómo se decide que algo “cambia”?
-
- ¿quién tiene derecho a proponer ajustes?
-
- ¿qué señales activan revisión?
-
- ¿qué pasa cuando el estándar no encaja?
Si la respuesta es “se hace una excepción y ya”, entonces lo que tienes es un sistema que acumula deuda.
## El conflicto típico: “estandarizar mata la artesanía”
En sectores de alta personalización, esto aparece siempre.
Yo estoy de acuerdo con una parte: si estandarizas lo que da valor, matas el valor.
Pero aquí está la clave: la artesanía no debería vivir en lo repetible. Lo repetible (lo básico) es donde la variabilidad se vuelve coste.
El valor premium no es improvisar. El valor premium es ejecutar con precisión bajo incertidumbre.
## Dónde yo miro primero (porque ahí se rompen promesa, plazo y margen)
Sin entrar en “cómo hacerlo”, hay zonas donde el estándar suele ser crítico:
### 1) Handovers internos
Donde el trabajo cambia de manos: tienda → oficina técnica → fábrica → instalación.
### 2) Operaciones sensibles a calidad
Las que generan defecto “caro” si fallan.
### 3) Puntos de no-retorno
Momentos donde una decisión mal tomada cuesta mucho revertir.
### 4) Excepciones recurrentes
Lo que “pasa a menudo” pero nadie reconoce como estándar.
Si no hay estándar ahí, lo normal es que la empresa sobreviva… hasta que crece.
## Preguntas de diagnóstico que hago para saber si un SOP te daría retorno
-
- ¿Qué tareas dependen de veteranos para salir bien?
-
- ¿Qué errores se repiten con personas distintas?
-
- ¿Dónde se descubre el problema tarde (cuando ya es caro)?
-
- ¿Qué parte del proceso se entrena por “sombra” y no por claridad?
-
- ¿Qué decisiones se toman sin criterio común?
-
- ¿Qué versión del proceso es la real: la del papel o la del suelo?
Cuando escucho “depende”, ya tengo el mapa.
## Lo que NO recomiendo (porque suele fabricar burocracia)
-
- Escribir SOPs largos “para cubrirse”.
-
- Describir casos raros como si fueran el día a día.
-
- Crear un estándar sin ownership real.
-
- Penalizar al que detecta desviaciones (eso mata la verdad).
-
- Convertir la mejora en un trámite.
El objetivo no es documentar. El objetivo es sostener una promesa sin heroísmo.
## Cierre
Para mí, estandarizar es esto: convertir lo que hoy depende de personas en un estándar vivo que sostiene la promesa.
Si quieres, puedo ayudarte a detectar:
-
- dónde tu calidad depende de veteranos
-
- qué puntos deberían tener estándar mínimo viable
-
- y cómo evitar SOPs que nacen muertos.
