Posts tagged ‘cambio’

Control de cambios es un término común para describir el proceso del manejo de cómo los cambios son introducidos dentro de un sistema controlado.

La mayoría de los problemas de los softwares y sistemas computarizados son introducidos cuando son efectuados cambios durante el uso de los mismos. El control de cambios es requerido para asegurar que los sistemas validados permanecen bajo control aun cuando son sometidos a cambios.

La falta de documentación y pobres testeos después de los cambios son unas de las principales observaciones de las auditorías. De ahí la importancia de disponer de un sistema de control de cambios robusto.

El proceso de control de cambios

cambio

Los sistemas computarizados no son estáticos y requieren un programa de mantenimiento robusto luego de la validación inicial. Un procedimiento de control de cambios es crítico para asegurar que los cambios son evaluados, documentados, efectuados y seguidos consistentemente a lo largo de su ciclo de vida. Este procedimiento define el proceso a seguir para evaluar la implementación de los cambios.

El proceso de control de cambios está típicamente definido por medio de la propuesta de necesidad de un cambio, la aprobación del mismo, la ejecución del cambio y la aprobación final de todas las actividades y el cierre del control de cambio.

Veamos cada una de las etapas:

  1. Cambio propuesto: el solicitante del cambio efectúa el requerimiento formal del mismo, el cual necesita ser evaluado para asegurar que es apropiado y que el cambio propuesto no impactará negativamente sobre otros aspectos o capacidades del sistema.

El cambio debe ser clasificado, por ej. de emergencia, de rutina, etc. Algunos cambios no esenciales pueden ser reunidos y ejecutados de manera conjunta. Esta clasificación indicará el ritmo de implementación y las actividades asociadas. Es esencial que el procedimiento de control de cambios provea una vía expeditiva para los cambios de emergencia. Estos cambios, frecuentemente son necesarios para corregir problemas en el software o reestablecer operaciones del proceso rápidamente. Si bien los cambios deben ser completados en un período de tiempo muy corto, deben ser implementados de forma controlada. Los cambios de emergencia deben estar sujetos a controles similares a los cambios de rutina. Sin embargo el proceso puede ser relativamente abreviado para el requerimiento del cambio, su evaluación y aprobación para asegurar que los cambios queden hechos rápidamente.

Siempre que sea posible, los cambios de emergencia deben ser testeados antes de la implementación.

Si IT no está plenamente disponible para testear las modificaciones de emergencia antes de su instalación, es crítico que se disponga de apropiados back up de archivos y programas, como también tener un plan de back out in place.

  1. Aprobación y planeamiento: Un equipo multifuncional debe determinar como el cambio podría afectar al sistema antes que el cambio sea efectuado. Este equipo debe incluir al menos al Propietario del sistema, Aseguramiento de Calidad e IT. Dependiendo del análisis de riesgo del cambio, el nivel y rigor de la documentación y los testeos a efectuar.

La aprobación para avanzar con el cambio debe ocurrir antes que cualquier cambio en el sistema sea efectuado.

En el caso de cambio de emergencia (situación urgente) un cambio podría ser aceptado antes de completar el proceso formal del control de cambio. Sin embargo, el mismo debe ser documentado de la misma forma de acuerdo a lo indicado en el procedimiento de control de cambios.

La decisión sobre si aceptar o rechazar un cambio podría ser basada en una serie de preguntas:

  • El cambio es inevitable?
  • El cambio aumenta el beneficio general de la organización?
  • El equipo está disponible para hacer tal cambio?
  • Es mejor hacer el cambio ahora o puede ser mejor diferirlo?
  • El cambio impactará otras áreas o sistemas?

La determinación del impacto ayudará a definir el nivel de testeos requeridos para el sistema.

Adicionalmente la matriz de trazabilidad (MT) es un documento que vincula formalmente los requerimientos de diseño y los testeos a través del proceso de validación.

El análisis de regresión podría indicar la funcionalidad que requiere testeos de regresión así como también un racional sólido para excluir aquellas funciones que no son impactadas por el cambio.

Los siguientes documentos deben ser evaluados para el impacto potencial debido al cambio y sus actualizaciones deberían ser planeadas si son requeridas;

  • Paquete de validación incluyendo URS, especificación de requerimiento técnico (TRS), TM, DQ, IQ, OQ, PQ y plan y reporte de validación
  • Procedimientos para el uso y mantenimiento del sistema

Los cambios deben ser planeados y ejecutados mínimamente involucrando a IT y QA y al propietario del sistema o del negocio. Los cambios deben ser comunicados a todas las áreas y funciones afectadas.

  1. Ejecución del cambio: el cambio es en esta etapa efectuado en un entorno de testeo de manera que puede ser testeado antes de la implementación en productivo. El cambio (y otros aspectos del sistema que pueden haber sido afectados) es testeado para asegurar la exactitud del sistema, confianza y asegurar una performance consistente acorde a su propósito.

