Cómo convertir la compra de automatización en un proceso repetible
Por DBR77 Team · Publicado el


La compra de automatización se vuelve repetible cuando se estandarizan los pocos documentos que necesita todo proyecto y se mantienen al día: una plantilla de brief, un conjunto de reglas para las preguntas de los proveedores, una tabla comparativa, un registro de decisión y un traspaso con lecciones aprendidas. Cada uno tiene un responsable, cada proyecto usa la última versión y cada proyecto termina con una breve revisión que mejora el siguiente. Para una planta mediana, basta con eso. No hace falta un departamento nuevo, solo el hábito de empezar cada proyecto con las últimas plantillas en lugar de una hoja en blanco.
Por qué cada proyecto de automatización empieza desde cero
En muchas plantas, el primer proyecto de automatización lo lleva un ingeniero y un comprador que aprenden sobre la marcha. El siguiente equipo encuentra una carpeta de PDF y correos, pero ningún método, así que redacta un brief nuevo, construye una nueva hoja de comparación y vuelve a discutir quién aprueba qué.
Esto era tolerable mientras la automatización era algo excepcional. En la encuesta de McKinsey a directivos industriales, muchos encuestados esperaban que los sistemas automatizados supusieran el 25 por ciento del gasto de capital en los próximos cinco años. La IFR contabilizó 542.000 robots industriales instalados en 2024, más del doble que diez años antes. Cuando la automatización se convierte en una parte habitual del capex, comprarla proyecto a proyecto, improvisando cada vez, desperdicia tiempo de calendario, dinero y la experiencia por la que la planta ya ha pagado.
El coste se manifiesta en briefs a los que siempre les faltan los mismos datos, en ofertas que no se pueden comparar y en el mismo error de aceptación o de traspaso en el tercer proyecto que en el primero.


Los cinco documentos estándar
Un proceso repetible se apoya en cinco documentos breves que, juntos, llevan un proyecto desde la idea hasta la ejecución.
| Documento | Qué estandariza | Responsable | Cómo mejora |
|---|---|---|---|
| Plantilla de brief | Datos del proceso, volúmenes, tiempos de ciclo, datos del producto, implantación, interfaces, condiciones de la planta, criterios de aceptación | Ingeniería | Añadir las preguntas que hicieron los proveedores la última vez |
| Reglas de preguntas y respuestas | Un solo canal para las preguntas, respuestas compartidas con todos los licitadores, plazo para las preguntas | Compras | Anotar qué respuestas cambiaron las ofertas |
| Tabla comparativa | Las mismas filas para cada oferta: alcance, exclusiones, supuestos, plazo de entrega, precio, hitos de pago, servicio | Compras con ingeniería | Quitar las filas que nunca importaron y añadir las que sí |
| Registro de decisión | Quién decidió, por qué esta oferta, a qué se renunció, riesgos abiertos | Promotor | Releerlo antes de la siguiente adjudicación |
| Traspaso y lecciones aprendidas | Paquete para el equipo de ejecución; breve revisión tras la puesta en marcha | Responsable del proyecto | Trasladar las conclusiones a los otros cuatro |
Cómo redactar el brief se explica en Cómo redactar un brief de automatización que los integradores puedan presupuestar, y los apartados de la RFQ en Qué incluir en una RFQ o RFP de automatización. Para la tabla comparativa, use Cómo comparar ofertas de automatización en una sola tabla.
El registro de decisión es el documento que la mayoría de las plantas se salta. Ocupa una página: las opciones, la elección, los motivos, los riesgos aceptados y quién firmó. Un año después, el motivo por el que se eligió un proveedor más caro está escrito, aunque la persona que lo eligió ya se haya ido.
Quién es responsable del sistema
La responsabilidad sigue a los documentos:
- El promotor (a menudo el director de operaciones o el director de planta) es responsable del resultado y del registro de decisión, y hace cumplir la regla de que todo proyecto use las plantillas.
- Compras es responsable de las reglas de preguntas y respuestas y de la tabla comparativa, y vela por que sean justas para todos los licitadores.
- Ingeniería es responsable de la plantilla de brief y de las filas técnicas de la comparación.
- Operaciones y mantenimiento son responsables de los criterios de aceptación y de las lecciones aprendidas en el funcionamiento del equipo.
Una persona debe custodiar las plantillas y sus versiones. En una planta mediana suele ser un ingeniero de procesos sénior o un comprador que ha llevado varios proyectos, con unas horas al mes dedicadas a ello. Con varios proyectos en curso a la vez, una oficina de proyectos del lado del cliente puede asumir este papel.
Use una misma estructura para cada compra de automatización
En DBR77 Marketplace, cada Technology Challenge sigue la misma estructura guiada y cada oferta llega en el mismo formato. Gratis para fabricantes.
Cómo ser rápido sin perder profundidad técnica
Los documentos estándar agilizan la compra porque eliminan el retrabajo, y las revisiones técnicas se mantienen. Unas pocas reglas ayudan:
- Limite el tiempo de cada etapa, por ejemplo: dos semanas para el brief, de tres a cuatro semanas para las ofertas, una semana para las preguntas, dos semanas para la comparación y la decisión. Dentro de cada plazo, el contenido técnico no es opcional.
- Revise en paralelo y decida una sola vez: ingeniería, operaciones y compras revisan las ofertas al mismo tiempo y después se reúnen una sola vez para decidir. Las opiniones enviadas una tras otra por correo crean semanas de retraso.
- Congele las filas de la comparación en cada ronda. Si las filas cambian cada vez que llega un correo nuevo, los proveedores no pueden responder a una pregunta estable.
- Publique las respuestas que cambian las ofertas. Una aclaración privada que ayuda a un proveedor hace injusta la comparación y suele costar otra ronda.
Mida el propio proceso de compra: semanas desde la idea aprobada hasta el contrato firmado, rondas de aclaraciones y órdenes de cambio causadas por huecos en el brief. Estas cifras muestran dónde hay que mejorar las plantillas.
Cuándo agrupar varias necesidades en una sola compra
Una planta con varias necesidades de automatización siente la tentación de reunirlas en una sola licitación: un proceso, un comité, un proveedor. A veces es lo correcto. A menudo, esconde las partes débiles del alcance dentro de una cifra grande.
Agrupe cuando:
- las células comparten interfaces o flujo de materiales, de modo que un solo proveedor debe ser responsable de la coordinación entre ellas;
- el orden de los trabajos importa para la seguridad o para la continuidad de la producción;
- las necesidades usan la misma clase de tecnología, de modo que los mismos proveedores pueden presupuestarlas bien todas.
Manténgalas separadas cuando:
- las necesidades usan tecnologías distintas (por ejemplo, una célula de paletizado y un puesto de inspección por visión);
- una necesidad está bien definida y la otra todavía no está clara;
- los plazos o los presupuestos son distintos;
- separarlas permitiría competir a proveedores especializados.
Si agrupa, defina igualmente cada parte como un paquete de trabajo propio, con su alcance, sus criterios de aceptación y su línea de precio, para que un paquete débil no pueda esconderse dentro del total.
Cómo ponerlo en marcha en tres pasos
Paso 1: reconstruya dos proyectos anteriores. Tome dos compras de automatización recientes. Anote qué impulsó la decisión, qué información pidieron los proveedores, dónde costó comparar las ofertas y qué salió mal en la ejecución. Lleva unos pocos días y le da el contenido de la versión 1.
Paso 2: publique la versión 1 y úsela en el siguiente proyecto. Mantenga las plantillas breves. Añada un ejemplo cumplimentado de un proyecto anterior, sin los datos sensibles.
Paso 3: revise tras la puesta en marcha y publique la versión 2. Haga una revisión de una hora con quienes compraron y quienes manejan el equipo. Actualice las plantillas, anote qué ha cambiado y por qué, y conserve las versiones antiguas.
Ejemplo ilustrativo: una planta de envases de tamaño medio reconstruye sus dos últimos proyectos y descubre que, en ambos, los integradores preguntaron por la calidad de los palés y la velocidad del proceso anterior después de presupuestar, y que los dos proyectos tuvieron una orden de cambio por ello. La especificación de los palés y la velocidad del proceso anterior pasan a ser campos fijos de la plantilla de brief. El siguiente proyecto recibe ofertas que ya los incluyen.
La misma lógica se aplica a la simulación, es decir, a probar implantaciones y flujos antes de comprar; para ello, empiece por Cómo convertir un gemelo digital en un proceso de decisión repetible.
Cómo ayuda DBR77 Marketplace
En DBR77 Marketplace, la estructura de la licitación es la misma en cada proyecto: cada Technology Challenge pasa por el mismo formulario guiado en ocho pasos, y la madurez que usted elige determina qué campos son obligatorios. Las ofertas llegan en un formato estandarizado con alcance, condiciones y costes, de modo que las filas de su tabla comparativa se mantienen estables. El registro de decisión y las lecciones aprendidas siguen en manos de su equipo, y el panel muestra la cartera de retos, los conceptos y ofertas aceptados y los elementos pendientes de revisión.


