6 preguntas para saber si su proceso está documentado

Un proceso "documentado" y un proceso con un manual guardado en una carpeta compartida no son la misma cosa. La diferencia aparece el día que alguien nuevo intenta seguir el documento y se da cuenta de que le faltan datos, o el día que el proceso cambió y nadie actualizó el papel.

Estas seis preguntas sirven para saber, en minutos, en cuál de los dos casos está su empresa. Responder que sí a las seis es la base sólida que se necesita antes de automatizar. Responder que no a alguna no es un fracaso: es la señal de qué relevar primero.

Estas seis preguntas concretas funcionan como un autodiagnóstico rápido para evaluar si la documentación existente de su empresa ya alcanza para automatizar, o si todavía describe la versión anterior del proceso.

Pregunta 1: ¿alguien nuevo podría ejecutar el proceso solo con el documento?

Esta es la prueba más simple y la más reveladora. Si la respuesta incluye "sí, pero me tendría que preguntar un par de cosas", el documento no está completo: está incompleto en las partes que el equipo actual resuelve de memoria.

Un documento que depende de la memoria de una persona no es documentación, es una nota personal. El proceso queda documentado recién cuando alguien externo al equipo puede seguirlo sin ayuda adicional.

Pregunta 2: ¿el documento incluye las excepciones, no solo el camino feliz?

Casi todos los manuales describen bien el caso normal: el pedido que llega completo, el pago que se acredita a tiempo, el dato que entra en el formato esperado. Muy pocos describen qué hacer cuando el pedido llega incompleto, el pago no se acredita o el dato viene mal cargado.

Las excepciones son, en la práctica, donde el equipo gasta más tiempo y donde más criterio aplica. Si el documento no las cubre, describe una fracción del trabajo real.

Pregunta 3: ¿dice quién es responsable de cada paso y de cada decisión?

Un proceso sin responsables asignados no es un proceso: es una descripción de tareas sueltas. Cuando algo falla y nadie sabe si le correspondía a esa persona intervenir, la excepción queda sin resolver hasta que alguien la nota por accidente.

El documento tiene que decir, para cada paso, quién lo ejecuta y quién decide qué hacer cuando algo no encaja.

Pregunta 4: ¿se actualizó la última vez que el proceso cambió, o describe cómo se hacía antes?

Un documento sin fecha de última revisión, o con una fecha de hace más de un año, suele describir una versión anterior del proceso. Los procesos cambian: se suma un sistema, se elimina un paso, se ajusta una política. Si el documento no siguió esos cambios, dejó de ser una fuente confiable.

La pregunta útil no es "¿existe el documento?" sino "¿la última vez que algo cambió, alguien volvió a este documento?". Estas son las señales más claras de que la documentación está desactualizada o incompleta, aunque el archivo siga estando guardado en la carpeta de siempre.

Pregunta 5: ¿especifica qué sistemas, datos y entradas o salidas intervienen en cada paso?

Un paso descrito como "se carga la información en el sistema" no dice en qué sistema, con qué datos ni de dónde sale esa información. Esa falta de precisión es la que más tiempo cuesta después, cuando alguien intenta automatizar ese paso y tiene que reconstruir esos detalles desde cero, preguntando otra vez al equipo.

Cuanto más específico el documento en sistemas y datos, menos relevamiento adicional hace falta antes de tocar tecnología.

Pregunta 6: ¿sirve para automatizar, o solo para explicar el proceso en una reunión?

Un documento puede ser suficiente para presentar el proceso en una reunión y, al mismo tiempo, insuficiente para automatizarlo. La automatización necesita el nivel de detalle de las preguntas anteriores: responsables, excepciones, sistemas y vigencia. Una descripción general del proceso no alcanza.

Si el documento sirve para lo primero pero no para lo segundo, el paso siguiente no es automatizar: es completar el relevamiento.

Estos criterios coinciden con lo que documentan las guías especializadas en la materia: Atlassian recomienda que la documentación de un proceso incluya entradas, salidas y responsables, y las guías de BPM de BOC Group insisten en que un procedimiento sin excepciones documentadas queda incompleto apenas se lo pone a prueba.

Qué hacer si su proceso no pasa el diagnóstico

Responder que no a una o más de estas preguntas no significa que el proceso esté mal diseñado. Significa que la documentación que existe hoy no alcanza para automatizar con base sólida todavía.

En Bprosys, antes de automatizar cualquier proceso, hacemos ese relevamiento: mapeamos el proceso real, no el que figura en el manual, con responsables, excepciones y sistemas incluidos. Con más de 15 años automatizando operaciones en 7 países de LATAM, la brecha entre el documento y el proceso real es, en nuestra experiencia, la causa más frecuente de que una automatización falle antes de arrancar.

Si su empresa respondió que no a alguna de estas seis preguntas, ese es el punto de partida, no un obstáculo. Un Process Discovery cierra esa brecha antes de comprometer un plazo de automatización. Puede reconocer el punto de partida en 3 señales de que su proceso pide automatización o medir el impacto de esperar en el costo invisible del proceso manual. Una vez que la documentación está lista, el siguiente paso es elegir el primer caso de uso de IA en su empresa, o sumar un equipo de staff augmentation dedicado a ejecutar el relevamiento sin sacar a su equipo de la operación diaria.