MRO en aviación: automatización a prueba de auditorías

Un avión no espera a que los sistemas desconectados se pongan al día. Cuando una discrepancia en mantenimiento de línea se convierte en un defecto diferido, la operación necesita una respuesta completa: la configuración de la aeronave, los datos de mantenimiento aprobados, el técnico cualificado, la pieza disponible, la inspección requerida y la autoridad de certificación. La automatización del MRO aeronáutico aporta valor cuando reduce el tiempo necesario para reunir esa información y actuar sobre ella sin debilitar los controles que la respaldan.

Para los directores de sistemas de información (CIO) y los responsables de aplicaciones empresariales, no se trata de sustituir todos los sistemas de mantenimiento por una amplia plataforma de flujos de trabajo. Un sistema MRO central sigue siendo el sistema de referencia para los registros técnicos, la planificación del mantenimiento, las fichas de tareas, el inventario y los datos de aeronavegabilidad, siempre que haya sido validado para esa función. La oportunidad de automatización está en los traspasos: ese trabajo que va de un departamento a otro —control de mantenimiento, almacenes, calidad, ingeniería, operaciones de tripulación y finanzas—, a menudo a través de correos electrónicos, hojas de cálculo, llamadas telefónicas y actualizaciones duplicadas.

Cómo la automatización del mantenimiento, reparación y revisión (MRO) en aviación aporta valor operativo

Los retrasos más persistentes casi nunca se deben a la propia tarea de mantenimiento. Suelen deberse a un paquete de trabajo que está a la espera de la confirmación de un componente con número de serie, a una instrucción de ingeniería que espera los datos correctos o a una revisión de calidad que no empieza hasta que alguien se da cuenta de que falta un documento escaneado.

Un programa de automatización práctico analiza estas dependencias antes de elegir la tecnología. Piensa, por ejemplo, en un flujo de trabajo para la sustitución de un componente. Se detecta un defecto a partir de una inspección móvil o de un informe operativo. El sistema clasifica el incidente, identifica la aeronave y la configuración correspondiente, crea o actualiza una orden de trabajo, comprueba la solicitud de piezas, deriva una consulta técnica cuando es necesario y señala la inspección independiente requerida. También debería indicar al responsable de mantenimiento si el problema afecta a la salida, a una revisión programada o a un límite de defectos aplazados.

Ese flujo de trabajo puede incluir una aplicación principal de MRO, un registro técnico electrónico, un software de inventario, la gestión de documentos y una plataforma de clientes u operaciones. Salesforce Service Cloud puede ofrecer una capa controlada de gestión de casos para excepciones, solicitudes de ingeniería, reclamaciones de garantía y comunicaciones con proveedores. Salesforce Field Service puede facilitar la ejecución móvil de ciertos flujos de trabajo en tierra y en línea cuando su modelo de datos se alinea deliberadamente con el registro de MRO, en lugar de tratarse como un sustituto de un sistema de aeronavegabilidad.

La métrica no se limita simplemente a las incidencias cerradas. Mide el tiempo transcurrido desde la creación del defecto hasta su resolución por parte de ingeniería, el tiempo desde la solicitud de piezas hasta la confirmación del problema, el porcentaje de paquetes de trabajo con la documentación completa en la primera revisión de calidad y el número de seguimientos manuales del estado por cada caso de avión inmovilizado. Estas métricas revelan si la automatización está eliminando las fricciones operativas o si simplemente las está trasladando a una nueva interfaz.

La automatización debe respetar la responsabilidad prevista en la Parte 145 de la EASA

La Parte 145 de la EASA no es una mera cuestión de documentación. Exige que una organización de mantenimiento autorizada controle el mantenimiento, los registros, la autorización del personal certificador y el certificado de puesta en servicio. Según el apartado 145.A.50, la automatización puede preparar las pruebas y garantizar que se cumplan las condiciones del flujo de trabajo, pero no puede sustituir el criterio ni la autorización del personal certificador.

Esa distinción define la arquitectura. Un flujo de trabajo puede impedir que una fase de lanzamiento avance hasta que se cuente con las aprobaciones necesarias de las tareas, la trazabilidad de las piezas y las pruebas de inspección. Puede comprobar que un usuario tenga un perfil de autorización actualizado antes de mostrarle la acción de lanzamiento. Puede conservar un registro de auditoría con fecha y hora, y atribuible, de los cambios, las aprobaciones y las excepciones. No debería dar por hecho automáticamente que el mantenimiento se ha completado solo porque un técnico haya marcado una tarea como finalizada en un dispositivo móvil.

El mismo principio se aplica a los operadores y talleres de reparación estadounidenses que operan bajo la normativa 14 CFR Parte 145 de la FAA. Los registros de mantenimiento deben estar completos, ser accesibles y coincidir con el trabajo realizado. Un proceso de trabajo rápido que genere registros ambiguos acaba creando problemas de cumplimiento más adelante en cuanto a la calidad, la gestión de la aeronavegabilidad continua y las auditorías de los clientes.

Incorpora los controles en el flujo de trabajo, no al margen de él

Un error muy común es automatizar el «camino normal» y dejar las excepciones en el correo electrónico. Ahí es precisamente donde se rompe la trazabilidad. El flujo de trabajo debería modelar explícitamente condiciones como un hallazgo fuera de lo habitual, una pieza con la documentación de certificación incompleta, un registro de calibración caducado, una inspección independiente obligatoria o una tarea que requiera datos aprobados por ingeniería.

