Qué preguntarle a un proveedor de ofertas con IA

Todas las demos de ofertas con IA quedan bien. El paquete está escogido, los planos están limpios y la cifra aparece en noventa segundos. De ahí no se aprende casi nada.

La diferencia entre un sistema con el que usted puede defender una oferta y uno que solo arroja una cifra con mucha seguridad se aprecia en cinco preguntas, y ninguna trata de porcentajes de precisión. Nosotros vendemos uno de estos sistemas, así que lea este artículo como la prueba a la que esperamos que nos sometan. Si un proveedor titubea ante cualquiera de las cinco, eso ya le está diciendo algo.

¿Qué hace el sistema cuando no está seguro?

Debe avisarle y mostrarle la hoja de la que surgió la duda. Empiece por aquí, porque este solo comportamiento dice más que cualquier benchmark.

Un sistema de ofertas que resuelve la ambigüedad adivinando es más peligroso que uno que omite datos. Una omisión se detecta en la revisión; alguien nota que falta la línea. Una respuesta equivocada pero segura termina presupuestada, porque se ve exactamente igual que las cuatrocientas líneas correctas que la rodean, y nadie audita una línea que parece terminada.

Cualquier paquete de RFQ real está lleno de ambigüedades. Qué revisión manda. Si los tramos de volumen válidos son los de la hoja de cálculo o los de la carta de presentación. Qué le hace la nota de la hoja 14 al acabado indicado en la hoja 3. El sistema se va a topar con todo eso.

Así que pregunte qué pasa en ese momento. Si la respuesta es distinta de «se le avisa», siga buscando.

Luego pídale que lo demuestre. Entréguele un paquete con una contradicción genuina, una especificación que choca con un plano, y observe si el conflicto vuelve como una excepción marcada, con la hoja y la evidencia adjuntas, o si desaparece en silencio dentro de una cifra.

¿Qué hay que configurar antes de que lea un plano?

La respuesta honesta es «sus tarifas y sus sistemas». La respuesta que debe preocuparle es «sus documentos».

Si un sistema necesita plantillas, una convención de nombres o un modelo de datos antes de poder leer un plano, ese coste de preparación no se paga una sola vez. Se paga cada vez que un cliente organiza la información de otra manera, y para la mayoría de los proveedores eso ocurre con cada programa nuevo. El trabajo recae en su departamento de ofertas con el nombre de «onboarding», y la semana que usted quería eliminar vuelve disfrazada de preparación.

La prueba no le cuesta nada. Envíe el paquete más desordenado que tenga, el de los planos antiguos escaneados y el historial de revisiones perdido en un hilo de correos. Su programa mejor organizado no sirve para esto. Un sistema que solo funciona con un paquete ordenado no se ha probado con lo que usted realmente hace cada semana, y eso lo descubrirá en el cuarto mes en vez de en la segunda semana.

¿Con qué se conecta y quién hace la integración?

Debe llegar a su PLM y su CAD, su ERP, su CRM y las unidades donde de verdad están las ofertas anteriores, y el proveedor debe poder decirle quién hace ese trabajo. Esta es la pregunta que define si usted compra una herramienta de lectura o algo que recuerda.

Leer un plano ya es la parte fácil. El valor está en que el sistema sepa cuánto costó esa operación la última vez que la presupuestó, qué revisión indica su PLM como vigente y a qué se refería el cliente en el hilo de aclaraciones del programa anterior. Nada de eso existe si el sistema no puede llegar a donde vive su historial: PLM y CAD, ERP y compras, CRM, y las unidades compartidas y espacios de trabajo donde realmente están las ofertas anteriores.

Pida la lista concreta de conectores; la palabra «se integra» no basta. Pregunte qué es de solo lectura y qué escribe de vuelta, e insista en que el volcado al ERP sea lo último que se active, nunca lo primero. Pregunte quién hace el trabajo y cuánto tardó con los últimos tres clientes.

