Control de configuración release ¡suelte las esposas!

La naturaleza cada vez más compleja y global de todos los negocios en industrias y sectores verticales, junto con los modelos de negocio de “tiempo de Internet” de fuego rápido, está impulsando un nuevo énfasis en la gestión del cambio. La capacidad de gestionar el cambio de manera eficaz se está convirtiendo en una clave diferenciadora entre los competidores, lo que permite a las organizaciones evolucionar modelos de negocio y líneas de productos, y cambiar de marcha con la rapidez suficiente para aprovechar las oportunidades de la economía actual, por delante de la competencia.

A medida que las organizaciones luchan por administrar proyectos en este entorno, la Gestión de la configuración (CM) se ha convertido en un componente cada vez más crítico, ofreciendo un marco para administrar el cambio.

La disciplina de CM consta de seis áreas de especialización definidas por EIA-649 (ANSI, 2004))

• Planificación y Gestión de CM (CMPM),
• Identificación de Configuración (CI),
• Gestión de cambios de configuración (CCM),
• Contabilidad de Estado de configuración (CSA),
• Verificación de configuración & Auditorías (CVA) y
• CM de Datos digitales.

Sin embargo, la norma ISO 10007 (ISO, 2003) agrupa a CM en cuatro clasificaciones:

• CI,
• Control de configuración (CC),
• CSA y
• Revisiones y auditorías de configuración (R&A).

(CCM y CC son idénticos para todos los propósitos prácticos, al igual que CVA y R&A.)

Tenga en cuenta que el control de configuración se analiza en este artículo. Gestión de cambios de configuración y control de cambios también son términos utilizados para describir el mismo proceso.

Muchos gerentes de proyecto perciben el control de configuración como sistemas de restricción y confinamiento, diseñados para impedir el desarrollo de productos y que generalmente afectan el calendario del proyecto de manera negativa. Desafortunadamente, con demasiada frecuencia los procesos genéricos de CC diseñados para programas grandes y complejos, como el desarrollo de armas o sistemas médicos, se imponen a otros tipos de proyectos. Estos procesos no están diseñados para satisfacer las necesidades de, por ejemplo, un esfuerzo de desarrollo web o la implementación de un nuevo producto. En última instancia, esto conduce a una intensa frustración con el proceso de CC y el efecto de “esposar”, donde los procesos no diseñados para satisfacer las necesidades del programa impactan negativamente en el progreso.

Los gerentes de proyecto implementan el control de configuración para controlar y hacer un seguimiento de los cambios. Los procesos están diseñados para garantizar que se utiliza el nivel adecuado para aprobar los cambios y que estos cambios se basan en la mejor información disponible. Los procesos proporcionan un marco para la revisión del cambio. Esto permite al equipo evaluar si la implementación del cambio es aceptable e identificar problemas potenciales de manera oportuna. Estos procesos permiten la calibración y, si es necesario, una revisión adicional.

La pregunta real no es si implementar el control de configuración, sino qué nivel de control de configuración implementar. Una organización puede requerir un paquete de control de configuración” estándar de la empresa ” en todos los proyectos. Este tipo de sistema a menudo se impone a los equipos de proyecto debido a un historial de falta de control de la configuración y el impacto financiero resultante. Los directores de proyectos, que reconocen que no funcionará un enfoque único para todos, deben demostrar que existen controles adecuados para evitar la repetición de errores del pasado.

Control de configuración en acción

El proyecto de desarrollo típico no requiere un proceso de control de configuración a nivel de un sistema de armas principal. Es importante dotar al equipo del nivel adecuado de flexibilidad y, al mismo tiempo, garantizar la existencia de un sistema de frenos y contrapesos. La clave de cualquier sistema es el esfuerzo requerido para documentar el proceso, junto con la documentación requerida por el proceso. El proceso de CC de ejemplo que se describe a continuación está diseñado para cumplir con los requisitos de un proyecto de desarrollo de aplicaciones de tamaño pequeño a mediano.

El equipo del proyecto debe analizar primero el papel apropiado del control de configuración en el proyecto. Esto, como mínimo en un proyecto de software, implicaría un tema de documentación interna de todos los archivos de código y algún tipo de documentación externa. Las áreas adicionales a cubrir incluyen los procesos de aprobación de cambios y documentación de cambios. El simple consenso de los participantes debería bastar. Por supuesto, una junta estructurada convocada regularmente es mejor.

Ahora vamos a entrar en los diferentes aspectos del proceso de Control de configuración simple.

Documentos

El Plan de Gestión de Configuración (CMP) definirá el proceso CC. En algunas aplicaciones donde el proceso CC es bastante detallado, se desarrolla un Plan de Control de Configuración (CCP). En cualquier caso, todos los procesos y procedimientos están cubiertos para realizar el control de configuración.

La documentación de cambio en sí (detallada más adelante) debe proporcionar suficiente información que se explique por sí misma hasta el punto de no requerir información adicional del originador. Esto es necesario debido a la posibilidad de que el originador no esté disponible en el momento en que se implemente el cambio.

Proceso

El proceso CC es simple (gráfico 1). Un individuo tiene una idea o encuentra un error en el sistema actual. Esta persona debe documentar sus hallazgos en una Solicitud de Cambio Empresarial (ECR), un formulario utilizado para registrar todos los errores, cambios o mejoras para el proyecto dado. La solicitud de cambio se envía a pares y supervisores para su revisión y luego se aprueba e implementa.

