Lenguaje de manufactura: ¿Cómo evitar torre de Babel?

La comunicación con los clientes puede resultar difícil; se sabe que los ingenieros de TI tienen cierta dificultad para expresarse en términos simples. En la universidad nuestros profesores nos enseñan el aspecto de negocio de TI e intentan mostrarnos cómo hablar con el cliente. Esta es una habilidad que requiere desarrollarse con la experiencia y algunos entre nosotras y nosotros lo hacen mejor que otros. Llamemos a eso “La barrera de lenguaje de TI”. Ahora bien, a mí me parece que el mundo de manufacturas ha inducido aún otra variante: la barrera de lenguaje de manufacturas.

Aunque la Sociedad Internacional de Automatización (ISA) desarrolló el estándar ISA-95 hace 20 años, Las compañías siguen hablando diferentes lenguajes de manufactura de acuerdo a su campo de actividad o el software que han empleado. De una firma a otra diferente, o de un escritorio a otro dentro de la misma compañía, a un ítem se le puede llamar de formas diferentes. Por ejemplo, un “Número de Serie” también puede ser conocido como un “Código de Barras” o “Lote” dependiendo de con qué persona hable usted. Además, la misma palabra puede tener diferentes significados cuando se hable con personas diferentes. Recuerdo alguna vez hablar con un capacitador de software de Product Lifecycle Management (PLM) acerca de un “Número de Serie”. Me tomó cierto tiempo darme cuenta de que aquello a lo que él se refería era eso que yo habría llamado “Material” con mi vocabulario de MES (Sistema de Ejecución de Manufactura), o “Definición de Material”, o “Número de Parte”…

Pueden surgir problemas al usar terminologías diferentes al inicio de un proyecto nuevo. Esto hará más lenta la conversación y añadirá confusión y malos entendidos. En el peor de los casos, esto puede llevar a un proyecto en la dirección incorrecta, poniéndolo en riesgo, especialmente cuando una barrera básica de lenguaje se agrega a la barrera del lenguaje técnico.

Yo estoy bastante sensibilizado con este tema en particular, toda vez que no hablo inglés de nacimiento. En un proyecto MES reciente con una compañía automotriz europea, que construía un nuevo sitio de fabricación en Norteamérica, volamos a la planta del cliente después de unos cuantos mes de desarrollo para la primera demostración. Conforme verificábamos algunas presentaciones y comentarios acerca de las siguientes fases del proyecto, comprendimos que una parte significativa del proceso había sido mal diseñada. En mi opinión, aquí hay algunas de las razones:

• Ausencia de una línea de producción real al momento de recolección de requerimientos (la línea ayuda al consultor a comprender el proceso de un cliente),
• Actualización constante de su nuevo proceso por parte del cliente (también debido al hecho de que la línea nueva no se había creado todavía),
• Barrera de lenguaje de manufactura,
• Barrera de lenguaje básico.

Tuvimos que acudir a la línea de producción apenas dispuesta y ver los procesos para así corregir el diseño de la solución. Esto le costó al proyecto unos cuantos días así como al equipo de desarrollo un cierto número de horas de sueño para sortear esta vicisitud de mala comunicación.

Obviamente, este caso es algo extremo; con todo, pienso que comenzar el proyecto por acordar en un vocabulario de manufactura en común habría sido una actividad en la que habría valido la pena “perder” el tiempo. Y creo que eso será valioso en proyectos futuros también, incluso en los menos riesgosos. Y entonces, la pregunta es: ¿debieran todos aprender la terminología ISA-95? Ya que este estándar abarca cada nivel de software de manufactura, esto no solo ayudaría al proyecto MES sino a cualquier integración ulterior con cualquier sistema de negocio, ejecución o control. Algunos podrán aducir, probablemente las escuelas y gurús de negocios, que es trabajo del proveedor el hacerse entender con su cliente y en consecuencia aprender a hablar el lenguaje de su cliente. Supongo que esta elección dependerá de varios parámetros, posiblemente, entre otros: el tamaño del proyecto, el número de sistemas involucrados o la disponibilidad del cliente… Porque a final de cuentas, el cliente manda.