Desarrollo de Software Aeronáutico

Un incidente de aeronave en tierra no expone un problema de software de forma gradual. Expone si el estado de mantenimiento está actualizado, si el técnico adecuado está autorizado, si la trazabilidad de las piezas puede demostrarse y si las operaciones pueden tomar una decisión justificable antes de que desaparezca el siguiente slot de salida. Los servicios de desarrollo de software aeronáutico tienen que funcionar en ese entorno, no solo mostrar pantallas limpias en una demostración.

En el ámbito del mantenimiento, reparación y revisión (MRO) aeronáutico y las operaciones de tripulación, la pregunta clave no es si comprar una plataforma o desarrollar una aplicación. Se trata de saber qué flujos de trabajo ya están bien cubiertos por un producto contrastado, cuáles requieren una coordinación a medida y en qué casos los datos inconexos están generando riesgos operativos. La respuesta suele incluir Salesforce Service Cloud, un sistema de registro de MRO, controles de identidad, aplicaciones móviles y una capa de integración capaz de tolerar datos de origen imperfectos sin que se pierda información.

Dónde aportan valor los servicios de desarrollo de software para la aviación

El trabajo más valioso suele estar entre sistemas, más que dentro de una sola aplicación. Puede que una empresa de mantenimiento, reparación y revisión (MRO) ya cuente con un buen sistema de ejecución de mantenimiento, mientras que su equipo comercial gestiona las comunicaciones con los clientes en Salesforce y su equipo de materiales trabaja con datos de inventario independientes. El punto débil suele estar en el traspaso de información: un defecto que se retrasa cambia el plan de mantenimiento, el tiempo estimado de vuelta al servicio varía y el estado que se muestra al cliente se queda desactualizado durante horas.

Un flujo de trabajo personalizado puede hacer que esa cadena quede clara. Puede recibir un evento de mantenimiento, identificar la aeronave y el paquete de trabajo, aplicar un modelo de estado controlado, derivar las excepciones al responsable y crear un registro de la decisión con fecha y hora. Salesforce Service Cloud puede proporcionar la capa de casos y comunicaciones cuando sea lo más adecuado. La plataforma MRO sigue siendo la autoridad técnica en lo que respecta a los registros de mantenimiento. El software personalizado se encarga del flujo de trabajo que ninguno de los dos productos gestiona de forma clara.

Esa distinción es importante. Cambiar un sistema de mantenimiento, reparación y revisión (MRO) ya establecido solo para tener una mejor visión del estado del cliente suele ser un error muy caro. Crear un registro de mantenimiento aparte, fuera del sistema aprobado, es aún peor: genera una segunda versión del historial de aeronavegabilidad. La tecnología con un propósito claro implica conservar el registro oficial y, a continuación, diseñar las integraciones y la experiencia del usuario en torno a la decisión operativa que actualmente se retrasa o es propensa a errores.

Empieza por el registro regulado, no por la interfaz

El software de mantenimiento no cumple con los requisitos porque tiene un registro de auditoría. El registro de auditoría debe respaldar la obligación real de conservación de registros y los procedimientos aprobados por la organización. Según la norma 14 CFR Parte 145.219 de la FAA, un taller de reparación certificado debe conservar ciertos registros de mantenimiento durante al menos dos años. La Parte 145 de la EASA tiene sus propios requisitos de conservación y puesta en servicio, incluido el de conservar los registros durante tres años según la Parte 145.A.55. Las organizaciones que operan en varias jurisdicciones necesitan una arquitectura que pueda aplicar la norma más estricta sin tener que confiar en que los usuarios recuerden las excepciones.

Esto tiene consecuencias prácticas en el diseño. Un flujo de trabajo debería registrar quién tomó una decisión, en qué datos se basó, cuándo ocurrió y qué cambios hubo después. No debería permitir que se deduzca el estado de autorización de un técnico a partir de un nombre de usuario o de una asignación informal al equipo. Tampoco debería sobrescribir una hora estimada de finalización anterior sin conservar el código de revisión y el motivo. Y si se usa un dispositivo móvil en el hangar, el sistema necesita un comportamiento fuera de línea bien definido: qué se puede registrar localmente, qué requiere una validación en tiempo real y cómo se resuelven los conflictos cuando vuelve la conexión.

No se trata de casos aislados. Es la diferencia entre una aplicación operativa útil y un sistema que genera incidencias de auditoría cuando se reconstruye un registro meses después.

Diseña el flujo de trabajo pensando en la rendición de cuentas

Pensemos en un flujo de trabajo habitual de AOG. El departamento de Operaciones abre un incidente tras recibir un aviso de un problema técnico. El control de mantenimiento evalúa el fallo e identifica los recursos necesarios. El departamento de Materiales confirma la disponibilidad o informa de cualquier falta de existencias. Un miembro del personal certificado realiza la tarea necesaria y registra la información de alta en el sistema oficial. El departamento de Operaciones de Clientes comunica el plan revisado.

El software debería mostrar cada traspaso, pero no debería obligar a todos los participantes a usar la misma herramienta. Un técnico necesita una vista de tareas rápida y adaptada a dispositivos móviles, con el material de referencia adecuado y una acción de confirmación clara. El control de mantenimiento necesita colas de excepciones, visibilidad del tiempo transcurrido y reglas de escalado. Un responsable de TI necesita que la solución incorpore de por sí funciones de identidad, integración, retención y observabilidad, en lugar de que se añadan una vez que el flujo de trabajo ya esté en marcha.

