Documentación de Procesos

Por qué documentar los procesos antes de un proyecto eCommerce o ERP

Quien implanta una tienda online, un ERP o una integración configura lo que se le describe. Si nadie le cuenta que ciertos clientes tienen precios especiales por proyecto, que una familia de productos se vende por palés incompletos o que los pedidos urgentes se preparan saltándose la cola, esas excepciones aparecen el día del arranque, cuando más caro es resolverlas.

Documentar antes de empezar reduce esa sorpresa y además protege a la empresa de algo frecuente: que el conocimiento de cómo funciona un proceso crítico esté en la cabeza de una sola persona.

Además, documentar obliga a tomar decisiones que de otra forma se aplazan: qué tarifa prevalece cuando un cliente tiene dos, quién puede autorizar un abono o qué se hace con un pedido que llega sin stock. Resolverlas sobre el papel es mucho más barato que resolverlas sobre un sistema ya configurado.

Documentar el estado actual: cómo se trabaja de verdad

Para documentar el estado actual hablamos con quien hace el trabajo, no solo con quien lo dirige, y seguimos documentos reales: un pedido, una devolución, una alta de producto. Anotamos cada paso, quién lo hace, con qué herramienta y en qué puntos se espera a otra persona.

Registramos también lo que no aparece en ningún sistema: las hojas de cálculo auxiliares, los correos que hacen de aviso, los datos que se vuelven a teclear de un programa a otro y los atajos que el equipo ha ido inventando. Esa es la información que más valor tiene para cualquier proyecto posterior.

En esta fase no juzgamos ni corregimos: el objetivo es reflejar la realidad tal como es. Si el estado actual se maquilla, el proyecto se diseña para una empresa que no existe. También anotamos el volumen aproximado de cada actividad, porque un paso manual que se hace dos veces al mes no merece la misma atención que uno que se repite cientos de veces.

Documentar el estado futuro y los responsables de cada paso

Con el estado actual sobre la mesa, diseñamos el proceso objetivo: qué pasos desaparecen, cuáles pasan a hacerse en la tienda o en el portal, qué sistema es la referencia de cada dato y quién es responsable de cada decisión. Usamos una matriz de responsabilidades para que no queden pasos sin dueño ni pasos con dos dueños.

La diferencia entre el estado actual y el futuro es, en la práctica, el alcance del proyecto. Por eso esta documentación sirve directamente como base para pedir presupuesto a un implantador o para elegir herramienta.

Para cada paso del estado futuro indicamos qué datos necesita, de qué sistema vienen y qué ocurre si faltan, que es justo lo que después necesita quien diseñe las integraciones entre la tienda, el ERP y el resto de herramientas. Cuando hay varias formas de trabajar el mismo proceso, por ejemplo entre delegaciones o entre marcas, el estado futuro decide cuál se convierte en estándar y qué diferencias están justificadas.

Una documentación de procesos que se mantenga viva

Una documentación que nadie actualiza queda obsoleta en pocos meses. Entregamos los diagramas en un formato editable con las herramientas que ya use tu empresa, asignamos un responsable a cada proceso y acordamos cuándo se revisa: como mínimo, cada vez que cambia el sistema o la forma de trabajar.

Cuando el equipo técnico la necesita, usamos notación estándar BPMN; para el resto de la organización, diagramas sencillos que se entienden sin formación previa. Lo importante es que la consulte quien hace el trabajo, no solo quien lo audita.

Conviene guardar las versiones anteriores de cada diagrama. Cuando un proceso empieza a dar problemas, comparar cómo era antes y cómo es ahora suele señalar enseguida qué cambio lo provocó.

Si la documentación se hace como paso previo a un proyecto, la actualizamos al terminarlo para que refleje cómo se trabaja con los sistemas nuevos y no cómo se trabajaba antes.