Mike Howell
Especialista de Soporte Técnico de EASA

El tema para el actual año administrativo de EASA y para la convención del 2018 es “Connect to Quality”. Así como el tamaño, la estructura organizacional y los procesos de los centros de servicio miembros de EASA pueden variar ampliamente, también lo pueden hacer sus  mediciones de la calidad del producto o de la prestación del servicio. Para entender porqué no existe un modelo de enfoque rutinario para la calidad de un centro de servicio, es útil recurrir a algunos términos.

Desde comienzos de los 90, la serie de normas ISO 9000 han sido interpretadas en muchos círculos como extremadamente complejas. Sin embargo, cuando se implementan como se pretende, estas normas ayudarán a las organizaciones de cualquier tamaño a adoptar un enfoque con sentido común de prácticas empresariales sólidas con resultados mejorables. Dicho esto, las normas son un recurso valioso de referencia, se desee o no cumplir con ellas y a continuación presentamos algunos términos definidos en la ISO 9000:2015.

• Calidad: Grado en el que un conjunto de características inherentes de un objeto cumple los requisitos.
• Característica: Rasgo distintivo
• Objeto: Entidad, artículo, cualquier cosa concebible o perceptible. Ej. Un producto, servicio, proceso, persona, organización, sistema, recurso.
• Requisito: Necesidad o expectativa establecida, generalmente implícita u obligatoria.

El término calidad suele complementarse con adjetivos como pobre, buena o excelente. Si usamos la definición de calidad anteriormente descrita, queda claro que la fórmula para obtener la excelencia de la calidad puede ser muy diferente entre un centro de servicio y otro, dependiendo de las diferencias de los requisitos. 

Por ejemplo, los requisitos de un gran centro de servicio para reparar el reactor de una bomba de enfriamiento de una central de energía nuclear, pueden ser muy diferentes a los de un pequeño centro de servicio que está reparando un motor de la amasadora de una panadería. Sin embargo, ambos centros de servicio podrían suministrar el mismo nivel de calidad a sus respectivos clientes. 

En la ISO 9001:2015 se puede encontrar una guía sencilla para gestionar los requisitos. La norma simplemente requiere que la organización (centro de servicio) determine los requisitos para los productos y servicios que ofrece, los revise  y que  gestione los cambios en estos requisitos. Cada una de estas tareas se puede ampliar para mayor claridad.  

Determinación de los requisitos para los productos y servicios
Cuando determine los requisitos para los productos y servicios que serán ofrecidos a los clientes, el centro de servicio deberá asegurarse que los requisitos están definidos, incluyendo los requisitos legales/reglamentarios aplicables y cualquier requisito que el centro de servicio considere necesario. Ejemplos de requisitos reglamentarios que encontramos en los Estados Unidos incluyen los establecidos por la Occupational Safety and Health Administration (OSHA), la Mine Safety and Health Administration (MSHA), la Nuclear Regulatory Commission (NRC) o la Food and Drug Administration (FDA). Ejemplos de requisitos considerados necesarios por el centro de servicio podrían incluir los que se encuentran en la EASA AR100 y/o  en las buenas prácticas internas.

Además, el centro de servicio debe asegurarse de que puede cumplir con las demandas de los productos y servicios ofrecidos. Por ejemplo, si el centro de servicio anuncia rebobinado de estatores clase H, debe tener la capacidad para instalar un sistema de aislamiento clase H, que ha sido calificado como tal por medio de pruebas, en contraposición a un listado de materiales reunido en base a hojas de datos de materiales individuales.

Revisión de los requisitos para los productos y servicios
Antes de comprometerse a suministrar productos y servicios (aceptar una orden), el centro de servicio debe efectuar una revisión para garantizar que puede cumplir con todos los requisitos que sean aplicables. 