Anexo 1: Proceso de control de configuración simple

Documentación de cambios

La documentación de cambios es la parte más crítica de un sistema de control de configuración. El detalle de la documentación no es tan importante como la información que se documenta. Sin embargo, la información documentada, debe describir el cambio e incluir, como mínimo, la siguiente información. Los requisitos mínimos de documentación son:

por supuesto, la información contenida en la documentación, más fácil es volver a crear, recuperar, analizar y corregir. Además, esto ayudará en la documentación final para la entrega del producto.

Cuando un individuo descubre un error o un requisito en el proyecto actual, documenta el cambio requerido. Una solicitud de cambio contiene información sobre la solicitud y describe el escenario que descubrió el error, quién lo descubrió, cuándo se descubrió y las correcciones recomendadas. La solicitud también debe identificar los elementos de configuración afectados, si es posible, y colocar algún tipo de código de gravedad o prioridad para identificar cuándo debe ocurrir este cambio, si se aprueba.

Aprobación de cambios

La aprobación de cambios debe provenir de un supervisor de proyecto designado con una visión general del impacto del cambio. Una revisión por pares es un medio muy eficaz para verificar todas las facetas del cambio y asegurar que se aborden todas las áreas afectadas por el cambio. Tener el cliente de acuerdo con el cambio sería beneficioso para las mejoras. Sin embargo, en pequeños proyectos de desarrollo, la mayoría de los cambios son de tipo “corrección de errores” y el cliente no vería el impacto del cambio.

Recopilación de datos

La recopilación de datos es vital para recuperar información de elementos similares y descubrir tendencias y tendencias. Esta información debe residir electrónicamente, lo que permite una fácil recuperación de datos y manipulación de datos para contabilidad de estado y métricas. La información se puede utilizar para compilar un informe de “lecciones aprendidas”, que se distribuye en toda la organización para la mejora técnica.

Implementación de cambios.

Una vez recibidas todas las aprobaciones apropiadas, comienza la tarea de implementación. Las pruebas en cada paso de la implementación verifican que los impactos en otros aspectos del programa sean mínimos. Todas las pruebas se completan y el cambio se implementa en todo el programa.

Proceso de bucle cerrado

Un proceso de bucle cerrado en el que el originador del cambio sabrá el resultado final del cambio antes de que aparezca en el producto final es un componente clave para el éxito. Esto es válido para todo tipo de industrias, desde la construcción hasta la fabricación y el software.

Este proceso de bucle cerrado configura tableros de control con diferentes funciones en el proceso de cambio (Gráfico 2). Cada junta tiene la obligación de revisar un cambio en el contexto completo de su estatuto y de llegar a una decisión definitiva para cada cambio. Por supuesto, la junta puede requerir información adicional antes de tomar esa decisión, pero esto debe ser mínimo.

El Institute for Configuration Management (ICMHQ) enseña la metodología CMII (CMIIU) para la gestión de la configuración y ha desarrollado esta visión de un proceso de cambio de bucle cerrado. Este proceso comienza y termina con el elemento final. Tenga en cuenta que la administración de cambios de configuración aparece en tres niveles diferentes dentro del bucle. Cada área se define de manera diferente y tiene funciones y responsabilidades específicas.

• Revisión técnica: Garantiza que todas las evaluaciones detalladas y los análisis de viabilidad estén completos.
• La Junta de Revisión de Cambios (CRB): Evalúa el impacto empresarial del cambio. ¿Este cambio es válido para nuestro entorno empresarial? ¿Cumple con uno de nuestros objetivos estratégicos? ¿Encaja en nuestra declaración de visión? Con un cambio aprobado, el CRB puede o no indicar un plazo para el cambio, dependiendo de la previsión competitiva y el riesgo de negocio.
• La Junta de Implementación de Cambios (CIB) asigna la financiación necesaria y determina los plazos de implementación de cambios. Esto también incluye la asignación de efectividad para el cambio, que especifica cuándo el cambio es efectivo. La efectividad podría referirse a una fecha, construcción, número de serie o número de lote. Esto depende del elemento final.

La opción de vía rápida del bucle es donde se libera todo el dolor de CC y los propietarios pueden obtener una aprobación de cambio en minutos frente a días. La clave de esto, por supuesto, es un árbol de documentación adecuado para cada producto. Cada documento debe tener un creador y un usuario asignados. Si los cambios solo afectan a la documentación de bajo nivel, entonces la vía rápida está en orden y el cambio grita a través del proceso de CC.

Resumen

La clave para cualquier proceso de Control de configuración exitoso es la aceptación de todo el equipo del proyecto. No se debe pedir a los miembros del equipo que renuncien a su buen juicio y control por el bien de una infraestructura de gestión que no está diseñada para cumplir con los requisitos del proyecto en cuestión. Los procesos de control de configuración están diseñados para reducir el riesgo de fallas y garantizar que los entregables se cumplan a tiempo y dentro del presupuesto. Si el equipo del proyecto participa en el establecimiento del marco de Control de Configuración inicial, se acelera la participación y aceptación de todo el equipo del proyecto y la infraestructura establecida apoyará los objetivos comerciales.