El ensayo debe ser documentado y los resultados deben conducir a correcciones y testeos adicionales o confirmar que los resultados finales después del cambio son lo que se pretendía. La documentación asociada con el cambio debe ser además completada.

Los cambios deben ser inicialmente implementados lejos del entorno de producción del sistema validado. Esto asegurará que no son efectuados cambios en el entorno de producción hasta que ellos han sido completamente validados y funcionan bien.

En relación a los sistemas computarizados es recomendable tener algunos entornos virtuales como por ejemplo:

  • Entorno de desarrollo (a veces se lo llaman “sandbox” o arenero), un entorno virtual donde un código / configuración experimental toma lugar, como el configurador / desarrollador está probando diferentes soluciones haciendo testeos preliminares, etc.
  • Sistema de testeo, un entorno virtual usado para testear preliminares del sistema conducidos por IT.
  • Validación, un entorno virtual que está congelado y es representativo de producción, seteado para el testeo de validación y controlado y NO modificable a lo largo de los testeos de validación.
  • Entrenamiento, no siempre usado por todos las compañías para todos los sistemas, un entorno virtual usado para manejar entrenamientos sobre un sistema nuevo o revisado.
  • Producción, es el entorno del negocio vivo o “instancia” del sistema.

El testeo debe verificar lo siguiente:

  • La performance del sistema luego que los cambios son efectuados y que los nuevos cambios no introducen errores que mantienen el sistema fuera de la performance buscada.
  1. Aprobación final / implementación del cambio: la aprobación final para liberar la nueva versión a productivo es concedida basada sobre los resultados de testeos exitosos y luego de disponer del paquete documental completo.

Si es requerido entrenamiento, el personal afectado (por ej. Usuarios, super-users, soporte de IT) deben ser entrenados antes que ellos estén notificados para el uso del sistema o antes de la implementación del sistema en el entorno productivo.

La aprobación final es típicamente concedida por medio del propietario del sistema y aprobada por personal autorizado de QA e IT.

La nueva versión del sistema es entonces liberada para el entorno productivo.

Cuando en una auditoría es incluida la inspección de cualquier sistema computarizado utilizado para un propósito regulado, los inspectores revisan típicamente la documentación del sistema, incluyendo los registros de los cambios, como fueron evaluados y la documentación de los mismos.

Resumiendo:

El proceso de control de cambios es importante para asegurar y evitar potenciales riesgos del negocio. Un proceso de toma de decisión objetivo debe ser usado para determinar el nivel y la complejidad de los cambios propuestos. El nivel del impacto que el cambio podría tener debe ser además determinado y esto nos indicará la profundidad de los testeos y  documentación requerida.

Un proceso de control de cambios es necesario para prevenir inapropiadas modificaciones o modificaciones que conducirán a efectos adversos. Un control de cambio efectivo es un aspecto importante para mantener el estado validado de los sistemas, permitiendo continuas mejoras y previniendo gaps de compliance.

La forma en que Usted ve la situación, cómo la analiza mentalmente y las conclusiones a las que llega, determina el modo en que reacciona al cambio organizativo. Sus pensamientos pueden impulsarle a resistir o hacer que Usted acepte y apoye las nuevas medidas.

Imagen de cambio

Como es natural, los factores que configuran su pensamiento son diversos. Todas las personas interpretan los hechos basándose en la información disponible y en su experiencia, deseos, necesidades, temores, esperanzas, prejuicios y creencias. Filtrar los datos, percibir selectivamente, eligiendo aquello a lo que se prestará atención o que se ignorará es propio de la naturaleza humana. Usted pondera la información de una manera muy personal, evaluando la situación y extrayendo conclusiones que reflejan su punto de vista.

La gente desarrolla con frecuencia una mentalidad negativa basándose en una mala interpretación de las cosas, o en supuestos incorrectos, o en motivos inconfesables o en una forma de pensar equivocada en general. El cambio impacta. La organización se conmueve y cambia. Comienza la ruptura. Los empleados interpretan esta agitación de una manera tergiversada y sacan conclusiones erróneas.

El resultado es una colección de “mitos” respecto del cambio. Estos mitos siempre penetran en la conciencia de la gente y son fuente de problemas. Si Usted está pensando de una manera distorsionada, o no comprende las cosas correctamente, probablemente reaccionará de una forma inadecuada. No abordará el cambio eficazmente.

¿El resultado? Problemas innecesarios.

Es muy importante desafiar los mitos. Primero, deben ser identificados. Luego, deben ser examinados a fondo. Deben ser ponderados a partir de una visión de la realidad más objetiva, mejor informada y más amplia. Los mitos son demasiado dañinos para ignorarlos. Desmotivan a las personas y paralizan la organización.