1. Requisitos especificados por el cliente, incluyendo requisitos de entrega y actividades posteriores a ella. Un ejemplo de este tipo de requisito es una especificación de un cliente que invoca la IEEE 522 requiriendo una capacidad para soportar impulsos de 3.5 por unidad. Este es un requisito que se debe detectar en una fase inicial para que pueda ser abordado en precio, diseño, implementación y pruebas. Otros ejemplos pueden ser tan simples como el color de la pintura o el tiempo de entrega.
2. Requisitos no establecidos por el cliente, pero necesarios para el uso especificado o previsto, si se conocen. Por ejemplo, si un cliente envía a rebobinar un motor inverter duty (apto para trabajar con  variador), la orden de compra del cliente no necesita especificar el uso de alambre inverter duty, rodamientos aislados, etc. El centro de servicio debe haber establecido métodos para la reparación de motores inverter duty, si eso se encuentra dentro del alcance de sus servicios y debe realizar las preguntas pertinentes a cerca de la instalación y aplicación antes de proceder a prestar el mejor servicio al cliente. 
3. Requisitos especificados por el centro de servicio. La mayoría de los centros de servicio tienen un tratamiento estándar de los requisitos. La fuente de los requisitos puede derivarse de diferentes áreas incluyendo, la experiencia, las mejores prácticas percibidas en la industria o la acreditación a una norma. Aunque son independientes de otros requisitos, las revisiones siempre deben buscar los requisitos contradictorios de todas las partes. 
4. Requisitos legales y reglamentarios aplicables a los productos y servicios. Dependiendo del trabajo realizado y la aplicación de la máquina, muchos requisitos legales y reglamentarios diferentes podrían ser aplicables. Muchas veces, el cliente especificará en los documentos de compra requisitos relacionados con la aplicación. Sin embargo, otras veces, el centro de servicio deberá ser informado de los requisitos relacionados con el alcance del trabajo. Por ejemplo, un servicio en particular podría requerir de un programa para entrar en espacios confinados para cumplir con los reglamentos OSHA de los Estados Unidos y es posible que el cliente no sea consciente de dicho requisito. Otro ejemplo podría ser cumplir con el National Electrical Code (NEC) o el NFPA 70 que se puede adoptar a nivel local y esto podría estar relacionado con el circuito de alimentación del motor, la puesta a tierra o algo como una ubicación peligrosa donde el motor pueda ser catalogado como UL.    
5. Requisitos de un contrato o pedido que difieren de los expresados previamente. El centro de servicio debe asegurarse que los requisitos de un contrato o pedido que difieran de aquellos expresados previamente sean resueltos. Un ejemplo de esto es un requisito de una orden de compra que difiera o que contradiga los requisitos de la solicitud de cotización original.
   Cuando el cliente no proporcione una descripción documentada de sus requisitos, haga que el cliente confirme los requisitos antes de la aceptación. La mayoría de los centros de servicio están familiarizados  con el pedido cuando el cliente llama y dice simplemente: “Venga por mi motor y repárelo”. Aunque esto es simple y le da al centro de servicio una gran libertad para escoger los procesos de reparación que debe emplear, puede haber un riesgo considerable de conflicto a la hora de la entrega (y el pago) debido a un desacuerdo en el alcance del trabajo después de realizarlo. El riesgo se puede mitigar simplemente informando al cliente del alcance de la reparación antes de proceder y solicitar su aprobación.

Conserve la información documentada de los resultados de la revisión y de los nuevos requisitos de los productos y servicios del centro de servicio. La extensión y el nivel de detalle de estos registros variarán ampliamente entre un centro de servicio y otro. 

Cambios en los requisitos de los productos y servicios
Cuando se hagan cambios en los requisitos de los productos y servicios, el centro de servicio debe asegurarse que la información documentada relevante ha sido modificada y que las personas adecuadas quedan informadas de los cambios.

Herramientas para la gestión técnica de los requisitos
Existen por ahí muchos métodos y herramientas para gestionar los requisitos. A lo mejor los centros de servicio con un programa de aseguramiento de calidad maduro pueden ser muy competentes en esto y pueden tener herramientas de software, de control de documentos, etc. que simplifican y comprueban los errores del proceso. Otros centros de servicio rara vez pueden tratar con clientes que suministran gran cantidad de especificaciones complicadas y esto puede ser un reto, especialmente cuando pocas personas deben manejar varias áreas funcionales diferentes.  

Una herramienta que puede resultar útil es una “Matriz de Trazabilidad de Requisitos” [Requirements Traceability Matrix (RTM)]. Esta es una herramienta muy utilizada en desarrollo de software y en la gestión de proyectos complejos, ya que estos proyectos son famosos por tener una gran cantidad de requisitos y muchos cambios. Si su centro de servicio tiene un desfase en esta área o ha tenido problemas con el manejo de los requisitos, un simple documento de trazabilidad puede ser valioso. La Figura 1 muestra un ejemplo de RTM.

