Cómo crear un sistema de documentación de procesos
Cómo construir un sistema de documentación de procesos que siga siendo cierto dentro de dos años: un inventario con responsables con nombre, intervalos de revisión fijados por el ritmo de cambio y un defecto fechado por cada mapa atrasado.
Un sistema de documentación de procesos mantiene cierta en el tiempo una biblioteca de documentos: un inventario con un responsable con nombre por proceso, una fecha de revisión que llega a ese responsable y un ritmo de degradación que alguien mide.
En resumen
- Empieza por un inventario, no por un documento: una fila por proceso, un responsable y una fecha de vencimiento.
- Construye el metaproceso antes que el primer documento: creación, aprobación, publicación, formación y retirada.
- En el conjunto de una biblioteca, el documento medio pasa desactualizado la mitad de su intervalo de revisión.
- Un cambio que llegó a producción antes que su mapa es un defecto de documentación con fecha.
- Una revisión que no cambió nada le debe igualmente una entrada fechada al registro, o la exactitud parece abandono.
El sistema es el metaproceso, no la plantilla
Cualquier organización puede producir cincuenta documentos de proceso, y varias lo han hecho dos veces. Lo que resuelve un sistema de documentación no es cómo se escriben, sino qué será cierto de ellos dentro de dos años. La aritmética es cruel. Si nada salvo el calendario obliga a volver a mirarlos, un cambio hecho la semana siguiente a una revisión anual pasa inadvertido durante casi un año, y, de media en toda la biblioteca, el documento medio se pasa la mitad de su intervalo de revisión describiendo un trabajo que ya se ha movido. Una plantilla de redacción no influye lo más mínimo en esa cifra.
Así que el primer artefacto no es un documento. Es un inventario: todos los procesos que ejecuta la organización, una fila cada uno, con una persona con nombre responsable de su descripción, el nivel al que está documentado y un intervalo de revisión. Después viene el metaproceso: la ruta por la que los documentos de proceso se crean, se aprueban, se publican, se imparte formación sobre ellos y se retiran. Sin él, cada documento lo mantiene quien se acuerde de él, y la regla para un proceso que cambió antes que su mapa no se escribe nunca.
Lo que sigue es ese metaproceso, no uno de los procesos que gobierna. «Confirmar el propietario de la política» es la segunda fila, antes de que empiece ningún análisis. La salida «Sin cambios» de «¿Hay que modificar la política?» llega a «Revisión registrada y nueva fecha fijada»: una revisión que no reescribió nada y aun así movió la fecha, que es la entrada que una biblioteca envejecida nunca tiene. Y «Rehacer» devuelve la decisión de aprobación a «Redactar la revisión con control de cambios».
Construye el metaproceso en cinco etapas
El metaproceso sobre el que funciona una biblioteca, no uno de los procesos que contiene. Léelo para ver qué se le debe al registro después de publicar una política.
Un responsable antes que un análisis
El disparador es una fecha de calendario o un evento, y la fila siguiente confirma al propietario responsable antes de leer nada. «¿Hay que modificar la política?» trata después «Sin cambios» como un final de verdad: «Revisión registrada y nueva fecha fijada» es lo que mantiene honesto a un registro sobre la edad de un documento.
La consulta no es una cortesía
Redacción con control de cambios, después las áreas de negocio afectadas y después el encaje legal y regulatorio. «¿Requiere consulta a la representación?» enruta hacia los representantes, y «No aceptado» acaba en «Derivado a negociación formal»: un final fuera del control de la biblioteca, dibujado en lugar de darse por supuesto.
Los niveles mantienen libre al consejo
«¿Qué nivel de aprobación aplica?» se abre en tres hacia el consejo, el comité de dirección y el comité de políticas, y los tres convergen en «¿Decisión de aprobación?». Su salida «Rehacer» apunta de vuelta a la fila de redacción; «Rechazada» archiva la revisión y deja en vigor la versión anterior.
La publicación escribe en el registro
El registro se escribe desde dos filas: «Publicar la nueva versión y anunciarla» y «Sustituir y archivar la versión anterior». La nueva revisión, la fecha de publicación y la próxima fecha de revisión salen las tres de ahí. Un paso de publicación que no escribe en ningún sitio deja un registro envejeciendo por su cuenta.
Las obligaciones posteriores a publicar
Una decisión de materialidad enruta la formación, el acuse se registra contra el personal afectado y «Actualizar el registro de excepciones» atrapa las exenciones concedidas contra cláusulas que ya no existen. El sistema termina en «Política revisada en vigor» y no en la publicación.
Cómo funciona
Escribe el inventario de procesos antes que ningún mapa
Enumera todos los procesos que ejecuta la organización, uno por línea, con una persona con nombre responsable de su descripción, el nivel al que debería estar documentado y su criticidad. Espera que la lista sea más corta de lo temido y que la columna de responsable sea la discusión. Nada más se puede construir mientras esa columna tenga huecos.
Fija cada intervalo de revisión por el ritmo de cambio
Toma el intervalo de cuántas veces se movió el proceso de verdad en los dos últimos años y no de un valor por defecto de la política: tres cambios se ganan seis meses, ningún cambio en cinco años se gana dos. Registra el intervalo, la próxima fecha de vencimiento y el nivel documentado en el inventario, para que ninguno de los tres se vuelva a discutir en cada revisión.
Construye el metaproceso primero como diagrama
Antes de documentar ningún proceso real, pon en filas tu propia ruta de documentación: qué dispara una revisión, quién confirma al responsable, a quién se consulta, quién aprueba, cómo se publica y cómo se forma a quien lo usa. Escribe las etapas en la columna «Box text» y únelas por número de fila en la columna «Line to». Todos los documentos posteriores heredan de él.
Pon el nivel de aprobación en el diagrama como decisión
La fila de enrutado toma Decision en la columna «Shape», con los niveles escritos en «Line text» contra los números de «Line to», para que la ruta de una revisión se conozca antes de empezar a redactar. Usa la columna «Horizontal lane» para la fase y la columna «Vertical lane» para el responsable, de modo que el diagrama enseñe que una oficina de políticas y un órgano de aprobación no son lo mismo.
Dibuja el bucle de rehacer como un número hacia atrás
Una aprobación que devuelve el trabajo es un número de fila que apunta a una fila anterior, no una flecha que alguien añade al dibujo después. Como la columna «Line to» guarda datos, ese bucle sobrevive a que se inserte un paso por encima. Un diagrama que solo enseña movimiento hacia delante describe un órgano de aprobación que no ha discrepado ni una sola vez.
Audita la biblioteca contra sus propias fechas
Cada trimestre cuenta cuatro cifras: documentos con la fecha de revisión pasada, documentos sin responsable con nombre, documentos cuyo proceso cambió antes que su mapa y revisiones registradas sin cambio. La última es salud. Anota el siguiente recuento en el inventario antes de cerrar este, porque un recuento sin fecha siguiente caduca y la biblioteca vuelve a degradarse.
Errores que debes evitar
Llevar la documentación como un proyecto
El proyecto entrega la biblioteca, se disuelve y la degradación empieza la misma semana en que se cierra. La documentación es una función permanente con un responsable y una partida presupuestaria, o es la foto de un trimestre que envejece mal.
Dirigir el recordatorio a un departamento
«Responsable: Operaciones» significa que la fecha de vencimiento no se entrega en ningún sitio. Un departamento no tiene calendario ni bandeja de entrada que conteste, así que el recordatorio se genera, se dirige a una función y no lo lee nadie en particular.
Revisar solo lo que ya está en la estantería
Un ciclo de revisión solo puede actuar sobre la lista que tiene, así que los procesos sin ningún documento son justo los que nunca aparecen. Construye el inventario desde el trabajo que hace la organización, no desde la carpeta de documentos que existen.
Redocumentar semanas después del cambio
Un proceso que cambió en marzo y se redocumentó en mayo estuvo equivocado durante ocho semanas, y nada en la biblioteca lo registra. Anota el intervalo con fechas; el patrón que dibujan esos intervalos enseña por dónde pierde el sistema.
Construye tu propio sistema de documentación
Abre el ejemplo de revisión de políticas como diagrama propio y fija después el responsable, el nivel de aprobación y el intervalo de revisión sobre el que funcionará tu biblioteca.
Guías relacionadas
Preguntas frecuentes
¿Qué es un sistema de documentación de procesos?
Es el conjunto de reglas y roles que mantiene cierta una documentación de procesos, a diferencia de los documentos en sí: un inventario con un responsable con nombre por proceso, el nivel al que está documentado cada uno, un intervalo de revisión cuyos vencimientos llegan a esos responsables, una medida del ritmo al que la biblioteca se queda por detrás del trabajo y una ruta para crear, aprobar, publicar y retirar un documento. La plantilla es lo que menos importa. La prueba es qué dice el registro sobre un documento que nadie ha tocado en tres años.
¿Qué debe contener un inventario de procesos?
Una línea por proceso: el nombre del proceso, el responsable como persona y no como equipo, el nivel al que está documentado, su criticidad, la ubicación de la versión vigente y las fechas de la última revisión y de la próxima. Hay dos columnas más que se ganan el sitio enseguida: los sistemas en los que corre el proceso, que te dice qué invalidará una migración, y el apartado que existe para cumplir, que te dice qué pedirá ver un auditor. El inventario va primero porque todas las decisiones posteriores son consultas contra él.
¿Quién debe ser el responsable de un sistema de documentación de procesos?
Una sola persona, y no la que posee más documentos. El responsable del sistema lleva el inventario, el metaproceso y el registro de fechas de revisión; cada propietario de documento lleva el contenido. Fundir las dos cosas produce el fallo conocido en el que cada revisión hace cola detrás del único individuo que entiende el sistema, y la cola se reporta como un problema de recursos y no como uno de diseño. Media jornada a la semana sostiene una biblioteca de cincuenta procesos, siempre que los recordatorios sean automáticos y todos los responsables sean un nombre.
¿Dónde debe vivir la documentación de procesos?
Donde diga el inventario, y por eso la ubicación es una columna suya y no una decisión que se toma una vez para toda la biblioteca. Un sistema de gestión de la calidad, un wiki y una unidad compartida pueden guardar cada uno una versión vigente; ninguno de los tres puede decirte qué procesos no tienen ninguna. Así que la prueba no es qué plataforma, sino si cada fila del registro nombra el sitio al que manda a sus lectores y si llegar allí produce la revisión que el registro dice. Un proceso sin fila es invisible para cualquier elección de plataforma.
