Estandarizar el gobierno de RFQ entre decisiones comerciales, técnicas, de compliance y de proyecto
Un caso ficticio y compuesto sobre solicitudes OEM y Private Label de ciclo largo. No es un flujo de aprobación: es el modelo de gobierno que decide qué solicitudes perseguir, con el criterio de quién y sobre qué evidencia.
Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.
El caso en síntesis
Realidad actual
Las RFQ complejas las decidía quien estuviera en copia del email: unas pasaban por ingeniería, calidad y finanzas; otras se ofertaban antes de que nadie comprobara su viabilidad.
Qué tiene que llegar a ser cierto
Cada RFQ compleja se clasifica al entrar, la evalúan las funciones que exige su clase y un responsable con nombre decide Go / No-Go sobre evidencia registrada y dentro de un plazo; y la decisión puede auditarse después.
Pregunta de diseño
¿Qué criterio necesita cada tipo de solicitud antes de que la empresa se comprometa, y quién puede tomar esa decisión?
01Realidad
Lo que la organización hacía en realidad.
Un proveedor industrial ficticio recibe solicitudes de información y de oferta de fabricantes de equipos (OEM) y de clientes que quieren productos con su propia marca (Private Label). Una sola solicitud puede implicar un producto nuevo, utillaje nuevo, capacidad de planta, validación de calidad, comprobaciones de compliance y una rampa de varios años. Ventas, ingeniería, calidad, planta, finanzas, compras y compliance tenían cada uno una parte del criterio; ninguno tenía la decisión.
- Las RFI y las RFQ llegaban por el mismo canal y se trataban igual
- Algunas solicitudes se valoraban antes de que ingeniería hubiera visto el plano
- Las revisiones de viabilidad, calidad y compliance se hacían por email, sin constancia de quién había concluido qué
- Las cuestiones de inversión y capacidad aparecían después de enviar la oferta
- El mismo tipo de solicitud recibía una revisión distinta según el gestor de cuenta
- Los No-Go casi nunca se registraban; las solicitudes descartadas simplemente se apagaban
- Las solicitudes OEM y Private Label seguían costumbres separadas, con reglas que se solapaban sin ser coherentes
02¿Un solo proceso?
¿Por qué no bastaba un solo proceso?
Tratar todas las solicitudes igual o enterraba las sencillas bajo revisiones, o dejaba pasar sin ellas las que tenían consecuencias. Estas variables decidían cuánto criterio necesitaba una solicitud:
- 01RFI o RFQ¿El cliente está explorando o pide una oferta vinculante?
- 02Novedad del producto y de la tecnología¿Una referencia existente, una variante o un desarrollo nuevo?
- 03Valor del programa y margen¿Cuánto vale el programa durante toda su vida, y con qué margen?
- 04Inversión¿Requiere utillaje, equipos u otra inversión antes de la primera entrega?
- 05Viabilidad industrial¿Puede una planta fabricarlo con los volúmenes y la rampa que se piden?
- 06Calidad y validación¿Qué validación, ensayos y homologaciones exige el cliente?
- 07Compliance¿Qué comprobaciones regulatorias, de comercio exterior o de uso de marca aplican?
- 08Encaje estratégico¿Un cliente, mercado o segmento estratégico, o una solicitud oportunista?
- 09Riesgo de proyecto¿Qué podría hacer fracasar el proyecto una vez comprometidos?
El objetivo no era automatizar un flujo de aprobación. Era convertir un criterio comercial, técnico, de compliance y de proyecto disperso en un modelo de decisión coherente y auditable.
03Segmentación
Cómo se segmentó la realidad
Las dimensiones dieron lugar a unas pocas clases. La clase se fija una vez en la entrada, puede subir cuando aparecen hechos nuevos y decide todo lo que viene después. Las solicitudes OEM y Private Label no son procesos separados: caen en la clase que marcan sus consecuencias.
Toda RFI y RFQ entrante
- RFISolo información. La responden ventas y gestión de producto; sin compromiso y sin punto de decisión.
- RFQ estándarReferencias existentes con volúmenes conocidos. Revisión comercial dentro de la política de precios.
- RFQ ampliadaVariantes, volúmenes nuevos o requisitos especiales. Evaluaciones técnica, de calidad y de costes antes de dar precio.
- Proyecto estratégicoDesarrollo nuevo, inversión o una cuenta estratégica. Evaluación transversal completa y punto de decisión Go / No-Go.
Decisión de diseño
Clasificar las solicitudes por sus consecuencias (novedad, inversión, capacidad, riesgo, peso estratégico) y dejar que sea la clase, y no el comercial ni solo el importe, la que fije las evaluaciones, el responsable de la decisión y el plazo.
04Modelo objetivo
Modelo operativo objetivo
Un único ciclo de vida de gobierno para todas las clases. La clase decide qué pasos son obligatorios y quién decide.
- 01Entrada y clasificación
- Responsable
- Responsable comercial
- Criterio de salida
- Registrados el tipo de solicitud, el cliente, la clase y las evaluaciones obligatorias
- 02Evaluación
- Responsable
- Las funciones que exige la clase
- Criterio de salida
- Cada evaluación concluida: viable, viable con condiciones o no viable
- 03Consolidación
- Responsable
- Jefe de proyecto (el responsable comercial en las estándar)
- Criterio de salida
- Un único expediente de decisión: evaluaciones, base de costes, riesgos, condiciones abiertas
- 04Go / No-Go
- Responsable
- Responsable de la decisión de la clase
- Criterio de salida
- Decisión registrada con evidencia, condiciones y justificación
- 05Oferta
- Responsable
- Responsable comercial
- Criterio de salida
- Oferta emitida dentro de las condiciones decididas
- 06Adjudicación y traspaso
- Responsable
- Jefe de proyecto
- Criterio de salida
- Adjudicación registrada; hitos de desarrollo, validación y rampa traspasados al proyecto
05Qué cambia según la ruta · Clasificación → evaluaciones → derechos de decisión
La clase decide el criterio
Cada clase lleva sus evaluaciones, su responsable de la decisión y un plazo. La matriz de derechos deja explícito quién decide, quién aprueba y a quién solo se consulta.
01RFI
Solicitud de información, sin oferta vinculante
- Encaje de producto
- Responsable de la decisión
- Ventas
- Plazo
- 5 días laborables
02RFQ estándar
Referencias existentes, volúmenes conocidos
- Comercial
- Política de precios
- Responsable de la decisión
- Jefe de ventas
- Plazo
- 5 días laborables
03RFQ ampliada
Variante, volúmenes nuevos o requisitos especiales
- Comercial
- Técnica
- Calidad
- Costes
- Responsable de la decisión
- Director de ventas
- Plazo
- 15 días laborables
04Proyecto estratégico
Desarrollo nuevo, inversión o cuenta estratégica
- Comercial
- Técnica
- Industrial
- Calidad
- Compliance
- Financiera
- Encaje estratégico
- Responsable de la decisión
- Dirección del negocio
- Plazo
- Calendario de puntos de decisión
Quién tiene cada derecho
| Decisión | Ventas | Ingeniería | Calidad | Planta | Finanzas | Compliance | Dirección |
|---|---|---|---|---|---|---|---|
| Clasificar la solicitud | D | C | — | — | — | — | I |
| Viabilidad técnica | I | D | C | C | — | — | — |
| Viabilidad industrial y capacidad | I | C | — | D | C | — | — |
| Plan de calidad y validación | I | C | D | C | — | — | — |
| Visto bueno de compliance | I | — | C | — | — | D | — |
| Base de costes y margen | R | C | — | C | D | — | I |
| Go / No-Go, clase estratégica | R | C | C | C | C | C | D |
| Condiciones de la oferta | D | — | — | — | A | — | I |
D decide · A aprueba · R recomienda · C consultado · I informado · — no interviene
Clases, plazos y derechos son ilustrativos. Lo que importa es el patrón: la clase se fija una vez, sube si cambian los hechos y cada Go / No-Go deja un registro de decisión.
06Excepciones y rutas de retorno
El camino feliz nunca es todo el proceso.
| Cuando | Entonces | Responsable | Vuelve a |
|---|---|---|---|
| Hechos nuevos suben la clase durante la evaluación: utillaje nuevo, un mercado nuevo | Se sube la clase; se añaden las evaluaciones que faltan y el plazo se reinicia para la nueva clase | Jefe de proyecto | Evaluación |
| Una evaluación está vencida | Se escala al responsable de la función cuando vence el plazo; la fecha de decisión nunca se mueve en silencio | Función evaluadora | Evaluación |
| Viable con condiciones | Las condiciones se registran en el expediente de decisión y pasan a la oferta y al proyecto | Responsable de la decisión | Go / No-Go |
| Dos funciones discrepan | Las dos conclusiones se quedan en el expediente; el responsable de la decisión de la clase decide y registra por qué | Responsable de la decisión | Go / No-Go |
| No-Go | Se registra con el motivo y el punto de decisión; se responde al cliente; las solicitudes similares pueden encontrarse más adelante | Responsable de la decisión | Cerrada, con registro de decisión |
| El cliente pide precio antes de que se cierren las evaluaciones | Ningún precio vinculante: solo un rango orientativo, marcado como tal | Jefe de ventas | Evaluación |
| La especificación cambia después de la oferta | Se trata como una nueva revisión de la solicitud; se vuelven a comprobar la clase y las evaluaciones afectadas | Responsable comercial | Entrada y clasificación |
07Capacidades de soporte y codificación en el sistema
Solo ahora, la tecnología.
CRMMotor de aprobacionesGestión documentalERPHerramientas de proyecto
Capacidades de soporte
- CRMGuarda la solicitud, su clase, el expediente de decisión y el resultado
- Motor de aprobacionesEnruta evaluaciones y puntos de decisión según la clase, y registra quién concluyó qué
- Gestión documentalMantiene planos, especificaciones y evidencias de evaluación junto a la solicitud
- Herramientas de proyectoReciben el proyecto adjudicado con sus condiciones y sus hitos
- Asistencia de IALee y estructura las solicitudes entrantes (ver el caso de RFQ asistido por IA). Nunca clasifica por sí sola una solicitud con consecuencias
Cómo codifica el sistema el modelo
Decisión operativa: Clases con obligaciones distintas
Respuesta del sistema: Una clase en la solicitud; las evaluaciones obligatorias se generan a partir de ella
Decisión operativa: Evaluaciones por función
Respuesta del sistema: Un registro de evaluación por función: conclusión, condiciones, evidencia
Decisión operativa: Go / No-Go de un responsable con nombre
Respuesta del sistema: Cada decisión Go / No-Go como registro con aprobador, evidencia y justificación, no como un valor de estado
Decisión operativa: Un plazo por clase
Respuesta del sistema: Niveles de servicio por clase, con escalado si se incumplen
Decisión operativa: Condiciones que deben sobrevivir a la oferta
Respuesta del sistema: Condiciones enlazadas desde el expediente de decisión con la oferta y con el traspaso al proyecto
Decisión operativa: Decisiones auditables
Respuesta del sistema: Histórico de decisiones por solicitud, con búsqueda entre solicitudes
08Medición
Qué se mide y qué pone en marcha.
| Métrica | Por qué | Responsable | Cadencia | Qué activa |
|---|---|---|---|---|
| Plazo de decisión por clase | Muestra si el plazo de cada clase es realista | Operaciones comerciales | Mensual | Reequilibrar la capacidad de evaluación o los plazos |
| Evaluaciones en plazo, por función | Los retrasos se esconden en las funciones que evalúan | Responsables de cada función | Mensual | Escalar el cuello de botella o dotarlo de recursos |
| Ratio Go / No-Go y motivos | Muestra qué descarta realmente la empresa, y por qué | Dirección del negocio | Trimestral | Ajustar el foco comercial y los criterios de clase |
| Sorpresas tras la adjudicación | Comprueba si las evaluaciones detectaron los riesgos reales | Gestión de proyectos | Trimestral | Reforzar la evaluación que falló |
| Cambios de clase tras la entrada | Si la clase sube a menudo, los criterios no están claros | Operaciones comerciales | Trimestral | Afinar los criterios de clase |
09La segunda capa
Preguntas que cambian el diseño.
Clasificación
- ¿Quién clasifica, y quién puede subir o bajar la clase?
- ¿Se gobierna también una RFI?
- ¿Qué hace que una solicitud sea estratégica y no simplemente grande?
Criterio
- ¿Qué evaluaciones pueden ir en paralelo y cuáles dependen de otras?
- ¿A qué obliga después un «viable con condiciones»?
- ¿Quién decide cuando dos funciones discrepan?
Compromiso
- ¿Cuándo es vinculante un precio?
- ¿Qué hereda el proyecto del expediente de decisión?
- ¿Cuánto tiempo sigue siendo válido un Go si el cliente tarda en decidir?
10Decisiones y entregables
Qué produce el trabajo.
- 01Modelo de clasificación de RFQ
- 02Catálogo de evaluaciones por clase
- 03Matriz de derechos de decisión
- 04Punto de decisión Go / No-Go y registro de decisión
- 05Plazos y reglas de escalado
- 06Traspaso tras la adjudicación