No existe un formato establecido que se deba emplear pero vamos a discutir brevemente como se pueden utilizar las columnas mostradas en el ejemplo. 

• ID: Un campo ID de cualquier tipo normalmente es creado solo para asignar un identificador único a cada requisito. A veces simplemente se numeran como 1,2, etc. mientras otras veces se usan identificadores más sofisticados. Por ejemplo, si un centro de servicio tiene un código asociado a cada departamento, Ej. M para lo mecánico y E para lo eléctrico, se puede anteponer una M o una E a los requisitos para separarlos. 
• Requisito: El campo Requisito debe contar con información suficiente de tal forma que cualquiera que lea el documento pueda entenderlo y a su fuente de origen. Por ejemplo, si una especificación de un cliente para un rebobinado a 4000 V tiene un documento identificado como SPEC-01 Rev 3 y en la sección 5.2 de este documento existe un requisito que el aislamiento a tierra no se debe someter a un esfuerzo que supere los 65 volts/mil, entonces el campo Requisito puede contener un texto similar a “SPEC-01 Rev 3, 5.2, el aislamiento a tierra no se debe someter a un esfuerzo que supere los 65 volts/mil”.
• Estado: Un campo de estado, si se utiliza, puede tener opciones disponibles para elegir tales como: Propuesto, Aprobado, Rechazado, Implementado, Verificado o cualquier otro término que funcione para la organización que está utilizando el documento. Por ejemplo, retomando el esfuerzo al que se debe someter el aislamiento a tierra, podría ser que una vez Aprobado, se pueda enviar una hoja de datos y una Solicitud de Cotización al fabricante de bobinas y el Estado pueda cambiar a Verificado una vez se genere la hoja de fabricación y se verifique una bobina de muestra. En otro ejemplo, muchos dueños de maquinaria que producen especificaciones para la reparación de motores voluminosas, son culpables de una solicitud sin sentido como: “La reparación debe cumplir con todas las normas IEEE aplicables”. El manejo adecuado de este requisito sería emplear un estado de Rechazado que da como resultado una excepción a la especificación o que se le envíe al cliente una solicitud de clarificación al respecto. Sin embargo, si se solicita un requisito similar que nombre un documento específico o una sección del mismo, este se hace manejable. Por ejemplo, si una especificación requiere el cumplimiento de la ANSI/EASA AR100-2015, un centro de servicio debería ser capaz de determinar rápidamente cualquier problema basado en el marco o en los fundamentos de sus prácticas normales. 
• Otros campos: Campos como Implementado, Probado y Verificado se pueden utilizar como mecanismos de control para hacer un seguimiento a través de estas etapas. La información escrita en el campo puede variar dependiendo de la organización que la esté utilizando. Por ejemplo, digamos que un centro de servicio está instalando un motor y un PLC (programmable logic controller) en una aplicación de un transportador. Podría haber requisitos independientes para arrancar el transportador cuando se presiona el botón de marcha y para pararlo cuando se presiona el botón de paro. Se puede considerar que estos requisitos quedan implementados cuando se escribe la lógica en escalera y el PLC está programado. Entonces, el programa se puede probar en diferentes escenarios para asegurarse que trabaja antes de poner en marcha la aplicación. Por último, la implementación se verificará durante la puesta en marcha. Dependiendo de la naturaleza del requisito, estos campos pueden contener iníciales/fechas o referencias de otros documentos tales como planes de prueba o registros de prueba.   

Síntesis
Al final del día, la entrega de una excelente calidad se puede explicar simplemente como el cumplimento de los requisitos. Por esta razón, la gestión de estos requisitos es esencial. Donde a menudo nos metemos en problemas es cuando los requisitos son ambiguos, no se comunican a lo largo de la cadena de suministro, se ignoran o simplemente no se identifican.

La mayoría de organizaciones exitosas clasifican en orden de importancia la seguridad, la calidad, la entrega y el costo y cada uno de ellos debe tener ciertos requisitos para cada orden. Estos pueden parecer muy diferentes en dos centros de servicio que proveen una excelente calidad, pero que prestan servicios a bases de clientes distintas. Cuando nos detenemos a planificar nuestras actividades de forma adecuada, el cliente recibirá un mejor producto, muy probablemente de una manera más rentable y oportuna.

DISPONIBLE EN INGLÉS

Categories: Miscellaneous

Tags: Job requirements Quality

Rate this article:

No rating

Print