¿Por qué es necesario analizar los procesos antes de empezar un proyecto de ERP?

En la demo de un ERP todo funciona sin fallos; el problema es que la empresa de la demo no es la suya. El análisis de procesos es el trabajo que, antes de pasar a un software, levanta paso a paso cómo se desarrolla realmente el trabajo, desde el pedido hasta el cobro. Que un proyecto de ERP avance bien depende, en buena parte, de la calidad de este trabajo.

En este artículo explicamos por qué no conviene omitir el análisis, qué se extrae en él y qué documentos debería tener usted al final. Abordamos el enfoque a partir de los principios de YazSis ERP, que construimos como una arquitectura adaptada a la empresa.

¿Qué pasa si se omite el análisis?

Se instala el software, se abren las pantallas, todos inician sesión. Unas semanas después, una parte de los empleados vuelve a sus viejos hábitos. Porque el software se construyó según cómo se cuenta el trabajo sobre el papel, y no según cómo se hace realmente. Los cuatro problemas siguientes son las consecuencias más frecuentes.

• El alcance se desplaza: las peticiones de “añadamos también esto” se acumulan a mitad del proyecto, el calendario se alarga y qué trabajo entraba en la primera fase se convierte en motivo de discusión.
• Comienza el doble registro: el trabajo que no tiene equivalente en el sistema se sigue haciendo en Excel; con el tiempo los dos registros se alejan y deja de estar claro cuál es el correcto.
• El usuario se resiste: en lugar de facilitar el trabajo del usuario, la pantalla le hace rellenar campos de más. Así, el software se percibe como una carga adicional.
• La responsabilidad queda sin definir: quién da la aprobación y quién resuelve una excepción se discute cuando el sistema ya está en funcionamiento; sin embargo, esa decisión podía haberse tomado al comienzo del proyecto.

Cinco pasos del análisis de procesos

1. Dibuje el flujo tal como es. Escriba por qué persona y con qué herramienta pasan hoy el pedido, la compra y el movimiento de stock. Lo que importa no es el flujo que debería ser, sino el que realmente ocurre.
2. Recoja las excepciones. Situaciones “no normales”, como devoluciones, envíos parciales, diferencias de precio o pedidos urgentes, pueden constituir buena parte del trabajo diario. El software tiene sus mayores dificultades justamente en estos casos; por eso conviene llevar una lista aparte.
3. Aclare aprobaciones y facultades. ¿Quién aprueba por encima de qué importe, quién puede conceder descuentos, quién puede hacer un ajuste de stock? Estas respuestas deben vincularse al rol, no a la persona.
4. Liste las fuentes de datos. ¿Dónde se guardan la lista de clientes, la ficha de producto y la lista de precios? ¿Cuál está actualizada y quién la actualiza? Los puntos donde una misma información vive en varios lugares son los que se reducirán a un único registro en el sistema.
5. Decida qué va a medir. Si desde el principio se eligen los pocos indicadores que la dirección quiere ver cada semana, las pantallas y los informes se construyen en consecuencia; añadir informes después siempre es más difícil.

Un pequeño ejemplo: la aprobación de descuentos

Un cliente pide un descuento. El comercial escribe al responsable por WhatsApp, el responsable dice “vale” y el comercial prepara la oferta. Nadie lo ha definido como proceso, pero funciona todos los días. Si este flujo no se escribe al pasar al ERP, en el sistema o no habrá ningún paso de aprobación o habrá uno que nadie usa. El análisis vuelca esta regla invisible al papel y la deja lista para incorporarla al software. El mismo método vale para otras reglas silenciosas, como el ajuste de stock, la elección de proveedor o la aceptación de devoluciones: primero se responde quién decide y con qué criterio, y después esa decisión se escribe en el sistema como un paso.

El proceso que no puede explicarle al software no funcionará en el software.

¿Quién debe participar en el análisis?

Quienes conocen el proceso más de cerca son las personas que hacen ese trabajo todos los días. Por eso el análisis no debe quedarse en el nivel de la dirección y de sistemas; también deben participar el comercial, el almacenero, el responsable de compras y el contable. La dirección cuenta cómo debería funcionar el trabajo; el empleado, cómo funciona. La diferencia entre ambos es la verdadera lista de tareas del proyecto. A veces esa diferencia no es una necesidad de software, sino solo una regla que falta o un paso de aprobación innecesario; verlo durante el análisis cuesta mucho menos esfuerzo que descubrirlo después de la instalación.

¿Qué debería tener al final del análisis?

Un buen análisis no termina en reuniones orales, sino en documentos concretos. Esos documentos son la base tanto de la implantación del ERP como de los cambios posteriores; cuando llega un empleado o un directivo nuevo, también explican por qué el sistema se construyó así:

• Mapas de procesos que van de la venta al cobro y de la compra a la entrega.
• Lista de excepciones y casos especiales, con quién decide en cada una.
• Tabla de roles y facultades: quién ve qué y quién aprueba qué.
• Mapa de integración que muestra las fuentes de datos y cómo se conectarán entre sí.
• El alcance de la primera fase y el orden de las áreas que se añadirán en las fases siguientes.

Nuestro enfoque: que el ERP se adapte a la empresa

Construimos YazSis ERP según cuatro principios. Estos principios también determinan qué se decidirá al final del análisis de procesos:

• Conservar el sistema existente: si hay un ERP en funcionamiento, no se desmonta; se completan los procesos que le faltan.
• Ampliar con un módulo propio: el flujo que el producto estándar no cubre se desarrolla a medida de la empresa.
• Unir los datos: el flujo de información común se construye mediante integraciones de API y de base de datos.
• Medir y mejorar: los informes de gestión hacen visibles el cuello de botella y el resultado.

Si desea mapear sus procesos con nosotros y definir el alcance de la primera fase, puede ponerse en contacto desde la página de YazSis ERP.