Más allá de la Integridad de Datos: gestión de la cadena de información (2° parte)

¿ALCOA es suficiente?

En el sector de las Ciencias de la Vida, la integridad de los datos es un concepto muy común que a menudo se menosprecia y, de este modo, se relaciona únicamente con el sistema. Todo el mundo conoce ALCOA, pero lo que vemos es que el concepto se relaciona únicamente con el sistema. 

Atribuible: generalmente se reduce a una pista de auditoría en el  sistema que se va a probar durante la validación, en lugar de hacer un análisis serio sobre cómo y quién recibe la información; a veces la información se recoge de manera informal y después, se copia en un registro de lote (firmado y verificado) y se vuelve a copiar en el sistema de información; la cadena no siempre es demostrable. PERO existe una pista de auditoría en el sistema con pruebas significativas que lo demuestran. 

Legible: se reduce generalmente a la accesibilidad a los datos almacenados, sin pensar en el "significado de los datos".  Por ejemplo:  A menudo me he encontrado con que el registro maestro de artículos tiene códigos "parlantes", digamos 1xxx materia prima comprada, 2xxx material producido. Está claro que si mi cadena de producción (compré producto intermedio, producto acabado) cambia, la información puede quedar obsoleta y ser engañosa. Otro ejemplo para las OCM: al pertenecer a un expediente de cliente, están obligadas a utilizar diferentes proveedores (libro de pedidos); lo habitual es crear un código de artículo por artículo/proveedor/fabricante. Esta información es clara para las compras, pero es engañosa para el almacén, la planificación y la producción.

C+O+A: Contemporáneo y Original y Exacto (Accurate) es, con mucho, la pieza menos considerada de ALCOA (porque es menos técnica), pero también la más importante. A menudo, los sistemas de información son el último aspecto del proceso de información, con las actividades en papel en medio y, a veces, una correspondencia no perfecta entre la información en papel y la del sistema (y no hablo de verificación de datos o doble control, sino de diferencias entre la información en papel y la del sistema). Permítanme utilizar un ejemplo que se ha dado a menudo: durante la recepción, hay una lista de comprobación para controlar el estado del material que, por lo general, está basado en papel.  En este caso, si algo va mal, a menudo el almacén devuelve el material y abre una desviación, PERO no hace nada en el sistema ERP.  Así que el problema surge cuando el sistema APR/PQR (Annual Product Review o Product Quality Review) no muestra ninguna prueba de que se haya devuelto un lote entrante. 

La ausencia de contemporaneidad es la mayor amenaza para los sistemas de información, ya que el sistema trabaja con datos obsoletos. Ejemplos típicos son el consumo de materia prima en la producción basado en registros de lotes en papel (tras la revisión de la BR); en este punto puede haber discrepancias en las existencias. Otro ejemplo es el de los tanques en los que los lotes se mezclan al llegar: basta con que un lote entrante en el tanque ya no exista para que sea necesario consumirlo en el sistema. 

¿Cuáles son las experiencias de gobernanza digital frente a los problemas de definición de un análisis eficaz para un escenario TO BE? 

La gobernanza digital funciona a dos niveles:  

• Ayuda a las empresas a organizar el departamento de IT y a crear planes estratégicos de implantación.  

• Ayuda a las empresas a tener un flujo de procesos sincronizado del sistema de información y el flujo físico.

• "Somos diferentes de los demás"

• "Necesitamos flexibilidad"  

• 'Ya hemos completado esto y para mí es sólo práctica'".

• "Sólo necesito algunos cambios en el sistema actual"

• "Para hacer el cambio necesito más personal" 

Los 3 puntos clave son: 

• Para realizar un análisis impulsado por la base de conocimientos PQE (construida sobre 25 años y miles de proyectos), se debe ofrecer al usuario escenarios TO BE y pedirle que "olvide" la situación AS IS. El uso de una base de conocimientos también es importante para ayudar a los usuarios a comprender lo que el sistema puede hacer potencialmente. Así pues, la metodología empleada se aleja del análisis estándar AS-IS TO-BE y
• Crear grupos de trabajo multifuncionales: esto es muy útil para que la gente entienda las consecuencias de algunas actividades (que faltan). A menudo, un esfuerzo importante durante las primeras fases de un proceso puede suponer un gran ahorro (por ejemplo, es más fácil no tener una orden de compra completa cuando sólo se necesita material/servicios, pero después, finanzas debe trabajar más para la verificación de facturas, etc.).  Sólo con un equipo de análisis que abarque todo el flujo es posible comprender qué actividades son eficaces y cuáles ineficaces (y hemos encontrado muchas) o duplican esfuerzos.
• La participación de la dirección es importante porque hay que reequilibrar las cargas y los recursos: un ahorro global puede corresponder a más actividades necesarias en algunas etapas (generalmente al empezar) y menos en otras (generalmente en las etapas finales y de control).

Nunca es demasiado tarde ni demasiado pronto para iniciar una actividad de este tipo si aún no se ha completado.

Por supuesto, es mejor cuando iniciamos el análisis a partir de una solicitud específica para mejorar la eficiencia de la cadena de información; normalmente estos casos están relacionados con una necesidad de un mejor uso del sistema impulsada por: 

• Una solicitud para tener un flujo más eficiente en la cadena de información y verificar si el sistema en uso puede ser mejor utilizado (la optimización en la gestión de registro de lotes, en la programación y gestión de la producción y en la gestión de existencias son los puntos de dolor más frecuentes);
• La necesidad de impulsar la planta en una visión industria 4.0 con integración entre ERP y equipos.

Los periodos de disrupción (lanzamiento de un cambio importante necesario, cambios organizativos previstos) son los momentos temáticos en los que se debe ejecutar el análisis para solapar la cadena de suministro con la cadena de información.  

• A veces, cuando llegamos nos encontramos con que el sistema ya en uso tiene tantas criticidades que la empresa quiere entender si debe cambiar el sistema, o si los problemas radican en cómo se utiliza el sistema. Ejemplos típicos se dan en empresas en las que hay algunas plantas/filiales que tienen más dificultades para utilizar los estándares de la empresa o en pequeñas y medianas empresas en las que se subestiman los impactos organizativos. La independencia de PQE de otros proveedores es un punto clave para la corrección del análisis
• A veces la solicitud está relacionada con un proyecto ERP en curso; ocurre (sobre todo en proyectos impulsados por productos) que durante las fases finales los usuarios no ven las funcionalidades esperadas y es típico que en casos así se subestime la gestión del cambio.  Hemos visto muchos de estos proyectos y generalmente las empresas prefieren cerrar el proyecto y remediarlo después. En algunos casos el proyecto no se gestiona correctamente y es imposible saber cuándo terminará (fechas de go live forzadas, por ejemplo); en este caso es mejor hacer el análisis para entender la situación real y reembolsar o reiniciar el proyecto.
• Otros casos están relacionados con las actividades de validación: en algunos casos, la validación es el momento en el que la empresa quiere entender si el sistema puede mejorarse para cumplir los procesos GMP.

Por lo tanto, independientemente de la etapa en la que se encuentre, un análisis para trazar y sincronizar el flujo físico con la información que le aporta siempre es beneficioso. 

Consulta la primera parte del artículo aquí