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
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:
- 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.
- 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.
- 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.
- 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.
