Diseñar un proceso de oferta a pedido con responsabilidades claras
Un caso B2B ficticio: versiones de oferta, umbrales de aprobación, reglas de revisión y la frontera CRM/ERP, diseñados para que una aprobación signifique lo mismo en el pedido que en la oferta.
Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.
01El resultado
Cada pedido se remonta a una única versión de oferta aceptada, cuya aprobación cubre exactamente los valores que contiene, y la viabilidad en el ERP se conoce antes de pedir al cliente que acepte.
Las ofertas cambian después de aprobarse, y el ERP rechaza pedidos que el cliente ya ha aceptado.
Modelo de aprobación y reglas de revisión
Vincular cada aprobación a una versión de la oferta y a sus valores, y adelantar las comprobaciones de viabilidad del ERP a antes de la aprobación en lugar de después de la aceptación.
Una organización comercial B2B hace las ofertas en el CRM, aprueba las desviaciones de la política de precios y crea los pedidos en el ERP. Ofertas, aprobaciones y pedidos se van separando: se editan ofertas ya aprobadas, se graban pedidos a partir de adjuntos de correo y el ERP rechaza pedidos que el cliente ya ha aceptado.
02La realidad · situación actual
Lo que pasa realmente hoy.
- Circulan varias versiones de la oferta y nadie sabe cuál aceptó el cliente
- Los umbrales de aprobación no están claros, así que o todo va a aprobación o no va nada
- Ventas puede cambiar una oferta después de aprobada sin que nadie lo note
- El ERP valida el pedido solo después de que el cliente haya dicho que sí
- Las ofertas rechazadas vuelven por correo, sin motivo ni versión
- Los pedidos no están ligados a un estado de la oferta, así que aparecen pedidos sin oferta aceptada
03Proceso objetivo
7 etapas, 4 roles, 2 sistemas.
Cada etapa se sitúa en el carril que es responsable de ella y muestra qué ocurre en cada sistema en ese momento. Selecciona una etapa para ver su anatomía; lee el modelo a través de los controles, las excepciones o la idoneidad para automatizar.
Validación comercial
- Disparador
Oferta enviada
- Decisión
¿Puede esta oferta convertirse en un pedido válido: cliente, productos, condiciones y crédito?
- Responsable
Gestión de pedidos
- Acción del sistema
La integración lanza una comprobación previa en el ERP: productos pedibles, condiciones de pago permitidas, estado de crédito
- Estado del dato
Oferta v1 · Validada
- Siguiente etapa
04 Aprobación comercial
- Estado de crédito del cliente
- Disponibilidad del producto para pedido
- Condiciones de pago permitidas para la entidad legal
- Las reglas del ERP se comprueban antes de la aprobación, no después de que el cliente acepte
- La comprobación previa no escribe nada en el ERP
- Falla la comprobación previa — Vuelve a borrador indicando la regla que fallaDetectada por: Comprobación previa del ERP · Responsable: Ventas · Vuelve a 02 Borrador de oferta
Automatizar. Una comprobación de solo lectura contra las reglas del ERP es determinista y reversible.
- Disparador
Oferta enviada
- Decisión
¿Puede esta oferta convertirse en un pedido válido: cliente, productos, condiciones y crédito?
- Responsable
Gestión de pedidos
- Acción del sistema
La integración lanza una comprobación previa en el ERP: productos pedibles, condiciones de pago permitidas, estado de crédito
- Estado del dato
Oferta v1 · Validada
- Siguiente etapa
04 Aprobación comercial
Información necesaria- Estado de crédito del cliente
- Disponibilidad del producto para pedido
- Condiciones de pago permitidas para la entidad legal
Controles- Las reglas del ERP se comprueban antes de la aprobación, no después de que el cliente acepte
- La comprobación previa no escribe nada en el ERP
Excepciones- Falla la comprobación previa — Vuelve a borrador indicando la regla que fallaDetectada por: Comprobación previa del ERP · Responsable: Ventas · Vuelve a 02 Borrador de oferta
Idoneidad para automatizarAutomatizar. Una comprobación de solo lectura contra las reglas del ERP es determinista y reversible.
- Disparador
04Dimensión clave · Modelo de aprobación y reglas de revisión
Reglas de revisión: qué le hace un cambio a una aprobación
La aprobación está vinculada a una versión y a sus valores. Un cambio posterior se clasifica con una regla publicada, no se debate en la bandeja de entrada del aprobador.
Cada cambio crea una nueva versión. Si esa versión necesita una nueva decisión lo dice una regla publicada, no el criterio del comercial.
05Responsabilidad y derechos de decisión
Un único responsable último por decisión.
| Decisión | Ventas | Dir. ventas | Op. comerciales | Gest. pedidos | Finanzas | Op. plataforma |
|---|---|---|---|---|---|---|
| 02Proponer precio, condiciones y forma de pago | A Responsable último | No interviene | C Consultado | I Informado | No interviene | No interviene |
| 04Aprobar una desviación de la política de precios | R Ejecutor | A Responsable último | C Consultado | No interviene | I Informado | No interviene |
| 04Aprobar condiciones de pago no estándar | R Ejecutor | C Consultado | No interviene | No interviene | A Responsable último | No interviene |
| 05Decidir si un cambio requiere volver a aprobar | R Ejecutor | C Consultado | A Responsable último | No interviene | No interviene | No interviene |
| 06Corregir un pedido que el ERP rechazó | C Consultado | No interviene | No interviene | A Responsable último | No interviene | R Ejecutor |
| 04Fijar los umbrales de aprobación | No interviene | A Responsable último | R Ejecutor | No interviene | C Consultado | No interviene |
- 02Proponer precio, condiciones y forma de pago
- AResponsable último
- Ventas
- CConsultado
- Op. comerciales
- IInformado
- Gest. pedidos
- 04Aprobar una desviación de la política de precios
- AResponsable último
- Dir. ventas
- REjecutor
- Ventas
- CConsultado
- Op. comerciales
- IInformado
- Finanzas
- 04Aprobar condiciones de pago no estándar
- AResponsable último
- Finanzas
- REjecutor
- Ventas
- CConsultado
- Dir. ventas
- 05Decidir si un cambio requiere volver a aprobar
- AResponsable último
- Op. comerciales
- REjecutor
- Ventas
- CConsultado
- Dir. ventas
- 06Corregir un pedido que el ERP rechazó
- AResponsable último
- Gest. pedidos
- REjecutor
- Op. plataforma
- CConsultado
- Ventas
- 04Fijar los umbrales de aprobación
- AResponsable último
- Dir. ventas
- REjecutor
- Op. comerciales
- CConsultado
- Finanzas
06Excepciones y rutas de fallo
10 rutas de excepción, cada una con responsable y destino.
La creación de la oferta espera hasta identificar la entidad de facturación
- Detectada por
- Comprobación al crear la oferta
- Responsable
- Ventas
- Destino
- Bloqueada hasta resolver la cuenta
Se solicita un precio especial antes de poder enviar la oferta
- Detectada por
- Regla de precios
- Responsable
- Dirección comercial
- Destino
- Solicitud de precio especial
Vuelve a borrador indicando la regla que falla
- Detectada por
- Comprobación previa del ERP
- Responsable
- Ventas
- Destino
- Vuelve a 02 Borrador de oferta
Una nueva versión en borrador con el código de motivo
- Detectada por
- Aprobador
- Responsable
- Ventas
- Destino
- Vuelve a 02 Borrador de oferta
Escala al siguiente aprobador
- Detectada por
- Reloj del SLA
- Responsable
- Dirección comercial
- Destino
- Escala un nivel
Una nueva versión; las reglas de revisión deciden si hay que volver a aprobar
- Detectada por
- Ventas
- Responsable
- Ventas
- Destino
- Vuelve a 02 Borrador de oferta
Se revalida con los precios y las reglas del ERP vigentes
- Detectada por
- Fecha de validez
- Responsable
- Ventas
- Destino
- Vuelve a 03 Validación comercial
Cola de corrección con el motivo del ERP; Ventas informada; la oferta sigue aceptada
- Detectada por
- Resultado de la integración
- Responsable
- Gestión de pedidos
- Destino
- Cola de corrección con responsable con nombre
Conciliado por clave; nunca se reenvía a ciegas
- Detectada por
- Monitor de integración
- Responsable
- Operaciones de plataforma
- Destino
- Conciliar por clave antes de cualquier reintento
La desviación se revisa antes de enviar la confirmación
- Detectada por
- Comparación de precios
- Responsable
- Dirección comercial
- Destino
- Revisión de desviación de precio
07Proceso ↔ sistema
Primero la pregunta de proceso. Entonces la pregunta de sistema tiene respuesta.
- Pregunta de proceso: P1¿Qué se aprueba exactamente: precio, margen, condiciones o forma de pago?
- Pregunta de sistema: S1¿Qué campos de la oferta se bloquean al aprobar y cuáles siguen editables?
- Pregunta de proceso: P2¿Un cambio posterior a la aprobación la invalida?
- Pregunta de sistema: S2¿Cómo hereda —o pierde— una nueva versión la aprobación anterior?
- Pregunta de proceso: P3¿Cuándo puede crearse un pedido?
- Pregunta de sistema: S3¿Qué evento lo crea y qué garantiza un único pedido por versión aceptada?
- Pregunta de proceso: P4¿Quién es responsable de corregir un pedido que el ERP rechazó?
- Pregunta de sistema: S4¿Dónde cae el rechazo, con qué motivo y quién lo ve?
08La segunda capa
Preguntas que cambian el diseño.
La aprobación
- ¿Qué se aprueba exactamente: precio, margen, condiciones comerciales o condiciones de pago?
- ¿Quién es responsable de cada una de esas decisiones?
- ¿Qué ofertas pueden aprobarse por regla y auditarse?
Después de aprobar
- ¿Puede cambiar la oferta después de aprobada?
- ¿Una modificación invalida la aprobación siempre, o según una regla?
- ¿Cuánto tiempo sigue siendo válida una aprobación?
Creación del pedido
- ¿Qué pasa cuando el ERP rechaza el pedido?
- ¿Quién es responsable de corregirlo y se entera el cliente?
- ¿Puede una oferta aceptada generar dos pedidos?
09Medición
La salud del proceso, definida por responsable y acción.
No se muestran valores: en un diseño, el entregable es la definición.
Del primer envío a la confirmación del pedido — mediana y percentil 90
- Responsable
- Dirección comercial
- Desencadena
- Localizar la espera: aprobación, cliente o ERP
Del envío a la decisión, por tipo de desviación
- Responsable
- Dirección de ventas
- Desencadena
- Ajustar umbrales o delegación donde se concentra la antigüedad
Ofertas aprobadas que cambian antes del pedido, por campo modificado
- Responsable
- Operaciones comerciales
- Desencadena
- Endurecer las reglas de revisión, o corregir lo que Ventas no podía saber en el borrador
Pedidos rechazados por el ERP tras la aceptación, por motivo
- Responsable
- Gestión de pedidos
- Desencadena
- Llevar la regla que falla a la comprobación previa
Importes de pedido confirmados que difieren de la oferta aprobada
- Responsable
- Dirección comercial
- Desencadena
- Encontrar dónde cambian los precios fuera de la versión aprobada
10Qué produce el trabajo
Entregables y conexiones.
- 01Ciclo de vida y modelo de estados de la oferta
- 02Modelo de aprobación por tipo de desviación
- 03Reglas de revisión
- 04Frontera CRM/ERP y comprobación previa
- 05Ruta de corrección de pedidos
- 06KPI de oferta a pedido