Les propongo pensar sobre cuáles son los mitos más comunes de la gente en épocas de cambios trascendentales y turbulencia organizativa, envíennos sus comentarios aquí o a info@cgmpdoc.com, nosotros le daremos nuestro punto de vista.

Les dejo uno de los mitos a modo de ayuda:

“puedo seguir haciendo mi trabajo como hasta ahora.”

Pritchett y Pound.

Algunas personas se aferran desesperadamente al pasado. Se atan a lo que es familiar y se refugian aún más profundamente en sus cómodas rutinas para no pensar en la espeluznante idea de que tendrán que cambiar. Alguien dijo, “Ninguna organización está fastidiada como para que a alguien no le guste cómo es”. El cambio siempre significa tener que dejar algo, y cuanto mayor sea el sacrificio personal, tanto mayor será el esfuerzo necesario.

Otro motivo que explica porque la gente defiende los viejos hábitos es para mantener la estabilidad personal y sentir que se conserva el control de las cosas. Combaten el cambio por temor al futuro, no por su amor al pasado. Si la incertidumbre y la ambigüedad le provocan ansiedad, será más difícil que el “progreso” despierte su entusiasmo. Cuanto menos le guste lo imprevisible, mayor es la posibilidad que Ud. Proteja el status quo.

Un tercer grupo de gente se resiste al cambio como una forma de desquitarse. Juegan a “penalizar a la empresa” en represalia por los cambios que nos les gustan. Nos referimos aquí a la típica revancha de siempre. Y lo fascinante es observar cómo la gente está dispuesta a perjudicarse a sí misma simplemente por vengarse de la organización.

Finalmente, algunos de los que se resisten al cambio son bien intencionados, son personas que piensan que la empresa está a punto de cometer un error y tienen el valor de intentar corregirlo. Combaten el cambio porque:

  1. Están totalmente comprometidos en interés de la empresa y
  2. Tienen la capacidad suficiente para adoptar una postura determinada.

Pero, francamente, estas personas con buenas intenciones a menudo están equivocada. Al tratar de salvar a la empresa en realidad lo que hacen es perjudicarla.

Cuando una empresa inicia cambios, lo hace con una finalidad, no hay ninguna duda de que existen razones urgentes para ello. Casi siempre encontrará una explicación financiera, regulatorias, etc.  para lo que está ocurriendo. Estudie la situación:

  • ¿Hay acontecimientos externos forzando el cambio en la empresa?
  • ¿Debe tomar la organización algunas medidas desagradables para permanecer viva?
  • ¿Contribuirá un ejercicio tan duro como éste a desarrollar el músculo de la organización necesario?

Cuando los vientos del cambio golpean su empresa, he aquí un consejo para unos buenos resultados: resistir hace más daño que bien. Para empezar, si adopta una postura opositora, puede tener problemas: alguien puede acusarle de causar problemas, de entorpecer el camino hacia el progreso. Esto puede dañar su carrera.

En segundo lugar, resistirse al cambio requiere esfuerzo, y Ud. Puede hallar formas más productivas de gastar las energías.

Además, probablemente va a perder la batalla de todas maneras. Es más, aunque gane una escaramuza de vez en cuando, perderá la guerra.

En lugar de aferrarse al pasado, agárrese fuertemente al futuro.

Escrito por Price Pritchett y Ron Pound.

Les dejo una lista de 10 ítems a considerar a la hora de calificar un contratista o tercero:

1. Existencia de QAA (Quality Assurance Agreement) disponible, aprobado y en cumplimiento.

2. Sistemas de Calidad, in place y efectivos.

3. Robustez del proceso de investigación del tercero o contratista.

4. Nivel de comunicación con el laboratorio, ante inspecciones recibidas por ellos o antes eventos que pudieran suceder.

5. Perfil GMP

6. Acciones frente al mercado, por ej. freno de operaciones ante un Recall.

7. Manejo de los cambios

8. Desvíos significativos, tasa de ocurrencia, disponibilidad de los reportes requeridos para la liberación del lote.

9. Reclamos de calidad, cuan efectivo es el sistema de manejo de quejas.

10. Historia de los riesgos, hay riesgos capturados?

Uno podría establecer respecto de estos 10 ítems una clasificación de la siguiente manera:

Riesgo alto:      2 o + de estos ítems altos

Riesgo medio: 1 ítem alto o 2 o + medios

Riesgo bajo:     1 ítem medio y otro bajo.

Bueno esta es una forma de poder evaluar el nivel de riesgo de mi contratista o tercero. Esta claro que debemos efectuar una revisión de todos estos ítem y ponderarlos cuali o cuantitativamente, de manera de poder calificarlos.

Espero que les resulte útil.