Forward Deployed Engineering: guía completa para empresas industriales
El forward deployed engineering (FDE) es un modelo de entrega de software en el que los ingenieros del proveedor trabajan dentro de las operaciones del cliente, construyen el sistema sobre sus datos y sus herramientas reales, lo ponen en producción y siguen siendo responsables de su buen funcionamiento después de la puesta en marcha.
- Publicado
- Actualizado
- Tiempo de lectura
- 37 min
- Autor
- Mehdi Yacoubi
El ingeniero que hace este trabajo se llama forward deployed engineer, abreviado FDE; en español, un ingeniero desplegado en el cliente. Esta guía se dirige a la dirección general y a las direcciones de operaciones, técnica y de sistemas de las empresas de construcción, minería, logística, industria y agroalimentación. Explica cómo funciona el modelo, qué exige a la empresa cliente, cómo medirlo y cómo elegir un proveedor, a partir de los despliegues que los ingenieros de Mirage llevan a cabo en Francia, España, Marruecos, Egipto, Arabia Saudí y Estados Unidos.
Lo esencial en seis puntos
- Un FDE construye y opera un sistema en producción. No entrega una recomendación, ni una maqueta, ni un documento de especificaciones.
- El trabajo empieza sobre el terreno, junto a las personas que hacen el trabajo, antes de la primera línea de código.
- La dificultad principal de un proyecto de IA industrial rara vez está en el modelo. Está en el acceso a los datos, en las excepciones y en la escritura de los resultados en los sistemas existentes.
- Un buen modelo FDE combina dos equipos: ingenieros de terreno que resuelven el problema de un cliente, y un equipo de producto que convierte lo que ha funcionado en una plataforma reutilizable.
- En Mirage, una prueba de concepto funciona sobre los documentos del cliente una semana después de la primera reunión, y el primer workflow entra en producción en 4 a 6 semanas en general.
- El modelo no sirve para todo: una necesidad estándar, estable y bien cubierta por un software del mercado se resuelve mejor sin ingenieros en sitio.
¿Qué es el forward deployed engineering?
El forward deployed engineering se define por tres cosas: el lugar del trabajo, la responsabilidad del ingeniero y la duración de su compromiso. Las tres tienen que darse a la vez. Un ingeniero en sitio que entrega un informe hace consultoría; un ingeniero que construye a distancia a partir de unas especificaciones hace integración.
El lugar. El ingeniero trabaja en el entorno del cliente: sus oficinas, sus obras, sus almacenes, sus minas, sus sistemas. Aprende el workflow con quienes lo practican todos los días. El término «forward» viene del vocabulario militar, donde una unidad desplegada en vanguardia opera en contacto con el terreno y no desde una base en la retaguardia.
La responsabilidad. El FDE responde de un resultado operativo: expedientes procesados, horas devueltas al equipo, errores evitados. Escribe el código, instala los conectores, define las reglas de gestión de las excepciones y corrige cuando algo se rompe.
Un desarrollador de producto aporta una capacidad a muchos clientes; un FDE aporta muchas capacidades a un solo cliente, el tiempo necesario para resolver su problema. Su trabajo se juzga por el resultado, y el código es solo un medio. Un buen FDE incluso busca volverse innecesario en el problema que ha tratado: si el cliente vuelve a necesitarlo para lo mismo, el problema no estaba realmente resuelto.
La duración. El compromiso no termina con las pruebas de aceptación. Los ingenieros que construyeron el sistema lo operan bajo la supervisión del cliente, lo ajustan con los datos reales y después pasan al workflow siguiente.
Por qué el contexto cuenta más que las especificaciones
Un proceso industrial real contiene un conocimiento tácito que ningún documento recoge. Un técnico de mediciones sabe de qué cota no fiarse en cierto tipo de plano. Un jefe de tráfico sabe qué cliente envía sus pedidos sin unidades. Un jefe de turno sabe qué máquina envía datos falsos cuando llueve.
La entrega de software clásica aplana ese conocimiento en una lista de requisitos redactada en una reunión. El forward deployed engineering parte del principio contrario: el contexto es el recurso escaso, y la única forma de captarlo es ir a buscarlo allí donde se hace el trabajo.
Los sustantivos y los verbos de la empresa
Lo primero que un FDE anota en una empresa son sus sustantivos y sus verbos. Los sustantivos son los objetos que la organización considera reales: un proyecto, un lote, una unidad de obra, un camión, un pedido, un cliente. Los verbos son la forma en que esos objetos avanzan: cómo se valida una oferta, qué debe cumplirse para cerrar una certificación de obra, quién firma una excepción a las once de la noche y qué pasa cuando esa persona está de vacaciones.
Un mismo objeto suele tener varios nombres según el departamento. El comercial habla de oportunidad, el departamento de estudios de obra, contabilidad de centro de coste y el software de presupuestos de identificador de proyecto. Cada paso de un nombre a otro esconde una regla de traducción, y es ahí donde los sistemas se rompen cuando alguien cambia una definición.
Casi nada de esto está escrito. Esas reglas viven en la cabeza de las pocas personas que llevan el tiempo suficiente en la empresa como para no notarlas ya, y en una hoja de cálculo creada hace años de la que depende todo el equipo. Por eso tienen tanto valor, y por eso también no basta con preguntarlas en una reunión: hay que observarlas.
El vocabulario que conviene conocer
| Término | Lo que designa |
|---|---|
| Forward deployed engineer (FDE) | El ingeniero que construye y opera el sistema en las instalaciones del cliente |
| Forward deployed software engineer (FDSE) | Variante del mismo título, que pone el acento en el desarrollo de software |
| Ingeniero desplegado en el cliente | La traducción al español más fiel |
| Applied AI engineer, deployment engineer | Títulos cercanos, usados a menudo para funciones parecidas en los proyectos de IA |
| Workflow | Una secuencia de trabajo concreta: tramitar un pedido, preparar unas mediciones, revisar una factura de transporte |
| Excepción | Un caso que las reglas no saben resolver solas y que se deriva a una persona |
| Puesta en producción | El momento en que el sistema procesa los volúmenes reales, en los sistemas del cliente, bajo supervisión |
El glosario de Mirage recoge estos términos y las nociones cercanas, como el agente de IA.
¿De dónde viene el modelo?
El forward deployed engineering nació a mediados de los años 2000 en empresas de software de análisis de datos que trabajaban para la defensa y los servicios de inteligencia. Esos clientes no podían recibir un software estándar: redes aisladas, datos sensibles, arquitecturas únicas. Las empresas de software enviaron entonces a sus ingenieros a trabajar en las instalaciones del cliente.
De los centros sensibles a las fábricas
El modelo se extendió después a la industria pesada, la sanidad, las finanzas y la aeronáutica. El esquema seguía siendo el mismo: pequeños equipos de ingenieros, instalados en el cliente varios días por semana, con mucha autonomía.
Su ventaja era la velocidad. Frente a integradores acostumbrados a proyectos de varios años en cascada, un equipo pequeño entregaba en pocas semanas una primera herramienta que los operadores usaban de verdad. En un taller de montaje, podía ser una interfaz única que reunía órdenes de trabajo, piezas que faltan y no conformidades, con una búsqueda en el historial de defectos ya tratados. Funciones sencillas, pero desplegadas allí donde se hace el trabajo.
Del servicio al producto
Durante mucho tiempo el modelo recibió críticas: muchos veían en él consultoría disfrazada de empresa de software. Sin embargo, las empresas que lo practicaron con disciplina siguieron la trayectoria inversa. Las herramientas que los ingenieros de terreno improvisaban en cada cliente (ingesta de datos, visualización, creación de aplicaciones de negocio) las retomó un equipo de producto, que las generalizó y las vendió como plataforma.
Ese paso del servicio al producto cambia la economía del modelo: un software vendido a varios clientes genera márgenes que una actividad facturada por tiempo dedicado nunca alcanza. De ahí sale la lección más útil para un comprador: un modelo FDE sano financia ingenieros en sitio para construir un producto, no para vender días.
El regreso del modelo con la IA
Entre 2024 y 2026, el modelo salió de su nicho. Los laboratorios de modelos de lenguaje, las grandes empresas de software empresarial y una nueva generación de compañías especializadas en agentes de IA crearon equipos de forward deployed engineers, y las ofertas de empleo con ese título se multiplicaron.
La razón es sencilla: un modelo de IA no crea ningún valor mientras no esté conectado a los datos, las reglas y los sistemas de una empresa concreta. Es exactamente el trabajo para el que se inventó el FDE.
Por qué la IA agéntica devuelve el FDE al primer plano
La mayoría de los proyectos de IA en las empresas se detienen entre la demostración y la producción. La demostración funciona sobre una muestra limpia; la producción recibe escaneos torcidos, archivos Excel modificados a mano, correos sin adjunto y casos que nadie había mencionado. El forward deployed engineering existe para salvar esa distancia.
Los problemas que un software estándar, vendido igual a mil empresas, podía resolver ya están resueltos en gran parte. Lo que queda está dentro de las empresas: workflows desordenados, poco documentados, imposibles de entender desde una llamada de descubrimiento. Ese último tramo, a menudo una pequeña parte del workflow, decide sin embargo si el resto se usará. Es el terreno del forward deployed engineering.
El modelo es la parte fácil
Un modelo de lenguaje reciente sabe leer un plano, una orden de compra o una carta de porte. Para ponerlo a trabajar en una operación hay que resolver seis problemas que son propios de cada empresa.
| Problema | Lo que hay que hacer | Dónde suele bloquearse |
|---|---|---|
| Acceso a los datos | Conectarse a los buzones de correo, las carpetas compartidas, los escaneos y el software de gestión, en los formatos en que los documentos llegan de verdad | Los permisos internos, no la técnica |
| Permisos | Definir qué lee el sistema, dónde escribe y con qué rol | La validación por parte del departamento de sistemas y de seguridad |
| Excepciones | Escribir una regla para cada caso recurrente o derivarlo a una persona | Los casos raros que solo aparecen en producción |
| Escritura en los sistemas | Enviar el resultado al ERP, al TMS, al WMS o a la base de precios | Los sistemas antiguos sin una API limpia |
| Supervisión | Mostrar al equipo qué ha hecho el sistema, qué ha señalado y por qué | El diseño de la pantalla de revisión |
| Responsabilidad | Designar quién decide del lado del cliente y quién corrige del lado del proveedor | La falta de un responsable funcional disponible |
Una regla empírica bien conocida en los proyectos de datos empresariales: la mayor parte del esfuerzo va al acceso a los datos, a su limpieza y a su conciliación, y solo una pequeña parte al análisis. Los agentes de IA no cambian esa proporción. La hacen más visible, porque un agente necesita leer y escribir en los sistemas críticos de la empresa para ser útil.
Un agente que escribe en sus sistemas necesita a alguien en sitio
Un cuadro de mando se limita a leer. Un agente de IA crea un pedido en el ERP, propone unas mediciones, prepara una declaración aduanera o asigna un camión. Cada acción compromete a la empresa. Hacen falta, por tanto, reglas escritas con las personas que hoy son responsables de ese trabajo, y un ciclo de corrección rápido durante las primeras semanas. La comparativa agentes de IA vs RPA explica por qué la automatización mediante scripts ya no basta para estas tareas.
La IA pone el modelo al alcance de presupuestos más modestos
Durante mucho tiempo, el FDE estaba reservado a contratos de varios millones: enviar a ingenieros sénior a un cliente durante meses costaba caro. Las herramientas de IA han cambiado la ecuación. Un ingeniero produce hoy en pocos días lo que antes exigía semanas, y parte del trabajo de adaptación (lectura de nuevos formatos, reglas de negocio, interfaces) se hace sin partir de cero. Proyectos antes reservados a las grandes cuentas se vuelven accesibles para las empresas medianas.
Es también lo que permite a Mirage desplegar sobre una plataforma común en lugar de reconstruir cada proyecto: los ingenieros adaptan componentes probados a los documentos y a los sistemas de cada cliente.
Una semana tipo de un FDE en un cliente industrial
La forma más sencilla de entender el oficio es seguir una semana real. El ejemplo de abajo es el de una constructora general que quiere acelerar sus mediciones y el análisis de los pliegos de sus licitaciones. El esquema es el mismo en una mina, un almacén o una fábrica.
| Día | Dónde | Lo que hace el ingeniero | Lo que sale de ahí |
|---|---|---|---|
| Lunes | Departamento de estudios | Sentado junto a dos técnicos de mediciones, observa cómo preparan una licitación en curso: planos en PDF, pliego de prescripciones técnicas, presupuesto y mediciones, revisiones de planos | La lista de las etapas reales, distinta del procedimiento escrito |
| Martes | Departamento de estudios | Anota cada excepción que encuentra: cota ilegible, revisión de plano no anunciada, lote mal dividido, unidad ausente | Un primer mapa de las excepciones, ordenadas por frecuencia |
| Miércoles | Despacho prestado por el cliente | Instala los conectores en el servidor de planos y en la hoja de cálculo de presupuestos, y escribe las primeras reglas | Un agente que trabaja sobre los expedientes reales, en solo lectura |
| Jueves | Departamento de estudios | El técnico de mediciones y el agente procesan el mismo lote en paralelo; el ingeniero compara línea por línea | Las diferencias, con su causa |
| Viernes | Sala de reuniones | Revisión de las diferencias con el jefe del departamento de estudios: qué se convierte en regla y qué sigue siendo una decisión humana | Las reglas de la semana siguiente y un informe de avance al patrocinador |
En la práctica, la semana se reparte más o menos a partes iguales entre conversaciones con los equipos y trabajo de construcción. La presencia en sitio varía según el proyecto y la geografía, a menudo en torno a la mitad del tiempo. Dos o tres jornadas en sitio bien elegidas (una observación, una revisión de excepciones, una puesta en producción) valen más que cinco jornadas de presencia sin un objetivo preciso.
Hablar el idioma del oficio
La eficacia de un FDE depende de la velocidad con la que aprende el vocabulario del cliente. En construcción, debe manejar sin equivocarse los pliegos, el pliego de prescripciones técnicas, el presupuesto con sus mediciones y su cuadro de precios, las certificaciones de obra y las órdenes de cambio. En una mina, leyes del mineral, ciclos de acarreo y disponibilidad de los equipos. En logística, conocimientos de embarque, declaraciones aduaneras, CMR e Incoterms. Un ingeniero que habla de «ganar en eficiencia» pierde a la sala; un ingeniero que habla de plazo de entrega de ofertas y de porcentaje de desviación en las cantidades la mantiene.
La página mediciones y presupuestos da una idea del nivel de detalle del oficio que se espera.
Leer la sala tanto como el código
La competencia menos visible del FDE es social. Llega a una organización que no conoce, a menudo frente a equipos que temen ser sustituidos o que ya han visto pasar proyectos informáticos sin futuro. Tiene que ganarse la confianza de los operadores, entender quién decide de verdad y saber cuándo insistir y cuándo dejar una decisión en manos del cliente.
Esa confianza se gana con pruebas. Un primer resultado útil en una o dos semanas, sobre los expedientes reales del equipo, pesa más que una presentación del calendario del proyecto. En Mirage, el objetivo declarado es una prueba de concepto sobre los documentos del cliente una semana después de la primera reunión.
Buscar la razón que nadie dice
Cuando una persona bloquea un cambio sin una razón clara, casi siempre está protegiendo algo que necesita para hacer su trabajo. Un caso típico: un responsable de control de calidad rechaza durante meses un nuevo formato de archivos, con objeciones que cambian en cada reunión. Un ingeniero pasa una mañana a su lado y entiende que verifica los datos abriendo los archivos en su ordenador y revisándolos a ojo. El nuevo formato le quitaba su única herramienta de control.
La solución no requería argumentos ni arbitrajes: un visor adaptado, construido en unas horas, y la migración se validó acto seguido. Esa persona nunca habría dado esa razón en una entrevista, porque desde su punto de vista era evidente. Solo la observación del trabajo real la hace aparecer.
El motor de dos velocidades: el terreno y el producto
Un modelo FDE sólido se apoya en dos equipos que trabajan juntos. El primero está sobre el terreno y resuelve, rápido, el problema de un cliente concreto. El segundo está en la sede y convierte lo que ha funcionado en ese cliente en componentes reutilizables para todos los demás.
El equipo de terreno escribe código que resuelve el problema del día. Acepta atajos para entregar un primer resultado en pocos días, porque un operador convencido al cabo de una semana vale más que una arquitectura perfecta al cabo de seis meses. No busca la generalidad: su misión es que el workflow del cliente funcione.
El equipo de producto observa lo que los ingenieros de terreno rehacen de un cliente a otro: un conector a un ERP, la lectura de un tipo de plano, una pantalla de revisión de excepciones. Los convierte en componentes sólidos, probados y mantenidos. Esos componentes dan después velocidad al terreno, que ya no tiene que reconstruirlos.
El vínculo entre los dos equipos depende de la calidad de la información que circula. «No funciona» no ayuda a nadie. Un aviso útil nombra el tipo de caso que falla, el dato que falta y la frecuencia del problema, por ejemplo: «los planos de estructura escaneados en baja resolución hacen fallar la lectura de las cotas, en una parte notable de los planos de este cliente». Ese nivel de precisión permite al equipo de producto mejorar el sistema para todos los clientes, y no solo para el que informó del problema.
La señal más valiosa rara vez es una petición de funcionalidad. Tres clientes que piden la misma pantalla es algo fácil de detectar y vale poco. Tres despliegues en los que los ingenieros esquivan el mismo límite de la plataforma indican que la plataforma se queda estrecha para lo que el terreno encuentra, y es ella la que hay que ampliar.
Cada atajo se convierte en un sistema que mantener
Un script escrito en una tarde para sacar de un apuro a un cliente puede seguir funcionando un año después, sobre miles de operaciones, sin que nadie lo haya diseñado nunca para durar. La disciplina de un equipo FDE consiste en decidir, para cada corrección, si se incorpora a la plataforma o si se descarta deliberadamente en cuanto ha cumplido su función. Una corrección que no toma ninguno de los dos caminos se convierte en deuda, y a menudo es el cliente quien acaba cargando con ella.
Este ciclo produce un efecto acumulativo. Cada despliegue hace más rápido el siguiente, y cada cliente se beneficia de lo aprendido en los demás sin que sus datos salgan de su perímetro.
Lo que esto cambia para el comprador
La pregunta sobre el ciclo entre terreno y producto es la más importante que se le puede hacer a un proveedor, porque determina lo que usted recibirá dentro de tres años.
| Perfil del proveedor | Lo que obtiene al principio | Lo que pasa después |
|---|---|---|
| Ingenieros de terreno sin producto | Un sistema a medida, entregado rápido | Una deuda técnica que hereda su empresa, una dependencia de las personas que lo escribieron, costes que siguen a los días facturados |
| Producto sin ingenieros de terreno | Un software sólido y mantenido | Una brecha entre el software y su workflow real, que cubren sus equipos o que nunca se cubre |
| Terreno y producto conectados | Un sistema adaptado a su workflow, construido sobre componentes mantenidos | Actualizaciones, parches de seguridad y mejoras que vienen de otros despliegues |
En Mirage, los ingenieros despliegan sobre la plataforma Mirage, la capa común que reúne los conectores (más de 200 sistemas a día de hoy), la lectura de documentos, las reglas de negocio y la supervisión. El trabajo específico del cliente se concentra en lo que le es propio: sus documentos, sus excepciones, sus reglas de validación.
Sin plataforma, cada despliegue aprende cómo funciona una empresa, entrega un sistema hecho a su medida y después pierde ese conocimiento al terminar el encargo: el cliente siguiente vuelve a empezar de cero. Es consultoría, a menudo de gran calidad, pero no se acumula. Con una plataforma, cada empresa cartografiada hace más rápido el despliegue siguiente y más preciso el producto.
¿A quién rinden cuentas los FDE?
La dependencia jerárquica de los forward deployed engineers dice mucho de lo que usted recibirá. Si dependen de ventas, se les juzga por la cuenta en curso: firmar, ampliar, renovar. Si dependen de producto, cada despliegue también debe dejar algo de lo que pueda partir el siguiente. Los dos oficios son útiles, pero un proveedor cuyos FDE responden solo a objetivos comerciales vende en realidad horas.
Lo que protege a un proveedor FDE de sus competidores no es el modelo de IA, que todos alquilan al mismo proveedor, ni el mapa de un cliente concreto, que cualquiera puede esbozar en una tarde. Es la comprensión acumulada, actualizada y verificada de cómo funcionan de verdad las empresas de un sector, construida equivocándose en clientes, siendo corregido e incorporando la corrección a la plataforma. Para el comprador, es un criterio sencillo: un proveedor que ya ha desplegado en empresas como la suya llega sabiendo qué preguntas importan.
FDE, consultoría, integrador, software, staff augmentation: ¿qué diferencias hay?
El forward deployed engineering se distingue de los demás modelos por un punto preciso: el proveedor construye el sistema, lo pone en producción y sigue siendo responsable de él mientras funcione. Los demás modelos se detienen antes, o dejan la operación en manos del cliente.
| Modelo | Lo que obtiene | Quién construye y opera | Cuándo se detiene el proveedor | Cómo se factura | La mejor opción cuando |
|---|---|---|---|---|---|
| Forward deployed engineering | Un sistema en producción sobre sus documentos y sus sistemas | El proveedor construye y opera; su equipo supervisa y resuelve las excepciones | No en la puesta en marcha: sigue con el sistema y luego pasa al workflow siguiente | Piloto a precio cerrado y luego suscripción según volúmenes | El workflow depende de controles informales, de varios sistemas y de excepciones que solo aparecen en producción |
| Consultoría de estrategia u organización | Un diagnóstico, un proceso objetivo, recomendaciones | Usted o un tercero lo implementan | Al entregar las recomendaciones | Jornadas de consultoría o estudio a precio cerrado | La pregunta abierta es qué cambiar, no cómo operarlo |
| Consultora tecnológica o integrador | Un sistema configurado o desarrollado según unas especificaciones | El integrador construye; su departamento de sistemas opera tras las pruebas de aceptación | En la aceptación, y luego contrato de mantenimiento | Precio cerrado o por horas, más mantenimiento | La necesidad es estable, está bien especificada y su departamento de sistemas tiene medios para operar el resultado |
| Empresa de software (SaaS) | Un producto estándar, igual para todos los clientes | La empresa de software construye; su equipo configura y usa | Nunca, pero el producto sigue el ritmo de la empresa de software | Licencia por usuario o por módulo | Un producto del mercado ya cubre el workflow con una simple configuración |
| Preventa técnica | Una demostración o una prueba de concepto durante la venta | El ingeniero de preventa, y luego sus equipos o un integrador | A la firma | Incluido en la venta | El producto ya está elegido y se trata de comprobar que encaja |
| Externalización de desarrolladores por horas (staff augmentation) | Desarrolladores adicionales en sus equipos | Sus equipos dirigen, los desarrolladores ejecutan | Al final del encargo | Tarifa por hora o por día | Sabe exactamente qué construir y le faltan manos |
Estas fórmulas se combinan a menudo. Una consultora puede identificar los workflows que hay que tratar, un despliegue FDE puede ponerlos en producción y un software del mercado puede cubrir las necesidades estándar de alrededor. Ningún modelo responde a todos los problemas.
La confusión más frecuente: FDE y externalización por horas
Los dos sitúan ingenieros en el cliente, pero la responsabilidad no está en el mismo lugar. En la externalización por horas, el cliente dirige el trabajo y responde del resultado. En el forward deployed engineering, el proveedor responde del resultado: si el sistema no procesa los expedientes como se acordó, le toca a él corregirlo.
La página comparativas sitúa a Mirage frente al software especializado por oficio.
Cómo se desarrolla un despliegue FDE, paso a paso
Un despliegue de Mirage sigue cinco etapas en el mismo orden, sea cual sea el sector: observar, cartografiar, construir, operar, ampliar. El cliente tiene dos puntos de decisión en los que puede parar: después de la prueba de concepto y al final del piloto. La suscripción anual solo empieza cuando el primer workflow está en producción.
- Primera reunión (día 0). De treinta minutos a una hora sobre un workflow concreto: los documentos afectados, los sistemas en los que se introducen, los volúmenes por semana. El cliente comparte algunos documentos reales, anonimizados si hace falta.
- Prueba de concepto (alrededor de una semana después). Los ingenieros muestran el sistema procesando los documentos del cliente, no una demostración genérica. Es el primer punto de decisión.
- Observar (piloto, semanas 1 y 2). Los ingenieros pasan tiempo con el equipo de operaciones antes de escribir código de producción: cómo se hace realmente el trabajo, dónde se atasca, qué decisiones corresponden a una persona.
- Cartografiar. Workflows, excepciones, fuentes de datos, controles manuales y puntos de escalado se recogen con el equipo. Se elige el workflow por el que empezar, en general el que combina mayor volumen y reglas más claras.
- Construir. El sistema se construye en torno a las restricciones observadas: conectores a los sistemas existentes, reglas propias del cliente, derivación de los casos dudosos a una persona.
- Operar (primer workflow en producción, en general entre 4 y 6 semanas). El sistema procesa los volúmenes reales, bajo supervisión. Las excepciones se revisan con el equipo y las reglas se ajustan cada semana. Fin del piloto, segundo punto de decisión.
- Ampliar. Cuando el primer workflow se considera fiable, el mismo equipo pasa al siguiente, sobre la misma plataforma. El contrato pasa a una suscripción anual calculada según los volúmenes.
Un workflow que atraviesa varios sistemas o varios centros puede necesitar más de 6 semanas. Ese plazo se discute desde la primera reunión, no a mitad del proyecto.
Por qué empezar en pequeño
El primer workflow sirve para demostrar el valor y para construir la relación de confianza. Un alcance demasiado amplio al principio diluye el esfuerzo, multiplica los accesos que hay que conseguir y retrasa el primer resultado visible. Un alcance estrecho y voluminoso (los pedidos recibidos por correo, las mediciones de un tipo de unidad de obra, las facturas de un tipo de transporte) da un resultado medible en pocas semanas y sirve de base para lo que viene después.
La regla es entregar primero la unidad más pequeña que funcione de principio a fin: un tipo de documento, leído, controlado y escrito en el sistema de destino. Después se amplía a otros formatos, centros y casos cercanos.
Validar sobre un conjunto de referencia antes de la producción
Antes de escribir en los sistemas del cliente, los ingenieros reúnen con el responsable funcional un conjunto de casos de referencia: documentos reales cuyo resultado correcto se conoce, excepciones incluidas. Ese conjunto traduce en pruebas lo que el equipo sabe del oficio. El sistema tiene que procesarlo correctamente antes de cualquier puesta en producción, y el conjunto se vuelve a ejecutar con cada modificación de las reglas, para comprobar que una corrección no rompe otra.
La página forward deployed engineering en Mirage resume este método y los compromisos de plazo.
El verdadero obstáculo: el acceso a los datos
En un despliegue FDE, el riesgo principal está en el acceso a los datos, mucho antes que en la técnica. Un piloto de ocho semanas puede pasar siete semanas consiguiendo autorizaciones y una semana improvisando una demostración. Este escenario es frecuente en las grandes organizaciones, y se evita casi por completo con una preparación hecha antes de la firma.
Tres etapas, tres dificultades
Conseguir el acceso. Los datos útiles están dispersos: buzones de correo compartidos, servidores de planos, ERP, TMS, hojas de cálculo, software de básculas, telemática de la maquinaria. Cada fuente tiene un propietario, y cada propietario tiene sus razones para decir que no o para decir «más adelante». Algunos equipos obtienen parte de su papel del control que ejercen sobre una fuente de datos y ven un nuevo sistema como una amenaza.
Limpiar y transformar. Los documentos reales llegan como PDF escaneados, archivos Excel modificados a mano o fotos tomadas en obra. Las mismas entidades tienen nombres distintos de un sistema a otro: un cliente, un artículo, una máquina, una obra. Conciliarlas exige reglas escritas con las personas del oficio.
Los datos reales también tienen huecos que los datos de prueba nunca tienen. Una fecha vacía interpretada como el 1 de enero de 1970, una cantidad introducida sin unidad, una referencia de cliente copiada con una errata: un sistema diseñado con ejemplos limpios puede venirse abajo el primer día en producción. Solo un ingeniero presente cuando el sistema funciona con los datos reales asume la responsabilidad de esa distancia entre el diseño y la realidad.
Hacerlos accesibles. Una vez limpios, los datos tienen que estar disponibles para el agente y para las personas que lo supervisan, con los permisos adecuados. Un resultado que se queda en una herramienta aparte acaba volviéndose a introducir a mano.
Lo que abre los accesos: la seguridad integrada en el sistema
Parte de las negativas de acceso se basa en preocupaciones de seguridad legítimas. La mejor respuesta es integrar los controles en la capa que maneja los datos: permisos por rol, acceso limitado a los datos estrictamente necesarios, registro de cada acción del agente, solo lectura mientras las reglas no estén validadas. Bien diseñado, un despliegue hace la circulación de los datos más trazable que antes, y el propietario del dato gana visibilidad.
Lo que hay que preparar antes del piloto
- La lista de las fuentes de datos del workflow elegido, con el nombre de su propietario.
- Un acuerdo por escrito de cada propietario sobre lo que el sistema leerá y, más adelante, escribirá.
- Un conjunto representativo de documentos reales, excepciones incluidas, y no solo los casos limpios.
- Un entorno de pruebas o un acceso en solo lectura para las primeras semanas.
- Un interlocutor del departamento de sistemas disponible para abrir las conexiones en la misma semana.
El artículo seguridad de datos e IA en construcción y la página seguridad detallan las prácticas de Mirage en estos puntos.
Lo que la empresa cliente debe poner sobre la mesa
Un despliegue FDE pide poco tiempo a la empresa cliente, pero pide a las personas adecuadas en el momento adecuado. Bastan cuatro funciones, y un despliegue al que le falta una casi siempre se ralentiza.
| Función | Quién, en general | Lo que se le pide | Lo que pasa si falta |
|---|---|---|---|
| Patrocinador | Un miembro de la dirección general o de operaciones | Elegir el workflow, decidir las prioridades, desbloquear los accesos | El proyecto espera decisiones que nadie toma |
| Responsable funcional | El jefe del departamento afectado (estudios, administración de ventas, operaciones, compras) | Explicar las reglas, resolver las excepciones, validar los resultados cada semana | Las reglas se adivinan en lugar de escribirse |
| Operadores | Dos o tres personas que hacen el trabajo todos los días | Dejarse observar y después revisar los casos señalados por el sistema | El sistema reproduce el procedimiento escrito en lugar del trabajo real |
| Interlocutor de sistemas | Un responsable de sistemas o de seguridad | Abrir los accesos, validar los permisos, seguir la integración | Las conexiones tardan semanas en lugar de días |
Los compromisos implícitos
Además de las funciones, cuentan tres compromisos. Aceptar que las primeras semanas de producción incluyan correcciones: un sistema que señala sus dudas es un sistema que funciona. Medir a partir de la situación de partida, lo que supone conocer los volúmenes y los tiempos actuales. Dejar que los ingenieros vean el trabajo real, incluido lo que no figura en ningún procedimiento.
El sistema no les quita la decisión a los equipos. Asume el trabajo repetitivo de lectura, introducción de datos y conciliación, y deriva a una persona cada caso que requiere criterio. Los equipos de operaciones conservan el control de las decisiones críticas.
El FDE por sector: construcción, minería, logística, industria, agroalimentación
El modelo FDE da sus mejores resultados allí donde el trabajo se basa en documentos heterogéneos, reglas de negocio tácitas y varios sistemas que no se comunican entre sí. Es el caso de la mayoría de los sectores industriales. Los ejemplos siguientes son despliegues de Mirage publicados; las cifras son las de cada caso de estudio.
Construcción e ingeniería
Las constructoras manejan volúmenes considerables de planos, documentos escritos y presupuestos, con plazos de entrega de ofertas cortos. El trabajo de los ingenieros se centra en las mediciones, el análisis de los pliegos de licitación, el control de coherencia entre planos y pliego de prescripciones técnicas, y la preparación de los presupuestos y de las certificaciones de obra.
- En un grupo de ingeniería industrial activo en Marruecos, un módulo de mediciones de tuberías lee los isométricos y produce por separado la lista de materiales y el despiece, y cada cantidad sigue siendo verificable en su plano. Resultado: de 80 a 90 % menos de tiempo de mediciones de tuberías (caso de estudio).
- En una constructora de Casablanca, los ingenieros trabajaron sobre los proyectos y los planos reales: extracción de mediciones, presupuestación de ofertas, control de coherencia entre revisiones de planos y documentos del expediente. Tres agentes funcionan en producción, y cada medición es trazable hasta su plano de origen (caso de estudio).
Para ir más lejos: construcción, mediciones y presupuestos y la guía completa de la IA en la construcción.
Minería y canteras
Una mina combina maquinaria, combustible, pesajes, transporte y mantenimiento, con datos repartidos entre telemática, hojas de cálculo e informes de turno. Los ingenieros tienen que trabajar en sitio, porque los flujos físicos y las limitaciones del terreno no se entienden a distancia.
- En un operador logístico y minero marroquí, los ingenieros trataron primero los documentos de transporte, y después el combustible, la maquinaria minera, una sala de control y un asistente privado. Cinco sistemas están en producción: 70 % menos de introducción manual de datos en los documentos de transporte y 12 % menos de consumo de diésel en la flota (caso de estudio).
Para ir más lejos: minería y la sala de control con IA para las operaciones mineras.
Transporte y logística
Agentes de carga, transitarios y transportistas reciben solicitudes de cotización, conocimientos de embarque, declaraciones aduaneras y facturas en todos los formatos. El ahorro viene de la lectura fiable de esos documentos y de su introducción directa en el TMS.
- En un grupo de intermediación de transporte, se construyeron en sitio dos entornos de agente de cotización, uno para carga completa y otro para grupaje, con los documentos de cada equipo y una conexión al TMS del grupo. Más del 90 % de las solicitudes de cotización estándar se procesan automáticamente (caso de estudio).
Para ir más lejos: logística y la calculadora de auditoría de facturas de transporte.
Agroalimentación y distribución
Los distribuidores reciben pedidos por correo electrónico, en PDF, en hoja de cálculo o en el cuerpo del mensaje, cada uno con sus referencias y sus unidades. El trabajo de los ingenieros consiste en aplicar las reglas comerciales del cliente y crear el pedido en el ERP.
- En un distribuidor de productos lácteos ecológicos, una cadena lee los pedidos de los clientes recibidos por correo en todos los formatos, aplica las reglas de negocio y crea el pedido en el ERP. Pasan 48 segundos de mediana entre el correo y el pedido listo; alrededor del 7 % de los pedidos se señalan para revisión humana, y ninguno se pierde (caso de estudio).
Para ir más lejos: cómo automatizar la entrada de pedidos en el ERP.
Industria manufacturera y sistemas críticos
En una fábrica, los ingenieros trabajan sobre las órdenes de fabricación, las no conformidades, las compras y la preparación de la producción, a menudo a partir de planos y listas de materiales. Los entornos críticos (centros sensibles, infraestructuras, defensa) exigen además despliegues aislados de la red y una trazabilidad completa de cada acción.
Para ir más lejos: industria, sistemas estratégicos y todos los casos de estudio.
Medir un despliegue FDE
Un despliegue FDE se mide con indicadores operativos, definidos antes del arranque y seguidos cada semana. Mirage sigue las mismas cinco medidas en cada despliegue, desde la primera reunión.
| Medida | Lo que cuenta | Orden de magnitud publicado |
|---|---|---|
| Plazo hasta la prueba de concepto | Los días entre la primera reunión y una prueba de concepto que funciona sobre los documentos del cliente | Una semana |
| Plazo hasta el primer workflow en producción | El tiempo hasta que el primer workflow funciona en los sistemas del cliente, con los volúmenes reales | De 4 a 6 semanas en general |
| Porcentaje de expedientes procesados sin intervención | Los documentos, pedidos o solicitudes que van de la recepción al sistema del cliente sin ningún paso humano | Más del 90 % de las cotizaciones estándar en logística; alrededor del 7 % de pedidos señalados en distribución |
| Excepciones por semana | Los expedientes derivados a una persona, con su motivo: dato ausente, regla aún no escrita, caso fuera de alcance | Seguimiento interno, sirve para elegir la siguiente regla |
| Horas devueltas al equipo | El tiempo que el equipo ya no dedica al trabajo que asume el sistema | 70 % menos de introducción manual de datos en los documentos de transporte; de 80 a 90 % menos de tiempo de mediciones de tuberías |
Cuatro reglas para una medición honesta
Medir el punto de partida. Sin volúmenes ni tiempos de tramitación registrados antes del piloto, no se puede demostrar ninguna mejora. Una semana de registro suele bastar.
Contar las excepciones, no solo los éxitos. Un porcentaje de automatización sin el motivo de las excepciones no dice qué mejorar. El motivo de las excepciones orienta el trabajo de los ingenieros la semana siguiente.
Verificar la calidad por muestreo. Un sistema rápido que se equivoca cuesta más que el trabajo manual. Un control regular de una muestra por parte del responsable funcional mantiene honesta la medición.
Preferir un sistema que señala a uno que improvisa. Un sistema que rellena los huecos con una respuesta verosímil nunca dirá que el dato de partida era malo. Un sistema que rastrea cada resultado hasta su fuente (una cantidad hasta su plano, una línea de pedido hasta su correo) convierte cada malentendido en una excepción visible, corregida en la misma semana, en lugar de un error descubierto meses después.
Modelos comerciales y coste de un despliegue FDE
El coste de un despliegue FDE depende sobre todo del número de sistemas que hay que conectar y de la heterogeneidad de los documentos, mucho menos del número de usuarios. En Mirage, la estructura es la misma para todos los clientes: un piloto a precio cerrado en sitio, al final del cual el cliente puede parar, y después una suscripción anual calculada según los volúmenes procesados. Los precios parten desde 10.000 $ para el lanzamiento, y desde 1.000 $ al mes; el detalle está en la página precios.
Las cuatro formas de facturar y sus efectos
| Forma de facturación | Lo que se paga | Efecto en los incentivos del proveedor |
|---|---|---|
| Por horas (staff augmentation) | El tiempo dedicado | Ningún incentivo para terminar rápido; el riesgo queda en el cliente |
| Precio cerrado por proyecto | Un entregable definido de antemano | Incentivo para entregar lo especificado, aunque las especificaciones resulten erróneas por el camino |
| Piloto a precio cerrado y luego suscripción según volúmenes | Un primer resultado y después el trabajo realmente procesado | Incentivo para poner en producción rápido y mantener el sistema fiable en el tiempo |
| Remuneración ligada a los ahorros | Una parte de los ahorros medidos | Alineación fuerte, pero exige una medición de partida indiscutible |
Lo que hace variar el precio
Lo que más pesa es el número de sistemas que hay que conectar y su antigüedad: un ERP reciente con API se conecta en días, un software de gestión antiguo puede necesitar semanas. Después vienen la diversidad de los documentos (un único formato de orden de compra o cientos de clientes que envían cada uno el suyo), el número de centros y de idiomas, y los volúmenes procesados, que determinan la suscripción. La presencia en sitio también cuenta: una mina aislada exige más desplazamientos que una sede en el centro de una ciudad.
Comparar con el coste de no hacer nada
El punto de comparación correcto no es el precio de un software estándar, sino el coste actual del workflow: horas que dedica el equipo, errores de introducción de datos y sus consecuencias, ofertas no presentadas por falta de tiempo, retrasos en la facturación. El artículo el costo real de la entrada manual de pedidos ofrece un método de cálculo que se puede aplicar a otros workflows.
Seguridad, confidencialidad y propiedad de los datos
Un ingeniero que trabaja en sus sistemas y un agente que escribe en su ERP plantean preguntas de seguridad legítimas. Se resuelven con reglas escritas desde el piloto, y la mayoría se resuelven en una reunión con el departamento de sistemas.
Los principios que hay que exigir a cualquier proveedor FDE
| Tema | Lo que hay que obtener |
|---|---|
| Mínimo privilegio | El sistema solo accede a las fuentes necesarias para el workflow, con una cuenta dedicada y permisos por rol |
| Lectura antes que escritura | Las primeras semanas se trabaja en solo lectura; la escritura en los sistemas solo se abre cuando el responsable funcional ha validado las reglas |
| Trazabilidad | Cada acción del agente queda registrada: qué leyó, qué produjo, qué escribió y quién lo validó |
| Propiedad de los datos | Los datos siguen siendo propiedad del cliente; el contrato precisa dónde se almacenan y qué ocurre con ellos al final del contrato |
| Separación entre clientes | Lo que se reutiliza de un cliente a otro se limita al código y a los componentes genéricos, nunca a los datos |
| Lugar de alojamiento | La elección entre nube, entorno dedicado o instalación en los servidores del cliente se hace según la sensibilidad de los datos |
| Acceso de los ingenieros | Los ingenieros en sitio siguen las reglas de acceso del cliente, como un empleado o un subcontratista autorizado |
Para los entornos más sensibles (infraestructuras, defensa, centros industriales críticos), el despliegue puede hacerse sobre una infraestructura aislada, sin conexión con el exterior. La página sistemas estratégicos describe este tipo de despliegue.
Las prácticas de Mirage se describen en la página seguridad, y las condiciones propias de las grandes cuentas en la página oferta para empresas.
Cuándo el modelo FDE no es el adecuado
El forward deployed engineering cuesta más que una suscripción de software estándar y pide tiempo a los equipos del cliente. Solo se justifica si el workflow es lo bastante voluminoso, lo bastante específico y lo bastante costoso hoy. En varias situaciones habituales, otra opción funciona mejor.
| Situación | Por qué el FDE no es la opción adecuada | Mejor opción |
|---|---|---|
| El proceso es estándar y un software del mercado ya lo cubre | Pagar a ingenieros para reconstruir lo que ya existe no tiene sentido | Un software estándar, configurado por sus equipos |
| El volumen es bajo: unas decenas de documentos al mes | El ahorro no cubre el coste de conectarse a los sistemas | Una herramienta ofimática o un tratamiento manual |
| La necesidad es un análisis puntual | No habrá ningún sistema que operar | Un encargo de consultoría o un estudio |
| Nadie del lado del cliente puede decidir las reglas de negocio | El sistema aprenderá reglas adivinadas | Designar primero un responsable funcional y después empezar |
| Los datos no podrán abrirse, ni siquiera en lectura | El piloto pasará su tiempo esperando accesos | Resolver la cuestión del acceso antes de cualquier proyecto |
| El objetivo es eliminar toda intervención humana desde el principio | Las primeras semanas de producción siempre tienen excepciones | Un objetivo progresivo, medido cada semana |
| Dispone de un equipo interno capaz de construir y operar | El proveedor solo aportaría manos | La externalización de desarrolladores por horas, o un acompañamiento más ligero |
Un proveedor que acepta todos los proyectos sin hacer estas preguntas merece desconfianza. La primera reunión sirve también para decir que no cuando el workflow no se presta.
Evaluar a un proveedor FDE: las preguntas que hay que hacer
El título de forward deployed engineer se ha puesto de moda y hoy abarca oficios que no tienen casi nada en común: un preventa presente en la segunda reunión, un comercial que sabe programar, un consultor con un portátil y una orden de compra. Muchas consultoras y empresas de externalización lo han adoptado sin cambiar de modelo. Doce preguntas bastan para marcar la diferencia en una primera conversación.
| Pregunta | Lo que contiene una buena respuesta | Señal de alerta |
|---|---|---|
| ¿Qué veremos una semana después de la primera reunión? | Un resultado sobre sus propios documentos | Una demostración genérica o un documento de arranque |
| ¿Quién vendrá a nuestras instalaciones, y cuántos días por semana? | Nombres, un ritmo, los mismos ingenieros desde el principio hasta la producción | «Un consultor hará la toma de requisitos y un equipo offshore desarrollará» |
| ¿Sobre qué base técnica construyen? | Una plataforma existente, mantenida, con componentes reutilizados | Todo se desarrolla desde cero para cada cliente |
| ¿En qué sistemas se escribirá el resultado? | Sus sistemas actuales, con nombre: ERP, TMS, herramienta de presupuestos | Una pantalla nueva que sus equipos tendrán que consultar además de las que ya usan |
| ¿Cómo gestionan los casos que el sistema no sabe resolver? | Una derivación a una persona, con el motivo, y un seguimiento semanal | Una promesa de automatización al 100 % |
| ¿Qué indicadores seguirán, y desde qué punto de partida? | Indicadores operativos definidos antes del piloto | Solo hitos de entrega |
| ¿Qué pasa después de la puesta en producción? | Los mismos ingenieros siguen con el sistema y luego pasan al workflow siguiente | Un traspaso a un equipo de soporte |
| ¿Podemos parar después del piloto? | Sí, con un punto de decisión explícito | Un compromiso plurianual desde el principio |
| ¿Cómo protegen nuestros datos? | Prácticas concretas: permisos, registro de actividad, lugar de almacenamiento, fin de contrato | Generalidades tranquilizadoras sin detalle |
| ¿Podemos hablar con un cliente en producción? | Referencias de sectores cercanos, con resultados cuantificados | Solo pilotos o demostraciones |
| ¿Cómo validarán el resultado antes de la puesta en producción? | Un conjunto de casos de referencia construido con su responsable funcional, que se vuelve a ejecutar con cada cambio de regla | «Lo ajustaremos directamente en producción» |
| ¿A quién rinden cuentas sus FDE, y qué pasa con lo que construyen en nuestra empresa? | Dependen del producto; cada corrección se incorpora a la plataforma o se retira de forma deliberada | Dependen solo de ventas, o los scripts escritos en su empresa se quedan sin dueño |
La página sobre nosotros presenta Mirage, y sus casos de estudio los despliegues en producción.
El perfil de un forward deployed engineer
Un forward deployed engineer combina tres competencias que rara vez se dan juntas: la ingeniería de software de producción, la capacidad de aprender rápido un oficio que no es el suyo y la soltura ante los equipos y la dirección del cliente. Es responsable del resultado, desde la primera entrevista con un operador hasta la corrección de un incidente en producción.
La ingeniería. Escribe código de producción, diseña flujos de datos, conecta sistemas que no se pensaron para comunicarse y domina las técnicas recientes de IA: lectura de documentos, agentes, evaluación de la calidad de los resultados. También sabe cuándo una regla sencilla vale más que un modelo.
El oficio. Aprende en pocos días el vocabulario y las limitaciones de un departamento de estudios, de una explotación minera o de una agencia de transporte. Hace las preguntas que un recién contratado no se atreve a hacer, y sabe distinguir el procedimiento escrito del trabajo real.
La relación. Se gana la confianza de operadores desconfiados, entiende quién decide, presenta un compromiso a un director sin jerga y sabe decir que no a una petición que pondría el sistema en peligro. Es la competencia más difícil de contratar, y la que convierte a muchos antiguos FDE en buenos fundadores de empresas.
Los mejores equipos mezclan ingenieros que ya conocen el sector con otros que vienen de fuera. Los primeros entienden rápido el trabajo; los segundos cuestionan costumbres que ya nadie pone en duda.
El equipo de Mirage
Mirage fue fundada por dos titulados de la École Centrale Paris y cuenta con unos quince ingenieros, con base en París, Barcelona y Casablanca, que se desplazan a las instalaciones de los clientes para cada despliegue. La página equipo presenta a los fundadores, y la oferta de forward deployed engineer describe el puesto para los candidatos.
Preguntas frecuentes
¿Qué es el forward deployed engineering?
Es un modelo de entrega de software en el que los ingenieros del proveedor trabajan dentro de las operaciones del cliente. Construyen el sistema sobre sus datos y sus herramientas reales, lo ponen en producción y siguen siendo responsables de su funcionamiento después de la puesta en marcha. El forward deployed engineer (FDE) es el ingeniero que hace este trabajo.
¿Cómo se traduce forward deployed engineer al español?
La traducción más fiel es «ingeniero desplegado en el cliente». El término inglés y su abreviatura FDE siguen siendo los más usados, también en las ofertas de empleo y en las licitaciones en español.
¿Qué hace un forward deployed engineer?
Observa el trabajo de los equipos, anota las excepciones, conecta los sistemas, escribe las reglas de negocio y pone el sistema en producción. Después revisa cada semana los casos señalados con el responsable funcional y ajusta las reglas.
¿Qué diferencia hay entre un FDE y un consultor?
Un consultor suele entregar una recomendación que otra persona implementa. Un FDE construye el sistema, lo pone en producción en los sistemas del cliente y sigue siendo responsable de él mientras funcione.
¿Qué diferencia hay entre un FDE y una consultora tecnológica o un integrador?
Una consultora tecnológica o un integrador construye según unas especificaciones y entrega el sistema al departamento de sistemas tras las pruebas de aceptación. Un FDE descubre las reglas reales sobre el terreno, construye a partir de lo que observa y sigue operando el sistema después de la puesta en marcha.
¿Cuánto dura un despliegue FDE?
En Mirage, una prueba de concepto funciona sobre los documentos del cliente una semana después de la primera reunión. El primer workflow entra en producción en 4 a 6 semanas en general; un workflow que atraviesa varios sistemas o varios centros puede necesitar más.
¿Cuánto cuesta un despliegue FDE?
El precio depende sobre todo del número de sistemas que hay que conectar, de la diversidad de los documentos y de los volúmenes procesados. Mirage factura un piloto a precio cerrado, al final del cual el cliente puede parar, y después una suscripción anual calculada según los volúmenes: desde 10.000 $ para el lanzamiento, y desde 1.000 $ al mes.
¿Hacen falta datos limpios para empezar?
No. El trabajo del FDE consiste precisamente en procesar los documentos tal como llegan: escaneos, hojas de cálculo modificadas a mano, correos electrónicos. Lo que sí hace falta es acceso a esos datos, idealmente concedido antes de que empiece el piloto.
¿El forward deployed engineering sustituye a los equipos de operaciones?
No. El sistema asume el trabajo repetitivo de lectura, introducción de datos y conciliación, y deriva a una persona cada caso que requiere criterio. Los equipos conservan el control de las decisiones críticas.
¿Los ingenieros tienen que estar en las instalaciones del cliente todo el tiempo?
La presencia en sitio es intensa durante la observación, la construcción y las primeras semanas de producción, a menudo en torno a la mitad del tiempo. Después se reduce, con visitas regulares para cada nuevo workflow o cada cambio importante.
¿Qué sectores se prestan mejor al modelo FDE?
Aquellos en los que el trabajo se basa en documentos heterogéneos, reglas tácitas y varios sistemas: construcción e ingeniería, minería y canteras, transporte y logística, agroalimentación y distribución, industria manufacturera.
¿Qué pasa después de la puesta en producción?
Los ingenieros siguen con el sistema, hacen el seguimiento de las excepciones y ajustan las reglas. Cuando el workflow se considera fiable, el mismo equipo pasa al siguiente, sobre la misma plataforma.
Fuentes y alcance
Verificado el . Alcance: el modelo tal como lo practica Mirage. Las comparaciones con los demás modelos describen su forma habitual, no una empresa en particular. Cada cifra de Mirage procede del caso de estudio publicado correspondiente.
- Caso de estudio, grupo de ingeniería industrial en Marruecos: el módulo de mediciones de tuberías y el 80 a 90 % menos de tiempo de mediciones
- Caso de estudio, empresa constructora en Casablanca: los tres agentes en producción y la trazabilidad de cada medición hasta su plano
- Caso de estudio, operador logístico y minero marroquí: los cinco sistemas en producción, el 70 % menos de introducción manual de datos y el 12 % menos de diésel
- Caso de estudio, grupo de intermediación de transporte: más del 90 % de las solicitudes de cotización estándar procesadas automáticamente
- Caso de estudio, distribuidor de productos lácteos ecológicos: los 48 segundos de mediana entre el correo y el pedido listo, alrededor del 7 % de pedidos señalados
- Precios de Mirage Metrics: el piloto a precio cerrado, la suscripción según volúmenes y los precios de partida
- El equipo de Mirage Metrics: los fundadores, el tamaño del equipo y las oficinas
Relacionado en este sitio
- Forward deployed engineering en Mirage: el método y los compromisos de plazo
- La plataforma Mirage: la capa que despliegan los ingenieros
- Construir, comprar o desplegar: tres formas de llevar la IA a una operación (en inglés)
- Precios: el piloto a precio cerrado y la suscripción
- Casos de estudio: cada despliegue publicado y sus cifras
- Qué es un agente de IA: lo que el ingeniero construye en torno al modelo
- OCR vs LLM: para la lectura de documentos
- Los mejores agentes de IA para operaciones industriales: el mercado en 2026
- Ser forward deployed engineer en Mirage: el puesto y cómo presentar la candidatura
Hablar con un ingeniero de Mirage
Describa el workflow que más tiempo le cuesta: los documentos afectados, los sistemas en los que se introducen y los volúmenes por semana. Un ingeniero le responde con un plan por escrito, y una prueba de concepto sobre sus propios documentos una semana después de la primera reunión.
¿Prefiere hablarlo directamente? Reservar una llamada