Las métricas útiles siguen el flujo de trabajo: el tiempo que transcurre desde la creación de un incidente hasta la evaluación técnica, el tiempo de espera para la confirmación de piezas, el porcentaje de cambios de estado realizados sin código de motivo, el tiempo de recuperación tras un fallo de integración y el número de pasos de reintroducción manual de datos por paquete de trabajo. Un panel de control que solo muestra el volumen de casos no refleja las limitaciones operativas.

Salesforce es muy útil, pero no debería convertirse en el libro de contabilidad de mantenimiento

Salesforce Service Cloud suele ser una opción ideal para la atención al cliente en el sector de la aviación, la comunicación con las cuentas, los casos de garantía y la coordinación de excepciones. Su gestión de casos, la lógica de derechos, las funciones de base de conocimientos y el espacio de trabajo basado en roles pueden ofrecer a los equipos comerciales y operativos una visión compartida de cualquier incidencia activa. Salesforce Experience Cloud también puede facilitar el acceso controlado de los clientes a la información de estado cuando el modelo de datos y los permisos están bien diseñados.

No es necesariamente el lugar adecuado para almacenar el historial de mantenimiento técnico ni los controles de aeronavegabilidad realizados por los ingenieros. Esa decisión depende de la plataforma de MRO existente, los procesos de mantenimiento aprobados, la titularidad de los registros, los requisitos de validación y el volumen y la granularidad de los datos en cuestión. Salesforce puede hacer referencia a eventos de mantenimiento oficiales y ofrecer una visión útil desde el punto de vista operativo sin convertirse en un registro duplicado y sin control.

El diseño de la integración merece el mismo escrutinio que la interfaz de usuario. Las API deberían mostrar los cambios de estado con marcas de tiempo de origen e ID de correlación. Los mensajes fallidos necesitan una política de reintentos, una cola de excepciones visible y alguien responsable de corregirlos. Un procesamiento por lotes nocturno puede ser suficiente para la elaboración de informes comerciales; pero normalmente no lo es para un flujo de trabajo sobre el estado de los clientes de AOG. Por el contrario, forzar la integración en tiempo real para cada documento histórico puede aumentar los costes y los riesgos de fallo sin mejorar la toma de decisiones.

La IA debe limitarse a decisiones concretas, no a valoraciones sobre la aeronavegabilidad

La IA puede ayudar a los equipos de aviación a procesar información no estructurada, pero solo cuando el límite de la decisión es explícito. Un modelo regulado puede clasificar la correspondencia técnica que llega, extraer campos de la documentación de los proveedores para que los revise una persona, resumir un historial de caso extenso o sugerir el siguiente paso a seguir basándose en reglas documentadas. Estos usos pueden reducir el tiempo de tramitación sin permitir que un modelo tome la decisión de dar el visto bueno para el servicio.

En el caso de las operaciones reguladas, la implementación requiere algo más que una conexión modelo. Necesita entradas definidas, controles de acceso, registro de mensajes y resultados cuando sea necesario, un proceso de aprobación para las acciones derivadas y un método para evaluar la precisión comparándola con muestras operativas reales. Si una herramienta resume un evento de mantenimiento, los usuarios deben poder ver el registro original subyacente. Si una recomendación afecta a la priorización, los factores deben poder revisarse y anularse.

Aquí es también donde la ingeniería de datos cobra importancia. Los identificadores de aeronaves, los identificadores de clientes, los códigos de tareas, los números de pieza y los códigos de estación suelen variar de un sistema a otro. Un modelo acentuará esa inconsistencia si no se resuelve la cuestión de la resolución de identidades. Una capa de datos canónica y regulada, junto con una atribución clara de la responsabilidad sobre los campos clave, suele aportar más valor que añadir IA a un flujo de trabajo mal conectado.

La adopción es una cuestión de seguridad y control

Las aplicaciones de aviación fallan de forma imperceptible cuando los usuarios crean hojas de cálculo paralelas, reglas para la bandeja de entrada compartida o soluciones provisionales verbales. Ese comportamiento suele ser una señal de que el software pide demasiados datos en un momento inadecuado del proceso, oculta la excepción relevante o tarda demasiado en el dispositivo que se usa realmente en el puesto de trabajo.

Por eso, el trabajo de UX/UI debería evaluarse en función del comportamiento, no de las preferencias visuales. ¿Puede un técnico identificar la tarea asignada, la autorización necesaria y los requisitos previos que faltan sin tener que pasar por varias pantallas? ¿Puede el control de mantenimiento distinguir en cuestión de segundos una pieza retrasada de una tarea sin asignar? ¿Puede un supervisor ver qué registros están pendientes de revisión antes del cambio de turno? Reducir el tiempo de formación y evitar errores evitables al introducir datos son resultados operativos, no simples adornos de diseño.

Nuvolar aborda estos programas analizando primero el flujo de trabajo real: el sistema de registro, las personas que toman cada decisión, la documentación que requiere cada decisión y los puntos en los que los datos cambian de manos. A partir de ahí, se pueden seleccionar la configuración de Salesforce, el software a medida, los servicios de integración, los controles de datos y la IA específica para la tarea que realmente hay que realizar.

El siguiente paso útil es elegir una interrupción recurrente —un incidente AOG, una escalación de defecto aplazada o una excepción en la cualificación de la tripulación— y seguirla desde la primera señal hasta el registro final. Las lagunas revelarán si lo que hay que priorizar es un cambio de plataforma, una reparación de integración, un flujo de trabajo específico o, simplemente, una pantalla que permita a la persona adecuada actuar antes de que el calendario se convierta en un problema.