Prepárese para que la respuesta honesta sobre los plazos resulte incómoda. El trabajo de integración rara vez es técnicamente difícil y casi siempre es lento por razones de organización, porque necesita a alguien de TI responsable de cada sistema y una revisión de seguridad que nadie ha programado.

¿A dónde van realmente nuestros planos?

Debe recibir, por escrito, la infraestructura identificada por su nombre, una lista nominal de subencargados del tratamiento y un plazo de conservación definido. Los planos de los clientes son los documentos más sensibles de su fábrica. El juego de planos de un Tier 1 es el producto aún no lanzado de otra empresa, normalmente protegido por un NDA con consecuencias serias.

Cuatro cosas que debe obtener por escrito:

• Aislamiento por cliente (tenant), para que sus datos estén separados y nunca mezclados con los de otros proveedores.
• Sin entrenamiento entre clientes, para que su estructura de costes nunca se convierta en una característica del modelo de otra empresa.
• Un informe SOC 2 que usted pueda leer; un sello en una web no cuenta.
• Una respuesta clara sobre las llamadas a modelos: qué proveedores, en qué regiones y con qué condiciones de conservación.

Tarde o temprano, sus propios clientes le harán estas preguntas durante una auditoría a proveedores. Es más fácil tener las respuestas antes de que se las hagan.

¿Puede demostrarlo con ofertas que ya enviamos?

Debe responder que sí sin rodeos, porque es la única demo que se puede evaluar. Un paquete elegido por el proveedor no demuestra nada; usted no tiene forma de saber qué se dejó fuera discretamente.

Lleve un paquete que ya haya presupuestado, preferiblemente uno con el que su proceso actual tuvo dificultades, y pida que lo procesen en directo. Usted ya conoce la respuesta correcta, y eso es justo lo que convierte el ejercicio en una prueba y le quita lo de presentación.

Después compare línea por línea con lo que produjo su equipo. Donde haya diferencias, pregunte de qué hoja salió cada una y por qué. Eso le dice más que cualquier cifra de precisión, porque se mide sobre sus planos, en sus formatos, frente a una respuesta en la que usted ya confía.

A partir de ahí, opere el sistema en paralelo con su proceso actual, sin sustituirlo, con un técnico de ofertas que apruebe todo lo que sale, hasta que la comparación deje de ser interesante.

Un proveedor que no acepta ser evaluado con un paquete que usted ya respondió le está diciendo que la demo era el producto.

Lo que le pedirán a cambio

Nada de esto sale gratis por su parte, y un proveedor que dé a entender lo contrario está describiendo una demo, muy lejos de una implantación. Le pedirán cuatro cosas:

Sus paquetes tal como llegan. Sin limpiarlos, sin renombrarlos y sin cambiar las hojas escaneadas por versiones nativas de CAD.

Sus tarifas, sus rutas de fabricación y sus ofertas anteriores. Un coste objetivo construido con tarifas genéricas del sector es el coste objetivo de la fábrica de otro: defendible en una demo e indefendible frente a un cliente que pregunta por qué ha cambiado su cifra. Todo eso ya existe dentro de su empresa y se entrega tal como está, sin un paso previo de limpieza. Espere que le pidan las ofertas de las que no está orgulloso, porque las que se perdieron por precio y las que se ganaron y luego se comieron el margen señalan dónde el proceso actual ya se equivoca.

Acceso de lectura y el tiempo interno para gestionarlo. Vea la tercera pregunta. El cuello de botella es la agenda de su departamento de TI; el conector es lo de menos.

Una aprobación que de verdad esté en sus manos. El sistema elabora el borrador y el técnico de ofertas firma, y eso tiene que mantenerse incluso los días en que resulta incómodo. Su sistema de calidad necesita que la firma signifique que una persona revisó el trabajo, y tarde o temprano un auditor preguntará si la aprobación es un control o un simple trámite. Una implantación en la que, sin que nadie lo note, aparece una vía de autoaprobación para piezas pequeñas ya ha eliminado el control, y la primera vez que eso importe será la primera vez que algo salga mal.

Este último punto es lo único de este artículo que ningún proveedor puede hacer por usted.