Preguntas frecuentes
¿Tiene sentido un proceso estándar para una planta con uno o dos proyectos al año?
Sí, en una versión ligera. Incluso con dos proyectos al año, el segundo equipo puede reutilizar el brief, la tabla comparativa y las lecciones del primero. El esfuerzo es de unos pocos días para ponerlo en marcha y una hora de revisión por proyecto.
¿Encajan las plantillas estándar en proyectos muy distintos?
Sí, si la estructura se mantiene y solo cambia el contenido. Un sistema de transporte y una célula robotizada necesitan datos técnicos distintos, pero ambos necesitan volúmenes, tiempos de ciclo, condiciones de la planta, criterios de aceptación y una comparación justa. Mantenga la plantilla modular, con apartados que se activan según la tecnología.
¿Deberíamos firmar acuerdos marco con unos pocos integradores?
Pueden agilizar trabajos repetidos del mismo tipo con proveedores probados. Consulte el mercado con regularidad, sobre todo para las tecnologías nuevas, para que el acuerdo marco no oculte opciones mejores.
Conclusión
Empiece por reconstruir sus dos últimas compras de automatización: qué impulsó cada decisión, qué preguntaron los proveedores y dónde costó comparar las ofertas. Convierta eso en la versión 1 de las cinco plantillas, úsela en el siguiente proyecto y publique la versión 2 tras la revisión posterior a la puesta en marcha.
Haga que el próximo proyecto sea más fácil que el anterior
Gestione sus compras de automatización con una misma estructura en DBR77 Marketplace, o hable con nuestro equipo sobre cómo implantarla en varios proyectos.
Publique su Technology Challenge · Contacte con el equipo de Marketplace
Fuentes
- McKinsey & Company, Unlocking the industrial potential of robotics and automation, 2023
- International Federation of Robotics, World Robotics 2025 report: Industrial Robots, 2025