El problema: pilotos que funcionan pero nunca escalan
El piloto de RA funciona. Cinco dispositivos, un caso de uso, un entorno controlado, un equipo motivado corriendo la demo. La dirección lo ve. El caso se arma. El presupuesto se aprueba.
Luego el programa se frena.
Las investigaciones de Gartner y PTC apuntan a la misma conclusión: 80% de los pilotos XR empresariales no llegan a escala dentro de 18 meses. La tecnología no es la razón. La infraestructura sí.
Un piloto con cinco dispositivos y un solo caso de uso es una demostración. Prueba si la tecnología puede ejecutar la tarea. No prueba si la organización puede sostener, administrar y escalar esa tecnología en un entorno real de producción.
Son preguntas distintas. Responder la primera y asumir que la segunda ya quedó resuelta es donde desaparecen las inversiones en RA empresarial.
Qué incluye realmente la infraestructura de despliegue
La infraestructura de despliegue es el conjunto de sistemas, procesos y capacidades que mantienen en marcha un programa de RA después de que el proveedor se va.
Incluye gestión de dispositivos: enrolar, actualizar, monitorear y reemplazar hardware a escala. Incluye autoría de contenido: construir, versionar y mantener procedimientos de RA cuando cambian los procesos. Incluye capacitación de facilitadores: asegurar que las personas más cercanas a la operación sepan correr sesiones, resolver fallos y capturar retroalimentación. Incluye integración: conectar los datos de sesión de RA con MES, ERP o sistemas de calidad para que sean útiles. E incluye medición: seguir las métricas que le dicen a la dirección si el programa está funcionando.
Nada de eso es glamoroso. Nada aparece en una demo. Todo determina si el programa sobrevive al contacto con una planta real.
Las cinco brechas operativas que matan los programas de RA empresarial
No hay MDM. La administración de dispositivos móviles es la capa de infraestructura que mantiene sincronizado cada dispositivo del despliegue. Sin ella, los dispositivos corren versiones distintas de software. Las actualizaciones de contenido llegan a unos sí y a otros no. Un procedimiento cambia a nivel de ingeniería y el cambio nunca llega al piso. El programa corre con instrucciones obsoletas sin que nadie lo note.
No hay control de versiones de contenido. Los procedimientos de RA envejecen. Los procesos cambian. Las piezas se revisan. El equipo se actualiza. Sin un sistema de versionado que rastree qué versión del procedimiento está activa y empuje actualizaciones a los dispositivos, el programa opera con instrucciones que ya no coinciden con el proceso real.
No hay capacitación de facilitadores. Las personas dejan de usar sistemas que no entienden y con los que no pueden recibir ayuda. Si la única persona que sabe cómo funciona el sistema de RA es el contacto del proveedor, el programa está a un cambio de personal de fallar.
No hay mecanismo de retroalimentación. Los errores en el contenido de RA no siempre son obvios. Una anotación incorrecta, un componente mal etiquetado, una tolerancia equivocada pueden persistir en silencio hasta que alguien comete un error y lo conecta con la instrucción. Sin una ruta estructurada de retroalimentación desde el piso hacia autoría, los errores se acumulan.
No hay métricas de éxito. La dirección pierde confianza en programas que no puede medir. Si lo único disponible son logs de uso del dispositivo, el programa queda expuesto en cualquier revisión de presupuesto. Tasa de escape de defectos, tiempo de ensamble y first-pass yield son las métricas que traducen desempeño de RA a términos operativos y financieros.
Gestión de dispositivos a escala: MDM, control de versiones de contenido y ciclo de vida del hardware
Cada dispositivo de RA en un entorno industrial debe estar enrolado en un sistema MDM antes del despliegue. Microsoft Intune y VMware Workspace ONE son las plataformas estándar para gestión empresarial de dispositivos. Ambas soportan RealWear, HoloLens 2 y hardware de RA basado en Android.
MDM permite distribución centralizada de contenido: empuja una actualización de procedimiento una vez y llega a cada dispositivo enrolado. Permite monitoreo de uso: qué dispositivos se están usando, con qué frecuencia y en qué contenido. Permite bloqueo y borrado remoto si un dispositivo se pierde o se compromete. Y permite hacer cumplir configuraciones: los dispositivos quedan bloqueados a apps aprobadas y no pueden usarse para fines ajenos al trabajo.
El ciclo de vida del hardware es un requisito de planeación, no una ocurrencia tardía. Los headsets industriales de RA tienen una vida útil de tres a cinco años bajo condiciones de producción. Los ciclos de reemplazo deben presupuestarse. Debe haber dispositivos de respaldo para ventanas de mantenimiento. La degradación de batería por uso diario debe rastrearse.
Las plantas que tratan el hardware como una compra única y la infraestructura como problema de alguien más son las que terminan con programas no funcionales dos años después del despliegue.
Pipelines de autoría de contenido: el cuello de botella invisible
La autoría de contenido es la brecha de mayor riesgo en el despliegue de RA empresarial. También es la menos visible durante la fase de piloto.
Durante un piloto, el proveedor construye el contenido. Los cinco procedimientos se autoran, prueban y refinan en un cronograma controlado. Parece manejable.
A escala, con 50 procedimientos en cuatro líneas de producto, la autoría de contenido es un proceso de producción que requiere capacidad interna. Cuando un proceso cambia —y en manufactura los procesos cambian todo el tiempo— el procedimiento tiene que actualizarse antes de que la versión revisada llegue al piso. Si esa actualización depende de un ticket al proveedor y una espera de dos semanas, el programa corre con instrucciones incorrectas durante ese lapso.
La solución es capacidad interna de autoría. Alguien del equipo —ingeniería de procesos, calidad, capacitación— necesita ser dueño de la herramienta de autoría y poder hacer actualizaciones sin depender del proveedor. Eso exige seleccionar una herramienta que el equipo realmente pueda operar, entrenar a la persona autora y meter la cadencia de actualización dentro del cambio normal de procesos.
PTC Vuforia Studio y Scope AR WorkLink son las plataformas de autoría de campo actuales para RA industrial. Ambas están pensadas para personas no desarrolladoras. Ambas producen contenido que corre en las principales plataformas de hardware AR.
Gestión del cambio y adopción del personal como variables de despliegue
El predictor más fuerte de falla de un programa de RA en producción es la desconfianza del personal hacia el dispositivo.
La desconfianza crece rápido. Si el dispositivo es complicado de poner, la interacción no es clara, el contenido de RA no coincide con la tarea real o la persona operaria no ve una ventaja visible en la primera semana, deja de usarlo. Una supervisión que obliga a usarlo contra la resistencia del personal está administrando un despliegue fallido, no uno exitoso.
La adopción exige que el sistema sea claramente mejor que lo que reemplaza, desde la perspectiva de la persona usuaria, en la primera sesión. Eso significa: más rápido de poner que encontrar un binder. Más claro que un procedimiento en papel. Más rápido para completar la tarea que hacerlo sin guía.
Si esas condiciones no se cumplen, el problema de cambio no se resuelve con comunicación o mandato.
Pilotea el sistema en una tarea donde entregue valor inmediato y obvio a la persona usuaria. Construye adopción a partir de ese ancla antes de expandirte a casos más difíciles.
Construir para durabilidad: qué requiere un sistema de RA listo para producción
Un programa de RA listo para producción tiene una persona dueña del dispositivo, una persona dueña del contenido, una persona facilitadora y una persona dueña de métricas. No tienen que ser cuatro personas distintas. Sí tienen que ser roles definidos con responsabilidades definidas.
Antes del despliegue, documenta: qué dispositivos están enrolados en MDM, cuál es el proceso de actualización de contenido, quién es dueño de la autoría, cómo llega la retroalimentación del piso al equipo de autoría y qué métricas se reportarán a la dirección y con qué cadencia.
Un programa sin esas respuestas documentadas es un piloto. Un programa con ellas es infraestructura.
Conoce más sobre las capacidades de despliegue de RA de Innovation. Ve cómo la realidad mixta extiende la guía de RA hacia escenarios de experto remoto.