Cada excepción necesita un responsable, una fecha límite, un proceso de resolución controlado y pruebas que se conserven. Por ejemplo, una discrepancia a la espera de una resolución por parte de ingeniería no debería aparecer como un caso abierto genérico. Debería incluir la matrícula de la aeronave, la referencia del paquete de trabajo, el capítulo de la ATA, la tarea afectada, la referencia a los datos de mantenimiento, la gravedad y el historial de decisiones. Ese registro permite a los equipos de calidad reconstruir por qué se tomó una decisión sin tener que pedir a tres departamentos que busquen en sus bandejas de entrada.

Aquí es donde el software a medida puede ser la solución adecuada. Las funciones de flujo de trabajo ya preparadas suelen ser suficientes para el enrutamiento estándar, las notificaciones y las solicitudes de servicio. Pero se quedan cortas cuando la organización necesita una lógica de configuración específica para cada avión, dependencias complejas entre tareas, una ejecución móvil sin conexión controlada o un modelo de datos que deba conciliar varios sistemas técnicos sin que ninguno de ellos se convierta accidentalmente en el principal.

Diseña la integración en función de la autoridad y la latencia

La cuestión no es si los sistemas pueden intercambiar datos, sino qué sistema tiene permiso para modificar qué dato y con qué rapidez debe estar disponible ese dato.

Un modelo útil asigna claramente la responsabilidad. El sistema MRO se encarga del estado de ejecución de los trabajos, los registros técnicos, el inventario serializado y los datos del programa de mantenimiento. Salesforce puede encargarse de los casos excepcionales, las comunicaciones con los clientes, las escaladas a los proveedores y los informes de nivel de servicio entre departamentos. Una capa de integración distribuye los eventos y crea referencias, en lugar de copias sin control de los registros críticos para la aeronavegabilidad.

En un flujo de trabajo con aeronaves en tierra, la latencia es clave. Un controlador de mantenimiento puede necesitar una confirmación casi en tiempo real de que un componente necesario está disponible, asignado y entregado. Por el contrario, una sincronización nocturna puede ser totalmente adecuada para los informes agregados sobre el rendimiento de los proveedores. Tratar ambos flujos de la misma manera genera o bien costes de integración innecesarios o bien retrasos operativos inaceptables.

La interfaz de usuario merece la misma atención. Los técnicos deberían ver el contexto de la tarea, la documentación necesaria y los avisos de excepciones en el orden en que realizan el trabajo. No deberían tener que navegar por una pantalla genérica de CRM diseñada para gestores de cuentas. Una capa de UX/UI diseñada específicamente para este fin puede reducir el tiempo de formación y los envíos incompletos, al limitar la pantalla a los campos y acciones relevantes para el paso de mantenimiento, al tiempo que se conserva el registro de auditoría subyacente.

Usa la IA para gestionar las pruebas, no para tomar decisiones sobre la aeronavegabilidad

La IA puede ser de ayuda cuando los datos de entrada son de gran volumen, repetitivos y requieren revisión humana. Algunos ejemplos son: extraer números de pieza y referencias de certificados de los documentos de los proveedores; clasificar las descripciones de defectos por capítulo del Código de Nomenclatura Arancelaria (ATA) para su clasificación inicial; identificar pruebas incompletas de paquetes de trabajo; y resumir un hilo largo de correspondencia técnica para un responsable de mantenimiento.

Esos son casos de uso de apoyo. Los resultados del modelo deben presentarse con referencias a las fuentes, umbrales de confianza y una acción de revisión explícita. Una extracción de un número de serie con baja confianza no puede actualizar automáticamente un registro de inventario serializado. Un modelo no debe determinar si un defecto afecta a la aeronavegabilidad, aprobar una desviación de mantenimiento ni emitir una autorización de puesta en servicio.

Para las organizaciones que usan Claude en flujos de trabajo controlados, la implementación requiere algo más que una indicación. Necesita acceso basado en roles, ámbitos de datos restringidos, normas de conservación, evaluación frente a documentos de mantenimiento representativos, registro de indicaciones y resultados cuando sea necesario, y un punto claro de aprobación humana. El RGPD también se aplica cuando los registros de trabajo, los datos de clientes o la información de los empleados entran en un proceso que utiliza IA. La minimización de datos y los controles de acceso son requisitos de diseño, no meras cláusulas legales añadidas tras la implementación.

Empieza por un traspaso que suele dar problemas

. Los grandes programas de modernización de MRO suelen perder impulso al intentar estandarizar todos los procesos antes de demostrar su valor. Un mejor punto de partida es un traspaso concreto, aunque de gran importancia: la resolución de problemas de ingeniería para casos no rutinarios, la documentación de piezas serializadas, el cierre de calidad de los paquetes de trabajo o la coordinación de la escalación de AOG.

Empieza por establecer la situación de partida. ¿Cuántas intervenciones manuales requiere el flujo de trabajo? ¿Cuánto tiempo permanece en cada cola? ¿Qué porcentaje de registros no supera la revisión de calidad en la primera pasada? ¿Qué campos o archivos adjuntos que faltan retrasan repetidamente el cierre del expediente? A continuación, automatiza los puntos de control que eliminen esos retrasos concretos.

Nuvolar aborda este trabajo como un problema de sistema, flujo de trabajo y datos, en lugar de como la implementación de una plataforma genérica. La solución no pasa por añadir más automatización a un panel de control. Se trata de que el responsable de mantenimiento pueda ver la siguiente limitación, de que el técnico pueda completar la documentación necesaria en el propio lugar de trabajo y de que el equipo de calidad pueda responder al auditor sin tener que reconstruir lo sucedido a partir de sistemas inconexos.