Cotizador de un ERP de ventas

Contexto

La empresa migró su proceso de venta interna de un sistema heredado a un ERP propio. El flujo completo va de la cotización a la tramitación del pedido: cotización, ajustes de oferta, pretramitación, validación de ajustes a la orden de compra y tramitación de la orden del cliente.

El cotizador es la primera pieza de ese flujo, y lo que pasa ahí afecta todo lo que sigue.

Para quién

Para los ejecutivos de venta interna, que convierten cada solicitud de un cliente en una cotización y pasan buena parte del día en esta pantalla. Cuando el sistema no les daba un camino, lo resolvían por fuera. No por falta de disciplina: el cliente estaba esperando.

El problema

El sistema ya estaba en uso, pero no cubría todos los escenarios reales. Cambiar las condiciones de pago, separar productos controlados o cotizar algo fuera del catálogo terminaba resolviéndose a mano. Cada cotización por fuera era una cotización sin trazabilidad y un riesgo para los pasos siguientes del pedido.

Mi rol

No diseñé el cotizador desde cero. Mi trabajo fue encontrar esos escenarios aislados y diseñar las mejoras para que el sistema los absorbiera: análisis con stakeholders, requisitos, flujos, interfaz, QA e implementación. También analicé el ERP completo y diseñé su adaptación para operar en Perú: experiencia de usuario, reglas de negocio e interfaz, con información del cliente.

Trabajar sobre un sistema en uso tiene un límite claro: cada mejora tenía que convivir con flujos que los equipos ya conocían de memoria. Cambiar demasiado habría costado más de lo que resolvía.

El espacio de trabajo

Cotizar empieza con un correo del cliente y un historial comercial, no con una pantalla en blanco. El cotizador reúne tres paneles: el contexto del cliente con sus condiciones comerciales, el requerimiento original tal como llegó y el armado de la cotización. Los dos primeros se contraen cuando el ejecutivo necesita espacio para trabajar la lista de productos.

Cada resultado de búsqueda muestra disponibilidad, vigencia, tiempo de entrega y cotizaciones vinculadas. Cuando un producto no se puede agregar, la interfaz explica por qué y qué hacer, en lugar de solo deshabilitar el botón.

Lo que mejoré

Cambiar condiciones de pago sin salir de la cotización

Diseñé el cambio dentro del flujo y comparé dos formas de validarlo. Una verificación única al final es más rápida, pero deja pasar errores hasta el último paso. Una verificación en cada cambio da más control, pero agrega fricción a un trabajo que se repite muchas veces al día.

La decisión. Elegí un código por cada cambio: así cada operación queda registrada y hay una bitácora de cambios con responsables. La fricción extra es el precio de esa trazabilidad.

Separar productos controlados

Los productos controlados siguen reglas distintas de las del resto. El cotizador ahora los identifica, muestra cuántos hay de cada tipo y permite dividir la cotización en lugar de armar otra a mano.

Lo que no se encuentra no bloquea la cotización

Los productos que no están en el catálogo pasan a una pestaña de investigación. El ejecutivo envía lo que sí tiene y da seguimiento a lo demás dentro del mismo sistema.

Resultado

Los escenarios que antes se resolvían por fuera ahora tienen un camino dentro del sistema. Según estimación del equipo, las cotizaciones resueltas por fuera bajaron cerca de 40%, y las que pasan por el sistema quedan trazadas hasta el pedido.

Lo que aprendí

Lo que funcionó. Las cotizaciones que se hacían por fuera resultaron ser la mejor fuente de requisitos: cada una señalaba un hueco concreto del sistema.

Lo que haría distinto. El 40% es una estimación del equipo. Propondría medir desde el propio sistema cuántas cotizaciones se resuelven por fuera, para seguir el impacto de cada mejora con datos.